Re: [WICG/webcomponents] Need a callback for when children changed or parser finished parsing children (#809)

> And for parity with builtin elements that ought to work in whichever way web developers want to do things. It shouldn't impose inserting children before insertion into the document, for instance.

0. builtin elements work great, but they aren't constrained by JavaScript API. So builtin elements are not informing us about a good API because we don't know their internals.
1. Is that really a responsibility of the Web Components API or should it be a responsibility of the developer?
2. Not all web components are going to be something in a public repository that should care about having the cleanest API. I suspect most people here want to use web components in projects which don't expect to share its web components, such as servers that generate HTML for their own purposes.
3. Perhaps the funny thing here is that the web component has no idea what to expect in its own subtree, but the developer writing the HTML knows exactly what to expect. So there's this situation where the developer has to write a lot of code inside the web component for the web component to know when its subtree meets the expectations. For the developer the easiest thing would be to know when the subtree is made available by the parser to trigger the subtree-operations. **Yes**, this *does* imply that the developer writing the subtree is the same developer that is writing the web component. I think this usage of web components is rather common, is it a use case that should be neglected? Is this implying that the only priority are web components whose subtree is written by different developers?

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

Message ID: <WICG/webcomponents/issues/809/1470835748@github.com>