Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

On Fri, 02 Sep 2011 20:47:27 +0200, Dimitri Glazkov  
<dglazkov@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/

Received on Saturday, 3 September 2011 11:32:05 UTC