[Custom] attachedCallback and detechedCallback should be removed

[rniwa]

In addition #222, attachedCallback and detachedCallback should be removed.

While it's a viable optimization to avoid work in a custom element while the element is not in the document, there is a lot of work that needs to happen regardless of where an element is inserted.

Since the author can easily check the existence of the browsing context by checking document.defaultView or detect whether the element has display: none as the used value or not, there is no need to have a separate callback.

[domenic]

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.

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 occurrences.

[smaug----]

The methods in Custom Elements spec certainly aren't the same what Gecko has.
The spec deals only with inserting/removing from a document in a browsing context, but
Gecko at least doesn't care whether there is browsing context and it gets a notification whenever ancestor chain has changed.
As bz said in https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0577.html

[rniwa]

This will be resolved in the issue #362.