On Fri, Aug 26, 2011 at 12:24 AM, Roland Steiner <rolandstei...@google.com> wrote: > Unless I'm misunderstanding something, I believe this actually is - or at > least touches upon - several questions in disguise: > .) Do we want to allow decoration of elements that are already in the DOM > tree?
If by "decoration" you mean "new ShadowRoot" then I think the answer is "yes." Why would you disallow it? It throws one more obstacle in the author’s way. > - which is for all intents and purposes a corollary of: > .) Do we allow calling of "new ShadowRoot" outside of an element > constructor? >From the DOM bindings point of view, it is very difficult to decide when a "constructor" is running. How would you do it? Stack walking? I don’t think any other bindings do this sort of thing. > If no, then we don't have a problem with "dead elements", because the author > can only declare new elements (and use encapsulation), but not meddle with > existing ones. FWIW, I don't think there is any real use-case for calling > "new ShadowRoot" within the constructor twice. I take the point that if you can only call it once, and only in constructors, then you can easily assign meaning to "new ShadowRoot(x) where x is not an extension element." It throws. But you could just make that restriction without all of these other restrictions on constructors, once only, etc. I don’t want us to confound being able to call it only once or more than once for a given element, being able to call it for extension elements only or built-in element types too, and being able to call it only inside constructors or also outside of constructors. > However, in this case we have to answer how encapsulation can address the > stated use cases for decoration. This probably means answering: > .) How is attribute forwarding handled from the host element to a nested > (form) element? +1. We should think about concrete proposals. Also: Do the use cases need it? And if we did nothing, what would authors do in response (ie how ugly are mutation listeners?) > .) How can components participate in forms (and other fun)? > ... or just leave decoration out for the time being (which I think is quite > reasonable). We should brainstorm other "fit" issues. What about the selection? Does it leak shadow nodes (probably not.) So can confined scripts ever read the selection? etc. > OTOH, if the answer to the decorators question is "yes", then the above > mentioned issues with multiple shadow roots arise. I think we need to think about these issues anyway. But maybe the multiple shadows problem is a good one to tackle early. Dominic
