W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Fri, 2 Sep 2011 11:47:27 -0700
Message-ID: <CADh5Ky3JxniX7xpaitoVx14Du9ZZoJLnfrLtddSb-uaG+Pv7gQ@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: WebApps WG <public-webapps@w3.org>, Dominic Cooney <dominicc@chromium.org>, Alex Russell <alex@dojotoolkit.org>
On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Wed, 31 Aug 2011 19:29:28 +0200, Dimitri Glazkov <dglazkov@chromium.org>
> wrote:
>>
>> To put it differently, you want to start with a well-known element in
>> markup, and, through the magic of computing, this element _becomes_
>> your component in the DOM tree. In other words, the markup:
>>
>> <button becomes="x-awesome-button">Weee!!</button>
>>
>> Becomes:
>>
>> <x-awesome-button>Weee!!</x-awesome-button>
>
> This does not work for assistive technology. That is, you would still have
> to completely implement the <button> element from scratch, including all its
> semantics such as keyboard accessibility, etc.

Ah, thanks Anne! I do indeed need to enumerate...

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.

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>

>
> 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.

>
> 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.

* 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.

* 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.

> 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.

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!

>
> 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.

BTW, I really ought to put this "fears" list on the Wiki.

:DG<

>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>
Received on Friday, 2 September 2011 18:47:54 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT