- From: Dominic Cooney <dominicc@google.com>
- Date: Thu, 25 Aug 2011 15:15:43 +0900
- To: Dimitri Glazkov <dglazkov@chromium.org>
- Cc: public-webapps <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>, Alex Russell <slightlyoff@google.com>, Erik Arvidsson <arv@google.com>, MarkM Miller <erights@google.com>
On Thu, Aug 25, 2011 at 11:55 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote: > On Wed, Aug 24, 2011 at 2:44 PM, Dominic Cooney <dominicc@google.com> wrote: >> On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote: >>> All, >>> >>> Adam raises an interesting question: should we allow more than one >>> shadow DOM subtree per element? >>> >>> Background: per current design >>> (http://wiki.whatwg.org/wiki/Component_Model#Encapsulation), you can >>> only create one ShadowRoot instance per element. >>> >>> The reasoning behind this goes like this: >>> * The use cases for adding an extra shadow DOM subtree for built-in >>> elements seemed like hacks around existing limitations of the >>> elements; >>> * We give leverage to elements, allowing them to control whether their >>> shadow DOM subtrees can be extended. If the element exposes its shadow >>> subtree, then yes you can. If it don't then no you can't. >> >> What is the benefit of this leverage? Secure presentation of <input >> type="file">? Sane editing model for <textarea>? > > No, this isn't for built-in controls. If Bob builds a Foo element, he > may decide to give it a Foo.shadow accessor to let anyone muck with > its shadow DOM. That's the situation I was talking about. Got it. Note that component authors could permit extension in a controlled way by including an instance of a trivial component within the larger component with simple composition, and then expose _that_ element’s shadow root. That would permit "multiple shadows" within a component. >> >>> * Multiple shadow DOM subtrees introduce the problem of ordering, >>> where the order of rendering these trees is unknowable at the time of >>> creation, which seems like a bad thing. >>> >>> Folks who worked on this with me, I am sure I am missing a couple of >>> things here -- please chime in. >>> >>> However, allowing multiple subtrees certainly has benefits: >>> * No more explicit dead-list of elements that can't have a shadow DOM. >>> You can just create another one. >> >> This problem could be tackled without the complexity of multiple >> shadows by reducing the dead-list to zero, by defining how a shadow >> would work with <input>, <textarea>, … any HTML element we hitherto >> thought would be “dead.” > > How would you do that? I am curious. If input element creates a shadow > DOM when constructed, it can't have a shadow DOM. How can we make it > work with shadow DOM? If we decide that the element should always be presented, then the built-in shadow DOM could include a trivial descendant element that is the extension point. When the script requests a shadow root for the component, it is commuted and gets a shadow root for the extension point. If we decide that it is OK to suppress the presentation of the component, then we could imagine that these elements capture a reference to their built-in shadow root and use that. When the script requests a shadow root for the component, the element’s shadow is replaced. The implementation of the element continues to consult its captured shadow. >> Or do you mean dead-list of instances of elements, not dead-list of >> kinds of elements? > > I think you lost me here -- can you explain? There are two kinds of "dead"—dead on arrival, like <input>, <textarea>; elements that you know by looking at the tag name that can not have shadow (at least in a given implementation) because it uses a shadow. Then there are newlydeads, like: function FooElement() { // "super" initialization etc. // not dead here var shadow = new ShadowRoot(this); // 'this' is newly dead to extension via new ShadowRoot at this point } Making <input>, <textarea> etc support shadows means nothing is DOA; permitting multiple shadows means there are no newlydeads either—nothing is ever dead. Dominic > :DG< > >> >>> * More freedom for extending elements (yes, this is the opposite of >>> the single-tree control benefit above) >>> >>> Concept-wise: >>> * Multiple shadow subtrees would just be a list. >>> * The order of a list is established once and is unchangeable. How it >>> is established? I have no idea. >>> * The trees are rendered sequentially (in list order) as if they are >>> children of the hosting element. >>> >>> Security-wise, I don't see any issues off hand. >>> >>> Plumbing-wise, adding support for multiple shadow subtrees should be >>> fairly simple, provided that we solve the order problem. >>> >>> What do you think? >>> >>> :DG< >>> >> >
Received on Thursday, 25 August 2011 06:16:09 UTC