W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2015

Custom elements "Constructor-Dmitry" baseline proposal

From: Domenic Denicola <d@domenic.me>
Date: Mon, 17 Aug 2015 22:19:58 +0000
To: public-webapps <public-webapps@w3.org>
Message-ID: <CY1PR0501MB136946EF0E53CFEAD7812B4EDF790@CY1PR0501MB1369.namprd05.prod.outlook.com>
In https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Constructor-Dmitry.md I’ve written up in some detail what I consider to be the current state-of-the-art in custom elements proposals. That is, if we take the current spec, and modify it in ways that everyone agrees are good ideas, we end up with the "Constructor-Dmitry" proposal.

The changes, in descending order of importance, are:

- Don't generate new classes as return values from registerElement, i.e. don't treat the second argument as a dumb { prototype } property bag. (This is the original "Dmitry proposal".)
- Allow the use of ES2015 constructors directly, instead of createdCallback. (This uses the constructor-call trick we discovered at the F2F.)
- Use symbols instead of strings for custom element callbacks.
- Fire attributeChanged and attached callbacks during parsing/upgrading

Those of you at the F2F may remember me saying something like "If only we knew about the constructor call trick before this meeting, I think we would have had consensus!" This document outlines what I think the consensus would have looked like, perhaps modulo some quibbling about replacing or supplementing attached/detached with different callbacks.

So my main intent in writing this up is to provide a starting point that we can all use, to talk about potential modifications. In particular, at the F2F there was a lot of contention over the "consistent world view" issue, which is still present in the proposal:

- Parser-created custom elements and upgraded custom elements will have their constructor and attributeChange callbacks called at a time when all their children and attributes are already present, but
- Elements created via new XCustomElement() or document.createElement("x-custom-element") will have their constructor run at a time when no children or attributes are present.

If we still think that this is a showstopper to consensus (do we!?) then I hope we can use this proposal as a baseline from which to derive additive solutions. Alternately, maybe you all will read this proposal and be amazed at how great it is already, and agree we can move on, leaving the consistent world view issue aside as an edge-case that shouldn't prevent cross-browser consensus on custom elements :)
Received on Monday, 17 August 2015 22:20:28 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:34 UTC