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 14:57:55 +0000
Message-ID: <52CAC473.4080503@splintered.co.uk>
To: Rick Byers <rbyers@google.com>
CC: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
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 

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 14:58:20 UTC

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