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

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.
>>
>>
>> <http://goto.google.com/dc-email-sla>
>>
>> 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.


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

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.

> In mentioning hooks, was merely observing that we could define more hooks
> to enable even more use cases.
>
>
>> In addition, consider how inheriting "views" work in AppKit, UIKit, .net
>> and MFC. When a view T inherits from another view S, T doesn't simply put S
>> into a subregion of T; S intrudes into T's view and modifies what's been
>> displayed or places extra content after or before T draws itself.
>>
>
> I can not discern a specific point you are making here. You are drawing an
> analogy to various UI frameworks but you have not completed the analogy. I
> think if you completed the analogy it would end up being a claim about
> Shadow DOM. You may have confused extending an element and having Shadow
> DOM. As Rafael Weinstein points out here: <
> http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0883.html>,
> whether an element has Shadow DOM is orthogonal to whether it is a Custom
> Element or not. I also disagree with your implied argument about Shadow DOM.
>
>
> Then we simply continue to disagree about this point.
>
> I have a hard time understanding how this bizarre mixture of inheritance
>> and composition is considered as the minimal subset of features while
>> adding one optional argument to document.register to eliminate the most
>> common boilerplate is considered as "building a framework" and "bundling"
>> orthogonal features. Where did use cases and developer ergonomics go?
>>
>
> The use cases were discussed on this list in 2010.
>
> As for ergonomics, this is subjective, but I spent a day last week
> building a Polymer app and the ergonomics were splendid. I have played with
> X-Tags in the past and they're great too.
>
>
> We're not talking about Polymer.
>

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.

If you're talking about framework developers, let's ask them... Could a
Polymer, X-Tags or other framework developer give some indication of
whether the ergonomics of document.register are acceptable?

I note that many Custom Elements bug comments were posted by framework
developers. So by being involved in the specification process, I am pretty
confident the process has produced something which has acceptable
ergonomics for them. But we can ask them directly to find out in more
detail.

Dominic