Re: ISSUE-133 modal-attribute - Chairs Solicit Alternate Proposals or Counter-Proposals

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