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

perrelet left a comment (WICG/webcomponents#551)

Great to see some momentum on this issue ⛵

**Full disclosure:** I write full-stack but rarely have to navigate these frontend spider-webs since we handle most templating [server-side](https://htmx.org/). From what I understand, Web Components were an attempt to make certain client-side framework features native—though some of those features were arguably [anti](https://gist.github.com/Widdershin/98fd4f0e416e8eb2906d11fd1da62984)-[patterns](https://lea.verou.me/blog/2020/09/the-failed-promise-of-web-components/) [to](https://gomakethings.com/the-shadow-dom-is-an-antipattern/) [begin](https://i.ibb.co/Z1XNTf1f/cgofpd5o2rwb1.jpg) [with](https://github.com/1cg/html-json-speed-comparison). IMHO, we would all be much better off in 2025 if W3C had focused its efforts on completing [HTML](https://intercoolerjs.org/2020/01/14/taking-html-seriously) as [hypermedia](https://htmx.org/essays/hateoas/) rather than chasing framework abstractions.

`</rant>`

The colorful conversation of issue #551 demonstrates a chasm in web-dev today. On one hand you have those who can't seem to comprehend why anyone would need to know the initial state of an elements decedents:

> No. We absolutely want zero children in as many places as possible. The whole point is that you should not depend on children, since you cannot depend on them with createElement() either. Web developers should create robust custom element implementations, not half-baked ones. ~ [annevk](https://github.com/annevk)

> The whole idea of initial children is flawed. Children are dynamic. ~ [annevk](https://github.com/annevk)

On the other, you have end-users with very real use-cases:

> So what approach is supposed to be used with loads of components in a page of which many rely on their children to setup? I mean, transforming their content which comes as plain HTML from the serverside to something different from my perspective is one of the main use cases for autonomous custom elements, as well as for customized built-ins which usually serve as containers for child elements. ~ [franktopel](https://github.com/franktopel)

> Not being able to see children in elements at connectedCallback() seems like a pretty big hassle when dealing with wrappers that are needed because of lack of support for customized built-in elements. ~ [justinfagnani](https://github.com/justinfagnani)

It feels like the spec tied it's own shoelaces together by assuming the entire universe could be expressed as atomic custom elements, when extending the most humble inbuilt element [remains out of reach](https://github.com/WebKit/standards-positions/issues/97). We need flexible custom elements that are declarative, semantic and SEO performant. Since [`Elements !== Components`](https://dev.to/ryansolid/web-components-are-not-the-future-48bh), in the meantime, those of us that don't use [JavaScript for everything](https://www.youtube.com/watch?v=lc5Np9OqDHU), simply need a consistent method to properly initialize custom elements, alongside their probably [less-than-custom](https://github.com/WICG/webcomponents/issues/551#issuecomment-241840803) children.

---

> FYI, that <last-element-in-lightDOM> "solution" has been around for many HTML/JS moons with the esoteric notation:

Thanks [Danny-Engelman](https://github.com/Danny-Engelman), yes I'm aware of the `onload` and `onerror` hacks. The intention with the proposed workaround is to do it in a Web Component way, to illustrate the insanity of not having an inbuilt `parsed` callback. As you mention, the `setTimeout` hack fails unpredictably for a large number of child nodes.

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

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