- 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