- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Wed, 31 Aug 2011 10:29:28 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: WebApps WG <public-webapps@w3.org>, Dominic Cooney <dominicc@chromium.org>, Alex Russell <alex@dojotoolkit.org>
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