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 <rniwa@apple.com> wrote:

>
> > On Apr 29, 2015, at 9:17 PM, Hayato Ito <hayato@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
>
>