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

> [@franktopel](https://github.com/franktopel) : The problem then is that the element won't get `connectedCallback` until all children are parsed. For example, if the entire document was a single custom element, that custom element would never receive `connectedCallback` until the entire document is fetched & parsed even though the element is really in the document. That would be bad.

Applying the same logic, `.remove()` removes an element, if you use `.remove()` on an html element it would remove the whole document. "That would be bad". So we don't need `.remove()`. 

Theres probably somewhere out there someone who is looking for exactly that. Instead treating developers like children, and giving them half a toolbox, let us design and make the trade off ourselves.

> 
> Alternatively, we could add something like `finishedParsingChildrenCallback` but then again, any JS could insert more child nodes after the parse had finished inserting children.

Yes that's fine, and a difference issue to handle. As mentioned many by others, for peformance reasons, one doesn't wish to caclulate a layout *every* time a child is added, only when all children have been added, at that point, a mutation observer can be attached if requried. These are two different concepts, hence this issue exists.

> 
> In general, the recommended approach is to either use MutationObserver to observe children being added or removed, or to have a child element notify the parent as it gets inserted. That's the only way a custom element would be able to behave correctly when JS, HTML parser, etc... inserts more children or remove some.

As mentioned above this would be much more inefficient, compared to a callback that handles oncee all children have been parsed, and then possibily setting up a MutationObserver for future children if required. There are many instances where the mutation will not happen, and a simple method that fires on a callback will do the trick and avoid many race conditions, arguably the most common case.

Question: Why are people so against adding it? If people want to misuse it or abuse, let them. We are adults. Same logic as say banning fire, or banning people playing in the sea, cause it may be dangerous.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/551#issuecomment-2656467320
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/551/2656467320@github.com>