Re: [pointerlock] Various comments

While we're on the subject of pointer lock, I'm concerned about what 
happens when the pointer is removed while in pointer lock.

New devices such as a Microsoft Surface have the pointing device as a 
trackpad embedded with a detachable keyboard. What happens when the user 
is pointer locked, they detach said keyboad and thus the pointer too? 
Now they only have touch input, no pointer, since the only "pointer" 
they had was the trackpack on the keyboard that they just detached. 
Traditional laptops and desktop PCs won't be detaching their pointers 
very frequently, but new form factor devices will do so more frequently 
and are more likely to hit this issue.

Perhaps we should add text to the spec to say that pointer lock should 
be exited if all pointers are detached from the device?

And should requests for pointer lock on devices without a pointer (like 
a touch-screen tablet for example) be specified to automatically fail?


Regards,
Chris Pearce.



On 1/10/2014 4:08 AM, Ms2ger wrote:
> Hi Vincent,
>
> I have by no means reviewed the entire spec, but while reviewing the 
> test cases, I noticed some room for improvement. Comments below.
>
>
> In the "4. pointerlockchange and pointerlockerror Events" section [1]:
>
> > "… with its |bubble| attribute set …"
>
> should be |bubbles|. Probably best to link to the definition in DOM, too.
>
>
> If you add attributes to MouseEvent, you should also add them to the 
> MouseEventInit dictionary, so they can be initialized.
>
>
> Defaults should be defined for those attributes in prose too, for the 
> createEvent case. Text could be:
>
> # When an event is created, the attribute must be initialized to […].
>
>
> In the definition of requestPointerLock [2], a reference to DOM 3 Core 
> is made; it looks like it should be to DOM 3 Events or UI Events instead.
>
>
> In section "6.1 Attributes", the writable attributes have two 
> consecutive commas in their definition:
>
> > onpointerlockchange of type EventHandler, , nullable
>
> Possibly a ReSpec bug; if so, please report to whereever such issues 
> should be reported.
>
>
> In general, the prose could be made less ambiguous. For example, the 
> definition of exitPointerLock:
>
> # Initiates an exit from pointer lock state if currently locked to a
> # target in this document, and sends a pointerlockchange event when the
> # lock state has been exited.
> #
> # The system mouse cursor must be displayed again and positioned at the
> # same location that it was when pointer lock was entered (the same
> # location that is reported in screenX/Y when the pointer is locked).
>
> could be rewritten as:
>
> | 1. If the pointer is not currently locked to a target in the
> | context object, terminate these steps.
> | 2. Exit the lock state. [Or should this be queued too? An
> | unambiguous specification would have answered this
> | question.]
> | 3. Display the system mouse cursor again, positioned at the
> | same location that it was when pointer lock was entered.
> | 4. Deliver [link to section 4. pointerlockchange and
> | pointerlockerror Events] a |pointerlockchange| event to the
> | context object.
> | Note: this is the same location that is reported in
> | screenX/Y when the pointer is locked.
>
>
> The dfn-exitpointerlock id is on an empty dfn element, which seems 
> pretty silly.
>
> HTH
> Ms2ger
>
> [1] 
> https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#pointerlockchange-and-pointerlockerror-events
> [2] 
> https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#widl-Element-requestPointerLock-void
>

Received on Sunday, 12 January 2014 22:48:51 UTC