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 11:25:30 -0700
Message-ID: <CAJ8+GohgHL+kXUFq28z4nR=O7wTMYFKMeL5s9MQC=PB3wVXR9g@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Dimitri Glazkov <dglazkov@chromium.org>, 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>
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.

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:26:15 GMT

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