Re: [Pointer Lock] Comments

Thank you again:
https://dvcs.w3.org/hg/pointerlock/rev/25ad122a8000

On Tue, Dec 2, 2014 at 6:43 PM, timeless <timeless@gmail.com> wrote:

> 1. w3c is en-us
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#abstract
>
> modelling -> modeling
>
Done.

>
> 2. Xlib
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#h3_why-bundle-all-functionality-hiding-cursor-providing-mouse-deltas-instead-of-using-css-to-hide-the-cursor-always-providing-delta-values-and-offering-an-api-to-restrict-the-cursor-movement-to-a-portion-of-the-web-page
>
> > Direct APIs do not exist on all platforms (Win, Mac, Linux) to bound the
> cursor to a specific rectangle, and prototypes have not yet been developed
> to demonstrate building that behavior by e.g. invisible windows with xlib
> or manual cursor movement on Mac.
>
> "Xlib - Wikipedia, the free encyclopedia" --
> http://en.wikipedia.org/wiki/Xlib

Done. Linked to definition.

>
>
> Also note that "Mac" is not a proper term, it could be "Mac OS (X)",
> "Macintosh ..." or "macs".
>

Done. Expanded to more formal names.

>
> 3. Mouse capture
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#introduction
>
> > Pointer Lock is related to Mouse Capture [MDN-SETCAPTURE].
>
> should https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600 be noted?
>
Done.

>
> MS should probably be referenced:
> http://msdn.microsoft.com/en-us/library/ie/ms536742%28v=vs.85%29.aspx
> since it's their fault...
>
Done.

>
> 4. a11y/i18n
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#dfn-engagement-gesture
>
> > An event generated by the user agent as a result of user interaction
> intended to interact with the page. e.g. click, but not mousemove.
> > Engagement gestures are any events included in the definition of being
> allowed to show a popup with the addition of keypress and keyup.
>
> "shift", or "control+shift" and similar things are often used to trigger
> an assistive technology, or an IME / language switch.
>
>
> https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/access_stickykeys_settings.mspx?mfr=true
>
> > turn StickyKeys on or off by by pressing the SHIFT key five times
>
>
> http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/langbar_keystroke_shortcuts.mspx?mfr=true
>
> > Switch between languages or keyboard layouts CTRL+SHIFT or left ALT+SHIFT
>
> http://support.microsoft.com/kb/97738
>
> > When you press the APOSTROPHE (') key, QUOTATION MARK (") key, ACCENT
> GRAVE (`) key, TILDE (~) key, ACCENT CIRCUMFLEX key, or CARET (^) key,
> nothing appears on the screen until you press the a second key. If you
> press one of the letters designated as eligible to receive an accent mark,
> the accented version of the letter appears. If you press an ineligible key,
> two separate characters appear. In other words, the US-International
> keyboard layout dynamic-link library (DLL) automatically accents letters
> that customarily receive an accent but does not automatically accent
> letters that do not customarily receive an accent.
>
> While it's nice to allow for "keys" to trigger a lock, "keys" that may
> eventually be handled by something outside the UA should probably not be
> eligible for this.
>
Done.
"user interaction intended to interact" -> "user interaction processed by
the user agent"
Added: "Note that operating system level accessibility and
internationalization features may intercept gestures before the user agent
processes them for interaction with a page. E.g. multiple key press codes
used to enter an extended international character."

>
> 5. must
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#pointerlockchange-and-pointerlockerror-events
>
> > Two events are used to communicate pointer lock state change or an error
> in changing state. They are named pointerlockchange and pointerlockerror.
> If pointer lock is entered or exited for any reason a pointerlockchange
> event must be sent.
>
> If I press ctrl-w/cmd-w (close window/tab), is the UA required to send
> these events?


> If an iframe has pointerlock, and its parent removes the iframe from the
> dom, is the UA required to send these events?
> If an iframe has pointerlock, and its parent changes the iframe's document
> url to another page, is the UA required to send these events?
>

Help me pin down language. For each case above: Yes, If the document exists
the events should be dispatched. Is more language needed to avoid the
alternative implied assumption that a document must live until the events
are dispatched?

>
>
> 6. and
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Element-requestPointerLock-void
>
> > (for example: mousemove, mousedown, mouseup, click, wheel)
> > (for example: mouseover, mouseout, drag, drop).
>
Done.

>
> Please use "and" -- you do elsewhere:
>
> > clientX, clientY, screenX, and screenY
>
> 7. movement/focus
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Element-requestPointerLock-void
>
> > Movement and button presses of the mouse must not cause the window to
> lose focus.
>
> Suppose I'm using Windows w/ a standard 104 key keyboard:
> http://en.wikipedia.org/wiki/Computer_keyboard#mediaviewer/File:Qwerty.svg
>
> If I press a system key (the Windows key), or a system key equivalent
> stroke (ctrl+esc), I expect the application to lose focus.
>
I agree, but don't see a conflict in the spec wording: "Movement and button
presses of the mouse" haven't occurred.

Thre requirements section states that unlock must happen in your described
situation: "Pointer lock must be exited if the target is removed from its
document, or the user agent, window, or tab loses focus."

>
> http://developer.android.com/design/media/whats_new_nav_bar.png
>
> If I press the home key on an Android device, I expect the window to lose
> focus.
>

I agree, a touch to home will remove focus at the OS level.

>
> If a user is on a system where there is no hardware home button, but there
> is a gesture which enables interacting with the system, the UA shouldn't be
> out of compliance.
>
> see Fast Quick Settings Access --
> http://blogs.blackberry.com/2014/05/planned-new-features/


I agree touch gestures such as these will remove focus and release pointer
lock. Note that touch gestures aren't controling the system pointer. I'm
not aware of a mobile implementation of pointer lock, but when one arrived
I would maintain that all pointer gestures must still comply and not exit
pointer lock.


>
> 8. comma comma
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#attributes
>
> > onpointerlockchange of type EventHandler, , nullable
>
> the extra comma here is not helpful.
>
> > onpointerlockerror of type EventHandler, , nullable
>
> the extra comma here is not helpful.
>
> > pointerLockElement of type Element, readonly , nullable
>
> the extra space before the comma here is not helpful.
>

https://github.com/w3c/respec/issues/295


>
> 9. if pointer lock state is currently unlocked?
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Document-exitPointerLock-void
>
> > 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.
>
> 10. please spell out screenY
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#widl-Document-exitPointerLock-void
>
> > (the same location that is reported in screenX/Y when the pointer is
> locked).

Done.

>
> 11. Long bounds
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#attributes-1
>
> > All motion data must be delivered via mousemove events such that
> > between any two mouse events earlierEvent and currentEvent the value of
> currentEvent.screenX-earlierEvent.screenX
> > is equivalent to the sum of all movementX values received on mousemove
> events after earlierEvent.
>
> webidl: The long type is a signed integer type that has values in the
> range [−2147483648, 2147483647].
>
> Suppose I have a computer with a lot of time on its hand.
>
> Steps:
> T1. trigger a page with pointerlock triggering code
> T2. pointerlock triggers
> T3. computer moves the mouse 100 pixels (x direction only, the computer is
> very precise)
> T4. computer goes to step T3 (this may take ~21,474,800 steps depending on
> screen position... -- but as I said, the computer has time on its hands)
>
> Eventually, I believe that one of screenX or movementX will hit an end of
> the `long` range. Will the "equivalent" statement above still apply?
>

I've added ", with the exception of when screenX can not be updated because
the pointer is clipped by the user agent screen boundaries."

Which leaves the case where the screen is larger than a long can represent,
in which case MouseEvent and PointerLock's extension to it will need
updating.


> 12. valid?
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#attributes-1
>
> > movementX/Y must be valid regardless of pointer lock state.
>
> what does "valid" mean?
>
Done. replaced with "updated".


>
> 13. a
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#requirements
>
> > A default unlock gesture must always be available that will exit pointer
> lock.
>
> I'm not sure what a default unlock gesture looks like, but please see 7
> for at least some examples where I suspect platforms will have multiple
> gestures where the application will lose focus. I'd like to ensure that the
> text understands this and makes it clear to implementers and consumers.
>

The text states after that sentence:
"""
NOTE
The ESC key is the recommended default unlock gesture for user agents with
keyboard input. It is recommended that the unlock gesture also match any
used to exit fullscreen [FULLSCREEN].
"""


> 14. exit due to events
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#requirements
>
> > Pointer lock must not be exited when fullscreen [FULLSCREEN] is entered
> or exited unless the pointer
> > is required to enable interaction with the user agent graphical user
> interface
> > or the default unlock gesture was used to exit both fullscreen and
> pointer lock.
>
> I'm using a laptop, it's running Windows 8. It isn't connected to a
> charging source (and hasn't been for 7 hours). I use a UA w/
> PointerLock+FullScreen w/ a web page that takes pointer lock and full
> screen. My system needs to tell me that I'm going to run out of power. It
> does so.
>
> I'm using a corporate laptop. It has a screen saver with a short timeout
> (IT...). I trigger the same app w/ the same full screen+pointer lock and
> then get coffee. When I get back, my system has taken focus and sent it to
> the screen saver.
>
> I'm using a phone. It has a phone. I trigger the same app w/ the same full
> screen+pointer lock and I receive a phone call. I need to be able to answer
> the phone call.
>
> I believe that the language I've quoted violates all three of the UCs I've
> described.
>

Added ", or window or tab focus was lost".

>
> 15. give your examples ids
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#synthetic-cursor-interaction-with-html-dom-ui
>
> > EXAMPLE 1
>
Done.


> 16. missing ;
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#synthetic-cursor-interaction-with-html-dom-ui
>
> >  var ee = document.createEvent("MouseEvents");
>
> >  var target = document.elementFromPoint(x, y)
>
Done.

>
>
> >  if (e._isSynthetic)
> >    return;
>
> >  if (target)
> >    target.dispatchEvent(ee)
>
Done.

>
> 17. undocumented
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#security
>
> > Changing to new tabs, windows, or any other action that causes a page to
> lose focus will exit pointer lock.
>
> I can't find this in the spec
>
Requirements section

"""
Pointer lock must be exited if the target is removed from its document, or
the user agent, window, or tab loses focus. """

>
> 18. Sentences start with capital letters
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#why-not-merge-with-mouse-capture-setcapture
>
> > Mouse Capture [MDN-SETCAPTURE] handles low security risk mouse event
> target lock for the duration of a mouse drag gesture.
> > pointer lock removes the concept of the cursor and directs all events to
> a given target.
>
> ^ this is the beginning of a sentence...
>
Done.

>
> > They are related, but different.
>
> 19. Brands
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#why-bundle-all-functionality-hiding-cursor-providing-mouse-deltas-instead-of-using-css-to-hide-the-cursor-always-providing-delta-values-and-offering-an-api-to-restrict-the-cursor-movement-to-a-portion-of-the-web-page
>
> > Direct APIs do not exist on all platforms (Win, Mac, Linux)
>
> Please spell out Windows and Mac OS X.
>
Done.

>
> > to bound the cursor to a specific rectangle, and prototypes have not yet
> been developed to demonstrate building that behavior by e.g.
> > invisible windows with xlib
>
> See earlier comment about Xlib
>
Done.

>
> > or manual cursor movement on Mac. Unaccelerated Delta values have been
> proposed to be accessed by reading raw Human Interface Device (HID) data.
> > E.g. WM_INPUT messages on windows, and USB device APIs on Mac / Linux.
>
> Note that this Windows should be Windows, not to be confused with the
> earlier windows which was not!
> And again, Mac OS X (or Macintosh, if you want to be inaccurate).
>
Done.

>
> 20. reference for "invisible windows"
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#why-bundle-all-functionality-hiding-cursor-providing-mouse-deltas-instead-of-using-css-to-hide-the-cursor-always-providing-delta-values-and-offering-an-api-to-restrict-the-cursor-movement-to-a-portion-of-the-web-page
>
> > e.g. invisible windows with xlib
>
> Please reference:
> http://tronche.com/gui/x/xlib/window/attributes/
> or something.
>
> Done.

> 21. references
>
>
> https://dvcs.w3.org/hg/pointerlock/raw-file/ea789b4e5b82/index.html#high-resolution-deltas-high-frequency-updates
>
> > "Why bundle all functionality (hiding cursor, providing mouse deltas)
> instead of using CSS to hide the cursor, always providing delta values, and
> offering an API to restrict the cursor movement to a portion of the web
> page?" above.
>
> Please save those of us with screen readers the pain of trying to find
> above. You appear to have anchors for this target, please use them.
>
Done.

>
>
>
> 22. Accessibility
>
> > users are expected to have already configured the full system of
> hardware input and operating system
> > options resulting in a comfortable control the system mouse cursor.
>
> If I'm using a Screen Reader. What should happen?
>
> The screen reader I normally use rarely sends mouse move events. It tends
> to only send mouse click events. It also spends a lot of time focusing
> things. Because the user wants to know what they are. (As far as the user
> is concerned, if the item can't be partially focused, it doesn't exist.)
>
> Note: The screen reader's click on something will almost certainly be a
> valid "Engagement gesture" unless modifications are made to the
> specification.


The section quoted is describing why the specification uses the same units
for movementX as are already used for screenX. I think the argument there
stands but is different than the question you are asking.

Pointer Lock is an input method centrally focused on movement deltas for a
pointer device. The use cases described would be hard to satisfy without an
input device that is suited for generating movement deltas similar to a
mouse, touch pad, or puck / nub.

Let's discuss a user using only a screen reader not designed for pointer
lock that moves the mouse instantly to target items that are focus targets.
I expect most applications using pointer lock will not offer useful focus
targets. If elements exist on screen I expect unmodified screen readers to
attempt to move to elements that may exist on the page out of the typical
canvas 2D or 3D area. This will likely cause large sudden movements to the
perception of the user agent. When viewing a 3D world or model there will
be a sudden impulse of change of orientation. It will likely be undesirable.

A screen reader, or alternative input tool, that had controls to simulate
mouse moves would offer some usability. E.g. for a person unable to use a
mouse who used a screen reader for more discrete input control there may
exist commands such as "move mouse left" which move the system pointer left
by e.g. 10 pixels. Perhaps there are variations for 1, 10, 100 pixels.
These may be bound to keyboard style keys, foot pedals, or voice commands.
These inputs would be feasible to work correctly with pointer lock. Though,
I could anticipate bugs in the integration if e.g. the user agent
implements pointer lock by cursor warping and this confused the input
software. However, it would be tractable to resolve these.

In that scenario I could see functional model viewers, 3D world navigation,
and map panning use cases, though input would likely take more time than
users with a mouse.