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

Right. Upon reading comment https://github.com/w3c/webcomponents/issues/668#issuecomment-334988964 again, it sounds to me like the issue is actually fixed in the native implementation and that perhaps this appears worse than it really is because the polyfill uses Mutation Observers for some kind of asynchronous implementation?

In that case, the solution is easy: Just wait for `DOMContentLoaded` before you do anything, including the registration of Custom Elements. I personally believe that all scripting should be suspended until this moment because anything that goes before is just confusing and will only lead to the event being fired later which in turn sustains the need to perform scripting before the event happens. It is in other words an arms race. Anyways, during initial parse the situation (as I imagine it) is equivalent to this:


```html
  <ul>
    <script>alert(document.querySelector('ul').innerHTML</script>
    <li>One</li>
    <li>Two</li>
    <li>Three</li>
  </ul>
```

This will alert then `<script>` tag without the `<li>` elements simply because the parser haven't found them yet, so it is not a problem that is unique to Custom Elements, it us just unfortunate that the upgrade process can happen during this stage of parsing. Perhaps the suggestion should be to postpone the upgrade to `DOMContentLoaded`? My own findings were based on the very first native implementation (v0) in Firefox and I am not in a position to verify if it is indeed fixed nowadays, it does sound like a problem with the polyfill, but upgrades during initial parsing do seem bound to be permanently confusing.

-- 
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-335005935