Re: [w3c/webcomponents] Custom Element definition ordering can cause difficult-to-find bugs. (#668)

There was according to https://bugs.chromium.org/p/chromium/issues/detail?id=658119#c4 a proposal for adding an "end tag parsed" callback to the spec. It seems to me that such a thing would clear this up. Let's call it `readyCallback` to stick with that jQuery terminology.

```javascript
  /**
   * Fires when the local DOM subtree has been fully parsed
   * and, if we are lucky, all nested CEs are fully upgraded :)
   */
  readyCallback() {
    if(this.querySelector('form')) {
      this.classList.add('interactive');
    }
  }
```

Note that the example use case doesn't involve nested custom elements, just plain elements, because I think those are important to keep in mind.

I haven't been far enough down this rabbit hole to tell if it would solve everything, because I abandoned my plan of basing our custom hacked framework on Custom Elements as soon as this issue became apparent. I think it is a real problem. It could also be fixed in another spec if the `DOMContentLoaded` event was rigged to fire upon all nodes for whom this particular listener was added.


```javascript
  connectedCallback() {
    this.addEventListener('DOMContentLoaded', () => {
      if(this.querySelector('form')) {
        this.classList.add('interactive');
      }
    });
  }
```

In any case, the spec does need to come up with a way for custom elements to synchronously evaluate the descendant subtree before it switches to Mutation Observers to monitor future updates, or at least it needs to formalize the use of `setTimeout` as a workaround for anyone who plans to build something moderately complicated. Perhaps I have overlooked something, but issues such as this makes me convinced that it is really not possible.

-- 
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/668#issuecomment-335003943