Olli, wanted to check with you on this. It makes good sense to me. Here's a really good example that Daniel built: http://jsfiddle.net/dfreedm/EMgtb/

Maybe we should revert this change in WebKit side:

https://bugs.webkit.org/show_bug.cgi?id=112214

I think the original behavior in WebKit is what we want.
What we have to do is to update the spec so that the spec matches the WebKit's original behavior.

(In reply to comment #2)
> Maybe we should revert this change in WebKit side:
> 
> https://bugs.webkit.org/show_bug.cgi?id=112214

Okay.

To continue further, let me confirm 'the desired behavior' at first.

Given the event path, from Node A (top-most) to Node G (target, inner-most), where C and D are shadow hosts and G is the target, 

an event dispatching order in the current WebKit implementaion is:
(T: AT_TARGET, C: CAPTURING, B: BUBBLING)


For bubbling events:

  A          1 (C)  11 (B)
  B          2 (C)  10 (B)
  C (SH)     3 (T) 
  D          4 (C)   9 (B)
  E (SH)     5 (T)
  F          6 (C)   8 (B)
  G (Target) 7 (T)  


For non-bubbling events:

  A          1 (C)
  B          2 (C)
  C (SH)     3 (T) 
  D          4 (C)
  E (SH)     5 (T)
  F          6 (C)
  G (Target) 7 (T)  


Are we changing this behavior?

Let me ignore my comment #2. Could you see comment #4?

(In reply to comment #3)
> (In reply to comment #2)
> > Maybe we should revert this change in WebKit side:
> > 
> > https://bugs.webkit.org/show_bug.cgi?id=112214
> 
> Okay.

(In reply to comment #5)

I think what Daniel wants is:

  A          1 (C)  
  B          2 (C)
  C (SH)            7 (T)
  D          3 (C)
  E (SH)            6 (T)
  F          4 (C) 
  G (Target)        5 (T)

Effectively, with Shadow DOM, AT_TARGET phase:
1) mimics bubbling if event is non-bubbling, or
2) is combined with bubbling otherwise.

Does this make any sense? Does this seem like a good idea? :)

I don't have a strong opinion to either idea.

For me, the original one looks natural one.
I'd like to know the reason and use cases for changing the behavior.


(In reply to comment #6)
> (In reply to comment #5)
> 
> I think what Daniel wants is:
> 
>   A          1 (C)  
>   B          2 (C)
>   C (SH)            7 (T)
>   D          3 (C)
>   E (SH)            6 (T)
>   F          4 (C) 
>   G (Target)        5 (T)
> 
> Effectively, with Shadow DOM, AT_TARGET phase:
> 1) mimics bubbling if event is non-bubbling, or
> 2) is combined with bubbling otherwise.
> 
> Does this make any sense? Does this seem like a good idea? :)

(In reply to comment #6)
> Effectively, with Shadow DOM, AT_TARGET phase:
> 1) mimics bubbling if event is non-bubbling, or
> 2) is combined with bubbling otherwise.
> 
> Does this make any sense? Does this seem like a good idea? :)

I guess that since element.addEventListener's third parameter, useCapture, is 'false' in default, people is likely to have a mental model of 'event listernes are called from inner to outer'.
That might support the idea of 'minicing bubbling events' for AT_TARGET phase.

(In reply to comment #8)
> I guess that since element.addEventListener's third parameter, useCapture,
> is 'false' in default, people is likely to have a mental model of 'event
> listernes are called from inner to outer'.
> That might support the idea of 'minicing bubbling events' for AT_TARGET
> phase.

Right. Most of the time this parameter is false (very few use capture), so the order of events looks whacky: first listener is fired on the host that's farthest from the target.

(In reply to comment #9)
> (In reply to comment #8)
> > I guess that since element.addEventListener's third parameter, useCapture,
> > is 'false' in default, people is likely to have a mental model of 'event
> > listernes are called from inner to outer'.
> > That might support the idea of 'minicing bubbling events' for AT_TARGET
> > phase.
> 
> Right. Most of the time this parameter is false (very few use capture), so
> the order of events looks whacky: first listener is fired on the host that's
> farthest from the target.

Okay. Agreed. Let's change the order.
For the record, the new order should be:

For bubbling events:

  A          1 (C)  11 (B)
  B          2 (C)  10 (B)
  C (SH)             9 (T) 
  D          3 (C)   8 (B)
  E (SH)             7 (T)
  F          4 (C)   6 (B)
  G (Target)         5 (T)  


For non-bubbling events:

  A          1 (C)
  B          2 (C)
  C (SH)            7 (T) 
  D          3 (C)
  E (SH)            6 (T)
  F          4 (C)
  G (Target)        5 (T)  

Does this sound good?

I have to address one more issue:
  How to handle event.cancelBubble in the new event order?

For example, if an event lister on Node E sets event.cancelBubble to true on #7, what should be done for (#8 - #11)?

My idea is:
  - Event listeners on #9 should be called with AT_TARGET phase even though.
  - Event listeners on (#8, #10, #11) should not be called with BUBBLING phase.

> For bubbling events:
> 
>   A          1 (C)  11 (B)
>   B          2 (C)  10 (B)
>   C (SH)             9 (T) 
>   D          3 (C)   8 (B)
>   E (SH)             7 (T)
>   F          4 (C)   6 (B)
>   G (Target)         5 (T)

For reference, I've uploaded a patch in implementation side:
https://bugs.webkit.org/show_bug.cgi?id=113676

(In reply to comment #11)
> I have to address one more issue:
>   How to handle event.cancelBubble in the new event order?
> 
> For example, if an event lister on Node E sets event.cancelBubble to true on
> #7, what should be done for (#8 - #11)?
> 
> My idea is:
>   - Event listeners on #9 should be called with AT_TARGET phase even though.
>   - Event listeners on (#8, #10, #11) should not be called with BUBBLING
> phase.

I think this is reasonable.

https://dvcs.w3.org/hg/webcomponents/rev/1150e6c009d3 Please let me know if I messed things up.

Also, adding William+Blake to keep such changes on their radars.