- From: Léonie Watson <tink@tink.uk>
- Date: Tue, 2 Feb 2016 16:49:20 -0000
- To: <tink@tink.uk>, <public-apa@w3.org>
Ken Gould originally reported this problem on the beta list. Léonie. > -----Original Message----- > From: Léonie Watson [mailto:tink@tink.uk] > Sent: 02 February 2016 15:38 > To: public-apa@w3.org > Subject: Pointer Lock API > > I had an unofficial action to look at the Pointer Lock spec [1]. > > Pointer Lock is an API for capturing mouse movement (not position). When > mouse movement is detected and a lock is initiated, the visible cursor is > removed and mouse movements are used to control the environment. > > One of the use cases given in the spec is control of viewport orientation > within a first person game environment. Another is the rotation of views > within a 3D modelling environment. > > The spec requires that a default mechanism for disengaging from the pointer > lock is made available. The escape key is the recommended mechanism, > which appears to address any concerns about mouse trapping. > > The pointer lock interaction closely resembles the way the mouse is used to > control the viewport with screen magnification though. For example, if the > mouse is locked into controlling the orientation of a viewport, it cannot > presumably be used to control which part of the viewport currently has > magnifier focus. > > I think the escape mechanism should be enough to permit magnifier users to > switch in/out of the lock when nescessary. Thoughts welcome though. > > Léonie. > [1] https://w3c.github.io/pointerlock/ > > -- > @LeonieWatson tink.uk Carpe diem > > > > >
Received on Tuesday, 2 February 2016 16:49:46 UTC