- From: Erik Arvidsson <arv@chromium.org>
- Date: Tue, 11 Oct 2011 12:41:19 -0700
- 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 UTC