W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

From: Rick Waldron <waldron.rick@gmail.com>
Date: Thu, 14 Feb 2013 17:10:01 -0500
Message-ID: <CAHfnhfr6dFaTR3w2RkDutYnY0jogFGYHswNGK7+BznmSsbXc0Q@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: public-webapps <public-webapps@w3.org>, Scott Miles <sjmiles@google.com>, Daniel Buchner <daniel@mozilla.com>, Erik Arvidsson <arv@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, Anne van Kesteren <annevk@annevk.nl>
On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov <dglazkov@google.com>wrote:

> Folks,
>
> I propose just a bit of sugaring as a compromise, but I want to make
> sure this is really sugar and not acid, so please chime in.
>
> 1) We give up on unified syntax for ES5 and ES6, and instead focus on
> unified plumbing
> 2) document.register returns a custom element constructor as a result,
> just like currently specified:
>
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-document-register
> 3) There are two ways to register an element: with a constructor and
> with a prototype object.
> 4) When registering with the constructor (aka the ES6 way), you must
> supply the constructor/class as the "constructor" member in the
> ElementRegistrationOptions dictionary
> (
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#api-element-registration-options
> )
> 5) If the constructor is supplied, element registration overrides
> [[Construct]] internal function as described in
> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0250.html
> 6) Registering with a prototype object (aka the current way) uses the
> "prototype" member in ElementRegistrationOptions dictionary and works
> roughly as currently specified
>

See Q's below...


> 7) If the prototype object is supplied, the constructor is generated
> as two steps:
>   a) Instantiate the platform object
>   b) Call "created" callback from lifecycle callback interface bound to
> "this"
> 8) We remove any sort of shadow tree creation and the corresponding
> template argument from the spec. Shadow tree management is left
> completely up to the author.
>
> Effectively, the "created" callback becomes the poor man's
> constructor. It's very easy to convert from old syntax to new syntax:
>
> The prototype way:
>
> function MyButton() {
>   // do constructor stuff ...
> }
> MyButton.prototype = Object.create(HTMLButtonElement.prototype, {
>  ...
> });
> MyButton = document.register(‘x-button’, {
>   prototype: MyButton.prototype,
>   lifecycle: {
>      created: MyButton
>   }
> });
>


Does this actually mean that the second argument has a property called
"prototype" that itself has a special meaning?

Is the re-assignment MyButton intentional? I see the original "MyButton"
reference as the value of the created property, but then
document.register's return value is assigned to the same identifier? Maybe
this was a typo?



>
> The constructor way:
>
> function MyButton() {
>  // do constructor stuff ...
> }
> MyButton.prototype = Object.create(HTMLButtonElement.prototype, {
>  ...
> });
> document.register(‘x-button’, {
>  constructor: MyButton,
>  ...
> });
>
>
Same question as above, but re: "constructor"?


When I first read this, I was expecting to see something about syntax, this
is all API.


Rick




> This is nearly the same approach as what  Scott sketched out here:
> http://jsfiddle.net/aNHZH/7/, so we already know it's shimmable :)
>
> What do you think?
>
> :DG<
>
>
Received on Thursday, 14 February 2013 22:10:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT