18535 2012-08-10 23:16:33 +0000 [Custom]: Scoping of element definitions in Shadow DOM 2012-08-24 20:31:15 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 17103 1 dglazkov dglazkov dominicc jackalmage public-webapps-bugzilla oldest_to_newest 72067 0 dglazkov 2012-08-10 23:16:33 +0000 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. 72069 1 jackalmage 2012-08-10 23:39:50 +0000 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. 72095 2 dominicc 2012-08-13 03:34:25 +0000 (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? 72292 3 dglazkov 2012-08-16 16:01:10 +0000 Also, what happens with elements that aren't in tree? 72731 4 dglazkov 2012-08-24 20:31:15 +0000 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.