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 > >