- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Thu, 23 Jun 2011 22:38:13 +0100
- To: "Edward O'Connor" <eoconnor@apple.com>
- Cc: public-html@w3.org
- Message-ID: <BANLkTimWqb8V-vdevdbvLiYNZ3UucYF9mQ@mail.gmail.com>
Hi Ted, * The CP as drafted doesn't provide implementers with anywhere near the level of detail needed to produce interoperable implementations. For example, what happens (to input events, to the a11y layer mapping, etc.) when multiple elements have modal="" specified? The HTML5 spec as a whole does not provide anywhere near the level of detail needed to produce interoperable implementations in regards to the a11y layer, in many instances there is simply no detail at all. hence a lack of interoperability. Case in point: http://www.html5accessibility.com/tests/placeholder-labelling.html So detail is not a pre-requisite for inclusion of features in the spec in regards to accessibility at least. It is my understanding that the spec is developed under a commit then review process, I have seen things added to the spec that changed a lot after review. it's called an iterative process right? * Authors generally turn modals on and off via script, so why have a content attribute at all? It's much less cumbersome to have some kind of direct JS API. I don't care what mechanism is used as long as the end result is focus management that does not need to be managed by the author. (think javascript alert()/confirm()) * Existing implementations of modals in the wild usually provide a mechanism for the author to shade or otherwise style the areas of the page outside of the modal. sometime, sometimes not, this is a presentation issue, best left up to the author, of course a default style may be provided, besides firefox (for example) has implemented a shading when a javascript alert() is called,. I'm sure that we could quickly throw together something that fixed the above problems with the existing CP, but we shouldn't be quickly throwing together APIs that we intend to expose to the Web. They should be designed carefully to address use cases, and that takes time. Again I make the point, no one expects implementors to take and run with the first pass at speccing the feature behaviour, its a starting point from which expert minds can develop and mature the feature until it is ready to implement. I just want to see something down on writing in the spec to get the ball rolling. regards Stevef On 23 June 2011 18:00, Edward O'Connor <eoconnor@apple.com> wrote: > Hi, > > > Can you please give insight, even in general terms, as to what is > > wrong with the current change proposal? > > Sure. Just some things off the top of my head: > > * The CP as drafted doesn't provide implementers with anywhere near the > level of detail needed to produce interoperable implementations. For > example, what happens (to input events, to the a11y layer mapping, > etc.) when multiple elements have modal="" specified? > > * Authors generally turn modals on and off via script, so why have a > content attribute at all? It's much less cumbersome to have some kind > of direct JS API. > > * Existing implementations of modals in the wild usually provide a > mechanism for the author to shade or otherwise style the areas of the > page outside of the modal. > > I'm sure that we could quickly throw together something that fixed the > above problems with the existing CP, but we shouldn't be quickly > throwing together APIs that we intend to expose to the Web. They should > be designed carefully to address use cases, and that takes time. > > > Ted > > -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Thursday, 23 June 2011 21:39:00 UTC