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 :)
