Re: [whatwg] Storage mutex
On Tue, Aug 18, 2009 at 4:26 PM, Jeremy Orlow 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 wrote: > On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow 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? > 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?
Re: [whatwg] Microdata
On Saturday, August 22, 2009, Eduard Pascual wrote: > On Sat, Aug 22, 2009 at 11:51 PM, Ian Hickson 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 indir
[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 Sat, Aug 22, 2009 at 11:51 PM, Ian Hickson 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 t
[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] 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 Pieters wrote: > I think making elements in 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 s can be AT-significant, though, such as or . These should, imo, be considered a part of the document just as much as Next Page in the is. So, yeah, agreed, the ARIA root should always default to the document root. ~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. wrote: + + html element + document role + Role must be either document or application This should say "the body element" instead. Root WAI-ARIA node the or 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 . For example, may participate (if made visible and given role=heading), and elements similarly have a role=link automatically. I think making elements in 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] [html5] r3657 - [acgiow] (2) First cut at ARIA integration.
On Sat, Aug 22, 2009 at 2:16 AM, Simon Pieters wrote: > On Sat, 22 Aug 2009 03:11:29 +0200, 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. > > >> + >> + html element >> + document role >> + Role must be either > title="attr-aria-role-document">document or > title="attr-aria-role-application">application > > This should say "the body element" instead. > > > Root WAI-ARIA node > > the or 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 . For example, may participate (if made visible and given role=heading), and elements similarly have a role=link automatically. ~TJ
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 - - /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] Remove addCueRange/removeCueRanges
On Sat, Aug 22, 2009 at 10:49 PM, Robert O'Callahan wrote: > On Mon, Aug 17, 2009 at 8:04 PM, Max Romantschuk 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] Storage mutex
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow 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 Mon, Aug 17, 2009 at 8:04 PM, Max Romantschuk 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] Section 1.7 "abstract language"
On Sat, Aug 22, 2009 at 2:51 AM, Ian Hickson wrote: > On Thu, 13 Aug 2009, Kevin Benson wrote: > > On Thu, Aug 13, 2009 at 10:10 PM, Ian Hickson 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=en&safe=off&q=define%3Alanguage&aq=f&oq=&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] HTML 5 Script Tag
On Fri, 14 Aug 2009, Markus Ernst wrote: > > The favored example: > > > > would actually not break pages in legacy browsers, unless their > functionality depends on the script. They would just not find and thus > not execute the script, and possibly throw "function does not exist" > errors. > > Authors are encouraged to code web pages in a way that the functionality > is provided, or at least degrades nicely, in no-script environments. So > I assume that a properly coded page would work or degrade nicely in > legacy browsers with the syntax. Anyway I am not sure about this, > as I am aware of the fact that a missing script file is not the same as > a user agent without script execution. At least the following example > would work in Firefox - if the foo() function is not defined, > otherpage.php will be called: > > Click here We could indeed add a new feature in this way. However, we're trying to limit the number of redundant features we add, because each such feature increases the complexity of the platform overall. On Fri, 14 Aug 2009, Cready, James wrote: > > > > Generally speaking I think we should avoid making the platform have > > too many redundant features, however illogical some of them might be. > > == == These are not the same. > == == These are really not the same. > == > == > == These are again very different. > == (if it was allowed inside ) These are close to the same, and they're not alone in being rather redundant -- , , , etc. (This is why I'd really rather not have to introduce another , despite the problems with .) This is something we're trying to avoid. > > I agree that some people expect this. I don't think that making it > > work with exactly one element and dependent on the presence of an > > attribute is the way to improve this situation, however. > > It already works this way. The browser ignores everything inside the > tag the moment you put these three letters inside the brackets: > "src" You still can't omit the , though. That's what I meant. -- 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, 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. + + html element + document role + Role must be either title="attr-aria-role-document">document or title="attr-aria-role-application">application This should say "the body element" instead. Root WAI-ARIA node the or in HTML, or the document element in all other languages. http://www.w3.org/WAI/PF/aria-implementation/#glossary -- Simon Pieters Opera Software
