- From: Dominic Cooney <dominicc@google.com>
- Date: Thu, 25 Aug 2011 06:44:53 +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 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>? > * 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.” Or do you mean dead-list of instances of elements, not dead-list of kinds of elements? > * 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 Wednesday, 24 August 2011 21:45:29 UTC