- From: Joseph Orbegoso Pea <notifications@github.com>
- Date: Mon, 29 Aug 2016 14:13:56 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/559/243258438@github.com>
@rniwa Although I run `document.registerElement` calls in the `<head>` of the `<html>` document and while the body contains ```html <some-el> <other-el> </other-el> </some-el> ``` then when the `attachedCallback` on `some-el` is called, it will be able to see the non-yet-upgraded child `other-el`, which leads me to believe that when `attachedCallback` of `some-el` is fired that the tree has already been parsed, otherwise how can the children of `some-el` be visible inside it's `attachedCallback`? It also seems that the upgrades happen in pre-order, so `some-el` is upgraded and it's `attachedCallback` fired, then `other-el` is upgraded and it's `attachedCallback` fired. However, if the elements are attached into DOM *after* the class registrations, then the `attachedCallbacks` will fire in post-order, in which case everything works fine without hacks. So, it seems there just needs to be some type of mechanism that can guarantee that `attachedCallbacks` are always fired in post-order (depth-first), and it seems that for this to happen that the upgrades should be delayed until all classes are registered. But, I'm not even sure why if I run my `document.registerElement` calls in the `<head>` why the upgrades happen in pre-order. Is this because of the parsing, as in ``` <some-el> <-- when the parser reaches here, it upgrades `some-el`? <other-el> <-- then when it reaches here it *first* calls attachedCallback on some-el, *then* upgrades other-el? </other-el> </some-el> ``` -- 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/559#issuecomment-243258438
Received on Monday, 29 August 2016 21:14:52 UTC