Re: [w3c/webcomponents] Consider adding a childrenChangedCallback or something (#619)

> Now in almost all implementations connectedCallback behave as connectedAndParsedChildrensCallback 

Let's assume that's true. As far as I know there's only two mostly complete implementations of this. Something happening in "almost all" of two isn't *that* persuasive to me.

> For example if need header/footer can write this.innerHTML="Header ..."+this.innerHTML+"Footer..."; With new specification this simple task will be impossible or need complicated code with childrenChangedCallback/MutationObservers.

Is there a specific proposal you're referring to? I don't think anyone is proposing the behavior of innerHTML will change. That uses fragment parsing. Custom elements get upgraded and see populated child nodes (unless another custom element modifies them.)

I think there's a slightly bigger point here, and that's what an element *should* do. The built-in elements can all be created by document parsing, fragment parsing (such as innerHTML), createElement, etc. and you can modify their children and they respond to those modifications. Jan is codifying some of these patterns in [this checklist](https://github.com/webcomponents/gold-standard/wiki); "detached instantiation" and ["content changes"](https://github.com/webcomponents/gold-standard/wiki/Content-Changes) are relevant to this discussion. One side effect of having main document and innerHTML parsing be so different means you pretty much have to respond to content changes, although it's more work.

Another argument I have heard against responding to content changes is performance. Some authors want to process custom elements like macros and it's inefficient for them to continue to get connectedCallbacks. HTML has a legacy wart like that—isindex.

Ideally we want something where it's possible, even easy, to do the right thing (which probably means responding to content changes.)

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