This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22565 - [Custom]: rename inserted/removedCallback to entered/leftDocumentCallback
Summary: [Custom]: rename inserted/removedCallback to entered/leftDocumentCallback
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 14968
  Show dependency treegraph
 
Reported: 2013-07-03 22:31 UTC by Dimitri Glazkov
Modified: 2013-08-29 21:50 UTC (History)
8 users (show)

See Also:


Attachments

Description Dimitri Glazkov 2013-07-03 22:31:12 UTC
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.
Comment 1 Anne 2013-07-12 22:11:07 UTC
That's called insert and remove by the DOM though and its various methods.
Comment 2 Daniel Buchner 2013-07-13 04:24:02 UTC
(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.
Comment 3 Scott Miles 2013-07-13 05:02:29 UTC
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'.
Comment 4 Dimitri Glazkov 2013-08-26 18:26:36 UTC
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).
Comment 5 Dimitri Glazkov 2013-08-26 18:33:11 UTC
https://dvcs.w3.org/hg/webcomponents/rev/3d4a6a4e4a3d, but will keep the bug open to hear reactions to enteredView/leftView idea.
Comment 6 Scott Miles 2013-08-26 18:35:11 UTC
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.
Comment 7 Daniel Freedman 2013-08-26 18:36:10 UTC
As long it's well explained that *View is not related to "element is in the visible rect on screen".
Comment 8 Dimitri Glazkov 2013-08-29 21:50:05 UTC
https://dvcs.w3.org/hg/webcomponents/rev/91083383c13c