Re: Custom Elements: insert/remove callbacks

[Boris Zbarsky]

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

[Elliott Sprehn]

On May 9, 2015 9:41 AM, "Anne van Kesteren"  wrote:
>
> On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky  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

[Anne van Kesteren]

On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky  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

[Adam Klein]

On Thu, May 7, 2015 at 10:56 PM, Elliott Sprehn 
wrote:

>
> On Thu, May 7, 2015 at 10:44 PM, Anne van Kesteren 
> wrote:
>
>> On Fri, May 8, 2015 at 7: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)
>> >
>> > 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

[Boris Zbarsky]

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

[Elliott Sprehn]

On Thu, May 7, 2015 at 10:44 PM, Anne van Kesteren  wrote:

> On Fri, May 8, 2015 at 7: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)
> >
> > 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

[Anne van Kesteren]

On Fri, May 8, 2015 at 7: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)
>
> 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

[Elliott Sprehn]

On Thu, May 7, 2015 at 10:24 PM, Anne van Kesteren  wrote:

> On Thu, May 7, 2015 at 10:14 PM, Boris Zbarsky  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

[Anne van Kesteren]

On Thu, May 7, 2015 at 10:14 PM, Boris Zbarsky  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/

Re: Custom Elements: insert/remove callbacks

[Boris Zbarsky]

On 5/7/15 3:43 AM, Anne van Kesteren wrote:

On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani
 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

[Dominic Cooney]

On Thu, May 7, 2015 at 4:43 PM, Anne van Kesteren  wrote:

> On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani
>  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.cpp&sq=package:chromium&type=cs&l=834&rcl=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"  and
something needs to be done/updated/etc. to implement that effect.


>
> --
> https://annevankesteren.nl/
>
>

Re: Custom Elements: insert/remove callbacks

[Anne van Kesteren]

On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani
 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

[Justin Fagnani]

On Wed, May 6, 2015 at 8:25 AM, Anne van Kesteren  wrote:

> On Wed, May 6, 2015 at 4:34 PM, Dimitri Glazkov 
> 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  or the   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

[Anne van Kesteren]

On Wed, May 6, 2015 at 4:34 PM, Dimitri Glazkov  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  or the   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/

Re: Custom Elements: insert/remove callbacks

[Dimitri Glazkov]

On Wed, May 6, 2015 at 6:45 AM, Anne van Kesteren  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<