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: Daniel Buchner <daniel@mozilla.com>
Date: Thu, 14 Feb 2013 14:10:27 -0800
Message-ID: <CAHZ6zJGS9K6LK2+OU-W7b68FbaBps2CH+M8yMr3GHNvG_v1HUA@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: public-webapps <public-webapps@w3.org>, Scott Miles <sjmiles@google.com>, Erik Arvidsson <arv@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, Anne van Kesteren <annevk@annevk.nl>
I love it, gives the developer control over the addition of sugar (just a
spoonful of...) and code preference, while at the same time addressing our
requirement set. Ship it!

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


On Thu, Feb 14, 2013 at 1: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
> 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
>   }
> });
>
> The constructor way:
>
> function MyButton() {
>  // do constructor stuff ...
> }
> MyButton.prototype = Object.create(HTMLButtonElement.prototype, {
>  ...
> });
> document.register(‘x-button’, {
>  constructor: MyButton,
>  ...
> });
>
> 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:11:27 GMT

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