> 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

Reply via email to