- From: Rick Waldron <waldron.rick@gmail.com>
- Date: Thu, 14 Feb 2013 17:10:01 -0500
- 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>
- Message-ID: <CAHfnhfr6dFaTR3w2RkDutYnY0jogFGYHswNGK7+BznmSsbXc0Q@mail.gmail.com>
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 UTC