- From: Domenic Denicola <d@domenic.me>
- Date: Fri, 21 Aug 2015 16:29:05 +0000
- To: Maciej Stachowiak <mjs@apple.com>
- CC: public-webapps <public-webapps@w3.org>
From: Maciej Stachowiak [mailto:mjs@apple.com]
> On Aug 17, 2015, at 3:19 PM, Domenic Denicola <d@domenic.me> wrote:
>
> > - 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
>
> Did you change that relative to the spec? Previously, parser-created custom
> elements would have their constructor called at a time when an
> unpredictable number of their children were present.
You're right that I didn't get this quite spelled out. Fortunately, given your below suggestion, I would have had to rewrite it anyway :).
> > - 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 you really got it down to two states, I like reducing the number of word
> states, but I would prefer to put parser-created custom elements in this
> second bucket. They should have their constructor called while they have no
> children and attributes, instead of when they have all of them.
This seems reasonable and doable. Here's my try at making it work:
- Diff from previous revision: https://github.com/w3c/webcomponents/pull/297/files?short_path=876522d#diff-876522df93719f9da9871064880af5d2
- All together: https://github.com/domenic/webcomponents/blob/constructor-dmitry-revisions/proposals/Constructor-Dmitry.md
> If any of this happens, an upgradeable element will be stuck in the pre-
> upgrade state for a possibly unboundedly long amount of time.
This seems totally fine to me though. You're basically saying that you don't upgrade elements that are left often. Not a big deal. You have to actually have a full `<x-custom-foo>...</x-custom-foo>` before you get a proper custom element. Just `<x-custom-foo>...` alone does not cut it.
> Against this, we have the proposal to forcibly put elements in a naked state
> before calling the constructor for upgrade, then restore them. That has the
> known bad property of forcing iframe children to reload. I owe the group
> thoughts on whether we can avoid that problem.
>
> ...
>
> I will read the document more closely soon, to see if it seems like a
> reasonable baseline. I agree it would be fine to start with something good
> that uses the constructor and has two possible stats for constructor
> invocation, then see if we can get it down to one.
Awesome! And yeah, the intent of this was exactly to provide such a baseline, and see if we could come up with a good solution for reducing the two states down to one using trickery such as that you mention. As a summary, after the above changes we have these two states:
- Upgraded custom elements, or elements created via other algorithms that are constructing a larger tree (such as cloneNode), will have their constructor and attributeChange callbacks called at a time when all their children and attributes are already present.
- Elements created via new XCustomElement() or document.createElement("x-custom-element") or via the parser will have their constructor run at a time when no children or attributes are present.
Note that we could move "elements created via other algorithms that are constructing a larger tree" into the latter bucket too, at the cost of synchronous script execution during all such algorithms. But the UA appetite for that was... mixed, and I don't think we should do so. It seems fine to leave their fate the same as upgrades, whichever way it shakes out.
Received on Friday, 21 August 2015 16:29:38 UTC