RE: Pointer Lock API

Sorry, wrong place. Please ignore.

Léonie.

> -----Original Message-----
> From: Léonie Watson [mailto:tink@tink.uk]
> Sent: 02 February 2016 16:49
> To: 'tink@tink.uk' <tink@tink.uk>; 'public-apa@w3.org' <public-
> apa@w3.org>
> Subject: RE: Pointer Lock API
> 
> 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:50:35 UTC