- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 11 Oct 2011 10:57:48 -0700
- To: Dimitri Glazkov <dglazkov@chromium.org>
- Cc: Erik Arvidsson <arv@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>
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 17:58:39 UTC