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

On Dec 10, 2013, at 9:20 AM, Erik Arvidsson <arv@chromium.org> wrote:
> On Tue, Dec 10, 2013 at 11:15 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola
> <domenic@domenicdenicola.com> wrote:
> > Nevertheless, it would be unfortunate to use the in-progress nature of making the web platform more JavaScript-friendly as an argument for making it more JavaScript hostile (by prohibiting element subclassing).
> 
> Well, the question is more what we should focus on first and whether
> doing it in the wrong order will be future hostile. I'm also somewhat
> skeptical that if we don't go through the exercise of explaining a
> couple of existing elements first, the generic mechanism they are all
> supposed to end up with will be correct.
> 
> I agree and have previously sketched how large parts of document.register can be made to work with @@create without adding anything to the platform (besides @@create). The things that are still magic are the lifetime callbacks and how the parser first creates the JS objects.
> 
> We carefully crafted document.register with ES6 classes in mind. It is not a coincidence that both constructor functions and the dict used today ind doc.reg have a prototype property.

Let us look at some examples.


http://www.whatwg.org/specs/web-apps/current-work/#dom-document-body
says on setting, document.body would in step 3:
"Otherwise, if the body element is not null, then replace that element with the new value in the DOM, as if the root element's replaceChild() method had been called with the new value and the incumbent body element as its two arguments respectively, then abort these steps."
Now, with custom elements, authors can easily override replaceChild's behavior. Yet, UAs will continue to use its internal implementation of replaceChild() for the purpose of this algorithm.


If some author is creating an element that inherits from HTMLInputElement like people have been suggesting, then it needs to support every supported types of the input element per Liskov substitution principe to be a proper subclassing.  I don't see authors possibly supporting all of the existing types, let alone future types we'll be adding  in the future.


Now recall our experience with "translate" content attribute where we broke some JS library made that supported its own version of "translate" content attribute.  With custom elements, authors are encouraged to add similar attributes on subclasses of HTMLElement.  It means that anytime we're adding a new property on HTMLElement, we have to be very careful in checking whether a given name is used or not.  Allowing subclassing from subclasses of HTMLElement would mean that we're increasing this API surface concern to all of them.  That's a lot of new constraints we'll be adding to the extensibility of the Web platform from the browser vendors.  Other GUI frameworks and platforms get away with this because those frameworks wouldn't get "upgraded" automatically.

It's true that authors could already do this by modifying the prototype chain of HTMLElement and their subclasses, but that's by no means a natural and encouraged way of programming on the Web today.  With custom elements, we'll be encouraging that.


- R. Niwa