On Fri, 02 Sep 2011 20:47:27 +0200, Dimitri Glazkov
<dglaz...@chromium.org> wrote:
Fear 6: Accessibility. Accessibility! Accessibility!?
I contend that the Component Model does not make accessibility any
worse. And likely the opposite.
By allowing ATs to traverse into shadow subtrees, and ensuring that
the shadow subtrees are well-behaving accessibility citizens, you
allow authors of components to encapsulate good practices and aid in
killing the "re-created poorly" anti-pattern. That's what Sencha,
SproutCore, Dijit all try to do -- and the Component Model will enable
them do this right. In fact, things like access keys or even z-index
are quite hard (impossible) to get right, unless you have something
like a well-functioning shadow DOM.
The problem is not so much that you cannot make it accessible. It is that
making it accessible is complicated for the average authors.
This leaves us with the argument of replacing semantics. Since we're
in business of sub-typing HTML elements, we don't necessarily need to
forego their semantics:
// ...
var AwesomeButton =
HTMLButtonElement.extend(awesomeButtonInitializerBag);
Element.register('x-awesome-button', AwesomeButton);
// ...
should give you a thing that behaves like a button, with the awesome
behavior added.
In the situations where existing semantics are representative, but
deficient, you are much better off replacing them anyway:
<button becomes="x-plus-one-button">+1</button>
Depending on the specifics, I suppose this might work.
What we need is not a becomes="" attribute (that renames an element and
therefore forgoes its semantics) but rather a way to get complete
control
over a semantic element and tweak aspects of it. Otherwise creating such
controls is prohibitively expensive and only useful if you have vast
resources.
I would argue that replacing is exactly the right thing to do. You are
changing an element from having some basic meaning to a more specific
meaning. Replacement seems natural and matches what authors do today.
It depends on what is exposed to assistive technolgoy and how much authors
have to implement themselves regarding e.g. keyboard accessibility. If you
get them somehow magically by using extend() you might not even need
becomes="".
Examples of elements that should not be replaced but could be changed
by a
binding: Having a sortable binding for <table>; Exposing cite="" on
<blockquote>; Turning a <select> listing countries into a map.
Great! Let's go through them:
* Sortable binding for a table is really just a table subclass with
some event listeners registered.
But how do make this work as a new element? Especially for <table> parsing
is somewhat hairy.
* Exposing cite on blockquote sounds like something CSS should do.
There's no extra behavior, and you're not really creating a new type
of element. It's just extra boxes.
There might be extra behavior, such as clicking on the <blockquote>
exposing it, or some such.
* Turning select listing countries into a map -- composition to the
rescue!:
<x-country-map>
<select>
<option>Lilliput
<option>Blefuscu
</select>
</x-country-map>
From the author's perspective, you don't actually need the select
element. If you intend to show a map on cool browsers and select on
the less cool ones, you are completely uninterested in having your
select semantics dutifully reproduced. All you need is something that
does what you need. Besides, the behavior of a map and a select are so
different than you probably would scrap the former to build the latter
anyway.
The idea is that the outcome is the same, but that the presentation is
completely different. Both controls have the same goal and semantics, just
their presentation is different. So wrapping it in a <x-country-map> does
not seem like the proper approach.
Having some way to mint custom elements as a last resort may very well
make sense too, but I think the emphasis should be on enhancing
existing elements as that is less complex (for authors anyway) and more
accessible.
Minting new elements only seems crazy and unreasonable if you can't do
it.
That's not what I said.
The thing is, today's Web apps have already retreated into the mostly
imperative world. Despite the angry rumors, the battle for markup has
been lost. Look the source and weep:
http://dev.sencha.com/deploy/touch/docs/, http://www.npr.org/webapp,
and lots, and lots of others.
However, harnessing the HTML parser to construct an object tree gives
us a new round. You don't have to think divs and spans anymore. Once
you can start viewing any functional block of your page as a custom
element, you can return to using markup as composition medium. Hell,
in this case fetching markup lazily becomes more attractive than JSON!
I don't think there is any disagreement about current practice. Heck,
maybe we do not even disagree and I just not understand it fully.
And FWIW, I do not think that has to be seen as "Decorator"
http://wiki.whatwg.org/wiki/Behavior_Attachment as for the examples I
listed
above I would expect the binding to be permanent. (I would also expect
you
could expose additional DOM members, etc.)
Right. The problem with aspects/decorators is that they are
essentially the October Revolution
(http://en.wikipedia.org/wiki/October_Revolution): we attempt to make
things better by abandoning the old ways (sub-typing, that is) that
quite obviously have flaws, and installing a whole new set of ways
that are ideal and awesome -- and full of problems yet undiscovered,
yearning to waste years of our lives. As one lolcat famously said, "do
not want".
I don't mind exploring and eventually implementing decorators as part
of the Component Model, but doing that right will be a long, long
journey -- and blocking the whole Component Model on it is _insane_.
A bunch of us actually discussed the notion of adornment (and Dominic
and I did it again this morning:
https://plus.google.com/103035368214666982008/posts/Las1CyzvBPM). The
adornment can be defined as viewing element behavior attachment as
two-phase: 1) the element exists without a behavior; and 2) the
element acquires behavior after being adorned.
The fundamental problem with adornment is generally incompatible with
how prototype inheritance (or Web platform) works. Unless you fix up
the prototype chain (and build this nastiness into Web platform), you
simply can't "upgrade" an object from being in state 1 to being state
2. That's how the whole "becomes" notion was born in the first place.
It's entirely likely that there are solutions we haven't thought of --
please chime in.
XBL was intended to be this I thought. I would be interested to hear what
Ian has to say about this.
BTW, I really ought to put this "fears" list on the Wiki.
Yeah that would probably be a good idea.
--
Anne van Kesteren
http://annevankesteren.nl/
