[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 #78 from Hayato Ito <hayato@chromium.org> ---
(In reply to Jonas Sicking from comment #76)

> I guess we could also argue over if the shadow-root should be in the event
> path or not, but I don't see any disadvantages of having it in the event
> path, and don't think I've seen anyone in here argue that it shouldn't be in
> the event path. Or did I miss that?

Good point. I've thought it too. 

My comment,

> 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.

implies that. :)

If we remove insertion points, we might want to remove shadow roots too from
the event path.


I'm not saying that we should remove insertion points (and shadow roots) from
the event path.
I still don't see a strong disadvantage of having these in the event path.

> So the question is, does the ability to listen to events from nodes inserted
> into an insertion point warrant that extra complexity?


I've seen 'extra complexity' of having insertion points in even path several
times in this discussion.
However, I'd like to figure out a real issue what this *complexity* would
cause.

>From the experience of implementing the event path in blink, this didn't cause
any extra burden for implementors.

Therefore, I'd like to know what is a real issue for web developers by having
insertion points in the event path.
>From the discussion, it looks the advantages outweigh the disadvantages, if
exists, for web developers.

I'd like to note that the original motivation of including insertion points in
the event path is we thought it's useful for web developers.

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

Received on Friday, 28 March 2014 04:25:52 UTC