Re: [WICG/webcomponents] Need a callback for when children changed or parser finished parsing children (#809)

> I think the problem is that an end tag notification doesn't cover all cases

it covers the only case that's not covered, and it shouldn't guarantee anything else *but* signaling the parser knows that node closed *or* the parser decided to close it (i.e. open body for sloppy cases).

It's been years we've discussed this (I've asked for this and provided libraries and workarounds) and meanwhile every library used to parse even streamed content is capable of signaling the end of a tag.

What happens internally with that tag is not responsibility of such end tag notification.

The most popular user-land parser has an [onclosetag](https://github.com/fb55/htmlparser2#usage) which helps a lot for SSR hydration cases and it's still not clear why the DOM itself cannot provide a way to understand the same: a `</close>` tag has been encountered (or a `</close-element>` for custom elements only, that'd be already something as *parsedCallback*) and I see the usual two ways custom elements work that could both be useful in all cases:

  * the element is being parsed (previously defined as CE, not fully parsed yet): `constructor`, `attributeChanged` (if any observed and changed), `connected` and `parsed` **whenever that happens**
  * the element is already live and parsed and it's being upgraded due lazy CE definition: `constructor`, `attributeChanged` (if any observed and changed), `connected` and `parsed` right after

The `parsedCallback` would basically be the *init* method that can't be the constructor itself due this dual nature of already known or declared at distance tat Custom Elements are either famous or cursing developers for, making it the perfect place to eventually define a *MutationObserver* if internal changes are meant to be observed.

It would be a *fix them all* solution developers need to harakiri themselves otherwise with intervals, MO that don't really guarantee anything, timers, and all other possible error-prone approaches that *still* don't guarantee anything ... we've been talking workarounds forever but still debating how to solve this.

Both @rniwa and @jakearchibald gave reasonable solutions ... I'd say pick the easiest to implement and see how that plays for real in the wild, then consider signaling that event to CSS ... where I'd honestly rather use a `element:not-parsed` instead of `element:parsed`, simply because `element:parsed` is what everyone writing CSS already assume is the correct default behavior, and I don't think we want everyone to write more verbose CSS to be sure these are applied only once the element is fully known ... we want escape cases instead for those not-always-common cases the element is huge and its end tag hasn't been reached yet (imho).

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

Message ID: <WICG/webcomponents/issues/809/1463698914@github.com>