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

WebReflection left a comment (WICG/webcomponents#551)

sorry for bothering further but I really would love a way forward for this and my latest edit might have not gone through your inbox ... the proposal here is to have a `<parsed />` void element *new* to the *HTML* standard that would hint, or better, invoke, the `parsedCallback` out of any *Custom Element* out there, so that everyone in charge can land that `<parsed />` void element at the end of a template or anything, and everyone not knowing `parsed` element exist will be in the exact same situation as today.

That `<parsed />` void element would be the trigger for the optionally provided `parsedCallback` out of any *Custom Element* class and no surprises should ever happen to user-land:

  * where nodes added after? code smell, if `<parsed />` was used
  * is flushing things affected? not at all, the `<parsed />` is awaited on the JS side that defines the *Custom Element*

If a strong **no** is received, or me banned from this channel, I assume there are non Web standard reasons to do so, as this request feels right, in terms of users expectations, it doesn't break existing *APIs* around *Custom Elements*, it does also nothing in older browsers incapable of dealing with it, plus it doesn't conflict or clash with workarounds based on the very same principle: a Web developer (front/back end) flagged the end of that *Custom Element* node.

Thanks for considering this!

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

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