- From: Rick Byers <rbyers@google.com>
- Date: Mon, 6 Jan 2014 10:09:26 -0500
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>, Alex Russell <slightlyoff@google.com>, Dimitri Glazkov <dglazkov@google.com>
- Message-ID: <CAFUtAY85CeOas4g-+KBq69TO47aQ67bDUne79GVTnxDHTJHUsw@mail.gmail.com>
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 > ______________________________________________________________ >
Received on Monday, 6 January 2014 15:10:14 UTC