> 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
