This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We've had a few iterations trying to come up with better names for these two callbacks, but the recent review with Mozilla app developers revealed that we are still not hitting the target. The intuitively proposed "inserted" and "removed" aren't quite fitting either, because they don't actually reflect http://dom.spec.whatwg.org/#concept-node-insert and http://dom.spec.whatwg.org/#concept-node-remove. To avoid "view" terminology (which developers aren't that familiar with) and "entered/left" confusion ("leftview? why not rightview?"), we settle on something simpler: "attached" and "detached".
InsertedIntoDocument and RemovedFromDocument? That's the terminology DOM3 events use for mutation events: http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMNodeInsertedIntoDocument
(In reply to Ryosuke Niwa from comment #1) > InsertedIntoDocument and RemovedFromDocument? > > That's the terminology DOM3 events use for mutation events: > http://www.w3.org/TR/DOM-Level-3-Events/#event-type- > DOMNodeInsertedIntoDocument This is what "inserted" and "removed" mean in DOM spec. They don't quite fit, because these callbacks are only invoked when custom elements are inserted to/removed from documents with a view (the closest indication to actually being rendered we have).
You mean a document with a browsing context? What prevents us from firing events inside a document without a browsing context?
Has anyone documented yet what we call these constructs inside the browser's code? E.g. when you look at the implementation of <img> or <input>, what are Gecko/Blink/WebKit/Presto/Trident's equivalent constructs called?
(In reply to Anne from comment #4) > Has anyone documented yet what we call these constructs inside the browser's > code? E.g. when you look at the implementation of <img> or <input>, what are > Gecko/Blink/WebKit/Presto/Trident's equivalent constructs called? They're called attach/detach in Blink/WebKit.
(In reply to Dimitri Glazkov from comment #5) > (In reply to Anne from comment #4) > > Has anyone documented yet what we call these constructs inside the browser's > > code? E.g. when you look at the implementation of <img> or <input>, what are > > Gecko/Blink/WebKit/Presto/Trident's equivalent constructs called? > > They're called attach/detach in Blink/WebKit. I don't think they're the same concept. In WebKit at least, willAttachRenderers and didDetachRenderers are never called on elements that are display:none, and they are called lazily when renderers are needed. These callbacks, however, are called immediately as a custom element is inserted into a document with a browsing context. That's a radically different concept from creating a renderer.
*** Bug 24600 has been marked as a duplicate of this bug. ***
The important concept is to get called when inserted into a non inert document. This is a document with a browsing context. Basically, if you poll it should fire when the following becomes true: element.ownerDocument.contains(element) && element.ownerDocument.defaultView Use cases: - HTMLScriptElement needs to set its "has started" flag. - Audio, video and animated img elements need to start playing. (hmm that also needs to check its display). - @autofocus
Did you guys talk to Ian to make sure nothing is missed here? There's a bunch in the HTML specification that I'm not sure maps 1:1 yet with DOM primitives.
(In reply to Erik Arvidsson from comment #8) > The important concept is to get called when inserted into a non inert > document. This is a document with a browsing context. > > Basically, if you poll it should fire when the following becomes true: > > element.ownerDocument.contains(element) && element.ownerDocument.defaultView If that's really the condition, why can't scripts simply check that condition instead?
(In reply to Ryosuke Niwa from comment #10) > (In reply to Erik Arvidsson from comment #8) > > The important concept is to get called when inserted into a non inert > > document. This is a document with a browsing context. > > > > Basically, if you poll it should fire when the following becomes true: > > > > element.ownerDocument.contains(element) && element.ownerDocument.defaultView > > If that's really the condition, why can't scripts simply check that > condition instead? Polling drains battery life but even if that was not an issue the timing for these would be wrong.
(In reply to Erik Arvidsson from comment #11) > (In reply to Ryosuke Niwa from comment #10) > > (In reply to Erik Arvidsson from comment #8) > > > The important concept is to get called when inserted into a non inert > > > document. This is a document with a browsing context. > > > > > > Basically, if you poll it should fire when the following becomes true: > > > > > > element.ownerDocument.contains(element) && element.ownerDocument.defaultView > > > > If that's really the condition, why can't scripts simply check that > > condition instead? > > Polling drains battery life but even if that was not an issue the timing for > these would be wrong. I'm not suggesting polling. I'm suggesting, instead, to add callbacks that are called whenever a custom element is inserted into or removed from a document, and the script could check whether the current document has defaultView or not. Also, the fact these callbacks cannot be explained or implemented as mutation observers is problematic. I don't think we want to add completely different mechanisms and queues for custom elements when we've just recently added mutation observers.
Not even inserted or removed from a document, but simply inserted or removed. I never understood why we did go with that primitive, but I think it might be because of Chrome bugs with regards to disconnected nodes? "node is inserted" and "node is removed" are the most basic callbacks the DOM provides and it seems we should expose those. There's also various attribute callbacks.
(In reply to Anne from comment #13) > Not even inserted or removed from a document, but simply inserted or > removed. I never understood why we did go with that primitive, but I think > it might be because of Chrome bugs with regards to disconnected nodes? > > "node is inserted" and "node is removed" are the most basic callbacks the > DOM provides and it seems we should expose those. There's also various > attribute callbacks. I completely agree. In addition, we should add an option to observe insertion and removal of an observed node itself to mutation observers.
Filed bug 24866 to track adding inserted/removed.
I renamed left/enteredView to attached/detached in https://github.com/w3c/webcomponents/commit/e1daad4cb481f4533e5c709534b0b3b1e92376c2 (I totally bungled the commit message though :-\) If we decide to remove these later in favor of inserted/removed, we'll need to put a deprecated notice around them, since these names is what's shipping in Chrome.