[Bug 20913] [Custom]: Meaning of prototype in document.register is underspecified

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

--- Comment #16 from Dimitri Glazkov <dglazkov@chromium.org> ---
(In reply to comment #15)
> In the following feedback, I'll highlight what I see as the most
> developer-friendly, ergonomic combination of the various concerns before us.
> In response, I would like to know what the major blockers or concerns are in
> relation to feasibility. (Some of the points below are already know or have
> been detailed in previous comments - they are included for cohesion)
> 
> 1. Developers should be able to subclass elements with ES6 methods, but
> sub-classing should not implicitly register them with the parser.
> 
>  - document.register and class extension should not be - and need not be -
> synonymous. These interfaces represent two different conceptual functions:
> 1) creating new objects that inherit from a previously declared
> HTMLElement-objects, and 2) registering an element prototype for parser and
> DOM method functionality.

Yup. That's unchanged in any of the proposed solutions.

> 
>  - ES6 extension of elements need not affect document.register if the
> register method understands that the second property could be an options
> object, or an HTMLElement-inheriting object.

The solution that Arv proposed in
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0250.html doesn't
have either/or split like this. Instead, there's the same syntax for both ES6
and ES5/3. If there _is_ a way to do that, I would think it's a Good Thing.

Boris is finding out how feasible it is, though.

> 
> 2. Developers should have access to all properties that existed on the base
> prototype whether declaring elements via tag or attribute. This means that
> setting 'src' on an <x-loader>, that was derived from { prototype:
> Object.create() } using HTMLScriptElement as a proto base should work - if
> it doesn't, that is non-optimal and should be corrected (feasible? Not sure.
> I'll plead ignorance on this point and defer to you all)

The problem that Boris raised is summarized in comment 9. It's a sucky
situation, but basically, if you inherit from HTMLScriptElement, you can only
be born as <script is="x-loader">, and never as <x-loader> :-\. I know you
don't like that, but I haven't been able to think a way out.

> 
> Examples to illustrate the above points:
> 
> This should work:
> 
> class SuperScript extends HTMLScriptElement;
> document.register('super-script', SuperScript);
> 
> So should this:
> 
> document.register('super-script', {
>     prototype: Object.create(HTMLScriptElement.prototype, { ... })
> });
> 
> *** Recommendation ***
> 
> Do not return constructors from document.register, ever.

I don't understand what you mean here. In the current form, we do return a
constructor. How would you instantiate an object? Being stuck with
document.createElement forever seems like ghetto.

> 
> We should leave user-facing constructor generation to ES6 and make
> document.register understand them when used as the second parameter.
> 
> In talking to just about every developer friend I could get a hold of over
> the weekend I found that...no one cares about constructors. Maybe that
> changes in 4 years when most browsers have ES6 implemented. They told me
> they can't use the constructors of 99.5% of elements currently, so they
> could care less as long as document.createElement('super-script') works.

Well, I am your developer friend, and I like allowing constructors a lot :)

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


Check this out:

function SuperScript() {
   HTMLScriptElement.call(this);
   var root = this.createShadowRoot();
   root.innerHTML = "BEHOLD TEH SUPPERRRR SCRIPT!!!"
}
SuperScript.prototype = Object.create(HTMLScriptElement.prototype);
document.register("super-script", SuperScript);

Compare to:

document.register("super-script", {
  prototype: Object.create(HTMLScriptElement.prototype),
  lifecycle: {
     shadowRootCreated(root) {
        root.innerHTML = "BEHOLD TEH SUPPERRRR SCRIPT!!!";
     }
  }
});

The first one looks and feels like idiomatic JS. The author is in control of
creating the shadow tree. The second has mysterious parameters, needs
additional learning, and the author has no control of when the shadow tree is
created.

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

Received on Tuesday, 12 February 2013 00:28:16 UTC