On Tue, Oct 11, 2011 at 11:25 AM, Erik Arvidsson <[email protected]> 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. <[email protected]> wrote: >> On Tue, Oct 11, 2011 at 10:01 AM, Dimitri Glazkov <[email protected]> >> wrote: >>> On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson <[email protected]> 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 >> >
