>> I hate to ask, since there could be use cases I'm missing, but what is a >> use >>case where a browser would need to grab the mouse immediately when the >> page >>starts? I'm not against the idea, but it might need a strategy to stop >> abuse. >>Here are some steps I see happening. > > 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. I want to point out that most FPS games have a menu at the front. 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? >> Also what are your guy's name ideas? I think I prefer mousecapture and >> >>mouserelease and just push aside the IE API. > > "Mouse capture" isn't just an >>IE API. There's also a similar Win32 API with > the same name, with the same >>use case as IE's API: to continue receiving > mouse motion when dragging. I'm >>sure there are other windowing systems with > it, too. > > I'd suggest >>"mousegrab". Since grab has no opposite mousegrab doesn't work. (ungrab isn't an English word and "let go" sounds wrong). After discussing this in the IRC channel for whatwg it seems like mouselock and mouseunlock are recommended. They describe the operation pretty well that the mouse is locked to an element. Anyone have disagreements or other ideas?
Received on Thursday, 10 February 2011 02:20:59 UTC