- From: Hayato Ito <notifications@github.com>
- Date: Mon, 20 Aug 2018 22:57:09 -0700
- To: w3c/uievents <uievents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 21 August 2018 05:57:31 UTC
@garykac the event viewer is great! I finally understand how `mouseenter` works exactly. Let me double-check what is being proposed in this issue here. Given the following tree (of trees): ```text A ├── B │ └── C │ └──/shadow-root-1 │ └── D │ └── E │ └──/shadow-root-2 │ └── F │ └── G └── H ``` C and E are shadow hosts. ## Case 1 mouse moves from `H` to `G` ### The current spec: Composed `mouseenter` events are fired on [shadow-root-2, F, G], in this order, if my understanding is correct. Note that it's a composed event, so E, for example, receives also a `mouseenter` at TARGET phase, for each event dispatching. ### New proposal Non-composed `mouseenter` events are fired on [B, C, shadow-root1, D, E, shadow-root-2, F, G], in this order. (Or any other ideas?) ## Case 2 mouse moves from `F` to `G` ### The current spec: Composed `mousenter` event is fired on only [G] ### New proposal Non-composed `mouseenter` event is fired on [G] -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/uievents/issues/208#issuecomment-414558563
Received on Tuesday, 21 August 2018 05:57:31 UTC