Re: [whatwg] Section 1.7 abstract language
On Thu, 13 Aug 2009, Kevin Benson wrote: On Thu, Aug 13, 2009 at 10:10 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote: This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language. The phrase abstract language concerns me. It's not clear to me that a language can be abstract, nor is it clear to me what this phrase refers to, especially since it seems to be distinguished from the concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification. Perhaps there's some sort of abstract data model or information model here; but I don't believe that the word language is appropriate to describe this. Language as normally understood is a collection of actual words or symbols, written or spoken. It is not a collection of abstract concepts, at least not in any definition of the term I was able to find. http://www.google.com/search?hl=ensafe=offq=define%3Alanguageaq=foq=aqi=g10 What term would you recommend rather than language that is more understandable than data model or information model? Would vocabulary be ok? Rather than changing the word language, how about changing the the word abstract instead... ...to an adjective such as prescriptive or normative... in order to describe the usage of the word language more purposefully ? On Sat, 15 Aug 2009, Elliotte Rusty Harold wrote: Vocabulary may be an an improvement over abstract language--I'd need to think further about that--but I think Kevin's suggestion is likely better. The spec defines a language (not abstract) with two syntaxes (or dialects, or variants). The word abstract is there to lead people away from thinking of HTML as being a concrete language in the sense that, e.g., C++ is a language or BibTex is a language. I agree that abstract isn't really the right word, but omitting it I think would cause more confusion here. Vocabulary is wrong too, since it implies just a lexicon of words, rather than a grammar, content models, etc. If anyone has any ideas for a better term than abstract language that conveys all the richness that language does but without implying a syntax exists, please let me know. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r3657 - [acgiow] (2) First cut at ARIA integration.
On Sat, 22 Aug 2009 03:11:29 +0200, wha...@whatwg.org wrote: Author: ianh Date: 2009-08-21 18:11:28 -0700 (Fri, 21 Aug 2009) New Revision: 3657 Modified: index source Log: [acgiow] (2) First cut at ARIA integration. +tr + tdcodehtml/code element + tdcode title=attr-aria-role-documentdocument/code role + tdRole must be either code title=attr-aria-role-documentdocument/code or code title=attr-aria-role-applicationapplication/code This should say the body element instead. Root WAI-ARIA node the body or frameset in HTML, or the document element in all other languages. http://www.w3.org/WAI/PF/aria-implementation/#glossary -- Simon Pieters Opera Software
Re: [whatwg] Section 1.7 abstract language
On Sat, Aug 22, 2009 at 2:51 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 13 Aug 2009, Kevin Benson wrote: On Thu, Aug 13, 2009 at 10:10 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote: This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language. The phrase abstract language concerns me. It's not clear to me that a language can be abstract, nor is it clear to me what this phrase refers to, especially since it seems to be distinguished from the concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification. Perhaps there's some sort of abstract data model or information model here; but I don't believe that the word language is appropriate to describe this. Language as normally understood is a collection of actual words or symbols, written or spoken. It is not a collection of abstract concepts, at least not in any definition of the term I was able to find. http://www.google.com/search?hl=ensafe=offq=define%3Alanguageaq=foq=aqi=g10 What term would you recommend rather than language that is more understandable than data model or information model? Would vocabulary be ok? Rather than changing the word language, how about changing the the word abstract instead... ...to an adjective such as prescriptive or normative... in order to describe the usage of the word language more purposefully ? On Sat, 15 Aug 2009, Elliotte Rusty Harold wrote: Vocabulary may be an an improvement over abstract language--I'd need to think further about that--but I think Kevin's suggestion is likely better. The spec defines a language (not abstract) with two syntaxes (or dialects, or variants). The word abstract is there to lead people away from thinking of HTML as being a concrete language in the sense that, e.g., C++ is a language or BibTex is a language. I agree that abstract isn't really the right word, but omitting it I think would cause more confusion here. Vocabulary is wrong too, since it implies just a lexicon of words, rather than a grammar, content models, etc. If anyone has any ideas for a better term than abstract language that conveys all the richness that language does but without implying a syntax exists, please let me know. From reading your latest response, the applicable term that _first_ popped into my mind was: corpus (plural corpora or corpuses) http://en.wikipedia.org/wiki/Text_corpus but I'll certainly think about alternatives in the context you/ve conveyed -- -- -- -- ô¿ô¬ K e V i N /¯\
Re: [whatwg] Remove addCueRange/removeCueRanges
On Mon, Aug 17, 2009 at 8:04 PM, Max Romantschuk m...@romantschuk.fi wrote: Silvia Pfeiffer wrote: Precision is influenced more strongly by the temporal resolution of the decoding pipeline rather than the polling resolution for currentTime. I doubt the previous implementations of start and end gave you a 3 sample accurate resolution even for wav files. I'll chime in here, having done extensive work with audio and video codecs. With current codec implementations getting sample- or frame-accurate resolution is largely a pipe dream. (Outside of the realm of platforms dedicated to content production and playback.) Especially for video there can be several seconds between keyframes, frame-accurate jumps requiring complex buffering tricks. Those tricks aren't that hard, at least for Theora; we do them in Firefox. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Storage mutex
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow jor...@chromium.org wrote: First of all, I was wondering why all user prompts are specified as must release the storage mutex ( http://dev.w3.org/html5/spec/Overview.html#user-prompts). Should this really say must instead of may? IIRC (I couldn't find the original thread, unfortunately) this was added because of deadlock concerns. It seems like there might be some UA implementation specific ways this could deadlock and there is the question of whether we'd want an alert() while holding the lock to block other execution requiring the lock, but I don't see why the language should be must. For Chromium, I don't think we'll need to release the lock for any of these, unless there's some deadlock scenario I'm missing here. So if one page grabs the lock and then does an alert(), and another page in the same domain tries to get the lock, you're going to let the latter page hang until the user dismisses the alert in the first page? Given that different UAs are probably going to have other scenarios where they have to drop the lock (some of them may even be purely implementational issues), should we add some way for us to notify scripts the lock was dropped? A normal event isn't going to be of much use, since it'll fire after the scripts execution ends (so the lock would have been dropped by then anyway). A boolean doesn't seem super useful, but it's better than nothing and could help debugging. Maybe fire an exception? Are there other options? A generation counter might be useful. Lastly, is navigator.getStorageUpdates() the right name for the function that drops the lock? Why was it changed from navigator.releaseLock()? I assume we're trying to avoid the word lock, but the reason why you'd need to call a function to get updates is not clear without understanding the concept of a lock...so what's the point of making this so cryptic? Authors would be confused that there's no aquireLock() API. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Remove addCueRange/removeCueRanges
On Sat, Aug 22, 2009 at 10:49 PM, Robert O'Callahanrob...@ocallahan.org wrote: On Mon, Aug 17, 2009 at 8:04 PM, Max Romantschuk m...@romantschuk.fi wrote: Silvia Pfeiffer wrote: Precision is influenced more strongly by the temporal resolution of the decoding pipeline rather than the polling resolution for currentTime. I doubt the previous implementations of start and end gave you a 3 sample accurate resolution even for wav files. I'll chime in here, having done extensive work with audio and video codecs. With current codec implementations getting sample- or frame-accurate resolution is largely a pipe dream. (Outside of the realm of platforms dedicated to content production and playback.) Especially for video there can be several seconds between keyframes, frame-accurate jumps requiring complex buffering tricks. Those tricks aren't that hard, at least for Theora; we do them in Firefox. Xiph has spent a long time on developing libraries that make seeking simple for Ogg Theora/Vorbis and Firefox has the advantage of using these libraries. I'm sure it's possible with other codecs / containers, too. But it's not trivial. Also, I still doubt that for lossy codecs a 3 sample accurate resolution on audio can be provided reliably every single time. I would be delighted to be proven wrong. Silvia.
Re: [whatwg] Proposed changes to the History API
Justin Lebar wrote: Mike Wilson wrote: It would be interesting to see a concrete example on how you intend the dynamics of your solution to work. It would be great if you could outline the different events and method calls used (in order) to save and restore the history state object in the following situations: - doing a fresh navigation from page#1 to page#2 - going back in history from page#2 to page#1 Here's one way it could go: User was at http://google.com, types http://mozilla.com/index.html#1 into address bar. * onload * stateactivated User clicks on link with href #2 * statedeactivated (until this event is complete, document.location.hash == #1 and the pageStorage object is for the #1 state) * stateactivated (at the beginning of this event, document.location.hash == #2 and the pageStorage object is for the #2 state) User clicks back * statedeactivated (for #2) * stateactivated (for #1) Great, this seems to be exactly what I want too. In particular I note the following differences from the current spec: - events both when entering and leaving a history entry (I called them hashload and hashunload but I agree it is better to avoid hash as we also have state-only history entries) - the same processing for fresh (newly navigated to) history entries as for historical (navigated back/forward to) history entries - removal of the popstate event and exposing a read/writable state object during the whole history entry session About stateactivated naming: Activated/deactivated is a bit longish. Could - stateload/stateunload - stateenter/stateleave or others be good alternatives? Is state the desired keyword? Or should history or others be considered? Or something playing on the pageshow/pagehide naming? About pageStorage lifetime: Adding on to your description, assuming we are navigating from one page (/a) to another (/b) in history without bfcache, the following would be a suitable chain of events: - /a statedeactivated event - /a unload event - /a browser saves form fields, scrollpos, and history state obj - browser swaps out /a and loads /b - /b browser restores history state obj before any script runs - /b scripts are executed and form fields and scrollpos are restored while document content is built - /b load event - /b stateactivated event About pageStorage naming: I think page makes you think more of Document than of history entries. Looking at an overview of storage areas, ordered from large scopes down to fine-grained scopes may spawn some ideas: CURRENTLY DISCUSSED: Scope Storage area / identifier - - user agent window.localStorage browsing contextwindow.sessionStorage document- history entry window.pageStorage If anticipating there could be a future storage area per Document, naming could be something like this: ALTERNATIVE: Scope Storage area / identifier - - user agent window.localStorage browsing contextwindow.sessionStorage documentdocument.documentStorage history entry window.history.entryStorage Best regards Mike
Re: [whatwg] [html5] r3657 - [acgiow] (2) First cut at ARIA integration.
On Sat, Aug 22, 2009 at 2:16 AM, Simon Pieterssim...@opera.com wrote: On Sat, 22 Aug 2009 03:11:29 +0200, wha...@whatwg.org wrote: Author: ianh Date: 2009-08-21 18:11:28 -0700 (Fri, 21 Aug 2009) New Revision: 3657 Modified: index source Log: [acgiow] (2) First cut at ARIA integration. + tr + tdcodehtml/code element + tdcode title=attr-aria-role-documentdocument/code role + tdRole must be either code title=attr-aria-role-documentdocument/code or code title=attr-aria-role-applicationapplication/code This should say the body element instead. Root WAI-ARIA node the body or frameset in HTML, or the document element in all other languages. http://www.w3.org/WAI/PF/aria-implementation/#glossary This does not appear to be correct, though, as AT-significant elements may appear in the head. For example, title may participate (if made visible and given role=heading), and link elements similarly have a role=link automatically. ~TJ
[whatwg] Root WAI-ARIA node for HTML (was: Re: [html5] r3657 - [acgiow] (2) First cut at ARIA integration.)
On Sat, 22 Aug 2009 17:24:15 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: +tr + tdcodehtml/code element + tdcode title=attr-aria-role-documentdocument/code role + tdRole must be either code title=attr-aria-role-documentdocument/code or code title=attr-aria-role-applicationapplication/code This should say the body element instead. Root WAI-ARIA node the body or frameset in HTML, or the document element in all other languages. http://www.w3.org/WAI/PF/aria-implementation/#glossary This does not appear to be correct, though, as AT-significant elements may appear in the head. For example, title may participate (if made visible and given role=heading), and link elements similarly have a role=link automatically. I think making elements in head visible and give them specific roles is not something authors would do, nor do I see any use case for doing so. However, making the ARIA root always be the document element seems simpler to implement and specify, so maybe the ARIA spec could be changed here? -- Simon Pieters Opera Software
Re: [whatwg] Root WAI-ARIA node for HTML (was: Re: [html5] r3657 - [acgiow] (2) First cut at ARIA integration.)
On Sat, Aug 22, 2009 at 12:49 PM, Simon Pieterssim...@opera.com wrote: I think making elements in head visible and give them specific roles is not something authors would do, nor do I see any use case for doing so. However, making the ARIA root always be the document element seems simpler to implement and specify, so maybe the ARIA spec could be changed here? Even invisible links can be AT-significant, though, such as link rel=next or link rel=prev. These should, imo, be considered a part of the document just as much as a href=next-pageNext Page/a in the body is. So, yeah, agreed, the ARIA root should always default to the document root. ~TJ
[whatwg] Microdata
Based on some of the feedback on Microdata recently, e.g.: http://www.jenitennison.com/blog/node/124 ...and a number of e-mails sent to this list and the W3C lists, I am going to try some tweaks to the Microdata syntax. Google has kindly offered to provide usability testing resources so that we can try a variety of different syntaxes and see which one is easiest for authors to understand. If anyone has any concrete syntax ideas that they would like me to consider, please let me know. There's a (pretty low) limit to how many syntaxes we can perform usability tests on, though, so I won't be able to test every idea. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Microdata
On Sat, Aug 22, 2009 at 11:51 PM, Ian Hicksoni...@hixie.ch wrote: Based on some of the feedback on Microdata recently, e.g.: http://www.jenitennison.com/blog/node/124 ...and a number of e-mails sent to this list and the W3C lists, I am going to try some tweaks to the Microdata syntax. Google has kindly offered to provide usability testing resources so that we can try a variety of different syntaxes and see which one is easiest for authors to understand. If anyone has any concrete syntax ideas that they would like me to consider, please let me know. There's a (pretty low) limit to how many syntaxes we can perform usability tests on, though, so I won't be able to test every idea. This would be more than just tweaking the syntax, but I think appropriate to bring forth my CRDF proposal as a suggestion for an alternative to Microdata. For reference, the latest version of the document can be found at [1], and the discussion that has happenned about it can be found at [2]. Rather than just saying use that syntax, I'm including here what IMO are the most prominent advantages (and potential issues) of that proposal, in no particular order: + Optional use of selectors: while the ability to use selectors seems quite useful, specially to handle list or collection cases, it has been argued that users may have problems with elaborated selectors. Since the last update of the CRDF document, this is addressed with the expanded inline content model: it should possible to express with only inline CRDF, and without using selectors at all, any semantics that can be represented with RDFa, Microdata, EASE, or eRDF. In other words: while CRDF can take full benefit of selectors to make better and/or clearer documents, it can still handle most cases (those actually handled by existing solutions) without them. + Microformats mapping: for good data (specifically, all content that doesn't duplicate any singular property), CRDF allows trivially mapping Microformat-marked data to an arbitrary RDF vocabulary (or even to multiple, overlapping vocabularies), thus allowing its re-use with RDF-related tools and/or combining it with RDF data from other sources and/or marked with other syntaxes. In order to achieve 100% compatibility with Microformats.org' processing model (including any form of bad data), a minor addition to Selectors is suggested in the document, although no substantial feedback has been given on it (neither against nor in favor). + Microformats-like but decentralized: the main issue with Microformats, at least with non-widespread vocabularies, is centralization: it requires a criticall mass of use-cases to get the Microformats community to engage in the process of creating a new vocabulary. With CRDF, any author may build their own vocabulary (implementing it as a CRDF mapping to RDF) and use it on their pages. If a vocabulary later gains momentum and is adopted by a wide enough set of authors, it'd be up to the Microformats community to decide whether standarize it or not. + Prefix declarations go out of HTML: After so many discussions, namespace prefixes has been the main source of criticism against RDFa. One of these criticism is the range of technicall issues that arise from the xmlns: syntax for defining namespace prefixes (in tag-soup syntax). CRDF handles this case by taking away the responsibility of prefix declarations from HTML: having a CSS-based syntax, CRDF takes the obvious step and uses CSS's own syntax for namespace declarations. + Entirely RDF based: while this might seem a purely theoretical advantage, there is also a practical benefit: once extracted from the webpage, CRDF data can be easily combined with any already existing RDF data; and can be used with RDF-related tools. - Copy-paste brittleness: IMO, the only serious drawback from CRDF; but there are some points worth making: 1) When used inline, CRDF can achieve the same resilience than RDFa, which is quite close to Microdata's. 2) I have noticed that some browsers can manage to copy-paste CSS-styled content preserving (most of) format. It shouldn't be hard for implementors to extend such functionality to CRDF. Of course, the support for this is not consistent among browsers, and also seems to vary for different paste targets. If there is some real interest, I might do some testing with multiple browsers and paste targets (for now, I have noticed that both IE and FF preserve most CSS formatting (but not layout) when pasting to Word, but pasting to OOo Writter gets rendered with the default formatting for the tags). It would be interesting, on this aspect, to hear about browser vendors: would they be willing to extend the CSS copy-paste capabilities to CRDF if it got adopted? - Prefix-based indirection: I'd bet that there are people on this list ready to argue that namespace prefixes are a good thing; but it seems that it raises some issues, so I'll include them and share my PoV on the topic: 1) For those who care
[whatwg] HTML 5 drag and drop feedback
Hello, I recently had a chance to play around with the new HTML 5 drag and drop implementations and documented my experiences on my blog. I was advised to share the link to this mailing list as I ran into a number of setbacks and had a few comments on the problems I experienced and some proposals as to how they could be overcome. The blog post is available here: http://www.alertdebugging.com/2009/08/16/on-html-5-drag-and-drop/ . Thank you, Francisco
Re: [whatwg] Microdata
On Saturday, August 22, 2009, Eduard Pascual herenva...@gmail.com wrote: On Sat, Aug 22, 2009 at 11:51 PM, Ian Hicksoni...@hixie.ch wrote: Based on some of the feedback on Microdata recently, e.g.: http://www.jenitennison.com/blog/node/124 ...and a number of e-mails sent to this list and the W3C lists, I am going to try some tweaks to the Microdata syntax. Google has kindly offered to provide usability testing resources so that we can try a variety of different syntaxes and see which one is easiest for authors to understand. If anyone has any concrete syntax ideas that they would like me to consider, please let me know. There's a (pretty low) limit to how many syntaxes we can perform usability tests on, though, so I won't be able to test every idea. This would be more than just tweaking the syntax, but I think appropriate to bring forth my CRDF proposal as a suggestion for an alternative to Microdata. For reference, the latest version of the document can be found at [1], and the discussion that has happenned about it can be found at [2]. Rather than just saying use that syntax, I'm including here what IMO are the most prominent advantages (and potential issues) of that proposal, in no particular order: + Optional use of selectors: while the ability to use selectors seems quite useful, specially to handle list or collection cases, it has been argued that users may have problems with elaborated selectors. Since the last update of the CRDF document, this is addressed with the expanded inline content model: it should possible to express with only inline CRDF, and without using selectors at all, any semantics that can be represented with RDFa, Microdata, EASE, or eRDF. In other words: while CRDF can take full benefit of selectors to make better and/or clearer documents, it can still handle most cases (those actually handled by existing solutions) without them. + Microformats mapping: for good data (specifically, all content that doesn't duplicate any singular property), CRDF allows trivially mapping Microformat-marked data to an arbitrary RDF vocabulary (or even to multiple, overlapping vocabularies), thus allowing its re-use with RDF-related tools and/or combining it with RDF data from other sources and/or marked with other syntaxes. In order to achieve 100% compatibility with Microformats.org' processing model (including any form of bad data), a minor addition to Selectors is suggested in the document, although no substantial feedback has been given on it (neither against nor in favor). + Microformats-like but decentralized: the main issue with Microformats, at least with non-widespread vocabularies, is centralization: it requires a criticall mass of use-cases to get the Microformats community to engage in the process of creating a new vocabulary. With CRDF, any author may build their own vocabulary (implementing it as a CRDF mapping to RDF) and use it on their pages. If a vocabulary later gains momentum and is adopted by a wide enough set of authors, it'd be up to the Microformats community to decide whether standarize it or not. + Prefix declarations go out of HTML: After so many discussions, namespace prefixes has been the main source of criticism against RDFa. One of these criticism is the range of technicall issues that arise from the xmlns: syntax for defining namespace prefixes (in tag-soup syntax). CRDF handles this case by taking away the responsibility of prefix declarations from HTML: having a CSS-based syntax, CRDF takes the obvious step and uses CSS's own syntax for namespace declarations. + Entirely RDF based: while this might seem a purely theoretical advantage, there is also a practical benefit: once extracted from the webpage, CRDF data can be easily combined with any already existing RDF data; and can be used with RDF-related tools. - Copy-paste brittleness: IMO, the only serious drawback from CRDF; but there are some points worth making: 1) When used inline, CRDF can achieve the same resilience than RDFa, which is quite close to Microdata's. 2) I have noticed that some browsers can manage to copy-paste CSS-styled content preserving (most of) format. It shouldn't be hard for implementors to extend such functionality to CRDF. Of course, the support for this is not consistent among browsers, and also seems to vary for different paste targets. If there is some real interest, I might do some testing with multiple browsers and paste targets (for now, I have noticed that both IE and FF preserve most CSS formatting (but not layout) when pasting to Word, but pasting to OOo Writter gets rendered with the default formatting for the tags). It would be interesting, on this aspect, to hear about browser vendors: would they be willing to extend the CSS copy-paste capabilities to CRDF if it got adopted? - Prefix-based indirection: I'd bet that there are people on this list ready to argue that namespace
Re: [whatwg] Storage mutex
On Tue, Aug 18, 2009 at 4:26 PM, Jeremy Orlow jor...@chromium.org wrote: It's also worth noting that Chromium is probably going to need to drop the storage mutex for most if not all plugin related calls due to deadlock conditions. If there were some place to mention this as a may type thing, it'd be good, but I realize it's probably out of scope for HTML 5. Oops. The spec already does specify this behavior: http://dev.w3.org/html5/spec/Overview.html#storage-mutex On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow jor...@chromium.orgwrote: First of all, I was wondering why all user prompts are specified as must release the storage mutex ( http://dev.w3.org/html5/spec/Overview.html#user-prompts). Should this really say must instead of may? IIRC (I couldn't find the original thread, unfortunately) this was added because of deadlock concerns. It seems like there might be some UA implementation specific ways this could deadlock and there is the question of whether we'd want an alert() while holding the lock to block other execution requiring the lock, but I don't see why the language should be must. For Chromium, I don't think we'll need to release the lock for any of these, unless there's some deadlock scenario I'm missing here. So if one page grabs the lock and then does an alert(), and another page in the same domain tries to get the lock, you're going to let the latter page hang until the user dismisses the alert in the first page? Yes. And I agree this is sub-optimal, but shouldn't it be left up to the UAs what to do? I feel like this is somewhat of an odd case to begin with since alerts lock up most (all?) browsers to a varying degrees even without using localStorage. Given that different UAs are probably going to have other scenarios where they have to drop the lock (some of them may even be purely implementational issues), should we add some way for us to notify scripts the lock was dropped? A normal event isn't going to be of much use, since it'll fire after the scripts execution ends (so the lock would have been dropped by then anyway). A boolean doesn't seem super useful, but it's better than nothing and could help debugging. Maybe fire an exception? Are there other options? A generation counter might be useful. Ooo, I like that idea. When would the counter increment? It'd be nice if it didn't increment if the page did something synchronous but no one else took the lock in the mean time. Lastly, is navigator.getStorageUpdates() the right name for the function that drops the lock? Why was it changed from navigator.releaseLock()? I assume we're trying to avoid the word lock, but the reason why you'd need to call a function to get updates is not clear without understanding the concept of a lock...so what's the point of making this so cryptic? Authors would be confused that there's no aquireLock() API. Good point. But getStorageUpdates is still not the right name for it. The only way that there'd be any updates to get is if, when you call the function, someone else takes the lock and makes some updates. Maybe it should be yieldStorage (or yieldStorageMutex)? In other words, maybe the name should imply that you're allowing concurrent updates to happen?
