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

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

--- Comment #18 from Daniel Buchner <danieljb2@gmail.com> ---
(In reply to comment #16)
> (In reply to comment #15)

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

"Instead, there's the same syntax for both ES6 and ES5/3" - I don't see how
this is at all possible to polyfill, because HTMLScriptElement.call(this);
throws.

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

^ Can we not fix this? What are all the options? I really don't think
developers are going to like this, it sounds like the platform coded itself
into a corner a bit - but I could be wrong ***ducks***

> > *** Recommendation ***
> > 
> > Do not return constructors from document.register, ever.
> > 
> > We should leave user-facing constructor generation to ES6 and make
> > document.register understand them when used as the second parameter.
>
> Well, I am your developer friend, and I like allowing constructors a lot :)

Developers rarely, if ever, use native element constructors in the wild because
only a handful are supported: Image, Option, etc. Now let's be clear,
developers use non-DOM/element related user-code constructors for their own
objects, but given there are only a few working element constructors as it is,
I assure you they won't miss what they never had. Additionally, if they can't
extend what is output by document.register in the ES6 way, because ES6 methods
aren't supported, what good is it to front-load the requirement?

> 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);

The problem is, the above doesn't work today and can't be polyfilled in a way
that gracefully falls forward. 

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

Let's not ignore the other extremely useful lifecycle callbacks by pointing to
constructors as a replacement for 'created'. In actual use, 'inserted',
'removed', and 'attributeChanged' are used (in some combination) in the
majority of components we've observed. Forcing developers to deal with magical,
implicitly-hooked mutation callback functions or long-in-tooth document-wide
Mutation Observer generation in every constructor would be ugly and obtuse -
comparatively, lifecycle callbacks are *waaay* better in terms of API
ergonomics.

I think you'd be surprised to what extent developers prefer option objects in
widgets and object instantiations, it is actually the most common pattern in
all major libraries today.

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

Received on Tuesday, 12 February 2013 01:20:15 UTC