W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: Mouse Lock

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 23 Jun 2011 19:10:20 -0700
Message-ID: <4E03F20C.6040709@jumis.com>
To: timeless <timeless@gmail.com>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, Olli@pettay.fi, Jonas Sicking <jonas@sicking.cc>, Adam Barth <w3c@adambarth.com>, Vincent Scheib <scheib@google.com>, Brandon Andrews <warcraftthreeft@sbcglobal.net>, "Gregg Tavares (wrk)" <gman@google.com>, Glenn Maynard <glenn@zewt.org>, Kenneth Russell <kbr@google.com>, robert@ocallahan.org, public-webapps@w3.org
timeless,

I agree, it'd be nice to know. I'd really like to see this put toward 
the "AG" (Accessibility Guidelines)
people, as they're the ones who follow this kind of things.

It's absolutely the case that a user needs an ability to escape from the 
mouse lock context,
and to have one which lies outside of any processing handled by the 
untrusted scripting environment.
The *AG practices are always the first to document these needs.

Requiring keyboard for something that locks a mouse is not acceptable;
a user must be able to release their pointer device without requiring
a keyboard. The same applies for keyboard locks.

Assistive technologies (AT) have their place in this, and can give some 
leeway to the user agent (UA),
as long as the UA provides enough semantics to allow the AT to handle 
this kind of work.

Again, these issues are always brought up by AG documents.

I'll give you two examples for pointer device escape:
1) "Right click"/context menu; always works.
2) "Click and hold"; X number of seconds could pop up a context menu.
3) "extreme coordinate and hold"; x seconds on an extreme coordinate 
pops up a menu.

On the extreme-coordinate; an input device which may only signal changes 
in x/y positioning
may still be used to activate UA menus.

Developers are by all practical purposes, required by existing standards 
and technologies,
to leave space on the edges of the screen. Though this is mostly related 
to "safe areas"
on televisions, the principle applies beyond that, and is de facto 
required by existing
full screen semantics [wherein the top extremes create a dialog to escape].

So, by luck of history; extreme coordinates are encouraged and in 
practice, required
as a means of escaping mouse lock.

There are certainly cases where extreme coordinates could be useful to 
an application.
Those corner cases will have to be thought about, by those implementing 
such apps.

All the best,

-Charles

On 6/23/2011 6:29 PM, timeless wrote:
> And what if the device in question is just a touchscreen with no
> keyboard, mouse or hardware buttons?
>
> On 6/20/11, Tab Atkins Jr.<jackalmage@gmail.com>  wrote:
>> On Mon, Jun 20, 2011 at 3:03 PM, Olli Pettay<Olli.Pettay@helsinki.fi>
>> wrote:
>>> On 06/21/2011 12:25 AM, Tab Atkins Jr. wrote:
>>>> The use-case is non-fullscreen games and similar, where you'd prefer
>>>> to lock the mouse as soon as the user clicks into the game.  Minecraft
>>>> is the first example that pops into my head that works like this -
>>>> it's windowed, and mouselocks you as soon as you click at it.
>>> And how would user unlock when some evil sites locks the mouse?
>>> Could you give some concrete example about
>>> " It's probably also useful to instruct the user how to release the lock."
>> I'm assuming that the browser reserves some logical key (like Esc) for
>> releasing things like this, and communicates this in the overlay
>> message.
Received on Friday, 24 June 2011 02:10:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT