****Update****

I found an example of a working container on Github

Fancy tab
From: ebidel
https://gist.github.com/ebidel/2d2bb0cdec3f2a16cf519dbaa791ce1b

I simplified it to the bones to compare it to my code (the one I provided before).

There was my surprise, after many hours of pruning code and shuffling things around: I could also break his code if I moved the HTML containers elements instances AFTER the scripts defining his custom elements (classes and define).

I did the reverse and moved my containers instances BEFORE my classes definitions scripts. EUREKA! My code worked. (I attached the modified working code).

This is counter intuitive. In most languages and platforms, especially HTML, we first define our elements and rules, then we use instances of those definitions. Even in JavaScript, classes definitions are not hoisted (contrarily to functions) and MUST precede any instance creation.

In this case, it will only work if we use something undefined and ignored (partially) by the interpreter at first and then define it officially later. OUCH!

Looking at the custom element specs, https://developers.google.com/web/fundamentals/getting-started/primers/customelements#upgrades

it seems that this is called UPGRADING an element i.e. using it before it is defined and defining it later. It insured in my case and ebidel's case that all the children already existed in the DOM when the container's'connectedCallback was called. 

In retrospect, defining custom elements before using them (typically with a definitions inclusion at the beginning of the HTML file) will not work for containers of custom elements. Also, no more can we look at the innerHTML and child nodes from a parent node's perspective during parsing.

*****I must remind you that if the inner children were native elements (instead of custom), everything worked as expected initially and all the children are ALREADY created when the container is called, even if we define the custom container BEFORE the elements' instantiation (inclusion at the begining).

It is too schizophrenic to have 2 different types of logic, one for native elements, and a new ugly beast for the custom elements. We DO WANT custom elements to be created and behave like native elements. It should be transparent to the coder. It is the whole point of custom elements! If my understanding is right, the implementation or specs is probably flawed here. 

I would like clarifications about this behavior. I'm convinced many will profit from it. I find really suspicious that I would have to do those includes at the end of the HTML page. It definitively breaks so many rules about HTML that the solution I found can be qualified at best as ugly, hacky and temporary.

Hopefully I totally missed something crucial and someone will enlighten me. 

Deleted: Test.php 1.5 KB

Test.php 1.5 KB View Download

Blink>WebComponents is deprecated.

CCing domenic and esprehn FYI re: custom elements design, microtask control, etc.

I'm closing this as WontFix because I think this is working as intended and per the spec, even though the behavior is surprising. domenic can sanity check me on that.

Some contributors to the spec considered a callback for "end tag parsed" which would be a good time to inspect children if you were doing "one shot" processing of children, however IIRC the decision was to not add this callback yet.

If you want a custom element's behavior to depend on its children you should use a MutationObserver or have the children coordinate with the container through events/methods/etc.