To not break consistency with normal DOM where if a node is in
event path, also its parent node is in the path, Shadow DOM shouldn't put
non-final destination insertion points to the path.
Can we have an example to work with to see the problem more clearly?
Is the proposal to change just the information exposed in event.path or to change the set of elements to which events bubble?
My concern is that this will interact poorly with composition. It seems desirable to maintain the invariant that event handlers on insertion points can see events which bubble from elements distributed to them.
My concern is that this will interact poorly with composition. It seems
desirable to maintain the invariant that event handlers on insertion points
can see events which bubble from elements distributed to them.
Thanks for the example, yes, I am not in favor of this change for the reason stated in #3: it does not interact well with composition.
If an element host-1 like this:
SR
I must be guaranteed that host-1 can see events on its element independent of what host-2 does. This is necessary to preserve the integrity of the subtree from the perspective of host-1's shadowRoot.
Note that even in this example: http://jsbin.com/IhIziHo/1/edit where host-2 entirely replaces the rendered subtree, the basic flow of events is maintained. If child-1 fires a bubbling event, then host-1's content must see the event.
---
comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c6
_Olli Pettay_ wrote on 2013-11-26 12:40:32 +0000.
(In reply to Steve Orvell from comment #5)
> If an element host-1 like this:
>
>
> SR
>
>
>
> I must be guaranteed that host-1 can see events on its element
> independent of what host-2 does.
> Why? You can add listener to host-2.
> And it is very odd that if you have
> listener both on host-2 and on content, both get called, per the current spec.
---
comment: 7
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c7
_Steve Orvell_ wrote on 2013-11-26 17:09:50 +0000.
> Why? You can add listener to host-2.
Whether host-2 has a shadowRoot and what it does to it is not a detail I should need to be aware of when I'm setting up listeners inside host-1's shadowRoot.
> And it is very odd that if you have
> listener both on host-2 and on content, both get called, per the current spec.
It's a natural consequence of host-1's content being in the event path, which I don't find odd =).
---
comment: 8
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c8
_Olli Pettay_ wrote on 2013-11-26 17:41:53 +0000.
It is very odd from normal DOM event dispatch point of view.
---
comment: 9
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c9
_Hayato Ito_ wrote on 2013-11-27 02:01:18 +0000.
This might be a good opportunity to discuss how event path should be.
In the most _strictest_ world, I don't think we should add either insertion points, whether it's final destination or not, or shadow roots to an event path. If we don't add these to the event path, the event path would become equivalent to just "the ancestors in the composed tree". That would make the spec simpler. :)
But I think that's a kind of ego of a spec editor. :) I guess that is very handy and convenience for developers if we add insertion points or shadow roots to the event path. That will make it easy for developers to listen events for distributed nodes, I think.
If some developers don't like this _dirty_ world, I think they can simply ignore all insertion points or shadow roots in the event path. That shouldn't interfere _outer world_ essentially, should it? If we can close our eyes on events which happen on insertion points or shadow roots, the current event dispatching model might be close to the normal DOM event dispatch point of view.
I don't have a strong opinion for this issue. Let's discuss and make the spec better one.
---
comment: 10
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c10
_Dimitri Glazkov_ wrote on 2013-11-27 04:51:25 +0000.
I totally agree that these insertion points in an event path are odd. They stink. I also think Steve is right -- you need this oddity to preserve composition properties.
Otherwise, it would be very hard for UI controls to reason about what's happening to elements, distributed into their insertion points without also being aware of all other shadow trees. Which is a bad thing.
---
comment: 11
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c11
_Olli Pettay_ wrote on 2013-11-27 11:54:19 +0000.
We should aim for clean and consistent APIs. The current event propagation in
shadow DOM isn't such.
What is the real world use case for having non-final insertion points
in the path?
Since an insertion point may not be the final, it is anyway impossible
to know what is happening to the element distributed to insertion points.
The element may be in some totally different place in the final tree than
what the initial shadow tree expects. So I don't quite understand the "preserve composition properties" argument.
Also, one can always add event listeners to the elements in the
insertionPoint.getDistributedNodes() list.
---
comment: 12
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c12
_Olli Pettay_ wrote on 2013-11-27 12:02:11 +0000.
Need to perhaps change getDistributedNodes() handling a bit to make it
useful, since one should be able to observe changes to that list.
---
comment: 13
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c13
_Olli Pettay_ wrote on 2013-11-27 17:54:48 +0000.
Unless I'm missing something in the spec,
the current setup let's also
the same event to be handled twice in an insertion point.
-SH1
- SR1
- IP1
- SH2
-SR2
-IP2
- Child
I know that setup is odd, but nothing seem to prevent adding shadow host
under an insertion point and if there is then an insertion point, it will be
the final, yet the other insertion point is in the event path too.
So event would be dispatched from child:
Child->IP1->IP2->SR2->SH2->IP1(again)->SR1->SH1
---
comment: 14
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c14
_Steve Orvell_ wrote on 2013-11-27 21:47:11 +0000.
> What is the real world use case for having non-final insertion points
> in the path?
I'll take a shot at this. Be kind, it's a little contrived. I start by making a fancy-list element that has a shadowRoot with a in it and I want to see the events on my list items so I put a listener on the content element:
fancy-list
SR
It works and I'm happy. Then I decide to decorate my list with another element:
fancy-list
SR
I know that fancy-decoration will show my list items and it looks nice so it makes fancy-list better.
Now I'm stuck because fancy-list unexpectedly stopped working. If I move the event listener, it'll work, but do we really expect developers to understand that they need to do this? This seems pretty arcane.
---
comment: 15
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c15
_Steve Orvell_ wrote on 2013-11-27 21:52:50 +0000.
(In reply to Olli Pettay from comment #13)
> Unless I'm missing something in the spec,
> the current setup let's also
> the same event to be handled twice in an insertion point.
Handling the event twice would be bad, no argument there.
> I know that setup is odd, but nothing seem to prevent adding shadow host
> under an insertion point
I'm not quite sure I follow this. Is SH2 a child of IP1? If so, it's fallback content in the insertion point and would only render if Child was not selected by IP1 so I'm not quite sure how the resulting event flow could occur.
---
comment: 16
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c16
_Steve Orvell_ wrote on 2013-11-27 21:55:47 +0000.
(In reply to Hayato Ito from comment #9)
> This might be a good opportunity to discuss how event path should be.
>
> In the most _strictest_ world, I don't think we should add either insertion
> points, whether it's final destination or not
I would prefer this to the proposal here (only the last insertion point in the path).
If insertion points are sometimes in the path, I worry that it will be too confusing to know when they can be used and it will become an anti-pattern to attach listeners there.
So my preferences in order are:
1. all insertion points in event path.
2. no insertion points in event path.
3. last insertion point in event path.
---
comment: 17
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c17
_Hayato Ito_ wrote on 2013-11-28 01:54:04 +0000.
(In reply to Steve Orvell from comment #15)
> (In reply to Olli Pettay from comment #13)
>
> > Unless I'm missing something in the spec,
> > the current setup let's also
> > the same event to be handled twice in an insertion point.
>
> Handling the event twice would be bad, no argument there.
If this happens in any cases, that means there is a serious error in the spec.
> > I know that setup is odd, but nothing seem to prevent adding shadow host
> > under an insertion point
>
> I'm not quite sure I follow this. Is SH2 a child of IP1? If so, it's
> fallback content in the insertion point and would only render if Child was
> not selected by IP1 so I'm not quite sure how the resulting event flow could
> occur.
Right. In this case, SH2 is not used at all.
---
comment: 18
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c18
_Hayato Ito_ wrote on 2013-11-28 02:04:34 +0000.
(In reply to Steve Orvell from comment #16)
> (In reply to Hayato Ito from comment #9)
>
> > This might be a good opportunity to discuss how event path should be.
> >
> > In the most _strictest_ world, I don't think we should add either insertion
> > points, whether it's final destination or not
>
> I would prefer this to the proposal here (only the last insertion point in
> the path).
>
> If insertion points are sometimes in the path, I worry that it will be too
> confusing to know when they can be used and it will become an anti-pattern
> to attach listeners there.
>
> So my preferences in order are:
> 1. all insertion points in event path.
> 2. no insertion points in event path.
> 3. last insertion point in event path.
Thank you. That means 2 is an acceptable proposal?
I wonder whether there is a missing piece of APIs or not in order to accept 2.
For example,
> Need to perhaps change getDistributedNodes() handling a bit to make it
> useful, since one should be able to observe changes to that list.
Adding an such event, like distributionChanged, would be useful to accept 2?
---
comment: 19
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c19
_Olli Pettay_ wrote on 2013-11-28 16:05:00 +0000.
(In reply to Steve Orvell from comment #14)
> fancy-list
> SR
>
>
>
>
> I know that fancy-decoration will show my list items and it looks nice so it
> makes fancy-list better.
You should add listener to SR or somewhere, higher up in the propagation path.
> Now I'm stuck because fancy-list unexpectedly stopped working. If I move the
> event listener, it'll work, but do we really expect developers to understand
> that they need to do this? This seems pretty arcane.
> It is really really odd if developer needs to put listener to and putting the
> listener to the parent wouldn't work.
---
comment: 20
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c20
_Olli Pettay_ wrote on 2013-11-28 16:06:33 +0000.
(In reply to Steve Orvell from comment #15)
> I'm not quite sure I follow this. Is SH2 a child of IP1? If so, it's
> fallback content in the insertion point and would only render if Child was
> not selected by IP1 so I'm not quite sure how the resulting event flow could
> occur.
What has rendering to do with this all. We're talking about event dispatch ;)
---
comment: 21
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c21
_Steve Orvell_ wrote on 2013-12-03 07:24:43 +0000.
(In reply to Olli Pettay from comment #20)
> (In reply to Steve Orvell from comment #15)
>
> > I'm not quite sure I follow this. Is SH2 a child of IP1? If so, it's
> > fallback content in the insertion point and would only render if Child was
> > not selected by IP1 so I'm not quite sure how the resulting event flow could
> > occur.
>
> What has rendering to do with this all. We're talking about event dispatch ;)
Yeah, that's fair. The key bit is that SH2 and Child1 cannot co-exist in the event path.
If the fallback content is not used, I think the event path is:
Child->IP1->SR1->SH1
If an event is fired on the fallback content:
(some distributed child of SH2)->IP2->SR2->SH2->IP1->SR1->SH1
Given this, I believe the event should never be able to bubble to the same insertion point more than once.
---
comment: 22
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c22
_Olli Pettay_ wrote on 2013-12-03 07:42:34 +0000.
(In reply to Steve Orvell from comment #21)
> If the fallback content is not used, I think the event path is:
>
> Child->IP1->SR1->SH1
> I'd like to understand what in the spec says this.
And whether or not an insertion point can be twice in the event path, event propagation
in event path is inconsistent with the rest of the DOM, and should be changed.
So far I haven't seen any real world use case which requires the current odd behavior.
---
comment: 23
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c23
_Hayato Ito_ wrote on 2013-12-03 08:48:52 +0000.
(In reply to Olli Pettay from comment #22)
> (In reply to Steve Orvell from comment #21)
>
> > If the fallback content is not used, I think the event path is:
> >
> > Child->IP1->SR1->SH1
> > I'd like to understand what in the spec says this.
>
> And whether or not an insertion point can be twice in the event path, event
> propagation
> in event path is inconsistent with the rest of the DOM, and should be
> changed.
> So far I haven't seen any real world use case which requires the current odd
> behavior.
I'd like to know which current behavior is odd in order to make the discussion clear.
In my understanding:
A). In some shadow trees, an insertion point receives an event, but its parentNode doesn't receive an event. That's odd!
Is my understanding correct? Have you found any odd behavior other than A)?
---
comment: 24
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c24
_Olli Pettay_ wrote on 2013-12-03 09:07:48 +0000.
(In reply to Hayato Ito from comment #23)
> A). In some shadow trees, an insertion point receives an event, but its
> parentNode doesn't receive an event. That's odd!
> Yes. And that leads also to the odd behavior that sibling nodes may receive the same event.
---
comment: 25
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c25
_Hayato Ito_ wrote on 2013-12-03 09:45:49 +0000.
(In reply to Olli Pettay from comment #24)
> (In reply to Hayato Ito from comment #23)
>
> > A). In some shadow trees, an insertion point receives an event, but its
> > parentNode doesn't receive an event. That's odd!
> > Yes. And that leads also to the odd behavior that sibling nodes may receive
> > the same event.
Thank you.
Could you provide a reproduce case for sibling nodes? That's not what I expected.
I am afraid that I might miss something.
---
comment: 26
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c26
_Olli Pettay_ wrote on 2013-12-03 10:07:56 +0000.
http://w3c.github.io/webcomponents/spec/shadow/#distribution-results
In the composed tree the second shadow host has insertion point as a child, but
also a shadow root. If event is dispatched to child1, both the
insertion point and shadow root get the event.
---
comment: 27
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c27
_Hayato Ito_ wrote on 2013-12-04 03:44:19 +0000.
(In reply to Olli Pettay from comment #26)
> http://w3c.github.io/webcomponents/spec/shadow/#distribution-results
> In the composed tree the second shadow host has insertion point as a child,
> but
> also a shadow root. If event is dispatched to child1, both the
> insertion point and shadow root get the event.
Okay. But in general, we don't have to treat a shadow root as a child of the shadow host. In event path, they might be adjacent to each other. But we should view them in separate trees. What I worry about is the odd behavior in the same node tree.
---
comment: 28
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c28
_Hayato Ito_ wrote on 2013-12-04 04:14:26 +0000.
I think there is a confusion. So let me explain the design principle of the current event path.
- An event can be dispatched across node trees.
- If we view each node tree as a separate tree, there should be a _certain level_ of consistency for the existing event dispatching model within the same node tree.
For example, given a fig4 (http://w3c.github.io/webcomponents/spec/shadow/index.html#distribution-results):
If child 1 is clicked, the event path would be:
[child1, IP1, IP3, IP3's parent, 2nd SR, 2nd SH, 1st SR, 1st SH, document]
For each node tree:
- For the document tree, the event path would be [child1, 1st SH, document]
- For 1st shadow tree, the event path would be [IP1, 2nd SH, 1st SR]
- For 2nd shadow tree, the event path would be [IP3, IP3's parent, 2nd SR]
---
comment: 29
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c29
_Olli Pettay_ wrote on 2013-12-04 06:31:16 +0000.
(In reply to Hayato Ito from comment #27)
> (In reply to Olli Pettay from comment #26)
>
> > http://w3c.github.io/webcomponents/spec/shadow/#distribution-results
> > In the composed tree the second shadow host has insertion point as a child,
> > but
> > also a shadow root. If event is dispatched to child1, both the
> > insertion point and shadow root get the event.
>
> Okay. But in general, we don't have to treat a shadow root as a child of the
> shadow host.
> That shadow host is a child of its parent node. And its parent node has an
> insertion point as a child.
In event path, they might be adjacent to each other. But we
> should view them in separate trees. What I worry about is the odd behavior
> in the same node tree.
---
comment: 30
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c30
_Olli Pettay_ wrote on 2013-12-04 06:40:44 +0000.
(In reply to Hayato Ito from comment #28)
> I think there is a confusion.
> I don't think so ;)
So let me explain the design principle of the
> current event path.
> - An event can be dispatched across node trees.
> - If we view each node tree as a separate tree, there should be a _certain
> level_ of consistency for the existing event dispatching model within the
> same node tree.
>
> For example, given a fig4
> (http://w3c.github.io/webcomponents/spec/shadow/index.html#distribution-
> results):
>
> If child 1 is clicked, the event path would be:
> [child1, IP1, IP3, IP3's parent, 2nd SR, 2nd SH, 1st SR, 1st SH, document]
>
> For each node tree:
> - For the document tree, the event path would be [child1, 1st SH, document]
> - For 1st shadow tree, the event path would be [IP1, 2nd SH, 1st SR]
> - For 2nd shadow tree, the event path would be [IP3, IP3's parent, 2nd SR]
> The example just happens to make that look nice.
> But if 1st shadow tree for example has a non-SH-node in the place of 2nd SH, and
> that node has 2nd SH as a child. Then for the 1st shadow tree the event path
> would be [IP1, 2nd SH, the-parent-of-2nd-SH, 2ns SR]
Now, the-parent-of-2nd-SH is the parent of both IP1 and 2nd SH, and event goes through both those siblings.
---
comment: 31
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c31
_Hayato Ito_ wrote on 2013-12-04 07:01:43 +0000.
(In reply to Olli Pettay from comment #30)
> (In reply to Hayato Ito from comment #28)
>
> > I think there is a confusion.
> > I don't think so ;)
>
> So let me explain the design principle of the
>
> > current event path.
> > - An event can be dispatched across node trees.
> > - If we view each node tree as a separate tree, there should be a _certain
> > level_ of consistency for the existing event dispatching model within the
> > same node tree.
> >
> > For example, given a fig4
> > (http://w3c.github.io/webcomponents/spec/shadow/index.html#distribution-
> > results):
> >
> > If child 1 is clicked, the event path would be:
> > [child1, IP1, IP3, IP3's parent, 2nd SR, 2nd SH, 1st SR, 1st SH, document]
> >
> > For each node tree:
> > - For the document tree, the event path would be [child1, 1st SH, document]
> > - For 1st shadow tree, the event path would be [IP1, 2nd SH, 1st SR]
> > - For 2nd shadow tree, the event path would be [IP3, IP3's parent, 2nd SR]
> > The example just happens to make that look nice.
> > But if 1st shadow tree for example has a non-SH-node in the place of 2nd SH,
> > and
> > that node has 2nd SH as a child. Then for the 1st shadow tree the event path
> > would be [IP1, 2nd SH, the-parent-of-2nd-SH, 2ns SR]
>
> Now, the-parent-of-2nd-SH is the parent of both IP1 and 2nd SH, and event
> goes through both those siblings.
Thank you for the explanation! But I still think this is the root cause of the confusion. :)
> that node has 2nd SH as a child. Then for the 1st shadow tree the event path
In this case, IP3 cannot select nodes which are distributed into IP1.
Because IP1 is not a child node of 2nd SH.
That means CHILD1's destination insertion point is [IP1], rather than [IP1, IP3].
---
comment: 32
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c32
_Olli Pettay_ wrote on 2013-12-10 12:22:27 +0000.
(In reply to Olli Pettay from comment #22)
> > that node has 2nd SH as a child. Then for the 1st shadow tree the event path
>
> In this case, IP3 cannot select nodes which are distributed into IP1.
> Because IP1 is not a child node of 2nd SH.
> That means CHILD1's destination insertion point is [IP1], rather than [IP1,
> IP3].
Hmm, was my example wrong. Trying to find a better example.
Anyhow, there is still no example where non-final-destination insertion
points are needed in the event path and since this makes event propagation
inconsistent with the rest to the platform, there is no need to make this
special case.
---
comment: 33
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c33
_Hayato Ito_ wrote on 2013-12-10 13:25:17 +0000.
(In reply to Olli Pettay from comment #32)
> (In reply to Olli Pettay from comment #22)
>
> > > that node has 2nd SH as a child. Then for the 1st shadow tree the event path
> >
> > In this case, IP3 cannot select nodes which are distributed into IP1.
> > Because IP1 is not a child node of 2nd SH.
> > That means CHILD1's destination insertion point is [IP1], rather than [IP1,
> > IP3].
>
> Hmm, was my example wrong. Trying to find a better example.
Yeah, it might be better to have a better example.
Especially, I am curious whether we can create an example which hits the following case A):
> A). In some shadow trees, an insertion point receives an event, but its parentNode doesn't receive an event. That's odd!
If we can create an example which causes A), I think it might be worth to fix the current spec.
> Anyhow, there is still no example where non-final-destination insertion
> points are needed in the event path and since this makes event propagation
> inconsistent with the rest to the platform, there is no need to make this
> special case.
---
comment: 34
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c34
_Olli Pettay_ wrote on 2013-12-10 13:51:31 +0000.
Actually, the more I think this issue, the less I understand why we need
_any_ insertion points in the event path.
All we need is the parent of the final destination insertion point
then propagate event there through shadow boundaries up to the non-shadow dom.
One can always add listeners to shadow host or to the distributed node.
(XBL1 adds listeners by default to the bound element == shadow host)
---
comment: 35
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c35
_Hayato Ito_ wrote on 2013-12-10 13:59:28 +0000.
(In reply to Olli Pettay from comment #34)
> Actually, the more I think this issue, the less I understand why we need
> _any_ insertion points in the event path.
> All we need is the parent of the final destination insertion point
> then propagate event there through shadow boundaries up to the non-shadow
> dom.
>
> One can always add listeners to shadow host or to the distributed node.
> (XBL1 adds listeners by default to the bound element == shadow host)
Thank you. That's (2) in the following list.
> 1. all insertion points in event path.
> 2. no insertion points in event path.
> 3. last insertion point in event path.
If we can get rid of (3) from this list, we must choose (1) or (2). The current spec is (1).
My opinion for (2) is comment #18.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c18
---
comment: 36
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c36
_Olli Pettay_ wrote on 2013-12-10 14:06:16 +0000.
yeah, and I don't understand why the complicated (1) is chosen.
distributionChanged event might be useful, but probably not needed.
One can always just add listeners to the host.
And distributionChanged could be added later if needed.
---
comment: 37
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c37
_Hayato Ito_ wrote on 2013-12-16 07:36:48 +0000.
(In reply to Olli Pettay from comment #36)
> yeah, and I don't understand why the complicated (1) is chosen.
>
> distributionChanged event might be useful, but probably not needed.
> One can always just add listeners to the host.
> And distributionChanged could be added later if needed.
I'd like to hear a opinion from Steve.
I agree that (1) is complicated than (2), but (1) doesn't break the original claim in comment #1, does that?
> To not break consistency with normal DOM where if a node is in
> event path,
I think we have to find a balance. (1) is complicated, but (1) gives developers more power.
---
comment: 38
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c38
_Olli Pettay_ wrote on 2013-12-16 12:34:40 +0000.
(In reply to Hayato Ito from comment #37)
> I think we have to find a balance. (1) is complicated, but (1) gives
> developers more power.
What more power? Event listener can always be added to the distributed nodes
or to their parent.
We should not add complicated stuff without good use cases.
---
comment: 39
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c39
_Steve Orvell_ wrote on 2013-12-16 17:27:02 +0000.
Removing insertion points from the event path is a significant change. I think it's important to try to gather more feedback before moving forward.
One obvious issue I see is that to capture the same behavior there are some cases where additional 'wrapper' elements will be required, e.g.
```
```
With the current rules, I can listen to events that bubble from elements selected into each insertion point via listeners on the content element. If we remove insertion points from the event path, one would need wrapper elements around the insertion points with the listeners on them.
---
comment: 40
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c40
_Olli Pettay_ wrote on 2013-12-16 17:34:05 +0000.
Why? Add a listener to the shadow host? You can easily filter out events in the listener, for example by using the content.getDistributedNodes().
Or you can add listeners to the distributed nodes themselves.
---
comment: 41
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c41
_Steve Orvell_ wrote on 2013-12-16 18:15:15 +0000.
Sure, that's another option. In either case, the developer must do more work to get the desired behavior.
---
comment: 42
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c42
_Hayato Ito_ wrote on 2013-12-17 03:26:50 +0000.
My biggest concern about removing insertion point from the event path is whether it would cause developers a kind of _burden_ or not.
We need more feedbacks.
> 1. all insertion points in event path.
> 2. no insertion points in event path.
> 3. last insertion point in event path.
My understanding between (1) and (2) is:
By (1):
For each node tree:
- For the document tree, the event path would be [child1, 1st SH, document]
- For 1st shadow tree, the event path would be [IP1, 2nd SH, 1st SR]
- For 2nd shadow tree, the event path would be [IP3, IP3's parent, 2nd SR]
By (2):
For each node tree:
- For the document tree, the event path would be [child1, 1st SH, document]
- For 1st shadow tree, the event path would be [2nd SH, 1st SR]
- For 2nd shadow tree, the event path would be [IP3's parent, 2nd SR]
Although I don't have a strong opinion whether which, (1) or (2) is better, I am still not convinced that (2) is much better than (1). So far, I think (1) is more useful for developers than (2).
---
comment: 43
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c43
_Steve Orvell_ wrote on 2014-02-26 03:20:46 +0000.
Let's go back to this case in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c39 and review the counter-argument.
```
```
> Why? Add a listener to the shadow host? You can easily filter out events in the
> listener, for example by using the content.getDistributedNodes().
> Or you can add listeners to the distributed nodes themselves.
Neither option is acceptable.
If a listener is added to the shadowRoot, then each handler must start at event.target and walk up the tree checking if the element is in the specific content's list of distributed nodes. This has a non-trivial cost in code and performance.
Alternatively, if handlers are attached to the distributed nodes, there's no good way today for the developer to respond to nodes that are added/removed. You can watch for mutations on the host's childList, but you will not see elements that are re-projected this way.
At this point, I don't see an alternative to requiring all insertion points to be in the event path. If we don't include insertion points, we run into the problems listed above. If we include only the last insertion point, we have composition fail.
---
comment: 44
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c44
_Hayato Ito_ wrote on 2014-03-10 08:12:55 +0000.
Thank you for the explanation, Steve.
Is there any comments about this?
If we don't have any further objection to the current spec, let me close this bug in a week.
Remember that we can re-open this bug anytime if we feel to discuss this topic again.
---
comment: 45
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c45
_Hayato Ito_ wrote on 2014-03-10 08:15:22 +0000.
Because I am cleaning up the bugs, I might close this bug in a few days. Please feel free to re-open this if you need further discussion.
---
comment: 46
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c46
_Olli Pettay_ wrote on 2014-03-21 16:57:32 +0000.
Uh, I didn't get bugmail about this.
Reading comments and possibly reopening...
I'm not happy shadow dom adding bizarre event propagation paths.
---
comment: 47
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c47
_Olli Pettay_ wrote on 2014-03-21 17:08:16 +0000.
(In reply to Steve Orvell from comment #43)
> Let's go back to this case in
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c39 and review the
> counter-argument.
>
> ```
>
>
> ```
>
> > Why? Add a listener to the shadow host? You can easily filter out events in the
> > listener, for example by using the content.getDistributedNodes().
> > Or you can add listeners to the distributed nodes themselves.
>
> Neither option is acceptable.
>
> If a listener is added to the shadowRoot, then each handler must start at
> event.target and walk up the tree checking if the element is in the specific
> content's list of distributed nodes. This has a non-trivial cost in code and
> performance.
> Making propagation path more complicated has also performance cost, and
> makes event propagation inconsistent.
> Also, it is rather trivial cost in code, and makes code less unexpected, since
> propagation path doesn't have inconsistencies.
>
> Alternatively, if handlers are attached to the distributed nodes, there's no
> good way today for the developer to respond to nodes that are added/removed.
> You can watch for mutations on the host's childList, but you will not see
> elements that are re-projected this way.
> Which is why I suggested making getDistributedNodes more useful. As of now it is rather
> dummy plain list, but one should be able to get notification when it has been changed.
>
> At this point, I don't see an alternative to requiring all insertion points
> to be in the event path. If we don't include insertion points, we run into
> the problems listed above. If we include only the last insertion point, we
> have composition fail.
XBL1 has the long tradition to put listener to the binding parent (shadowroot),
and that hasn't been a perf problem.
---
comment: 48
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c48
_Olli Pettay_ wrote on 2014-03-21 17:22:48 +0000.
(In reply to Steve Orvell from comment #43)
> Neither option is acceptable.
>
> If a listener is added to the shadowRoot, then each handler must start at
> event.target and walk up the tree checking if the element is in the specific
> content's list of distributed nodes. This has a non-trivial cost in code and
> performance.
> In other words, is there any real world use case when this would be a
> performance issue enough to warrant to inconsistent propagation path.
> (inconsistencies make code harder to read and understand, and error prone.)
---
comment: 49
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c49
_Steve Orvell_ wrote on 2014-03-21 21:34:40 +0000.
I'm ok with eliminating insertion points from the event path.
We shouldn't include just the final one because, as discussed, this doesn't support composition.
I still do think it would be better to have all the insertion points in the event path to support the cases mentioned previously. However, these cases feel uncommon to me. Most of the time, there is going to be a convenient node around the insertion point on which to hang the listener.
---
comment: 50
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c50
_Boris Zbarsky_ wrote on 2014-03-21 21:39:10 +0000.
I would like to clarify what the expected behavior is here, at least in the simple case.
Say the light DOM looks like this:
The
has a shadow DOM like so (I'm going to give the shadow root an ID, though I realize it's not an element; that's just for ease of referring to it):
and the
has a shadow DOM like so:
Now an event is fired at
. In the composed tree, the parent chain looks like 3, 2, 9, 6, 5, 1, I believe.
If I am following the algorithm at http://w3c.github.io/webcomponents/spec/shadow/#event-paths correctly, we start with the event path being [3, 2], then we see that the destination insertion points of
is not empty and that none of them are shadow insertion points, so we set the path to [3, 2, 7, 10](note that the order of the insertion points here is "rootmost first", unlike normal event path behavior).
Now we start off at the and start walking the parent chain. We add "9" to the path, then we add "8" to the path. Then CURRENT is a shadow root, so we skip to its shadow host, which is "6". We keep walking: "5", "4", skip to "1". So the final path is:
3,2,7,10,9,8,6,5,4,1
I have ignored for now issues dealing with multiple shadow trees and whatever scenario comment 13 is talking about.
I have confirmed that in the above simple testcase Chrome in fact has the event path I just described.
What I don't quite understand, if we posit that we do want to put all the insertion points in the path, is why the path is not the somewhat more intuitive:
3,2,10,9,8,7,6,5,4,1
?
---
comment: 51
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c51
_Boris Zbarsky_ wrote on 2014-03-21 21:39:31 +0000.
Created attachment 1457
Simple testcase
---
comment: 52
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c52
_Dimitri Glazkov_ wrote on 2014-03-21 22:19:31 +0000.
(In reply to Boris Zbarsky from comment #50)
Thanks for the test case -- I turned it into a jsbin:
http://jsbin.com/newir/1/edit
> What I don't quite understand, if we posit that we do want to put all the
> insertion points in the path, is why the path is not the somewhat more
> intuitive:
>
> 3,2,10,9,8,7,6,5,4,1
Here's how the reasoning works. Since insertion points aren't in the composed tree, but are in event path, we have to come up with a mental model of how they are added.
Here's the mental model that the spec ascribes:
During distribution, first 2 is distributed into insertion point 7. So the path is now 3,2,7.
Then, the result of that distributed into 10, so the path is now 3,2,7,10.
In other words, the spec follows the distribution sequence and builds the path accordingly.
FWIW, I am fine for insertion points to not receive any events. I'll be sad about it for a day, and then I'll get over it.
---
comment: 53
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c53
_Dimitri Glazkov_ wrote on 2014-03-21 22:40:38 +0000.
The desired property here is composition symmetry. If you group chunks of the path by trees (let's mark them as 1, 2, and 3), you get:
1:[3,2] 2:[7] 3:[10,9,8] 2:[6,5,4] 1:[1](http://w3c.github.io/webcomponents/spec/shadow/#event-paths-example)
Notice how if I only had trees 2 and 3 (for example, I am an author of a component that created shadowroot#4), I have a view into the contiguous fragment of the same event path:
2:[7] 3:[10,9,8] 2:[6,5,4]
Similarly, if the main document turns out to be not a document at all, but just another shadow root, and we add insertion point in it, its inner event path will not change, only the outer parts of it will. Which means that the authors of components don't have to worry about how the composition affects them.
---
comment: 54
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c54
_Dimitri Glazkov_ wrote on 2014-03-21 23:47:42 +0000.
(In reply to Olli Pettay from comment #47)
> (In reply to Steve Orvell from comment #43)
>
> > Let's go back to this case in
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c39 and review the
> > counter-argument.
> >
> > ```
> >
> >
> > ```
> >
> > > Why? Add a listener to the shadow host? You can easily filter out events in the
> > > listener, for example by using the content.getDistributedNodes().
> > > Or you can add listeners to the distributed nodes themselves.
> >
> > Neither option is acceptable.
> >
> > If a listener is added to the shadowRoot, then each handler must start at
> > event.target and walk up the tree checking if the element is in the specific
> > content's list of distributed nodes. This has a non-trivial cost in code and
> > performance.
> > Making propagation path more complicated has also performance cost, and
> > makes event propagation inconsistent.
I agree on this point. The key here is deciding whether we should carry this burden as a platform or pass it on to developers.
> Also, it is rather trivial cost in code, and makes code less unexpected,
> since
> propagation path doesn't have inconsistencies.
A good general exercise here is to assume that each shadow root chunk is written by different people at different times. As a rule, these developers should not need to have any insight into how these chunks are composed. In other words, if I as a developer have to defensively anticipate what will happen outside of my shadow tree, we failed the main objective of this whole shadow DOM exercise -- composition.
Having all insertion points included in the event path satisfies this constraint very well. As a developer, I have a consistent, simple way to find out what events are being dispatched in the parts of the outer tree that are distributed to my insertion points.
Having no insertion points included in the event path also satisfies this constraint, and it's pretty clear that our guinea pig developer (Steve) already worked around this problem by simply putting a div around the insertion point.
Having only final insertion point included in event path is craziness, because now I, as a developer of my component may or may not receive an event depending on how some other dude/dudette composed it in their app. That's composition fail.
So, to keep on moving, we should just zap the insertion points altogether from the event path.
---
comment: 55
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c55
_Boris Zbarsky_ wrote on 2014-03-22 00:43:49 +0000.
I think the difference in mental model here is in whether insertion points get redistributed themselves or not. So where you came up with:
1:[3,2] 2:[7] 3:[10,9,8] 2:[6,5,4] 1:[1](http://w3c.github.io/webcomponents/spec/shadow/#event-paths-example)
I had come up with:
1:[3,2] 3:[10,9,8] 2:[7,6,5,4] 1:[1](http://w3c.github.io/webcomponents/spec/shadow/#event-paths-example)
based on the staying put when redistribution into 10 happens.
So in my mental model, you distribute stuff into an insertion point, then you make the insertion point go away, hoisting its kids up to be kids of its parent, then you look for shadow trees attached to that parent. But in your model it sounds like you distribute stuff into the insertion point, then you look for shadow trees attached to its parent and distribute the entire insertion point into those as needed, and then you hoist things out of insertion points. At least if I understand your model correctly
I think my model makes a lot more sense when thinking about what happens when 10 only accepts some of the kids of 6. At that point it becomes clear that 7 itself is not actually being distributed under 10...
---
comment: 56
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c56
_Boris Zbarsky_ wrote on 2014-03-22 00:47:53 +0000.
I guess we're no longer using this stuff for CSS inheritance at least (if I read http://dev.w3.org/csswg/css-scoping/#inheritance right), so we can just worry about the event behavior...
---
comment: 57
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c57
_Jonas Sicking_ wrote on 2014-03-22 04:17:52 +0000.
First off, I think we should look at this from the point of view of use cases.
What is the use case for adding an event listener to an insertion point? A user can't ever click an insertion point because they are not rendered.
However it does seem nice and intuitive if an event listener attached to an insertion point ends up receiving events targetted at any of the nodes inserted into that insertion point. As well as those nodes descendants of course.
And for the sake of consistency, this should always happen, no matter if there is shadow DOM attached to the parent of the insertion point or not. And no matter if there is shadow DOM attached to one of the nodes inserted into that insertion point.
Assuming that we can do this without creating large performance problems, and without creating too weird edge cases, do people agree that this is a laudable goal?
So I read comment 50 and also ended up with the same question as bz. Why not the more intuitive propagation path of 3,2,10,9,8,7,6,5,4,1?
So I started writing a comment why Dimitri's logic in comment 52 didn't make sense.
And instead writing the logic that would lead to bz's intuitive propagation path in comment 50 (3,2,10,9,8,7,6,5,4,1).
However I realized that I couldn't come up with a logical set of rules that would lead to that path.
While it seems to make sense to have that come before the , I couldn't motivate why that should be.
And, more importantly, it only seems to make sense if the '7' insertion point is an immediate child of the '6' shadow host. Let's insert an element between the '6' and the '7' nodes, such that we get the following tree:
In this case no node is inserted into multiple insertion points, which makes the whole thing much simpler. The '2' node is inserted into the '7' insertion point, and the 'a' node is inserted into the '10' insertion point.
In this case it's pretty clear that an event fired at the '3' node would get a propagation path of 3,2,7,a,10,9,8,6,5,4,1
So it makes sense to me that if you simply remove the 'a' and insert the '7' directly into the '6', that you'd get the same propagation path but with the 'a' removed. I.e. 3,2,7,a,10,9,8,6,5,4,1
I've read through the initial comments in this bug but I don't see the inconsistencies that are being discussed there. I.e. all of the following appears true:
- No node ever receives the same event twice.
- Any time an event reaches a node, it also reaches the node's parent.
- During the capturing phase, a node always receives an event before its children.
- During the bubbling phase, a node always receives an event after its children.
- The only way to receive an event multiple times in the same shadow tree is by
registering listeners on multiple nodes, where some of the nodes are ancestors of
other nodes.
All of the above appears to be true both both with and without the shadow DOM spec.
The only way that I can see that you could receive the same event multiple times is if you register event listeners in multiple different shadow trees. In that case it doesn't seem surprising that you can receive an event multiple times. It's something that happens even in the very simple event model that XBL1 uses.
Is the above wrong? Or is there some other inconsistency that I'm missing? Or is the concern about performance at this point?
Examples would be very helpful.
---
comment: 58
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c58
_Jonas Sicking_ wrote on 2014-03-22 04:31:38 +0000.
For what it's worth, if I create a tree which illustrates how event propagation happens using the currently defined event path, and the example at [1](http://w3c.github.io/webcomponents/spec/shadow/#event-paths-example) I get something like this:
[1](http://w3c.github.io/webcomponents/spec/shadow/#event-paths-example) http://w3c.github.io/webcomponents/spec/shadow/#distribution-results
---
comment: 59
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c59
_Olli Pettay_ wrote on 2014-03-22 13:34:25 +0000.
(In reply to Jonas Sicking from comment #57)
> Is the above wrong? Or is there some other inconsistency that I'm missing?
> Or is the concern about performance at this point?
The inconsistency comes from the non-linear event propagation path in the
final flattened tree.
---
comment: 60
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c60
_Olli Pettay_ wrote on 2014-03-22 14:18:27 +0000.
(In reply to Dimitri Glazkov from comment #54)
> So, to keep on moving, we should just zap the insertion points altogether
> from the event path.
This would be fine to me. A lot less surprising propagation path.
---
comment: 61
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c61
_Boris Zbarsky_ wrote on 2014-03-22 15:01:14 +0000.
> non-linear event propagation path in the final flattened tree.
I'm still thinking about Jonas' example, but do you mind explaining clearly the issue here? At least in my simple example, the nodes in the final flattened tree (so ignoring the insertion points and shadow roots, which are not present in the flattened tree) see the event in the order 3,2,9,6,5,1, which seems like the expected order...
---
comment: 62
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c62
_Olli Pettay_ wrote on 2014-03-22 16:26:42 +0000.
Created attachment 1458
example
This shows a case when dispatching two events ends up creating
a diamond shape, because the first insertion point is cherry picked form the
flattened tree to the next item in the propagation path after the target.
Such behavior is really odd when we otherwise operate on trees and lists.
(And in my mind insertion points are there in the flattened tree. Otherwise events couldn't go through them at all.
But it is actually not a Shadow DOM terminology.)
DOM:
[click me 1] [click me 2]
attached to sh1:
attached to sh2:
propagation paths are
- SPAN[id=s1], CONTENT[id=ip1], CONTENT[id=ip2.1], SPAN[id=sh2], DIV[id=sh1]
- SPAN[id=s2], CONTENT[id=ip1], CONTENT[id=ip2.2], SPAN[id=sh2], DIV[id=sh1]
---
comment: 63
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c63
_Olli Pettay_ wrote on 2014-03-22 17:00:48 +0000.
In other words, atm union of two event paths is a tree.
You can rely on that if there is a target T in the path, the next
target T' in the path is always the same for event type foo.
---
comment: 64
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c64
_Jonas Sicking_ wrote on 2014-03-22 17:45:04 +0000.
Ah, I think I see the issue indeed.
In Olli's example the "tree" that the DOM events code sees is this (I took the liberty of adding id's to the shadowroots for clarity):
[click me 1] [click me 2]
Note that the node shows up twice!
I.e. if you fire an event on s1 the event path is
s1,ip1,ip2.1,sr2,sh2,sr1,sh1
And if you fire an event on s2 the event path is
s2,ip1,ip2.2,sr2,sh1,sr1,sh1
I.e. in both cases does the event go through ip1 (which is expected given that both s1 and s2 are inserted into ip1), but ip1's parent is different in the two events.
I'm curious, what does the spec say the event path is if you target an event on the ip1 node? Or on insertion points in general?
I still don't feel convinced either way of what the right thing to do here is.
I don't think including just the innermost insertion point is a good solution since it introduces other types of inconsistencies. I.e. it would mean that adding a shadow DOM to sh1 means that suddenly ip1 doesn't see any events. This will prevent any type of encapsulation.
And preventing any and all events to go through insertion points seems like breaking a useful feature.
---
comment: 65
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c65
_Olli Pettay_ wrote on 2014-03-22 18:11:26 +0000.
It is probably best to not add any insertion points to the path.
You can add listener to the shadow host, or to the parent of the insertion point
or to the child nodes of shadow host or only to those child nodes which
are currently distributed to insertion point etc.
That gives already plenty of flexibility without need to change
event path creation significantly.
---
comment: 66
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c66
_Dimitri Glazkov_ wrote on 2014-03-23 16:02:54 +0000.
I turned Olli's snippet into the jsbin here: http://jsbin.com/gakid/1/edit
I added the wrapper around ip2.*, and Steve's workaround works well there. It doesn't work as well around ip1, since that makes ip1 a grandchild of sh2. In that particular case, I can listen to the shadow root and get the same result...
I am almost sure that the wrapper workaround is a reasonable solution, but I need to play with this some more.
---
comment: 67
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c67
_Hayato Ito_ wrote on 2014-03-24 04:50:29 +0000.
Thank you for all guys for comments for the event path.
I am feeling that I have to explain the background of the current event path calculation algorithms and the rationale of that.
I've designed the current event path algorithms so that we can achieve the following goal:
Objective A) In _each_ node tree (forget other node trees), the event path should be a _linear_ path.
That means:
- If a node on the event path has the parent node in the node tree, the parent node should also be on the event path. Only exception is the root node of a node tree.
- In each node tree, the child node must come before its parent node on the event path.
From the view of developers whose concern is only one node tree where they live, they see the behavior of the event path doesn't change at all as long as their concern is one node tree. They shouldn't care of other node trees.
The following is _not_ the goal of the current algorithm:
Objective B) Define a reasonable total _order_ between nodes which are in different node trees on the same event path.
I'd like to point out the following fact because I guess every one here doesn't notice this fact:
- Think about a tree of trees. Node trees that are involved in one even path can _form_ a tree of node trees. Node trees can't be linear here.
I suggest you guys to think about this fact carefully. You can easily create this case by modifying the example in comment #50 as follows:
- Make
a shadow host and let it host the following shadow tree.
In this case:
- Event path will be [3, 2, 7, 10, 9, 8, 6, 13, 12, 11, 5, 4, 1].
- There are 4 node trees which are involved in this event path.
- A node tree whose root node is #4 have _two_ child node trees, a node tree whose root node is #8 and a node tree whose root node is #11.
It'd be difficult to define a reasonable total order between nodes in this case. Can you define a reasonable total order in this case?
DFS pre-oder? BFS-post-order? Neither can be a reason strong enough to abandon the current simple _one-pass_ algorithm.
That's the reason why objective B) is not the goal.
The current algorithm uses one-pass algorithm and can achieve the objective A) at the same time.
I think simple one-pass algorithm is important here for the efficiency.
I'm not saying that we should include insertion points in the event path. That's orthogonal.
However, comment #63 can't be a strong reason not to include insertion points because the claim of 'union of two event paths is a tree' is not correct according to the current spec.
The current spec doesn't define one _super_ node tree, which are composed of nodes which participate in a node tree in the same tree of trees.
The spec doesn't define ancestor/descendant relationships between nodes if they are in different node trees. That's intentional.
That means a _tree_ used in 'union of two event paths is a tree' can't have a clear definition. Nodes in different node trees can't be a tree.
They live in separated worlds and should be considered as disconnected.
One more thing:
If we would exclude all insertion points from event path, we must have exceptional rule for insertion points which have fallback elements.
Example:
In this case, event path for "#n4" can't be [n4, n2, n1]. That should be [n4, n3, n2, n1]. We have to have an exceptional rule.
---
comment: 68
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c68
_Hayato Ito_ wrote on 2014-03-24 05:49:48 +0000.
As I mentioned that in comment #9, I'd like to note the following again:
If we exclude all shadow roots and insertion points from the current event path, the event path will be equivalent with "inclusive ancestors of the target node in the composed tree" with the following exceptional cases:
- The target node itself is an insertion point.
- If fallback elements are distributed to a insertion point, we must include the insertion points to the event path so that we can achieve objective A).
---
comment: 69
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c69
_Dimitri Glazkov_ wrote on 2014-03-25 16:16:52 +0000.
Thank you so much for explaining the design goals, Hayato-san!
It was illuminating for me. I'd forgotten about the fallback content in insertion points.
---
comment: 70
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c70
_Jonas Sicking_ wrote on 2014-03-26 22:34:05 +0000.
I agree with comment 67 and comment 68. Order within a tree is much more important than order between nodes in different trees.
And in comment 50 bz also suggests an event path where the total order of nodes is arguably "non-sensical" since it jumps back and forth between two trees.
I'd even argue that the order of the non-insertion-point nodes makes a lot of sense as it's currently defined by spec since it matches rendering order. This means that if you click an icon inside a button inside a toolback that the event goes first to the icon, then the button then the toolbar as it's bubbling out. Even if the nodes are spread out over multiple shadow DOM trees.
I don't see a way to accomplish that if we also want to have a simple total order between nodes?
That said, it's still not clear to me what the right answer is on the topic of when/if to fire events on insertion points.
I do quite like the current feature that you can listen on an insertion point to get notified about all the events that are inserted in that insertion point. And it feels quite intuitive for authors that that is the case.
While you can generally wrap a around the insertion point and add your listeners there, that can affect rendering. For example if some of the nodes involved in the rendering are rendered as tables/tablecells/tablerows.
It also will affect nested insertion points if the parent of the insertion point that you are wrapping has a binding. Now it's the span that will get distributed rather than all the nodes that were inserted in the insertion point.
---
comment: 71
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c71
_Dimitri Glazkov_ wrote on 2014-03-27 16:18:13 +0000.
(In reply to Jonas Sicking from comment #70)
> I don't see a way to accomplish that if we also want to have a simple total
> order between nodes?
>
> That said, it's still not clear to me what the right answer is on the topic
> of when/if to fire events on insertion points.
Maybe we can resolve this if we reduce the overall problem to this question: is introducing more complex total order in event path net positive or net negative?
Cons:
- increased complexity
- (please add more)
Pros:
- more intuitive for the consumer localized to any given tree
- useful to listen for events coming out of elements, distributed to insertion points
- fallback content is handled consistently
---
comment: 72
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c72
_Olli Pettay_ wrote on 2014-03-27 17:19:28 +0000.
(In reply to Dimitri Glazkov from comment #71)
> Cons:
> - increased complexity
> Slower event dispatch since event target chain creation becomes
> more complicated because ... see the next point
> - (please add more)
> Inconsistent targeting from target T to T' in the event target chain,
> which makes event dispatch less intuitive when one needs to think about the
> whole event dispatch, not only local shadow tree.
> And because of .stop*Propagation() for example one needs to think about the whole
> path in some cases, not only local parts. Same with default handling. If you use in the
> shadow trees and click somewhere, which link to follow? The first shadow tree
> can affect to the behavior of the nested shadow trees.
>
> Pros:
> - more intuitive for the consumer localized to any given tree
> - useful to listen for events coming out of elements, distributed to
> insertion points
> - fallback content is handled consistently
(I'm not saying pros aren't pros)
I guess XBL1 doesn't have this problem since it doesn't have explicit insertion points,
so event propagation follows always the natural path.
---
comment: 73
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c73
_Jonas Sicking_ wrote on 2014-03-27 17:59:28 +0000.
XBL1 these days do have explicit insertion points. I.e. we leave the insertion points in the tree. The reason XBL1 doesn't have this problem simply because it optimizes simplicity over usefulness.
For example, if you have an XBL1 binding for a button that looks like
<-- xbl1 equivalent of shadowroot, sort of
Let me close this issue tentatively. Event path calculation algorithm was updated so that it doesn't consider multiple shadow roots. I'm afraid that the current situation is different than the situation when the this bug was filed.
If this issue is still blocking Mozilla's implementation, please feel free to re-open this issue.
Title: [Shadow] Change the order of insertion points which are involved in a re-distribution in event path (bugzilla: 23887)
Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887
comment: 0 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c0 Olli Pettay wrote on 2013-11-22 10:34:35 +0000.
To not break consistency with normal DOM where if a node is in event path, also its parent node is in the path, Shadow DOM shouldn't put non-final destination insertion points to the path.
comment: 1 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c1 Hayato Ito wrote on 2013-11-22 10:42:43 +0000.
Sounds reasonable. Thank you for filing the bug! Let me update the spec. I think there is no concern for that.
comment: 2 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c2 Hayato Ito wrote on 2013-11-25 04:56:47 +0000.
+sorvell
Do you have any opinion for this proposal?
My concern is whether Polymer depends on the behavior of the current event path or not.
I don't think we want to include intermeidiate insertion points in the event path, but I'd like to make sure we really don't need that.
comment: 3 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c3 Steve Orvell wrote on 2013-11-25 18:11:56 +0000.
Can we have an example to work with to see the problem more clearly?
Is the proposal to change just the information exposed in event.path or to change the set of elements to which events bubble?
My concern is that this will interact poorly with composition. It seems desirable to maintain the invariant that event handlers on insertion points can see events which bubble from elements distributed to them.
comment: 4 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c4 Hayato Ito wrote on 2013-11-26 00:04:47 +0000.
(In reply to Steve Orvell from comment #3)
Both. Both uses the result of event path calculation algorithm. http://w3c.github.io/webcomponents/spec/shadow/#event-paths
Let's use the example. See Fig.4 http://w3c.github.io/webcomponents/spec/shadow/#distribution-results
When a click event happens on child1 node,
I supposed that insertion point 1 doesn't have to see events which happened on child1.
comment: 5 comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c5 Steve Orvell wrote on 2013-11-26 01:47:00 +0000.
Thanks for the example, yes, I am not in favor of this change for the reason stated in #3: it does not interact well with composition.
If an element host-1 like this:
Let me close this issue tentatively. Event path calculation algorithm was updated so that it doesn't consider multiple shadow roots. I'm afraid that the current situation is different than the situation when the this bug was filed.
If this issue is still blocking Mozilla's implementation, please feel free to re-open this issue.