Re: Inheritance Model for Shadow DOM Revisited
On Fri, May 1, 2015 at 10:36 AM, Ryosuke Niwa wrote: >> On May 1, 2015, at 1:04 AM, Anne van Kesteren 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 wrote: > > On Thu, Apr 30, 2015 at 11:35 PM, Ryosuke Niwa 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
On Thu, Apr 30, 2015 at 11:35 PM, Ryosuke Niwa 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? > 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? -- https://annevankesteren.nl/
Re: Inheritance Model for Shadow DOM Revisited
> On Apr 30, 2015, at 2:44 PM, Ryosuke Niwa wrote: > > >> On Apr 30, 2015, at 2:29 PM, Brian Kardell wrote: >> >> On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa wrote: >>> On Apr 30, 2015, at 4:43 AM, Anne van Kesteren wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa wrote: > The problem with " 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 " as a function". I.e. " as an actual function"? Would that give us agreement? >>> >>> We object on the basis that " 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 Apr 30, 2015, at 2:29 PM, Brian Kardell wrote: > > On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa wrote: >> >>> On Apr 30, 2015, at 4:43 AM, Anne van Kesteren wrote: >>> >>> On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa wrote: The problem with " 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 " as a function". I.e. " as an actual function"? >>> Would that give us agreement? >> >> We object on the basis that " 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. - R. Niwa
Re: Inheritance Model for Shadow DOM Revisited
> On Apr 30, 2015, at 4:43 AM, Anne van Kesteren wrote: > > On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa wrote: >> The problem with " 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 " as a function". I.e. " 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
On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa wrote: > >> On Apr 30, 2015, at 4:43 AM, Anne van Kesteren wrote: >> >> On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa wrote: >>> The problem with " 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 " as a function". I.e. " as an actual function"? >> Would that give us agreement? > > We object on the basis that " 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 wrote: > > On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa wrote: >> The problem with " 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 " as a function". I.e. " as an actual function"? > Would that give us agreement? We object on the basis that " 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
Filed as https://www.w3.org/Bugs/Public/show_bug.cgi?id=28587. On Fri, May 1, 2015 at 1:16 AM Hayato Ito 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 > wrote: > >> On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa wrote: >> > The problem with " 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 " as a function". I.e. " 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 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 wrote: > On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa wrote: > > The problem with " 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 " as a function". I.e. " 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 Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa wrote: > The problem with " 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 " as a function". I.e. " 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
For reference, the discussion about " as function" was done in W3C bugzilla, https://www.w3.org/Bugs/Public/show_bug.cgi?id=22344, where everyone in the discussion agreed with the proposal. On Thu, Apr 30, 2015 at 7:03 PM Hayato Ito wrote: > On Thu, Apr 30, 2015 at 6:38 PM Ryosuke Niwa wrote: > >> >> > On Apr 30, 2015, at 1:47 AM, Hayato Ito wrote: >> > >> > Thanks, let me update my understanding: >> > >> > - There is no use cases which " as function" can't support, but >> "" can support. >> > - The purpose of the proposal is to remove an *extra* syntax. There is >> no other goals. >> > - There is no reason to consider "" 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, >> " as a function" as a mere proposal just as much as our "> slot>" is a proposal since you've never convinced us that " 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 >> 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 ", which makes me >> hard to understand the goal of each. >> > Can I assume that the proposal is trying to remove "", >> not only from such a multiple templates, but also from everywhere? >> >> As I understand the situation, the last F2F's resolution is to remove >> 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. >> >> > This is not true. > The resolution is: The decision is blocked on "The upcoming proposal of > Imperative APIs". > > > >> - R. Niwa >> >>
Re: Inheritance Model for Shadow DOM Revisited
On Thu, Apr 30, 2015 at 6:38 PM Ryosuke Niwa wrote: > > > On Apr 30, 2015, at 1:47 AM, Hayato Ito wrote: > > > > Thanks, let me update my understanding: > > > > - There is no use cases which " as function" can't support, but > "" can support. > > - The purpose of the proposal is to remove an *extra* syntax. There is > no other goals. > > - There is no reason to consider "" 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, > " as a function" as a mere proposal just as much as our " slot>" is a proposal since you've never convinced us that " 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 > 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 ", which makes me > hard to understand the goal of each. > > Can I assume that the proposal is trying to remove "", > not only from such a multiple templates, but also from everywhere? > > As I understand the situation, the last F2F's resolution is to remove > 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. > > This is not true. The resolution is: The decision is blocked on "The upcoming proposal of Imperative APIs". > - R. Niwa > >
Re: Inheritance Model for Shadow DOM Revisited
> On Apr 30, 2015, at 1:47 AM, Hayato Ito wrote: > > Thanks, let me update my understanding: > > - There is no use cases which " as function" can't support, but > "" can support. > - The purpose of the proposal is to remove an *extra* syntax. There is no > other goals. > - There is no reason to consider "" 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, " as a function" as a mere proposal just as much as our "" is a proposal since you've never convinced us that " 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 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 ", which makes me hard to > understand the goal of each. > Can I assume that the proposal is trying to remove "", not > only from such a multiple templates, but also from everywhere? As I understand the situation, the last F2F's resolution is to remove 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
Thanks, let me update my understanding: - There is no use cases which " as function" can't support, but "" can support. - The purpose of the proposal is to remove an *extra* syntax. There is no other goals. - There is no reason to consider "" 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 ", which makes me hard to understand the goal of each. Can I assume that the proposal is trying to remove "", not only from such a multiple templates, but also from everywhere? On Thu, Apr 30, 2015 at 4:18 PM Ryosuke Niwa wrote: > > > On Apr 29, 2015, at 9:17 PM, Hayato Ito wrote: > > > > Thanks. As far as my understanding is correct, the conclusions so far > are: > > > > - There is no use cases which " as function" can't support, but > "" can support. > > - there are use cases which " as function" can support, but > "" can't support. > > I disagree. What " 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. > > > - " as function" is more expressive than "" > > Again, I disagree. > > > - "" 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, " 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 wrote: > > Thanks. As far as my understanding is correct, the conclusions so far are: > > - There is no use cases which " as function" can't support, but > "" can support. > - there are use cases which " as function" can support, but " slot>" can't support. I disagree. What " 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. > - " as function" is more expressive than "" Again, I disagree. > - "" 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, " 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
Thanks. As far as my understanding is correct, the conclusions so far are: - There is no use cases which " as function" can't support, but "" can support. - there are use cases which " as function" can support, but "" can't support. - " as function" is more expressive than "" - "" 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, " 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 wrote: > > > On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa wrote: > >> > >> > On Apr 27, 2015, at 9:50 PM, Hayato Ito wrote: > >> > > >> > The feature of " 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 " 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 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 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 can support, > but " as function" can't support? > > The problem isn’t so much that slot can do something " as > function" can’t support. It’s that " 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 Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa wrote: >> >> > On Apr 27, 2015, at 9:50 PM, Hayato Ito wrote: >> > >> > The feature of " 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 " 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 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 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 can support, but > " as function" can't support? The problem isn’t so much that slot can do something " as function" can’t support. It’s that " 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
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 so that subclass can override it with arbitrary element with class="input-foo". Could you give me an concrete example which can support, but " as function" can't support? On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa wrote: > > > On Apr 27, 2015, at 9:50 PM, Hayato Ito wrote: > > > > The feature of " 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 " 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 Apr 27, 2015, at 9:50 PM, Hayato Ito wrote: > > The feature of " 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 " 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
I'm aware that our consensus is to defer this until v2. Don't worry. :) The feature of " 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 wrote: > Note: Our current consensus is to defer this until v2. > > > On Apr 27, 2015, at 9:09 PM, Hayato Ito 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 " 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 `` 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 `` is if the subclass wants to add additional > styling. That is, a subclass wants to override base class styling, and can > do so via: > > ``` > > subclass styles go here > > > ``` > > One rare exception is `core-menu` [3], which does add some components in a > wrapper around a ``. However, even in that case, the components in > question are instances of ``, 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.html&sa=D&sntz=1&usg=AFQjCNH0Rv14ENbplb6VYWFh8CsfVo9m_A > > - R. Niwa > >
Inheritance Model for Shadow DOM Revisited
Note: Our current consensus is to defer this until v2. > On Apr 27, 2015, at 9:09 PM, Hayato Ito 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 > " 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 `` 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 `` is if the subclass wants to add additional styling. That is, a subclass wants to override base class styling, and can do so via: ``` subclass styles go here ``` One rare exception is `core-menu` [3], which does add some components in a wrapper around a ``. However, even in that case, the components in question are instances of ``, 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.html&sa=D&sntz=1&usg=AFQjCNH0Rv14ENbplb6VYWFh8CsfVo9m_A - R. Niwa
