Re: [w3c/webcomponents] components v1 native implementation - inner components problem (#615)

Thanks for fixing the jsbin demo.  I can see your problem now.

So when HTML parser sees the `<tag-1>...`, the following sequence happens in Chrome:

1. recognize opening `<tag-1>`
2. construct `tag1`
3. connect `<tag-1>` to its parent (`connectedCallback()` is called - adds `xx` as innerHTML)
4. recognize `aa` and append to `<tag-1>`
5. recognize `<tag-2> TAG2 </tag-2>` and append to `<tag-1>`
6. recognize `bb` and append to `<tag-1>`
7. recognize closing `</tag-1>`

which results in showing `xxaa TAG2 bb`, and you describe as *incorrect*.

For `.innerHTML` case, roughly the following happens

1 `<tag-1>aa<tag-2> TAG2 </tag-2></tag-1>` are parsed by fragment parser, which does not synchronously construct custom elements (thus `<tag-1>` and `<tag-2>` remain HTMLElement)
2. construct DOM fragment (`<tag-1>` as root)
3. append the fragment to its parent
4. upgrade `<tag-1>`, `<tag-2>` in this order - `constructor()` and `connectedCallback()` are called

In this case, `<tag-1>`'s children are all available when its `connectedCallback()` is called, thus `.innerHTML = 'xx'` wipes away all the children and replaces them with `xx`.

Both cases are expected with the current specification. So in general, you are allowed to touch `innerHTML` in `connectedCallback()` unlike `constructor()` in which you aren't, but the readiness of children may differ.

I tested with Safari (10.1.1 and TP34), and all 4 cases show `xx` inside `<tag-1>`, while on Chrome only the third case show `xx`.

 @rniwa @dominiccooney @domenic looks like the timings of running `connectedCallback()` microtask differ between Blink and WebKit.  Is this an interop issue?

-- 
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/615#issuecomment-314324723