- From: James Graham <james@hoppipolla.co.uk>
- Date: Wed, 1 Jun 2016 10:23:20 +0100
- To: "public-browser-tools-testing@w3.org" <public-browser-tools-testing@w3.org>
I haven't tried writing this up in more detail yet, but I have at least one major question about how pointer events are supposed to work when the pointer moves. Imagine a document with three elements, all square and 10px x 10px in a horizontal line, like so: _ _ _ | | | | - - - For simplicity let's call the elements A,B,C from left to right. Let's save I move a mouse-type pointer to (5,5) and then to (25,5). Ignoring the events generated by the initial move to (5,5) for now (because that's a second and harder question), what events should be generated for the second move taking us from the middle of A to the middle of C? The simplest answer would be a single mousemove event. But an answer more like the movement of a real pointer would include events like mouseleave on A, mouesenter, mouseover, and mouseleave on B and mouseenter and mouseover on C, as well as the mousemove event and the corresponding pointer events. This apparently requires knowing the complete set of elements along the path. In fact it's much worse than that; consider the case where B responds to a mouseover event by resizing itself to 20x10; in this case there should certainly not be any mouseevents targeted at C. If we want the latter option it's possible to spec in a handwavy way by talking about the set of mouse events that will be generated by moving from the current position to the new position. But in terms of implementation it seems to represent a specific choice; you would have to inject cursor movements at an above-DOM layer and lat the browser go through its normal hit testing code path. I can also imagine non-interoperable cases where the resolution of the events is different and so different elements are hit. What is desired in this case? Is there an option I missed?
Received on Wednesday, 1 June 2016 09:23:46 UTC