- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 12 Aug 2011 09:53:35 -0700
- To: robert@ocallahan.org
- Cc: Vincent Scheib <scheib@google.com>, Klaas Heidstra <klaas1988@gmail.com>, Brandon Andrews <warcraftthreeft@sbcglobal.net>, Olli@pettay.fi, Ryosuke Niwa <rniwa@webkit.org>, Adam Barth <w3c@adambarth.com>, "Gregg Tavares (wrk)" <gman@google.com>, Glenn Maynard <glenn@zewt.org>, Charles Pritchard <chuck@jumis.com>, Kenneth Russell <kbr@google.com>, public-webapps@w3.org
On Thu, Aug 11, 2011 at 10:14 PM, Robert O'Callahan <robert@ocallahan.org> wrote: > If your implementation had to warp the mouse cursor on Windows to get > accurate delta information, the mouse position in the existing mouse > events would no longer be very meaningful and a new event type seemed > more logical. But assuming Klaas is right, we no longer need to worry > about this. It seems we can unconditionally add delta information to > existing mouse events. So I withdraw that comment. I suspect that, while locked, we still don't actually want to expose the various x and y properties for the mouse. I agree with Vincent that the *other* mouseevent properties are all useful, though, and that the delta properties are really useful in non-mouselock situations. We should just zero all the position information. Even if we can switch all OSes to a delta mode, the position will be arbitrary and meaningless. This seems easier than making a new type of mouse event that exposes all of normal mouse events except the position, and ensuring that the two stay in sync when we add new info. ~TJ
Received on Friday, 12 August 2011 16:54:22 UTC