- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Tue, 11 Oct 2011 11:37:06 -0700
- 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 UTC