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: Dimitri Glazkov <dglazkov@chromium.org>
Date: Tue, 11 Oct 2011 11:37:06 -0700
Message-ID: <CADh5Ky2=PnLN71dCTRmXMaMpu1ARopYk8z4E4izg6Dx1Emg3Bg@mail.gmail.com>
To: Erik Arvidsson <arv@chromium.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Ian Hickson <ian@hixie.ch>, 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>
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.

:DG<

>
> erik
>
>
>
>
>
>
>
>
> On Tue, Oct 11, 2011 at 10:57, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Tue, Oct 11, 2011 at 10:01 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>>> On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson <arv@chromium.org> wrote:
>>>> Splitting this up into two different things is great.
>>>
>>> The specific meaning of "splitting up" is where the things get
>>> interesting. As far as I understand Hixie's idea, the component (which
>>> exposes API) and the binding (which supplies shadow tree) aren't
>>> coupled, which means they can share no internal state. For example,
>>> you can't close over a set of event listeners that interact with
>>> shadow DOM in a component method, because the listeners are applied
>>> separately. I don't think that's workable.
>>>
>>> It seems to me that  we should have a way to create a shadow DOM
>>> subtree inside of the component -- component's own tree (aka element
>>> behavior attachment).
>>>
>>> Then, there could be a separate method to decorate a component with
>>> one additional shadow tree using CSS (aka decorator behavior
>>> attachment).
>>>
>>> The component model is explicitly interested in the former, not the latter.
>>
>> Agreed.  Having the shadow tree entirely separate from the component
>> is explicitly bad in many cases.  It prevents you from doing native
>> implementation of many of the shadow-using HTML elements, like <video
>> controls>, which need to hook the controls markup together with the
>> scripting.
>>
>> Being able to decorate an element with a script-free shadow tree
>> declaratively might be useful, but it's separate from the component
>> use-cases.
>>
>> ~TJ
>>
>
Received on Tuesday, 11 October 2011 18:37:33 GMT

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