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

I was going to write essentially what Jacob did.  I agree it's a bit of a
blurry line.  Eg. what about a TV-based browser that has a DPAD that makes
a mouse-like cursor jump between the center-points of focusable elements,
but also has a (rarely used) trackpoint for moving that cursor arbitrarily.
 In that case pointer events does seem appropriate to me.  Now what if the
'cursor' only shows when the trackpoint is used (but is still jumping
around to the center of focus rings when the DPAD is touched).

The good news is I don't think any of this is really a standards question -
it's a UA design choice (including the choice to use a new value for
'pointerType').  I still have some concerns about the true extensibility of
pointer events, but hopefully we'll see a number of UAs (like Opera) and JS
frameworks try a bunch of things we can learn from.  In that vein, why have
the UA set pointerType to 'keyboard' at all when 'mouse' will probably work
better with existing websites?  If there's no new API surface area at all,
then we can skip the hard part (multi-vendor consensus) and focus on
changing specific UAs.

Personally I suspect there's a good reason why web developers sometimes
avoid the higher-level APIs (focus, blur, etc.), and that we should focus
on addressing those issues.  Eg. perhaps it's because they have semantics
which are complex, poorly specified, and implemented quite differently
between browsers and with different input devices.  If that's the case then
we can probably do more good by focusing on a library that consistently
exposes higher level semantics on top of pointer/mouse/touch/keyboard
events and encouraging it's use (trickling down into the standards and user
agents as appropriate).

Rick


On Mon, Jan 6, 2014 at 2:00 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:

> + www-dom, Gary Kacmarcik, and Travis Leithead who have been making great
> improvements on keyboard events over in Web Apps WG
>
> On Mon, Jan 6, 2014 at 8:06 AM, Bruce Lawson <bruce@brucelawson.co.uk>
> wrote:
> > Patrick said,
> >
> > "I fear that as we move over to pointer events, the same thing will
> > happen - devs just relying on pointer events as being the "umbrella"
> > events model that catches "everything"...and still forgetting to address
> > keyboard/keyboard-like interactions."
> >
> > I think this is a legitimate fear. I *want* pointer events to be an
> umbrella events model that catches everything, and from feedback I've
> received, developers do, too.
> >
> > However, we know that developers forget about keyboard access already
> (and other accessibility concerns, such as alternate text for images) so I
> worry that as pointer events catch on, there will be more accessibility
> problems.
>
> While I agree developers commonly forget about keyboard access, I don't
> think pointer events are going to make the situation worse. With respect to
> keyboard interaction, they work no different than what we already had with
> mouse events.
>
> > (And, FWIW, there seems to me no difference between "pointing" at
> something with a mouse, a finger, a pen or by tabbing to it).
>
> If all you're using pointer events for is to essentially select/click an
> element, sure. But for most scenarios that I see pointer events used in,
> the keyboard input wouldn't be compatible with the code used for true
> pointing devices. Just a few examples (each using pointer events today) to
> consider that don't work if all you can do is select an element:
>
> Bing/Google Maps (pan/zoom map)
> Flipboard.com (swipe page turns)
> Atari.com/arcade (interactive canvas games)
>
> While some pointing devices have coarser precision (e.g. touch), these
> devices all point on a coordinate-based input model whereas keyboard
> toggles on a focus ring style model. There are key differences to those
> models that make me skeptical that sites would share code between them.  I
> believe the result would then be that, at best, many sites would need to
>     if(e.pointerType=="keyboard") { //do something special}
> and, at worse, would continue to forget about keyboard--thus introducing
> odd/broken behavior when a keyboard is used because it triggers their
> pointer code paths that weren't designed with keyboard in mind. If they're
> doing the former, then it's probably no harder (perhaps, easier) to use the
> existing keyboard events.
>
> It's possible we might get some accessibility wins from firing pointer for
> keyboard, so it's certainly worth the exploration. But I like Rick's
> suggested approach of investigating this through polyfills as all the
> primitives in the platform to build this behavior should already be there.
>
>
>