- From: Marcos Cáceres <notifications@github.com>
- Date: Wed, 25 Oct 2023 15:13:52 -0700
- To: w3c/pointerlock <pointerlock@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/pointerlock/pull/49/review/1698329018@github.com>
@marcoscaceres commented on this pull request. > + Once in the [=pointer lock state=] the [=user agent=] has a + [=pointer-lock target=], a <dfn>pointer-lock options</dfn>, which is + a {{PointerLockOptions}} and a <dfn>cursor position</dfn> which is a + pair of numbers representing the location of the system mouse cursor + when the Pointer Lock State was entered (the same location that is + reported in `screenX`, `screenY`). The [=pointer-lock target=] must + receive all relevant user generated {{MouseEvent}} events: namely, + all user-generated `mousemove`, `mousedown`, `mouseup`, `click`, + `dblclick`, `auxclick`, and `wheel` [[ui-events]]. No other elements + may receive these events while in [=pointer lock state=]. There will + be no dispatching of events that require the concept of a mouse + cursor: namely, `mouseenter`, `mouseleave`, `mouseover`, `mouseout`, + `drag`, and `drop`. + </p> + <p> + While in the [=pointer lock state=] if the [=pointer-lock options=]' ```suggestion While in the [=pointer lock state=] if the {{PointerLockOptions}}'s ``` Can we also drop the pointer-lock options concept? We don't really need it if we have the dictionary. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/pointerlock/pull/49#pullrequestreview-1698329018 You are receiving this because you are subscribed to this thread. Message ID: <w3c/pointerlock/pull/49/review/1698329018@github.com>
Received on Wednesday, 25 October 2023 22:13:58 UTC