- From: Daniel Buchner <daniel@mozilla.com>
- Date: Thu, 14 Feb 2013 14:10:27 -0800
- 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>
- Message-ID: <CAHZ6zJGS9K6LK2+OU-W7b68FbaBps2CH+M8yMr3GHNvG_v1HUA@mail.gmail.com>
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 UTC