Re: [whatwg/dom] Custom element callback/promise for "connected and parsed" (#662)

patricknelson left a comment (whatwg/dom#662)

@trusktr 

> A connectedParsedCallback would be nifty to avoid work until parsing is done, but we probably also need a way to know when we get connected without parsing.

It sounds like the specific problem as you described it can already be resolved with a straightforward check to see if `document.readyState` is still `loading` in an existing `connectedCallback` and, if so, waiting to do your initialization by listening to the `DOMContentLoaded` event. Similar situation for @Jamesernator's problem in https://github.com/whatwg/dom/issues/662#issuecomment-404054274. In his case, the issue isn't with the `.define()` timing per se, it's just that the parser is still working. 

<details><summary>Essentially this...</summary>

Modified from example at https://github.com/whatwg/dom/issues/662#issuecomment-404054274:

```js
class XModuleTest extends HTMLScriptElement {
 connectedCallback() {
  if (document.readyState === 'loading') {
   // Still parsing children, wait for DOMContentLoaded or readystatechange...
   document.addEventListener('DOMContentLoaded', () => this.init())
  } else {
   // HTML children parsed already
   this.init()
  }
 }
 init() {
  console.log(this.text)
 }
}
```
</details>

However, that's watching global state and we want something faster than that.

Specifically: I think this GitHub issue is more concerned about explicitly letting us know when the HTML parser itself is done parsing a particular element's HTML contents and has moved on in the DOM tree, effectively reaching the closing tag of that element while still in the `loading` state (i.e. still parsing). This is tricky you realize that other scripts on the page (including the current element) can _also_ mutate both children and adjacent siblings while the parser is also actively parsing and updating the DOM. I believe the goal here would be to have a known _consistent and deterministic_ way in which the parser can signal to an element that it has completed processing that particular element's HTML contents regardless of that. 

That's why @franktopel's polyfill for this at https://github.com/WebReflection/html-parsed-element is so interesting to me, because it acts much more quickly without relying on global state. It relies on a `MutationObserver` that basically waits until it sees a `.nextSibling` and fires a custom `parsedCallback` in a `requestAnimationFrame`. This isn't exactly the same thing, but it's functionally very close. Remember: Other scripts can still be appending to the same parent! It seems to work well in my isolated tests, but I don't know how well it works in the real world in much larger and more complex documents yet.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/662#issuecomment-5724824703
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/662/5724824703@github.com>