A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Custom Tags Analysis: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
(Created page with 'The Component_Model proposes using custom HTML tags (prefixed with <code>x-</code>) as a way to express components in markup. This is motivated by the need to provide [http:/...')
 
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
The [[Component_Model]] proposes using custom HTML tags (prefixed with <code>x-</code>) as a way to express components in markup. This is motivated by the need to provide [http://wiki.whatwg.org/wiki/Behavior_Attachment element behavior attachment]. This analysis studies the issues associated with using custom tags in HTML.
The [[Component_Model | Component Model]] proposes using custom HTML tags (prefixed with <code>x-</code>) as a way to express components in markup. This is motivated by the need to provide [http://wiki.whatwg.org/wiki/Behavior_Attachment element behavior attachment]. This analysis studies the issues associated with using custom tags in HTML.


==Accessibility==
==Accessibility==


I contend that the Component Model does not make accessibility any
The Component Model does not make accessibility any worse. Quite the opposite! By allowing ATs to traverse into shadow subtrees, and ensuring that the shadow subtrees are well-behaving accessibility citizens, it allows 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.
worse. And likely the opposite.


By allowing ATs to traverse into shadow subtrees, and ensuring that
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:
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:


<code>
<pre>
// ...
// ...
var AwesomeButton = HTMLButtonElement.extend(awesomeButtonInitializerBag);
var AwesomeButton = HTMLButtonElement.extend(awesomeButtonInitializerBag);
Element.register('x-awesome-button', AwesomeButton);
Element.register('x-awesome-button', AwesomeButton);
// ...
// ...
</pre>
</code>


should give you a thing that behaves like a button, with the awesome
should give you a thing that behaves like a button, with the awesome behavior added.
behavior added.


In the situations where existing semantics are representative, but
In the situations where existing semantics are representative, but deficient, you are much better off replacing them anyway:
deficient, you are much better off replacing them anyway:


<button becomes="x-plus-one-button">+1</button>
<code>&lt;button becomes="x-plus-one-button"&gt;+1&lt;/button&gt;</code>


==Behavior Fallback==
==Behavior Fallback==


<x-accordion></x-accordion> is no worse than <div
<code>&lt;x-accordion&gt;&lt;/x-accordion&gt;</code> is no worse than <code>&lt;div class="accordion"&gt;&lt;/div&gt;</code> in every mechanical sense. In the absence of definition for "x-accordion" (or component model support), 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.
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.
 


==Clarity==
==Clarity==


The <x-accordion> clearly identifies the type of the behavior expected
The <code>&lt;x-accordion&gt;</code> clearly identifies the type of the behavior expected from the element, and conveys element behavior attachment nicely. On the other hand, <code>&lt;div class="accordion"&gt;</code> implies decorator behavior attachement, e.g. that removing the class value (and thus turning it back into a vanilla &lt;div&gt;) 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.
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.
 


==Local Semantics==
==Local Semantics==


Well, friends -- this train had left the station a long time ago. Alex
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. The Component Model provides an explicit path ''learn'' about the need for new elements in the spec. Also, though HTML will grow new tags, it won't 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.
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.
 


==Conflicts with new HTML tags==
==Conflicts with new HTML tags==


Well, here, FTFY -- the Component Model explicitly requires prefixing
The Component Model explicitly requires prefixing all elements with <code>x-</code>, ensuring there are no conflicts.
all elements with "x-".
 


==Misuse/Abuse==
==Misuse/Abuse==


Indeed they will. I yell regularly at authors (like that old man from
Indeed, misuse and abuse will happen. It already happens all the time. 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.  
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
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.
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
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:
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>
<code>&lt;button becomes="x-awesome-button"&gt;Weee!!&lt;/button&gt;</code>


Becomes:
Becomes:


<x-awesome-button>Weee!!</x-awesome-button>
<code>&lt;x-awesome-button&gt;Weee!!&lt;/x-awesome-button&gt;</code>


As soon as:
Following [[Component_Model_Progressive_Enhancement|this algorithm]].
1) the definition of "x-awesome-button" is registered and;
2) the element is in the DOM tree.

Latest revision as of 18:23, 29 September 2011

The Component Model proposes using custom HTML tags (prefixed with x-) as a way to express components in markup. This is motivated by the need to provide element behavior attachment. This analysis studies the issues associated with using custom tags in HTML.

Accessibility

The Component Model does not make accessibility any worse. Quite the opposite! By allowing ATs to traverse into shadow subtrees, and ensuring that the shadow subtrees are well-behaving accessibility citizens, it allows 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>

Behavior Fallback

<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 support), 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.

Clarity

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.

Local Semantics

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. The Component Model provides an explicit path learn about the need for new elements in the spec. Also, though HTML will grow new tags, it won't 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.

Conflicts with new HTML tags

The Component Model explicitly requires prefixing all elements with x-, ensuring there are no conflicts.

Misuse/Abuse

Indeed, misuse and abuse will happen. It already happens all the time. 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.

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>

Following this algorithm.