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