Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

On Dec 9, 2013, at 5:12 PM, Dominic Cooney <dominicc@google.com> wrote:
> On Tue, Dec 10, 2013 at 6:38 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
> On Dec 8, 2013, at 4:42 PM, Dominic Cooney <dominicc@google.com> wrote:
>> On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> On Dec 7, 2013, at 4:38 PM, Dominic Cooney <dominicc@google.com> wrote:
>>> On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>> On Dec 5, 2013, at 10:09 PM, Hajime Morrita <morrita@google.com> wrote:
>>> > On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance.
>>> 
>>> Right.  Differentiating the two is very important.
>>> 
>>> > For Custom Elements, the inheritance is not only about interface, but also about implementation. The implementation is more complex and flux in detail, thus worth being shared between different elements. Actually, the implementation of built-in HTML elements, which are usually done in C++, uses inheritance heavily, at least Blink and (I believe) WebKit.
>>> 
>>> The reason we can use inheritance heavily is because we have control over both parent and child classes, and there are careful distinctions between public, protected, and private member functions and member variables in those classes.
>>> 
>>> Unfortunately, custom elements can't easily inherit from these builtin HTML elements because builtin elements do not provide "protected" functions, and they don't expose necessary hooks to override internal member functions to modify behaviors.
>>> 
>>> Built-in HTML elements have lots of hooks to modify their behaviour (for example, HTMLVideoElement's autoplay attribute.) The analogy is extending a Java class which has private and public final members, but no protected or public non-final ones.
>>> 
>>> If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals.
>> 
>>> 
>> 
>> The problem here is that until such hooks are well defined, inheriting from builtin elements doesn't make any sense. So let's not support that until such proposal is made and implemented.
>> 
>> You assert that inheriting from built-in elements does not make any sense. You seem to base this on the claim that hooks (the example being form submission protocol hooks) are not well defined. Whether hooks are well defined or not doesn't sufficiently support your assertion, because:
>> 
>> 1. Not all subtyping relies on hooks. For example, subtyping a built-in element can add additional API to it. This may make sense. For example, a social network "endorse" button has a number of additional properties. Yet it is (or could be) a button.
> 
> If the only use case was to add new JavaScript property, then we wouldn't need custom elements at all.  Authors could already do this by simply adding properties on builtin elements.
> 
> If you do this on the Interface Prototype Object of a built-in element, the API will appear on all elements of that type. So that is not a feasible solution for many use cases.
> 
> If you try to do this on a per-instance basis, that means you have to track instances. As I pointed out here: <http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0893.html> that is very difficult for the author to do correctly. Custom Elements puts the responsibility for this in the UA which has full knowledge of when elements are being created.

But one of Google representatives stated that the current goal of web components, which we may not necessarily agree with, is to provide the minimum set of features for JS frameworks to build on top of it.  If that were the goal, why are we bothering to add this API at all?

In fact, why do we even bother to add any new API at all for web components if our primary target was framework authors.  Ember.js, Angular JS, etc... all work great already because they add an abstraction layer on top of DOM.  As currently argued by many representatives of Google, we'll be adding a bunch of APIs for frameworks to define declarative syntax, etc... each of which may or may not be interoperable with one another thereby making it impossible for us to later introduce one unified API.  If that were true, then web components specifications don't satisfy the previously claimed goal of letting multiple frameworks and libraries to co-exist at all.

Recall that "[t]he WebApps Working Group is chartered to develop specifications for webapps, including standard APIs for client-side development, and a packaging format for installable webapps. This work will include both documenting existing APIs such as XMLHttpRequest and developing new APIs in order to enable richer web applications."

We have a serious problem with the goal itself if the primary goal of web components features were to satisfy needs and use cases of JS frameworks.

> As for the social "endorse" button, I've never seen a popular SNS share buttons implemented using HTML button elements; most of them add their own DOM to add icons, etc... 
> 
> This is why it is important to be able to subtype built-in elements. Some authors prefer buttons to be <button>s because of the better default handling by accessibility technology.

I have previously explained why this accessibility benefit doesn't exits at least on platforms we care about.  See the discussion following http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0765.html

> Tangentially, this is also why it is important to be able to add Shadow DOM to built-in elements. It should be possible to elaborate the UI of a button but still get the benefits of encapsulated styles, encapsulation from accidental access through casual DOM walking or simple CSS selectors, etc.
>> 2. The premise that hooks are not defined is also incorrect. Many hooks are already defined. Here is one example: the INPUT element has input and change events and a value property. These are sufficient to observe, filter and change the value of the INPUT element.
> 
> This can't possibly be an explanation for "whether hooks are well defined or not doesn't sufficiently support your assertion".  HTML input elements have a lot more internal states than just the value.  To list a few:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-value-dirty-flag
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#concept-input-checked-dirty-flag
> 
> 
> I did not claim that all possible hooks are defined. I claimed that some hooks are defined. These enable some use cases. I was observing that we could define more hooks to enable even more use cases.

We object to exposing half-baked APIs like that to the Web.  We'll be stuck with the browser-specific quirks like we did with many DOM APIs.

> You mentioned developer ergonomics. If you're talking about web developers, many web developers use frameworks. So the needs and ergonomics of frameworks are pertinent to the question of developer ergonomics.

Again, while we don't object to addressing use cases for framework authors, we have a serious problem with the goal and the broader web components effort itself if framework authors were the only target of new APIs.

> I note that many Custom Elements bug comments were posted by framework developers.

Most of web developers are busy working on actual products they ship and maintain while it's natural for people building frameworks to be actively looking out for and testing new Web features since many frameworks provide abstraction layer around the raw APIs browsers provide.   But that doesn't mean only framework authors have opinions, can give useful feedback, or that they are the only developers we should care about.

- R. Niwa