- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Wed, 24 Aug 2011 10:44:32 -0700
- To: public-webapps <public-webapps@w3.org>
- Cc: Adam Barth <w3c@adambarth.com>, Dominic Cooney <dominicc@google.com>, Alex Russell <slightlyoff@google.com>, Erik Arvidsson <arv@google.com>, MarkM Miller <erights@google.com>
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. * 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. * 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 17:44:59 UTC