- From: Glenn Maynard <glenn@zewt.org>
- Date: Wed, 9 Feb 2011 22:06:28 -0500
- To: Brandon Andrews <warcraftthreeft@sbcglobal.net>
- Cc: Charles Pritchard <chuck@jumis.com>, Kenneth Russell <kbr@google.com>, robert@ocallahan.org, public-webapps@w3.org
- Message-ID: <AANLkTik9VKr3YpGUgNk+SVH3U7XyROn+cdzr1pws2kOZ@mail.gmail.com>
On Wed, Feb 9, 2011 at 9:20 PM, Brandon Andrews < warcraftthreeft@sbcglobal.net> wrote: > > If I load a first-person game in a tab, I shouldn't need to click the window > > to allow the page to capture the mouse. That'll force every game to start > > with a superfluous box saying "click here to start". > > So right when you go to that tab even just to glance at it your mouse will be grabbed. That depends on how it's implemented. (I'd rather not go into specifically how I think browsers might do this--those particular details aren't the point, at least at this stage.) Of course, browsers can still choose to only allow initiating a grab on click, and it can even be codified in the spec if that's what people really want. Again, the point is that it's not necessary to do that in a way that's impossible to change later on. If grabbing the mouse happens by the act of receiving a particular event, then it's impossible to ever relax the restriction without making a whole new API. (I also seriously doubt that any proposal will gain traction that causes merely listening to an event to have side-effects. That's not how DOM events work.) > I want to point out that most FPS games have a menu at the front. Try not to make too many assumptions about UIs. A couple more examples: - Depending on clicking on the main menu to grab the mouse is brittle. It means you need to determine *at the time of the click* whether to grab the mouse. For example, if you have "start game" and "options" menu items, the menu item itself needs to know to grab the mouse when "start game" is clicked, but not when "options" is clicked. That's an ugly, limiting design. - It breaks down in a typical "lobby" UI. For example, you have a window where people can join a game about to start, set options, chat, etc., with a timer counting down for the game to start. When the timer reaches 0, the lobby UI goes away and the game starts--and everyone's mouse should be grabbed without needing to click the window again. - VMware grabs keyboard and mouse input to redirect it to the VM. You can do this by clicking the window, but you can also do it with a keyboard shortcut (^G), so you can fully grab input with the keyboard alone. This should be allowed from the start: mouse grabbing should be allowed from any input event (other than mousemove), including keyboard events. (Please don't nitpick the individual examples; the point is that there are lots of cases where it makes sense to grab the mouse without it being in response to a click.) > But yeah the main problem with just grabbing the mouse is that people just switching through tabs probably don't want their mouse grabbed. That and what happens when a tab isn't in view when capture is called? It fails, as if the user was prompted for permission and clicked "no". > Since grab has no opposite mousegrab doesn't work. (ungrab isn't an English word and "let go" sounds wrong). I don't think "ungrab" is unnatural, but I'm not too concerned with the naming, aside from avoiding "capture". -- Glenn Maynard
Received on Thursday, 10 February 2011 03:07:01 UTC