Re: Inheritance Model for Shadow DOM Revisited
On Fri, May 1, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote: On May 1, 2015, at 1:04 AM, Anne van Kesteren ann...@annevk.nl wrote: This is where you directly access superclass' ShadowRoot I assume and modify things? In the named slot approach, these overridable parts will be exposed to subclasses as an overridable slot. In terms of an imperative API, it means that the superclass has a virtual method (probably with a symbol name) that can get overridden by a subclass. The default implementation of such a virtual method does nothing, and shows the fallback contents of the slot. 3. Fill holes superclass provided - e.g. subclass implements abstract virtual functions superclass defined to delegate the work. This is the part that looks like it might interact with distribution, no? With the named slot approach, we can also model this is an abstract method on the superclass that a subclass must implement. The superclass' shadow DOM construction code then calls this function to fill the slot. I think I need to see code in order to grasp this. -- https://annevankesteren.nl/
Re: Inheritance Model for Shadow DOM Revisited
On May 1, 2015, at 1:04 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Apr 30, 2015 at 11:35 PM, Ryosuke Niwa rn...@apple.com wrote: To start off, I can think of three major ways by which subclass wants to interact with its superclass: 1. Replace what superclass shows entirely by its own content - e.g. grab the device context and draw everything by yourself. So this requires either replacing or removing superclass' ShadowRoot. 2. Override parts of superclass' content - e.g. subclass overrides virtual functions superclass provided to draw parts of the component/view. This is where you directly access superclass' ShadowRoot I assume and modify things? In the named slot approach, these overridable parts will be exposed to subclasses as an overridable slot. In terms of an imperative API, it means that the superclass has a virtual method (probably with a symbol name) that can get overridden by a subclass. The default implementation of such a virtual method does nothing, and shows the fallback contents of the slot. 3. Fill holes superclass provided - e.g. subclass implements abstract virtual functions superclass defined to delegate the work. This is the part that looks like it might interact with distribution, no? With the named slot approach, we can also model this is an abstract method on the superclass that a subclass must implement. The superclass' shadow DOM construction code then calls this function to fill the slot. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
Thanks, let me update my understanding: - There is no use cases which shadow as function can't support, but content slot can support. - The purpose of the proposal is to remove an *extra* syntax. There is no other goals. - There is no reason to consider content slot proposal if we have a use case which this *extra* syntax can achieve. I'm also feeling that several topic are mixed in the proposal, Imperative APIs, Multiple Templates and content slot, which makes me hard to understand the goal of each. Can I assume that the proposal is trying to remove content select, not only from such a multiple templates, but also from everywhere? On Thu, Apr 30, 2015 at 4:18 PM Ryosuke Niwa rn...@apple.com wrote: On Apr 29, 2015, at 9:17 PM, Hayato Ito hay...@chromium.org wrote: Thanks. As far as my understanding is correct, the conclusions so far are: - There is no use cases which shadow as function can't support, but content slot can support. - there are use cases which shadow as function can support, but content slot can't support. I disagree. What shadow as function provides is an extra syntax by which authors can choose elements. That's not a use case. A use case is a solution for a concrete user scenario such as building a social network button. - shadow as function is more expressive than content slot Again, I disagree. - content slot is trying to achieve something by removing expressiveness from web developers, instead of trusting them. I still don't understand fully what the proposal is trying to achieve. I've never heard such a complain, content select is too expressive and easy to be misused. Please remove it, from web developers. I think any good APIs could be potentially wrongly used by a web developer. But that shouldn't be a reason that we can remove a expressive API from web developers who can use it correctly and get benefits from the expressiveness. Now let me make an analogous comparison between C++ and assembly language. - There is no use cases which assembly can't support, but C++ can support. - There are use cases which assembly can support, but C++ can't support. - Assembly language is more expressive than C++. - C++ is trying to achieve something by removing expressiveness from programmers, instead of trusting them. Does that mean we should all be coding in assembly? Certainly not. For a more relevant analogy, one could construct the entire document using JavaScript without using HTML at all since DOM API exposed to JavaScript can construct the set of trees which is a strict superset of what HTML tree building algorithm can generate. Yet, we don't see that happening even in the top tier Web apps just because DOM API is more expressive. The vast majority of Web apps still use plenty of templates and declarative formats to construct DOM for simplicity and clarity even though imperative alternatives are strictly more powerful. Why did we abandon XHTML2.0? It was certainly more expressive. Why not SGML? It's a lot more expressive than XML. You can re-define special character as you'd like. Because expressiveness is not necessary the most desirable characteristics of anything by itself. The shape of a solution we need depends on the kind of problems we're solving. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
On Apr 29, 2015, at 9:17 PM, Hayato Ito hay...@chromium.org wrote: Thanks. As far as my understanding is correct, the conclusions so far are: - There is no use cases which shadow as function can't support, but content slot can support. - there are use cases which shadow as function can support, but content slot can't support. I disagree. What shadow as function provides is an extra syntax by which authors can choose elements. That's not a use case. A use case is a solution for a concrete user scenario such as building a social network button. - shadow as function is more expressive than content slot Again, I disagree. - content slot is trying to achieve something by removing expressiveness from web developers, instead of trusting them. I still don't understand fully what the proposal is trying to achieve. I've never heard such a complain, content select is too expressive and easy to be misused. Please remove it, from web developers. I think any good APIs could be potentially wrongly used by a web developer. But that shouldn't be a reason that we can remove a expressive API from web developers who can use it correctly and get benefits from the expressiveness. Now let me make an analogous comparison between C++ and assembly language. - There is no use cases which assembly can't support, but C++ can support. - There are use cases which assembly can support, but C++ can't support. - Assembly language is more expressive than C++. - C++ is trying to achieve something by removing expressiveness from programmers, instead of trusting them. Does that mean we should all be coding in assembly? Certainly not. For a more relevant analogy, one could construct the entire document using JavaScript without using HTML at all since DOM API exposed to JavaScript can construct the set of trees which is a strict superset of what HTML tree building algorithm can generate. Yet, we don't see that happening even in the top tier Web apps just because DOM API is more expressive. The vast majority of Web apps still use plenty of templates and declarative formats to construct DOM for simplicity and clarity even though imperative alternatives are strictly more powerful. Why did we abandon XHTML2.0? It was certainly more expressive. Why not SGML? It's a lot more expressive than XML. You can re-define special character as you'd like. Because expressiveness is not necessary the most desirable characteristics of anything by itself. The shape of a solution we need depends on the kind of problems we're solving. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
On Apr 30, 2015, at 1:47 AM, Hayato Ito hay...@chromium.org wrote: Thanks, let me update my understanding: - There is no use cases which shadow as function can't support, but content slot can support. - The purpose of the proposal is to remove an *extra* syntax. There is no other goals. - There is no reason to consider content slot proposal if we have a use case which this *extra* syntax can achieve. That's not at all what I'm saying. As far as we (Apple) are concerned, shadow as a function as a mere proposal just as much as our content slot is a proposal since you've never convinced us that shadow as a function is a good solution for shadow DOM inheritance. Both proposals should be evaluated based on concrete use cases. And even if there are use cases for which a given proposal (either shadow as a function or named slot) doesn't adequately address, there are multiple options to consider: 1. Reject the use case because it's not important 2. Defer the use case for future extensions 3. Modify the proposal as needed 4. Reject the proposal because above options are not viable I'm also feeling that several topic are mixed in the proposal, Imperative APIs, Multiple Templates and content slot, which makes me hard to understand the goal of each. Can I assume that the proposal is trying to remove content select, not only from such a multiple templates, but also from everywhere? As I understand the situation, the last F2F's resolution is to remove content select entirely. That's not a proposal but rather the tentative consensus of the working group. If you'd like, we can initiate a formal CfC process to reach a consensus on this matter although I highly doubt the outcome will be different given the attendees of the meeting. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. So what if we flipped this as well and came up with an imperative API for shadow as a function. I.e. shadow as an actual function? Would that give us agreement? It'd be great to have something like this available. -- https://annevankesteren.nl/
Re: Inheritance Model for Shadow DOM Revisited
On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. So what if we flipped this as well and came up with an imperative API for shadow as a function. I.e. shadow as an actual function? Would that give us agreement? We object on the basis that shadow as a function is fundamentally backwards way of doing the inheritance. If you have a MyMapView and define a subclass MyScrollableMapView to make it scrollable, then MyScrollableMapView must be a MyMapView. It doesn't make any sense for MyScrollableMapView, for example, to be a ScrollView that then contains MyMapView. That's has-a relationship which is appropriate for composition. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
On Apr 30, 2015, at 2:44 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 2:29 PM, Brian Kardell bkard...@gmail.com wrote: On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. So what if we flipped this as well and came up with an imperative API for shadow as a function. I.e. shadow as an actual function? Would that give us agreement? We object on the basis that shadow as a function is fundamentally backwards way of doing the inheritance. If you have a MyMapView and define a subclass MyScrollableMapView to make it scrollable, then MyScrollableMapView must be a MyMapView. It doesn't make any sense for MyScrollableMapView, for example, to be a ScrollView that then contains MyMapView. That's has-a relationship which is appropriate for composition. Is there really a hard need for inheritance over composition? Won't composition ability + an imperative API that allows you to properly delegate to the stuff you contain be just fine for a v1? Per resolutions in F2F last Friday, this is a discussion for v2 since we're definitely not adding multiple generations of shadow DOM in v1. However, we should have a sound plan for inheritance in v2 and make sure our imperative API is forward compatible with it. So the goal here is to come up with some plan for inheritance so that we can be confident that our inheritance API is not completely busted. Sorry, I meant to say our *imperative* API is not completely busted. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. So what if we flipped this as well and came up with an imperative API for shadow as a function. I.e. shadow as an actual function? Would that give us agreement? We object on the basis that shadow as a function is fundamentally backwards way of doing the inheritance. If you have a MyMapView and define a subclass MyScrollableMapView to make it scrollable, then MyScrollableMapView must be a MyMapView. It doesn't make any sense for MyScrollableMapView, for example, to be a ScrollView that then contains MyMapView. That's has-a relationship which is appropriate for composition. - R. Niwa Is there really a hard need for inheritance over composition? Won't composition ability + an imperative API that allows you to properly delegate to the stuff you contain be just fine for a v1? -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Inheritance Model for Shadow DOM Revisited
On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. So what if we flipped this as well and came up with an imperative API for shadow as a function. I.e. shadow as an actual function? To start off, I can think of three major ways by which subclass wants to interact with its superclass: 1. Replace what superclass shows entirely by its own content - e.g. grab the device context and draw everything by yourself. 2. Override parts of superclass' content - e.g. subclass overrides virtual functions superclass provided to draw parts of the component/view. 3. Fill holes superclass provided - e.g. subclass implements abstract virtual functions superclass defined to delegate the work. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
Filed as https://www.w3.org/Bugs/Public/show_bug.cgi?id=28587. On Fri, May 1, 2015 at 1:16 AM Hayato Ito hay...@chromium.org wrote: Thanks Anne, I agree that it would be great to have something like this. I think it's too early for us to judge something because we don't have a well defined Imperative API as of now. Let's re-open this issue after we can see how an Imperative API goes. I'll file a bug for the spec about this inheritance challenge so that we can continue the discussion in the bugzilla. On Thu, Apr 30, 2015 at 8:43 PM Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. So what if we flipped this as well and came up with an imperative API for shadow as a function. I.e. shadow as an actual function? Would that give us agreement? It'd be great to have something like this available. -- https://annevankesteren.nl/
Re: Inheritance Model for Shadow DOM Revisited
Thanks. As far as my understanding is correct, the conclusions so far are: - There is no use cases which shadow as function can't support, but content slot can support. - there are use cases which shadow as function can support, but content slot can't support. - shadow as function is more expressive than content slot - content slot is trying to achieve something by removing expressiveness from web developers, instead of trusting them. I still don't understand fully what the proposal is trying to achieve. I've never heard such a complain, content select is too expressive and easy to be misused. Please remove it, from web developers. I think any good APIs could be potentially wrongly used by a web developer. But that shouldn't be a reason that we can remove a expressive API from web developers who can use it correctly and get benefits from the expressiveness. On Wed, Apr 29, 2015 at 3:52 AM Ryosuke Niwa rn...@apple.com wrote: On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 9:50 PM, Hayato Ito hay...@chromium.org wrote: The feature of shadow as function supports *subclassing*. That's exactly the motivation I've introduced it once in the spec (and implemented it in blink). I think Jan Miksovsky, co-author of Apple's proposal, knows well that. We're (and consequently I'm) fully aware of that feature/prosal, and we still don't think it adequately addresses the needs of subclassing. The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. The reason I reverted it from the spec (and the blink), [1], is a technical difficulty to implement, though I've not proved that it's impossible to implement. I'm not even arguing about the implementation difficulty. I'm saying that the semantics is inadequate for subclassing. On Apr 28, 2015, at 10:34 AM, Hayato Ito hay...@chromium.org wrote: Could you help me to understand what implicitly means here? I mean that the superclass’ insertion points use a CSS selector to select nodes to distribute. As a result, unless the subclass can supply the exactly kinds of nodes that matches the CSS selector, it won’t be able to override the contents into the insertion point. In this particular case, you might want to blame the super class's author and tell the author, Please use content select=.input-foo so that subclass can override it with arbitrary element with class=input-foo”. The problem is that it may not be possible to coordinate across class hierarchy like that if the superclass was defined in a third party library. With the named slot approach, superclass only specifies the name of a slot, so subclass will be able to override it with whatever element it supplies as needed. Could you give me an concrete example which content slot can support, but shadow as function can't support? The problem isn’t so much that slot can do something shadow as function can’t support. It’s that shadow as function promotes over specification of what element can get into its insertion points by the virtue of using a CSS selector. Now, it's possible that we can encourage authors to always use a class name in select attribute to support this use case. But then why are we adding a capability that we then discourage authors from using it. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
On Apr 27, 2015, at 9:50 PM, Hayato Ito hay...@chromium.org wrote: The feature of shadow as function supports *subclassing*. That's exactly the motivation I've introduced it once in the spec (and implemented it in blink). I think Jan Miksovsky, co-author of Apple's proposal, knows well that. We're (and consequently I'm) fully aware of that feature/prosal, and we still don't think it adequately addresses the needs of subclassing. The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. The reason I reverted it from the spec (and the blink), [1], is a technical difficulty to implement, though I've not proved that it's impossible to implement. I'm not even arguing about the implementation difficulty. I'm saying that the semantics is inadequate for subclassing. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
Could you help me to understand what implicitly means here? In this particular case, you might want to blame the super class's author and tell the author, Please use content select=.input-foo so that subclass can override it with arbitrary element with class=input-foo. Could you give me an concrete example which content slot can support, but shadow as function can't support? On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 9:50 PM, Hayato Ito hay...@chromium.org wrote: The feature of shadow as function supports *subclassing*. That's exactly the motivation I've introduced it once in the spec (and implemented it in blink). I think Jan Miksovsky, co-author of Apple's proposal, knows well that. We're (and consequently I'm) fully aware of that feature/prosal, and we still don't think it adequately addresses the needs of subclassing. The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. The reason I reverted it from the spec (and the blink), [1], is a technical difficulty to implement, though I've not proved that it's impossible to implement. I'm not even arguing about the implementation difficulty. I'm saying that the semantics is inadequate for subclassing. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 9:50 PM, Hayato Ito hay...@chromium.org wrote: The feature of shadow as function supports *subclassing*. That's exactly the motivation I've introduced it once in the spec (and implemented it in blink). I think Jan Miksovsky, co-author of Apple's proposal, knows well that. We're (and consequently I'm) fully aware of that feature/prosal, and we still don't think it adequately addresses the needs of subclassing. The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants to insert matches exactly what the author of superclass considered, the subclass won't be able to override it. e.g. if the superclass had an insertion point with select=input.foo, then it's not possible for a subclass to then override it with, for example, an input element wrapped in a span. The reason I reverted it from the spec (and the blink), [1], is a technical difficulty to implement, though I've not proved that it's impossible to implement. I'm not even arguing about the implementation difficulty. I'm saying that the semantics is inadequate for subclassing. On Apr 28, 2015, at 10:34 AM, Hayato Ito hay...@chromium.org wrote: Could you help me to understand what implicitly means here? I mean that the superclass’ insertion points use a CSS selector to select nodes to distribute. As a result, unless the subclass can supply the exactly kinds of nodes that matches the CSS selector, it won’t be able to override the contents into the insertion point. In this particular case, you might want to blame the super class's author and tell the author, Please use content select=.input-foo so that subclass can override it with arbitrary element with class=input-foo”. The problem is that it may not be possible to coordinate across class hierarchy like that if the superclass was defined in a third party library. With the named slot approach, superclass only specifies the name of a slot, so subclass will be able to override it with whatever element it supplies as needed. Could you give me an concrete example which content slot can support, but shadow as function can't support? The problem isn’t so much that slot can do something shadow as function can’t support. It’s that shadow as function promotes over specification of what element can get into its insertion points by the virtue of using a CSS selector. Now, it's possible that we can encourage authors to always use a class name in select attribute to support this use case. But then why are we adding a capability that we then discourage authors from using it. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
I'm aware that our consensus is to defer this until v2. Don't worry. :) The feature of shadow as function supports *subclassing*. That's exactly the motivation I've introduced it once in the spec (and implemented it in blink). I think Jan Miksovsky, co-author of Apple's proposal, knows well that. The reason I reverted it from the spec (and the blink), [1], is a technical difficulty to implement, though I've not proved that it's impossible to implement. [1] https://codereview.chromium.org/137993003 On Tue, Apr 28, 2015 at 1:33 PM Ryosuke Niwa rn...@apple.com wrote: Note: Our current consensus is to defer this until v2. On Apr 27, 2015, at 9:09 PM, Hayato Ito hay...@chromium.org wrote: For the record, I, as a spec editor, still think Shadow Root hosts yet another Shadow Root is the best idea among all ideas I've ever seen, with a shadow as function, because it can explain everything in a unified way using a single tree of trees, without bringing yet another complexity such as multiple templates. Please see https://github.com/w3c/webcomponents/wiki/Multiple-Shadow-Roots-as-%22a-Shadow-Root-hosts-another-Shadow-Root%22 That's a great mental model for multiple generations of shadow DOM but it doesn't solve any of the problems with API itself. Like I've repeatedly stated in the past, the problem is the order of transclusion. Quoting from [1], The `shadow` element is optimized for wrapping a base class, not filling it in. In practice, no subclass ever wants to wrap their base class with additional user interface elements. A subclass is a specialization of a base class, and specialization of UI generally means adding specialized elements in the middle of a component, not wrapping new elements outside some inherited core. In the three component libraries [1] described above, the only cases where a subclass uses `shadow` is if the subclass wants to add additional styling. That is, a subclass wants to override base class styling, and can do so via: ``` template stylesubclass styles go here/style shadow/shadow /template ``` One rare exception is `core-menu` [3], which does add some components in a wrapper around a `shadow`. However, even in that case, the components in question are instances of `core-a11y-keys`, a component which defines keyboard shortcuts. That is, the component is not using this wrapper ability to add visible user interface elements, so the general point stands. As with the above point, the fact that no practical component has need for this ability to wrap an older shadow tree suggests the design is solving a problem that does not, in fact, exist in practice. [1] https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution [2] Polymer’s core- elements, Polymer’s paper- elements, and the Basic Web Components’ collection of basic- elements [3] https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FPolymer%2Fcore-menu%2Fblob%2Fmaster%2Fcore-menu.htmlsa=Dsntz=1usg=AFQjCNH0Rv14ENbplb6VYWFh8CsfVo9m_A - R. Niwa
