[Bug 20831] [Custom]: Make document.register work with ES6 classes and @@create

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20831

--- Comment #2 from Dimitri Glazkov <dglazkov@chromium.org> ---
>From bug 20913, continuing discussion.

(In reply to comment #25)
> (In reply to comment #16)
> 
> > It lets us to get rid of the creation callbacks, simplifies the spec, and
> > basically lets the builder of a component do exactly what they need at
> > creation time, instead of dealing with "created" and "shadowRootCreated".
> 
> I'm sorry if I've somehow clouded the issue here, I don't oppose ES6 or
> extending DOM element objects via class/extends. I simply want the impact of
> changing doc.register to only take generated constructors to be clearly
> spelled out with a real example and realized. The above statement makes the
> current document.register property object sound like *it* is the complex,
> obtuse choice - what I'm saying is that it's the *opposite*. We're forcing
> constructors that have more cumbersome ergonomics and polyfill surface on
> folks that prefer not to use constructors for generating elements, as this
> survey shows:
> https://docs.google.com/forms/d/16cNqHRe-7CFRHRVcFo94U6tIYnohEpj7NZhY02ejiXQ/
> viewanalytics
> 
> My contention is as follows: 
> 
> Developers rarely use element constructors - there are several reasons,
> including: they're currently uncallable and throw (basically unusable,
> except for Image, Option, etc), devs have document.createElement and don't
> need them, they aren't programming Java.
> 
> Why it matters:
> 
> 1) We are arguing to change the interface to take only a parameter type that
> is largely irrelevant on the web today.
> 
> 2) We lose easily defined callbacks to common actions - if we don't, *please
> correct me* and show an example. For instance, inside the constructor will I
> not be able to do: this.lifecycle.inserted = function(){...}? If so, yay, I
> am less concerned!

We're not losing callbacks. We are trying to get rid of construction callbacks
only, because they are a hack around current platform limitations.

> 
> 3) I am worried about boilerplate and monotony. Without answering the
> ergonomics questions about providing the functionality in the spec's current
> property object in a way easily accessible to developers within their
> user-generated constructor definitions, this concern persists.

I soothe your worry by promising to keep the non-construction callbacks :)

> 
> document.register('super-list', {
>   prototype: Object.create(HTMLUListElement.prototype),
>   lifecycle: {
>     created: function(){
>       this.setAttribute('super', true);
>     },
>     inserted: function(){
>       // do something when super-list elements are added
>     }
>   }
> });
> 
> Me thinks --> "Holy burgeoning boilerplate Batman!"

I hope to arrive to:

function SuperList() {
   HTMLUListElement.call(this);
   this.setAttribute('super', true);
}
SuperList.prototype = Object.create(HTMLUListElement.prototype);
document.register('super-list', SuperList, {
   inserted: ...
});

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 12 February 2013 18:03:28 UTC