28446 2015-04-08 16:10:20 +0000 [Shadow]: Consider removal of multiple shadow roots 2015-05-27 03:05:19 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED MOVED P2 normal --- 28552 1 dglazkov hayato annevk hayato mike public-webapps timdream public-webapps-bugzilla oldest_to_newest 119380 0 dglazkov 2015-04-08 16:10:20 +0000 This is a contentious bit: https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits#a-multiple-shadow-roots-per-element 119381 1 dglazkov 2015-04-08 16:10:58 +0000 From https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0052.html: Annevk: "We'd like to retain this feature. Although it has complexity, we've heard from both Firefox UI and Firefox OS application developers that the moment your library gets sophisticated, you want this for extensibility." 119570 2 dglazkov 2015-04-16 16:42:41 +0000 From https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0109.html: "I was asked to provide a use case for our stance. One that we've found with Firefox OS is custom dialogs, quoting Wilson Page: # I have an <x-dialog> component. It takes care of transitioning # in and out of the viewport and appropriate styling contained # elements (<h1>, <button>, <p>). # # I want to be able to extend this component to produce # <x-dialog-alert>. In this case extending the prototype alone # isn't enough, I need to also be able to extend the markup # and styling of <x-dialog>. # # At the point of creation <x-dialog-alert> can add a second # ShadowRoot that allows it to compose its own content # inside that of the 'old' <x-dialog> ShadowRoot. Without this # <x-dialog-alert> would have to duplicate all the markup, style # and interaction code again." 119572 3 dglazkov 2015-04-16 16:45:22 +0000 From https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0122.html: "I don't think you need to duplicate anything. The super class can still fill in the original shadow root, then the subclass can modify it. This is the same concept of the prototype inheritance, your methods will shadow the super class methods, but you can just call them and then extend the behavior. This is also the reason the created and attached callbacks are on the prototype. So you can call super and use the parent behavior by shared protocol." 119573 4 dglazkov 2015-04-16 16:46:04 +0000 From https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0132.html: "> This is an interesting approach that didn't occur to me! Similar to Anne's > concerns, this would require you to have more knowledge of the internals of > the super-class component. If you own both components then this is fine. > Yes, the main problem here is the degree of separation between creator and consumer of the base component. The higher the degree, the less inclined the creator will be to expose innards of the shadow tree to the consumer. Multiple shadow roots solves the same problem as shadow trees (provides a composition contract), but along the inheritance chain. For example, multiple shadow roots make sense: * if you are a maker of UI library that's strongly rooted in inheritance and intend to for your base components to be used directly; * if you are hoping to inherit from components with closed shadow trees." 119773 5 hayato 2015-04-22 22:36:07 +0000 FYI. I've written a memo about "Multiple Shadow Roots". https://github.com/w3c/webcomponents/wiki/Multiple-Shadow-Roots-as-%22a-Shadow-Root-hosts-another-Shadow-Root%22 I'm not saying anything about whether we should remove multiple shadow roots or not there. Please consider it just for reference. 119909 6 hayato 2015-04-27 03:15:33 +0000 The resolution is "Remove for v1". See https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting. Let me try to update the spec. I might use this bug as a meta bug. 120514 7 hayato 2015-05-27 03:05:19 +0000 Moved to https://github.com/w3c/webcomponents/issues/90