W3C home > Mailing lists > Public > public-pointer-events@w3.org > January to March 2014

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

From: Patrick H. Lauke <redux@splintered.co.uk>
Date: Mon, 06 Jan 2014 15:22:22 +0000
Message-ID: <52CACA2E.2000604@splintered.co.uk>
To: Rick Byers <rbyers@google.com>
CC: "public-pointer-events@w3.org" <public-pointer-events@w3.org>, Alex Russell <slightlyoff@google.com>, Dimitri Glazkov <dglazkov@google.com>
On 06/01/2014 15:09, Rick Byers wrote:
> 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).

Speaking of philosophy, though...what if you consider 
keyboard/keyboard-like interfaces to simply be another type of mechanism 
for the user to move a "pointer" around the screen? Rather than being a 
little arrow (as would be the case with a physical mouse), it's a focus 
rectangle, but conceptually it still serves the purpose of letting the 
user "point" to something to indicate what will receive an action (mouse 
button click for instance, or hitting space/enter on the keyboard)?

Looking at it in this light, I'd say bringing keyboard under the fold of 
pointer events would even resonate well with the pointer events' (non 
normative, admittedly) intro:

" Newer computing devices today, however, incorporate other forms of 
input, like touchscreens or pen input. Event types have been proposed 
for handling each of these forms of input individually. However, that 
approach requires a step function in opportunity cost to authors when 
adding support for a new input type. [ED: as we've seen with devs not 
adding focus/blur and instead just doing mouseover/mouseout] This often 
creates a compatibility problem when content is written with only one 
device type in mind."

Not trying to be contrary here. I do understand the points against this, 
and agree that doing a polyfill for test purposes may be a good idea. 
Just interested though if we're not artificially classing kbd/kbd-like 
as "not a  pointer" when in a way it can be seen as one?

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
______________________________________________________________
Received on Monday, 6 January 2014 15:22:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:25 UTC