Re: Inheritance Model for Shadow DOM Revisited

2015-05-01 Thread Anne van Kesteren
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

2015-05-01 Thread Ryosuke Niwa

 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

2015-04-30 Thread Hayato Ito
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

2015-04-30 Thread Ryosuke Niwa

 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

2015-04-30 Thread Ryosuke Niwa

 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

2015-04-30 Thread Anne van Kesteren
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

2015-04-30 Thread Ryosuke Niwa

 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

2015-04-30 Thread Ryosuke Niwa

 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

2015-04-30 Thread Brian Kardell
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

2015-04-30 Thread Ryosuke Niwa

 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

2015-04-30 Thread Hayato Ito
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

2015-04-29 Thread Hayato Ito
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

2015-04-28 Thread Ryosuke Niwa

 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

2015-04-28 Thread Hayato Ito
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

2015-04-28 Thread Ryosuke Niwa

 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

2015-04-27 Thread Hayato Ito
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