Expand introduction to better describe problem/use case

[patrickhlauke]

DOM input events are an abstraction above low-level input events, only loosely tied to physical device input (e.g. ‘click’ events can be fired by a mouse, touchscreen or keyboard). There is no mechanism to obtain lower-level details about the physical device responsible for an event. This leads to problems, as developers may need to make assumptions or rely on heuristics. For example, when supporting both mouse and touch input, it's difficult to know whether a mousedown event represents new input from a mouse, or a compatibility event for a previously processed touchstart event.

I think the first part of this could do some additional text to introduce the idea of compat events.

DOM input events are an abstraction above low-level input events, only loosely tied to physical device input (e.g. ‘click’ events can be fired by a mouse, touchscreen or keyboard). There is no mechanism to obtain lower-level details about the physical device responsible for an event. Depending on implementation, certain types of input can also generate further "fake" DOM input events for compatibility reasons. For example, touchscreen interactions not only fire touch events, but also compatibility mouse events; when supporting both mouse and touch input, it's difficult to know whether a mousedown event represents new input from a mouse, or a compatibility event for a previously processed touchstart event. This leads to problems, as developers may need to make assumptions or rely on heuristics.

...or something like that?

[RByers]

Love it, want to submit a PR for this?

[patrickhlauke]

I'll try, without tripping over git and making a mess :wink:

[RByers]

I don't mind just making the change if you like, but learning github is fun :-). You can even do that without ever leaving the github web UI (just fork, create a branch, edit the file in the web UI, view your local version to make sure it looks good, then generate a pull-request).