Custom Tags Analysis
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.
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:
<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.
<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
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. HTML will grow new tags, but it wont 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.
The Component Model explicitly requires prefixing all elements with
x-, ensuring there are no conflicts.
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:
Following this algorithm.