W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

From: Erik Arvidsson <arv@chromium.org>
Date: Tue, 11 Oct 2011 12:41:19 -0700
Message-ID: <CAJ8+GogjscdK7s-sJqG1RysmMz64PLFnEMh6Qh7qB1u1cbfbfg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Dimitri Glazkov <dglazkov@chromium.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Roland Steiner <rolandsteiner@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org, Dominic Cooney <dominicc@google.com>, Brian Kardell <bkardell@gmail.com>, "Edward O'Connor" <eoconnor@apple.com>
I think one thing that is missing from this table/proposal is how the
prototype chain is hooked up.

For the permanent case I would like to see the user defined object on
that chain.

<script>
function FancyButton () {}
// registration and whatevs
</script>

<button is=FancyButton id=b>

b.constructor === FanceButton
b.__proto__ === FancyButton.prototype
b.__proto__.__proto__ === HTMLButtonElement.prototype

erik








On Tue, Oct 11, 2011 at 12:20, Ian Hickson <ian@hixie.ch> wrote:
> On Tue, 11 Oct 2011, Dimitri Glazkov wrote:
>> On Tue, Oct 11, 2011 at 11:25 AM, Erik Arvidsson <arv@chromium.org> wrote:
>> > By splitting I meant (and I think Ian did as well) that we have
>> > decorators that does not change the interface and then we have
>> > components which can change the shadow tree and define a new interface
>> > (API).
>> >
>> > The decorators can be attached and detached at runtime using css and
>> > maybe even an imperative API. The decorators cannot change the
>> > interface.
>> >
>> > The components have to be defined before first access and elements are
>> > created tied to a specific interface.
>>
>> +1. However, Hixie just one message ago indicated that he doesn't see
>> distinction between components and decorators (or bindings). So I think
>> there's still some clarification work to do.
>
> I don't see a distinction between the word "component" and the word
> "binding". The term "binding" comes from the point of view of the linking
> of a definition to an element. The term "component" comes from the point
> of view of the definition itself. Microsoft has historically used the term
> "component" ("HTC" stands for "HTML Component"), whereas Mozilla has
> historically used the term "binding" ("XBL" stands for "(something)
> Binding Language", for various values of "something").
>
> These aren't the only terms that have been used to describe this, by the
> way. The term "behaviour" has long been used (indeed "behavior" the CSS
> property used to link to an HTC component, and was originally the property
> used to link to an XBL binding, and that term was used by the CSS working
> group to refer to the concept; e.g. "BECSS" stands for "Behavioral
> Extensions to CSS"). The CSS working group also worked on a technology
> called "Action Sheets", which is in the same space.
>
> The main development in this space recently has been the idea of the split
> Erik describes in the text quoted above. That is, that a component, or
> binding, can be an API-defining component or API-defining binding,
> permanently bound using is="" at element-creation time; and a component,
> or binding, can be a decorator component or decorator binding, bound from
> CSS (or using is="", or via an API), in a potentially transient manner,
> but not defining an API.
>
> Or to use a table:
>
>                             | Decorator binding or | Permanent binding or
>                             | decorator component  | permanent component
> -----------------------------+----------------------+----------------------
>  Can be bound at element-    |         YES          |        YES
>  creation time (is="")      |                      |
> -----------------------------+----------------------+----------------------
>  Can be bound from CSS       |         YES          |        NO
> -----------------------------+----------------------+----------------------
>  Can be bound from an API    |         YES          |        NO
> -----------------------------+----------------------+----------------------
>  Can be rebound to another   |         YES          |        NO
>  binding later              |                      |
> -----------------------------+----------------------+----------------------
>  Can have the binding        |         YES          |        NO
>  removed altogether         |                      |
> -----------------------------+----------------------+----------------------
>  Can define a shadow tree    |         YES          |        YES
> -----------------------------+----------------------+----------------------
>  Can define ARIA roles for   |         YES          |        YES
>  the element and shadow tree|                      |
> -----------------------------+----------------------+----------------------
>  Can define scope styles     |         YES          |        YES
> -----------------------------+----------------------+----------------------
>  Can define event handlers   |         YES          |        YES
> -----------------------------+----------------------+----------------------
>  Can run script from timers  |         YES          |        YES
> -----------------------------+----------------------+----------------------
>  Can manipulate the DOM via  |         YES          |        YES
>  script                     |                      |
> -----------------------------+----------------------+----------------------
>  Can define a public API     |         NO           |        YES
> -----------------------------+----------------------+----------------------
>  Must be declared in the     |         YES          |        YES
>  page before the binding    |                      |
>  can be used                |                      |
> -----------------------------+----------------------+----------------------
>
> Since these are so close to each other, I don't see much value in having
> different solutions for decorating bindings (used for presentation,
> changing what existing widgets look and feel like) vs permanent
> API-defining bindings (used to introduce new widgets). Indeed all of the
> existing solutions -- HTC, XBL (both the original version and the various
> XBL2 variants), ActionSheets, etc, can all be relatively easily
> shoe-horned into this new concept to support both transient and permanent
> bindings/components with their various subtle differences.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
Received on Tuesday, 11 October 2011 19:42:13 GMT

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