Re: Pointer Events types and keyboard/keyboard-like interfaces?

It's an interesting question, thanks Patrick.

To me, pointer events is a relatively low-level API whose primary job
should be to faithfully represent the hardware to JS.  Higher level
semantics (such as click, focus, blur, etc.) are built above it.  In this
regard, synthesizing fake pointer events for a keyboard seems potentially
backwards to me.

I'd rather think of pointer events as being one of many possible inputs to
higher level semantics that indicate intent.  Unfortunately these higher
level input semantics are a bit of a mismash of various concepts from
various specs.  Perhaps there's something we could do to improve that?  Are
there concrete scenarios motivating your question?  Is the fundamental
problem here that websites tend to design for low-level mouse/pointer input
rather than targeting the higher level abstractions?

All that said, as with most spec design questions, I think we'd best answer
it by real-world experience with polyfills.  It seems like it shouldn't be
too hard to build a library that generates pointer events for keyboard
input.  There may be limitations and bugs that make this difficult, but I'd
personally prefer to focus on fixing those.  To me there's no reason why
this decision (do keyboards generate pointer events) _needs_ to be part of
the browsers instead of part of the framework.

Rick

On Sat, Jan 4, 2014 at 5:07 PM, Patrick H. Lauke <redux@splintered.co.uk>wrote:

> Although Pointer Events allow for much easier handling of pen/touch/mouse,
> one type of input that still requires completely separate event handling
> are keyboards (which fire keydown/keypress/keyup and the more abstracted
> focus/blur/click) and keyboard-like interfaces (for instance Talkback
> screenreader on Android, which seems to fire focus/blur when the focus
> rectangle is moved sequentially, plus an interesting blur > mousedown >
> mouseup > click > focus sequence when a control is activated on a page).
>
> I don't think it'd matter too much to distinguish between sequential
> navigation (TAB/SHIFT+TAB style moving along the cycle of focusable
> elements) and spatial navigation (old Opera-style SHIFT+cursor keys to move
> between focusable elements as they appear in the visual layout), but in
> principle, would it make sense to include a new pointerType value of
> "keyboard" or similar?
>
> On a more general note, is it out of scope for this spec to also suggest
> that browsers should then fire the relevant pointer events for
> keyboard/keyboard-like interfaces? I seem to remember that Sangwhan Moon
> mentioned to me that Opera were planning to do this for upcoming TV browser
> versions at some point...but basically, mapping the more abstracted events
> (not the key* ones) as follows:
>
> focus - pointerenter > pointerover
> click (when activated with kbd) - pointerdown > pointermove > pointerup
> (sort of like the equivalent of mouse compatibility events fired for touch
> events)
> blur - pointerout > pointerleave
>
> Thoughts?
>
> P
> --
> Patrick H. Lauke
> ______________________________________________________________
> re·dux (adj.): brought back; returned. used postpositively
> [latin : re-, re- + dux, leader; see duke.]
>
> www.splintered.co.uk | www.photographia.co.uk
> http://redux.deviantart.com | http://flickr.com/photos/redux/
> ______________________________________________________________
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> ______________________________________________________________
>
>