- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Sat, 3 Sep 2011 18:56:59 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>, Dominic Cooney <dominicc@chromium.org>, Alex Russell <alex@dojotoolkit.org>
On Sat, Sep 3, 2011 at 12:08 PM, Ian Hickson <ian@hixie.ch> wrote: > On Fri, 2 Sep 2011, Anne van Kesteren wrote: >> >> 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. > > Exactly. This is in fact how XBL works. This is why the widgets in the > HTML spec are defined in terms of bindings -- the idea is that authors can > then provide their own alternative bindings or inherit from them. We would > provide basic bindings that they can reuse in their inheritance chain, > e.g. so that they can override just the look of the button but get all the > interactive behaviour (accessibility roles, keyboard navigation, mouse > click reactions, etc) for free. You get all of those for free with the ability to sub-type the elements, as explained elsewhere in this thread. What you also get with the Component Model vs. XBL-like bindings is the consistency of the API surface. Note: I am explicitly calling this "XBL-like", because XBL2 intentionally avoids the ability to extend a DOM element API surface with a binding -- so we're not operating in real of a currently existing spec here. But in a general XBL-like model, the problem you have is that at any given moment of time, it is unclear whether your element has a certain API or not. Consider this: in your JS application, you hold a reference to DOM element, and know for a fact it has methods/properties of some Widget binding, that's currently applied to the element. You then access an offsetWidth property on that DOM element... Pop quiz: what's the API surface of your widget now? The answer is: you can never know. The offsetWidth query could've triggered an event handler execution, which could've modified some CSS that binds that particular Widget binding to this element, unbinding it or worse yet, turning it into some other type. BOOM goes the landmine, and there you are, watching your leg fly off. That's the trouble with decorators -- they are ephemeral things that should never, _ever_ expose an API on DOM elements. Otherwise, _anytime_ you are about to access a property or call a method on a DOM element, you'd have to first do a hasBinding check on it. Show of hands -- who wants to write their code that way? If I see any, it's not for long -- those landmines will expeditiously take care of those extra limbs for you. XBL2 provides a set of machinery to make decorators, but in doing so it fails miserably at addressing the use cases that Web application and Web framework developers actually need. And that's why "XBL-like approach" is a pie-in-the-sky key phrase that should never be applied to element behavior attachment. :DG< > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Sunday, 4 September 2011 01:57:37 UTC