This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Should element definitions (the <element> thingies) be scoped inside of a shadow DOM subtree? That is, in parallel with id/name/selector scoping, would it make sense to do the same with element definitions? This means that you will have to explicitly state which components you want to use inside of each <element>, but also means that you can have a whole set of internal components that aren't surfaced to the document. Example: Bob has framework A and framework B used on his page. Both define x-qux, and A one wins. Bad news for framework B, which happens to also use it in its components.
Experience suggests that this kind of collision is easily worked around by library authors, by a combination of simple prefixing and just googling for names beforehand. I don't think we need to give it a technical solution.
(In reply to comment #0) > Should element definitions (the <element> thingies) be scoped inside > of a shadow DOM subtree? > > ... > > This means that you will have to explicitly state which components you > want to use inside of each <element>, but also means that you can have > a whole set of internal components that aren't surfaced to the > document. The proposed solution might be workable for large, complex components that have a single instance on a page. However if there are going to be multiple instances of a component on a page, something that means each instance has its own copy of the element definitions sounds heavyweight. (In reply to comment #1) > Experience suggests that this kind of collision is easily worked > around by library authors, by a combination of simple prefixing and just > googling for names beforehand. I don't think we need to give it a technical > solution. Is it so easily worked around? What about the related problem of integrating two copies of different versions of the same script library in the same page?
Also, what happens with elements that aren't in tree?
http://dvcs.w3.org/hg/webcomponents/rev/da7ba1b845b3 Made it iterate all enclosed trees for now. We can get back to this later. Split the free-standing elements question into bug 18684.