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

> > @jakearchibald I agree that there are some builtin elements that use the end tag notification, but it's not clear to me we should expose that. Certainly the kinds of components people bring up shouldn't require parity with them.
> 
> This is a very good point. While `<script>` and `<style>` are arguably fairly "magic", other controls seem like they should provide a good model for web component versions. Several of those **do** have things that happen only when all children are parsed. Some examples:
> 
> * The `<video>` element [waits](https://sourcegraph.com/github.com/WebKit/WebKit/-/blob/Source/WebCore/html/HTMLMediaElement.cpp?L833:24) until all children are present before evaluating contained tracks.
> * The `<input>` element [waits](https://sourcegraph.com/github.com/WebKit/WebKit/-/blob/Source/WebCore/html/HTMLInputElement.cpp?L829:24) until all children are present before setting checked-ness.
> * The `<form>` elements [waits](https://sourcegraph.com/github.com/WebKit/WebKit/-/blob/Source/WebCore/html/HTMLFormElement.cpp?L951:23) until all children are present before attempting form state restoration.

If browsers ate their own dog food, i.e. created the native elements with the CustomElements API, we would see a lot of changes to make custom webcomponents usage much more practical. Unfortunately it would be much slower than the C++ implementation, so it's not going to happen. But in an ideal world, how browser create web components, should be the same way user do, that will ensure feature parity.

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

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