Re: Custom Elements: insert/remove callbacks

2015-05-09 Thread 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

2015-05-09 Thread Anne van Kesteren
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

2015-05-09 Thread Elliott Sprehn
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

2015-05-08 Thread Adam Klein
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

2015-05-08 Thread 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

2015-05-07 Thread Dominic Cooney
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

2015-05-07 Thread Anne van Kesteren
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

2015-05-07 Thread Boris Zbarsky

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

2015-05-07 Thread Elliott Sprehn
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

2015-05-07 Thread Anne van Kesteren
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

2015-05-07 Thread Elliott Sprehn
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

2015-05-07 Thread Anne van Kesteren
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/



Re: Custom Elements: insert/remove callbacks

2015-05-06 Thread Dimitri Glazkov
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

2015-05-06 Thread Justin Fagnani
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

2015-05-06 Thread Anne van Kesteren
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/