Re: [w3c/webcomponents] connectedCallback timing when the document parser creates custom elements (#551)

I apologize for continuing a thread that's closed, but I'm worried I might be confused -- shouldn't there be 2 children (instead of *no* children) in the `connectedCallback` in @WebReflection's first example (because it's an upgrade, where the children have already been appended to the element)?

In an upgrade:

0. (There is an `HTMLUnknownElement` with children)
1. Enqueue attribute callbacks
2. Enqueue the connected callback
3. Run the constructor (with children)
4. (some time later) Run the callbacks (attributes and connected) (with children)

vs. when parsing:

1. Parser hits start tag (so it hasn't seen children yet)
2. Create an element
  1. Find custom element definition
    1. Run microtasks (which runs any waiting reaction callbacks)
    2. Run the constructor (no children here)
  2. Otherwise make a normal HTML element
3. Append attributes (and enqueue attribute callbacks if custom element)
4. Run callbacks (just attributes at this point) (no children yet)
5. Insert the element
  1. Actually insert, set up `parentNode`, etc.
  2. Enqueue connected callback
  3. Run any callbacks (e.g. the connected callback) (new in https://github.com/whatwg/html/pull/1707, which solves the initial issue here) (still no children yet)
6. Parser continues on and hits the start tag for the first child (go back to step 1)

Do I have that right?

*In this case, I don't think @WebReflection's second example would help anything or guarantee children are present, right?*

As an everyday web developer, this generally makes sense and seems fairly straightforward to *me*. When parsing, the start tag is the thing that represents the element (not the end tag) and is what triggers construction, attributes, and insertion (in that order), whether an element is custom or not. The end tag is merely a marker that tells the parser where to do the insertion (that is, it's a *parser instruction* and not really anything to do with the DOM).

Upgrades are the special magic that allows me to attach my behavior to an element that already exists and has been fully set up. **(And thank you @domenic and everyone who fought to keep upgrades in the spec; they are incredibly useful to have even when they complicate things.)**

I will echo that my naive first reaction is to ask for a `finishedParsingEndTagCallback` or something, but I ultimately think @annevk's comment that "the whole idea of initial children is flawed" is probably right. While I thirst for a way to unifying parsing and upgrading, having a way to get the "initial children" while parsing still doesn't unify them with the live reality of an element that can have children appended to it later. It's probably better to unify all three cases with ideas like `childListChanged` callbacks.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/551#issuecomment-242586704