- From: Domenic Denicola <notifications@github.com>
- Date: Wed, 22 Jan 2020 10:48:07 -0800
- To: w3c/pointerlock <pointerlock@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/pointerlock/pull/49/review/346818779@github.com>
domenic commented on this pull request.
> + we will call the <dfn>target</dfn>, receives all mouse events and the cursor
+ is hidden.</p>
+ <p>
+ Once in the <a>Pointer Lock State</a> the <a>user agent</a> must fire all
+ relevant user generated {{MouseEvent}} events (for example:
+ `mousemove`, `mousedown`, `mouseup`, `click`, and `wheel`)
+ [[ui-events]] to the <a>target</a> of pointer lock, and not fire
+ mouse events to other elements. Events that require the concept of
+ a mouse cursor must not be dispatched (for example: `mouseover`,
+ `mouseout`, `drag`, and `drop`).
+ </p>
+ <p>
+ <dl data-dfn-for="PointerLockOptions" data-link-for=
+ "PointerLockOptions">
+ While in the <a>Pointer Lock State</a> if <a>unadjustedMovement</a> is
+ <code>true</code> the event coordinates must not be affected by the
Hmm, I think this comment was overtaken by later parts of the review, which suggest storing a user agent-wide pointer lock options, which does use the `PointerLockOptions` dictionary. In that case I think it's OK to reference API-level concepts, but you should take about the user agent's pointer lock options's unadjustedMovement member being true.
(Note: it cannot be undefined; the Web IDL layer will translate undefined to false.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/pointerlock/pull/49#discussion_r369738109
Received on Wednesday, 22 January 2020 18:48:10 UTC