W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mouse Lock

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 12 Aug 2011 09:53:35 -0700
Message-ID: <CAAWBYDDP9FAd=R2DSvAVSKz_QTX8MmYE0cijYVMVbUt+_Qbd6Q@mail.gmail.com>
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

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.

Received on Friday, 12 August 2011 16:54:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:43 UTC