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

Splitting off to its own thread, because this deserves a good discussion.

On Wed, Aug 31, 2011 at 12:00 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Wed, 31 Aug 2011 07:33:16 +0200, Dominic Cooney <dominicc@chromium.org>
> wrote:
>>
>> Thanks for reading this far! These proposals aren't formal or
>> detailed. I would love to get feedback as I try to nail down some
>> specifics.
>
> The basic problem with this is that you get proprietary markup going over
> the wire:
>
> http://ln.hixie.ch/?start=1064828134&count=1

FWIW, I am in total agreement with this post. If the author requires a
UA to have a proprietary parser that has its own, separate means of
producing a valid DOM tree, you are so screwed.

>
> Having said that, I am not sure what the "correct" alternative would be. XBL
> (as Ian envisioned it anyway) was meant to enhance non-proprietary markup,
> not to let authors create novel constructs. Now you cannot stop authors from
> exploring novel constructs of course, but whether we should explicitly
> endorse it is another matter.

Yes, indeed. We are at the crossroads. The Web needs element behavior
attachment (http://wiki.whatwg.org/wiki/Behavior_Attachment) and the
ability to define new types elements, yet we are really afraid of
following through with that. But... are these fears rational? Let's
examine the them in detail.


Fear 1: Fallback bogeyman cometh.

<x-accordion></x-accordion> is no worse than <div
class="accordion"></div> in every mechanical sense. In the absence of
definition for "x-accordion" (or Component Model plumbing), both mean
the same thing, both can be styled in the same way. One is
HTMLUnknownElement, the other is HTMLDivElement, and their API surface
is identical. So... no fallback problems.


Fear 2: Custom tags are confusing.

The <x-accordion> clearly identifies the type of the behavior expected
from the element, and conveys element behavior attachment nicely. On
the other hand, <div class="accordion"> implies decorator behavior
attachement, e.g. that removing the class value (and thus turning it
back into a vanilla <div>) is perfectly ok, which by the way, is
probably _not_ what the author of the Accordion component expects "in
real life". I mean, you can _make_ the author expect that, but that
seems like cruel and unusual punishment.

In other words -- it's quite the opposite. Custom tags are more
_clear_. In fact, they are as close as _saying_what_you_mean_ as it
gets.


Fear 3: Custom tags have no meaning.

Well, friends -- this train had left the station a long time ago. Alex
Russell joked once that you already totally can add custom tags in
HTML -- as long as you're Hixie. As HTML spec grows new tags, their
meaning is only captured in a written document that's meaningless to
the UAs that were built a priori. If anything, the Component Model
provides an explicit path _learn_ about the need for new elements in
the spec. Just grep the Web for "<x-" and look at the common names.

In all seriousness, I expect HTML to grow new tags, and I think it
will add a great many new things that will make authors' life easier.
I don't expect HTML to grow every element ever needed -- the long tail
is far too massive. Addressing this long tail in a local (meaningful
in your document), organized fashion is what the Component Model does.


Fear 4: Custom tags will clash with newly invented HTML tags.

Well, here, FTFY -- the Component Model explicitly requires prefixing
all elements with "x-".


Fear 5: The Author will forego well-known semantics in lieu of their
awesome custom tags.

Indeed they will. I yell regularly at authors (like that old man from
his front porch) for using divs to build buttons and links. Those
anti-patterns suck. We should not make it worse. If anything, we have
an opportunity to provide a progressive enhancement vehicle, whereby
authors can use components as a way for hiding implementation
specifics and leaving out only the commonly established semantics in
markup. Soo.. how would something like this work?

We need a way to let the authors specify a well-known element to
describe underlying semantics of their component, coincidentally
providing a proper fallback element for non-Component Model-aware UAs.
It's similar to ARIA, but the machinery is about populating the DOM
tree with the most-specific thing, while keeping markup most-generic.

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>

As soon as:
1) the definition of "x-awesome-button" is registered and;
2) the element is in the DOM tree.

I will write up the exact algorithm in a wiki shortly.

I hope this addressed our worst fears and some. I thereby declare that
we should stop being afraid and liberate ourselves from the burden of
custom tag anxiety. Long live custom tags!

:DG<

Received on Wednesday, 31 August 2011 17:29:54 UTC