W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

[pointerlock] Various comments

From: Ms2ger <ms2ger@gmail.com>
Date: Thu, 09 Jan 2014 16:08:15 +0100
Message-ID: <52CEBB5F.9020402@gmail.com>
To: Vincent Scheib <scheib@google.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
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.


Received on Thursday, 9 January 2014 15:08:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC