- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Tue, 19 Nov 2013 09:05:46 +0000
- To: public-touchevents@w3.org
On 18/11/2013 17:01, Patrick H. Lauke wrote: > - as the user moves keyboard focus around, fire the relevant > PointerOver/PointerEnter not just on the focusable element that they > landed on, but also any other parent elements they may have "crossed". > E.g. if focus was initially on a direct child of <body>, and the next > TAB gets them in a <div><p><a ...></a></p></div> then fire the events on > the <div>, the <p> and the <a>. If the next TAB then moves to a sibling > paragraph inside the same <div>, only fire PointerLeave/PointerOut of > the <a> and the original <p>, then PointerOver/PointerEnter just on the > sibling <p> and the next <a> that they focused on. sorry, > convoluted...but does that make any sense? Actually, ignore this bit altogether...I was somehow thinking about the existing issues with mouse-driven events and how they could be fixed for keyboard users, but these legacy issues would not be present in sites actually using Pointer Events. In effect, keyboard focus moving directly to a focusable element should be no different from a stylus hovering over an element, so simply firing the relevant Pointer Events (without that whole "fire them on intermediate elements as well" part above) should be fine. 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 Tuesday, 19 November 2013 09:06:13 UTC