Re: [w3c/webcomponents] connectedCallback timing when the document parser creates custom elements (#551)

As a [data point](https://github.com/ampproject/amphtml/search?q=buildcallback+BaseElement&unscoped_q=buildcallback+BaseElement), AMP's custom element base class has a custom callback called `"buildCallback"` named to signal the point when custom elements should be safe to "build" there child structure.

This is currently implemented as:

- `connectedCallback` fired
- the element or its parent elements have a `nextSibling`
- OR DOMContentLoaded is reached
- OR a MutationObserver triggers and we recheck above conditions

For the vast majority of elements this is strictly a better time to do initialization than `connectedCallback`. Currently `connectedCallback` may be called with and without children present. That kind of racy behavior leads to bugs all over the place. Requiring use of MutationObserver for cases where actual mutations are unexpected is a really bad programming model and prone to buggy code.

Of course, some custom elements must be initialized before children are parsed. This is primarily the case for container elements that may have large amounts of child nodes and waiting for all of them to parse would break streaming rendering. This needs to continue to be supported but that isn't a good argument that there shouldn't be a shortcut for the the more common use case.

-- 
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/551#issuecomment-430638054