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

Yeah, this is a tough design point in my opinion.  To what extent do we
make the lowest layers of the platform have additional magic in order to
try to trick more naively-written websites into 'mostly working' in
accessibility or other unusual input scenarios?  +Alex and Dimitri as this
is related to web platform layering discussions they're passionate about.

I think the answer is more philosophical than technical.  Other platforms
have a pretty clear philosophy about this sort of thing (eg. you'd never
extend the Windows kernel with this sort of magic, but the high-level
frameworks people actually target might have it).

Again I'd be really hesitant to go down this path without a bunch of data
from real-world experiments.  I think a polyfill library that could be used
both directly in websites that want it (as a quick fix for their
accessibility issues) and as a content script extension (for browser
users/vendors who want to enable it on naive sites) could be pretty
effective and teach us a lot...

Rick



On Mon, Jan 6, 2014 at 9:57 AM, Patrick H. Lauke <redux@splintered.co.uk>wrote:

> On 06/01/2014 14:48, Rick Byers wrote:
>
>> 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?
>>
>
> My main motivation here probably comes from the fact that even today most
> designers/developers still seem to cater for mouseover/mouseout type events
> rather than focus/blur, which often has accessibility implications. (or, if
> we look at touch events, how devs do naive "if it supports touch events,
> listen to those instead of 'click'", which of course has accessibility and
> usability implications as soon as their pages run on a device with both
> touchscreen AND traditional keyboard/mouse, or Android/Talkback).
>
> 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.
>
> Also, partially related is my interest in "web on TV" and the
> Opera/spatial navigation angle (where, according to Sangwhan, pointer
> events will be fired).
>
>
>  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.
>>
>
> The reason for having it in the browser was to automagically add better
> keyboard support (in future, once sites in the wild use pointer events
> extensively) out-of-the-box even when devs haven't even thought about
> keyboard.
>
>
> 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
> ______________________________________________________________
>