Re: Custom Elements: insert/remove callbacks
On 5/9/15 12:40 PM, Anne van Kesteren wrote: So that seems clearly wrong (in the specification)... Are descendants notified in tree order? In Gecko, yes. Note that running script during these insert/remove notifications is not OK, so anything that needs to run script has to do it later (for various definitions of later). -Boris
Re: Custom Elements: insert/remove callbacks
On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/8/15 1:42 AM, Elliott Sprehn wrote: That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node insertionPoint) Node#removedFrom(Node insertionPoint) To be clear, ours is also in the form of two methods (BindToTree/UnbindFromTree) that take various arguments. The DOM only has insert/remove hooks: https://dom.spec.whatwg.org/#concept-node-insert-ext https://dom.spec.whatwg.org/#concept-node-remove-ext So that seems clearly wrong (in the specification)... Are descendants notified in tree order? I filed https://github.com/whatwg/dom/issues/34 to track this. -- https://annevankesteren.nl/
Re: Custom Elements: insert/remove callbacks
On May 9, 2015 9:41 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/8/15 1:42 AM, Elliott Sprehn wrote: That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node insertionPoint) Node#removedFrom(Node insertionPoint) To be clear, ours is also in the form of two methods (BindToTree/UnbindFromTree) that take various arguments. The DOM only has insert/remove hooks: https://dom.spec.whatwg.org/#concept-node-insert-ext https://dom.spec.whatwg.org/#concept-node-remove-ext So that seems clearly wrong (in the specification)... Are descendants notified in tree order? Yes, and anything that can run script is notified in a second pass. So for example if you create a script, put it in a subtree, then append the subtree, the script runs after all insertedInto notifications have been sent to the subtree. - E
Re: Custom Elements: insert/remove callbacks
On Thu, May 7, 2015 at 10:56 PM, Elliott Sprehn espr...@chromium.org wrote: On Thu, May 7, 2015 at 10:44 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 8, 2015 at 7:42 AM, Elliott Sprehn espr...@chromium.org wrote: That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node insertionPoint) Node#removedFrom(Node insertionPoint) where insertionPoint is the ancestor in the tree where a connection was added or removed which may be arbitrarily far up the ancestor chain. From that you can figure out all the cases Boris is describing. Cool. So maybe the DOM specification needs to be updated to have that model and we should expose that as low-level hook to web developers. We'd consider adding a new MutationObserver type, we'd prefer not to add any more tree mutation callbacks. Anything you can do with those you can do with an ancestorChanged record type and takeRecords(). We should think hard before adding ancestor information to MutationObservers; like other DOM-tree-related APIs, they are very much based around the model of information coming up the tree from below (you can imagine how odd it would be to add event dispatch that flowed down the tree towards the leaves). - Adam
Re: Custom Elements: insert/remove callbacks
On 5/8/15 1:42 AM, Elliott Sprehn wrote: That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node insertionPoint) Node#removedFrom(Node insertionPoint) To be clear, ours is also in the form of two methods (BindToTree/UnbindFromTree) that take various arguments. I just described the conceptual information that one can typically get based on what all those arguments are. It also happens that in Gecko the Bind/Unbind functions aren't pure notification; they are also responsible for doing things like setting the parent pointer as needed. But yes, the upshot is that the two cases are pretty similar. Gecko doesn't have on hand the exact node that the insertion/removal happened at, but adding that would not be a big deal. -Boris
Re: Custom Elements: insert/remove callbacks
On Thu, May 7, 2015 at 4:43 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani justinfagn...@google.com wrote: How are you supposed to tell if one of your ancestors was removed? Is that a hook builtin elements have today? Blink's built-in elements' hook is inserted into/removed from document, including via an ancestor being manipulated as you can see here (this--Node::removedFrom--is the removed case): https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/ContainerNode.cppsq=package:chromiumtype=csl=834rcl=1430970612 This is overridden 68 times by various kinds of nodes including many elements. What it's used for varies; one example is the HTMLMarqueeElement that stops a callback that's driving its animation. If you were trying to implement MARQUEE as a Custom Element, you'd want this callback to call clearTimeout, cancelAnimationFrame, or whatever. There are similar hooks and uses for insertion. The HTML spec itself points to a lot of uses for this; when it switches on things being in a document https://html.spec.whatwg.org/#in-a-document and something needs to be done/updated/etc. to implement that effect. -- https://annevankesteren.nl/
Re: Custom Elements: insert/remove callbacks
On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani justinfagn...@google.com wrote: How are you supposed to tell if one of your ancestors was removed? Is that a hook builtin elements have today? -- https://annevankesteren.nl/
Re: Custom Elements: insert/remove callbacks
On 5/7/15 3:43 AM, Anne van Kesteren wrote: On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani justinfagn...@google.com wrote: How are you supposed to tell if one of your ancestors was removed? Is that a hook builtin elements have today? In Gecko, yes. The set of hooks Gecko builtin elements have today is, effectively: 1) This element used to not have a parent and now does. 2) This element has an ancestor that used to not have a parent and now does. 3) This element used to have a a parent and now does not. 4) This element has an ancestor that used to have a parent and now does not. -Boris
Re: Custom Elements: insert/remove callbacks
On Thu, May 7, 2015 at 10:44 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 8, 2015 at 7:42 AM, Elliott Sprehn espr...@chromium.org wrote: That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node insertionPoint) Node#removedFrom(Node insertionPoint) where insertionPoint is the ancestor in the tree where a connection was added or removed which may be arbitrarily far up the ancestor chain. From that you can figure out all the cases Boris is describing. Cool. So maybe the DOM specification needs to be updated to have that model and we should expose that as low-level hook to web developers. We'd consider adding a new MutationObserver type, we'd prefer not to add any more tree mutation callbacks. Anything you can do with those you can do with an ancestorChanged record type and takeRecords(). - E
Re: Custom Elements: insert/remove callbacks
On Fri, May 8, 2015 at 7:42 AM, Elliott Sprehn espr...@chromium.org wrote: That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node insertionPoint) Node#removedFrom(Node insertionPoint) where insertionPoint is the ancestor in the tree where a connection was added or removed which may be arbitrarily far up the ancestor chain. From that you can figure out all the cases Boris is describing. Cool. So maybe the DOM specification needs to be updated to have that model and we should expose that as low-level hook to web developers. -- https://annevankesteren.nl/
Re: Custom Elements: insert/remove callbacks
On Thu, May 7, 2015 at 10:24 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 7, 2015 at 10:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: In Gecko, yes. The set of hooks Gecko builtin elements have today is, effectively: 1) This element used to not have a parent and now does. 2) This element has an ancestor that used to not have a parent and now does. 3) This element used to have a a parent and now does not. 4) This element has an ancestor that used to have a parent and now does not. So that is more granular than what Dominic said Chrome has. I wonder why there's a difference. Normally at the low-level things are pretty close (or have a difference like linked list vs array). That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node insertionPoint) Node#removedFrom(Node insertionPoint) where insertionPoint is the ancestor in the tree where a connection was added or removed which may be arbitrarily far up the ancestor chain. From that you can figure out all the cases Boris is describing. - E
Re: Custom Elements: insert/remove callbacks
On Thu, May 7, 2015 at 10:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: In Gecko, yes. The set of hooks Gecko builtin elements have today is, effectively: 1) This element used to not have a parent and now does. 2) This element has an ancestor that used to not have a parent and now does. 3) This element used to have a a parent and now does not. 4) This element has an ancestor that used to have a parent and now does not. So that is more granular than what Dominic said Chrome has. I wonder why there's a difference. Normally at the low-level things are pretty close (or have a difference like linked list vs array). -- https://annevankesteren.nl/
Custom Elements: insert/remove callbacks
Open issues are kept track of here: https://wiki.whatwg.org/wiki/Custom_Elements This has come up before, but it came up again at the Extensible Web Summit so raising hopefully for the last time. The DOM has insert/remove primitives for nodes. Custom Elements uses insertion into a document and removal from a document which are quite a bit different and higher level. Why should we have different primitives here? -- https://annevankesteren.nl/
Re: Custom Elements: insert/remove callbacks
On Wed, May 6, 2015 at 6:45 AM, Anne van Kesteren ann...@annevk.nl wrote: Open issues are kept track of here: https://wiki.whatwg.org/wiki/Custom_Elements This has come up before, but it came up again at the Extensible Web Summit so raising hopefully for the last time. The DOM has insert/remove primitives for nodes. Custom Elements uses insertion into a document and removal from a document which are quite a bit different and higher level. Why should we have different primitives here? This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866. The way I remember it, the argument went like this: the most common use case for this callback is to react to element becoming part of the main document (the rough approximation of a nebulous concept am I useful on the screen?), and making these callbacks be invoked in other cases may just be noise for devs. :DG
Re: Custom Elements: insert/remove callbacks
On Wed, May 6, 2015 at 8:25 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 4:34 PM, Dimitri Glazkov dglaz...@google.com wrote: This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866. The way I remember it, the argument went like this: the most common use case for this callback is to react to element becoming part of the main document (the rough approximation of a nebulous concept am I useful on the screen?), and making these callbacks be invoked in other cases may just be noise for devs. I see. We know from HTML that a change of parent element might be significant, e.g. with picture or the details element. I'm inclined to make a proposal here that we change these callbacks to be the primitives the DOM offers rather than these higher-level callbacks. How are you supposed to tell if one of your ancestors was removed? -- https://annevankesteren.nl/
Re: Custom Elements: insert/remove callbacks
On Wed, May 6, 2015 at 4:34 PM, Dimitri Glazkov dglaz...@google.com wrote: This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866. The way I remember it, the argument went like this: the most common use case for this callback is to react to element becoming part of the main document (the rough approximation of a nebulous concept am I useful on the screen?), and making these callbacks be invoked in other cases may just be noise for devs. I see. We know from HTML that a change of parent element might be significant, e.g. with picture or the details element. I'm inclined to make a proposal here that we change these callbacks to be the primitives the DOM offers rather than these higher-level callbacks. -- https://annevankesteren.nl/
