W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Sat, 3 Sep 2011 18:56:59 -0700
Message-ID: <CADh5Ky0GkGH4sJ69BeCtKojOzLZQRBu5AVLaZhmQYsYVNOp8TA@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT