Re: [shadow-dom] Event Retargeting

On Tue, Feb 12, 2013 at 7:55 AM, Anne van Kesteren <> wrote:

> The more I read this algorithm to figure out how to rewrite DOM event
> dispatch the more confused I get. For starters it would probably help
> if ancestor was renamed to event parent.

Well.. I am not sure what event parent is, but the "ancestor" is just an
item along the event path.

> I was wondering if this rewrite of 3.1-3.3 is correct:
> 1. Let CONTEXT be null.
> 2. If ANCESTOR is an insertion point, set CONTEXT to the top-most item
> in STACK that is not an insertion point, if any.
> 3. If STACK is empty, push ANCESTOR on STACK.
> I think this would be quite a bit clearer.

Cool! Filed a bug:

> Also, I think this algorithm gives the wrong result. Given a tree
> <a><b/></a>. Now to <a> we apply a shadow tree with an insertion point
> for <b>. This algorithm seems to say that we go through the shadow
> tree and when we reach the shadow root we change the target, but that
> would mean the shadow tree is observable from the DOM, which is bad.
> Am I misunderstanding something here?

Okay, let's unroll this. Suppose we have this tree:

a -- [sr] -- <>

(where <> is the insertion point, and [sr] is the shadow root)

1) Event is fired on b.
3) ANCESTOR is not an insertion point
4) CONTEXT = null
5) STACK is empty, so STACK.push(b) (STACK now [b])
6) TARGET = b
7) Adding (b, b) to TARGETS
8) ANCESTOR is not a shadow root
9) ANCESTOR = <>
10) ANCESTOR is an insertion point
11) CONTEXT = b
12) TOP = b
13) STACK.push(b) (STACK now [b,b])
14) TARGET = b
15) Adding (b, <>) to TARGETS
16) ANCESTOR is not a shadow root
17) ANCESTOR = [sr]
18) ANCESTOR is not an insertion point
19) CONTEXT = null
20) TARGET = b
21) Adding (b, [sr]) to TARGETS
22) ANCESTOR is a shadow root, so STACK.pop() (STACK now [b])
23) ANCESTOR = a
24) ANCESTOR is not an insertion point
25) CONTEXT = null
26) TARGET = b
27) Adding (b, a) to TARGETS
28) ANCESTOR is not a shadow root
29) ANCESTOR = null (for our tree)
30) stop.

At the end of the road, our TARGETS looks like this:

Adjusted target is "b" when at "b"
Adjusted target is "b" when at "<>"
Adjusted target is "b" when at "a"

As you can see, no details about the shadow tree have leaked. This is a
simple example, but once you get into nested trees, you'll see that the
algo still works.


Received on Tuesday, 12 February 2013 17:49:33 UTC