Re: [webcomponents] [Custom] attachedCallback and detechedCallback should be removed (#286)

Hmm, I'm a little confused how this squares with https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0517.html where (by my reading) @bzbarsky and @coonsta point out that the primitive inside implementations today is in fact the same as attachedCallback and detachedCallback, and @annevk agrees that it's probably best to update the DOM/HTML to work in terms of those concepts.

See especially

- https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0572.html
- https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0577.html
- https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0587.html
- https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0588.html

So I'm not entirely sure what the proposal is here. Maybe it is for something similar to `insertedIntoCallback(Node insertionPoint)`/`removedFromCallback(Node insertionPoint)`? That is not what #222 proposes though. And it does not solve one of the primary use cases of `detachedCallback`, of telling when you're ancestor is removed from the document, which is used [68 times in Blink's HTML elements](https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0572.html).

I could see advocating for the addition of insertedInto/removedFrom, but we'd also need attachedCallback/detachedCallback to handle the HTML spec's many [in a document](https://html.spec.whatwg.org/#in-a-document) occurrences.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/286#issuecomment-123169994