This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The inserted/removed aren't as precise in describing the reason they're called, which is when the custom element enters or leaves the document.
That's called insert and remove by the DOM though and its various methods.
(In reply to comment #0) > The inserted/removed aren't as precise in describing the reason they're > called, which is when the custom element enters or leaves the document. I agree with Anne, developers are more likely to recognize these actions as 'inserted' and 'removed' - remove(), removeChild(), insertBefore(), DOM Level 3 Mutation Event legacy, etc. I would rather see the API use method names that mirror what developers are already thinking and are instantly recognizable, than ones that are excessively descriptive and obtuse. In addition, are entered/leftDocument really correct? What happens when I move a node by reference that is already in the DOM to another place in the DOM? For example: <ul> <li id="one"></li> <li id="two"></li> <li id="three"></li> </ul> var one = document.getElementById('one'), three = document.getElementById('three'); one.parentNode.insertBefore(one, three); Does 'one' ever leave the document before insertion above 'three'? Further, even if it _technically_ does, would everyday developers actually be aware of such a nuance? All this goes to the point that while enter/left may be a bit more technically correct (assuming it is still so in the above case - albeit briefly), developers are conditioned (for various reasons) to associate this behavior with inserted/removed.
The problem is that I can compose a zillion nodes into a big tree and none of them are 'inserted' until the root of that tree hits the document. IOW, what triggers this event is not necessarily any direct action or change to the node itself. It does not reflect the state of 'parentNode' which is what developers actually seem to expect from 'inserted' and 'removed'.
What do you guys think about enteredView/leftView? The thing is, these callbacks are only called on documents that have browsing context (and thus a non-null defaultView property).
https://dvcs.w3.org/hg/webcomponents/rev/3d4a6a4e4a3d, but will keep the bug open to hear reactions to enteredView/leftView idea.
I agree that the suffix `document` is confusing, since we mean a specific document (I usually think of it as window.document, but it sounds like 'document with defaultView' is more precise). From that standpoint, suffix 'view' seems to me an improvement.
As long it's well explained that *View is not related to "element is in the visible rect on screen".
https://dvcs.w3.org/hg/webcomponents/rev/91083383c13c