Dispatch of pointerover+pointerenter and pointerout+pointerleave in relation to related mouse events is not clearly specified

[graouts]

If I write a test that listens to pointerover and pointerenter as well as the mouse events mouseover and mouseenter I get this sequence in both Firefox and Chrome:

1. pointerover
2. pointerenter
3. mouseover
4. mouseenter

However, I'm not sure the spec says why this would be the correct behavior instead of:

1. pointerover
2. mouseover
3. pointerenter
4. mouseenter

Should the spec clearly state how those related events are ordered?

The same applies to pointerout, pointerleave, mouseout and mouseleave.

[NavidZ]

The spec used to be similar to what you expected. But due to this issue we had to change to make it to the current state. Can you take a look at that issue and let me know whether you have more concerns or not?

[graouts]

Just to confirm @NavidZ, you're saying the spec does not mandate either of the cases I describe and both are accepted? I don't think it's a big interop issues because content using pointer events and content using mouse events will get a similar sequence of events in both cases.

If so, happy to close this issue as a duplicate.

[patrickhlauke]

The specific event sequence mentioned in the spec is only a suggestion (couched in MAYs and SHOULDs) per the section 11 intro https://www.w3.org/TR/pointerevents/#compatibility-mapping-with-mouse-events

The following describes an algorithm for how a user agent MAY map generic pointer input to mouse events for compatibility with this content. [...] The compatibility mapping with mouse events are an OPTIONAL feature of this specification.

The suggested order of events in https://www.w3.org/TR/pointerevents/#mapping-for-devices-that-do-not-support-hover is further inside a note, which in this spec is treated as non-normative.

[NavidZ]

As @patrickhlauke said there is no mandate on that ordering. However, I can tell you some back history of what caused to do this. Basically depending on how the UA generates the compatibility mouse events the boundary events (say mouseout and pointerout) don't always come together. Sometimes there is a mouseout without any pointerout for example when there is multiple pointers on the screen that can generate mouse compatibility events. Then we realized the old text of having pointerout right before mouseout gives the impression of them always being fired at the same time. So we completely made them separate so that each will follow their own logic.