[Bug 23887] [Shadow] Put only the final destination insertion point to the event path

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887

--- Comment #116 from Hayato Ito <hayato@chromium.org> ---
Olli, thank you for the explanation. 

Now I can say I understand the intention clearly. It's great to design the
concrete algorithm. I've enjoyed reading and running the WIP algorithm in my
head. It seems promising.

Aa far as I understand, the result between the current one and WIP one differ
only if a re-distribution happens.
If re-distribution occurs, they put non-final destination insertion points in
different places.

I don't have a strong opinions about which is better because both satisfy the
main goal which I explained in '5.3 Event Paths Example':

http://w3c.github.io/webcomponents/spec/shadow/#event-paths-example

> That means if we focus on one node tree and forget all other node trees, the event path would be seen as if the event happened only on the node tree which we are focused on. This is an important aspect in a sense that hosting shadow trees doesn't have any effect to the event path within the node tree the shadow host participate in as long as the event is not stopped somewhere in the descendant trees.

> For example, from the view of the document tree 1, the event path would be seen as [D, C, B, A]. From the view of the shadow tree 2, the event path would be seen as [I, H, G, F, E]. The similar things also apply to other node trees.

> It is also worth pointing out that if we exclude all insertion points and shadow roots from an event path, the result would be equivalent to the inclusive ancestors of the node on which the event is dispatched, in the composed tree.


>From the view of difficulty in implementing, I don't have any concerns because
both algorithm seem simple *enough*. That's great.

I am not sure how many developers will notice the difference between them and
how important the difference is.
I'd like to hear opinions from developers about what use cases would tell the
difference between them and when the difference matters.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 29 August 2014 02:49:15 UTC