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

Since Dimitri has already said everything I would, and better, I just
want to very quickly second his point about where we are today vs.
where we fear we might be: non-trivial apps have *already* given up on
HTML. Suggesting that there's an un-semantic future that will be
*caused* by the component model is to fight a battle that's already
lost.

The only question we need to answer now is: how do we repair the situation?

In spending the last 9 months thinking and working through the issues
Dimitri presents below, our strongest theory now is that there *is* a
market for semantics, that it *does* organize around winners (e.g.,
Microformats), and that we're missing a mechanism for more directly
allowing authors to express their intent at app construction time in
ways that don't either pull them fully out of markup/html (see:
Closure, GWT, etc.).

Instead of imagining total anarchy, imagine a world where something
like jquery-for-WebComponents comes along: a "winner" toolkit that a
statistically significant fraction of the web uses. Once that intent
is in markup and not code, it helps us set the agenda for the next
round of HTML's evolution.

Think of Web Components and custom elements not as (marginally) a way
to defeat HTML's semantics, but as a way for developers to get back in
touch with markup and a path for HTML's evolution that paves a
sustainable path.

The toolkits and frameworks of today are the TODO list for the current
round of HTML's evolution, and Web Components give us a better, *more*
semantic, lower-friction way to evolve in the future.

On Fri, Sep 2, 2011 at 11:47 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
> 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 19:11:47 UTC