E-mail List Archives
Thread: Touch Event Delay
Number of posts in this thread: 3 (In chronological order)
From: Tim Harshbarger
Date: Tue, Oct 27 2015 10:45AM
Subject: Touch Event Delay
No previous message | Next message →
Patrick,
Again, thanks for the link to the test results and tests you put together. As I read through the material, I noticed you mentioned a 300 millisecond delay. I am not quite sure I understand.
For example, with focus and blur events, is the situation that there is a 300ms delay before a focus or blur event is triggered? I am particularly interested in the delay as it relates to Voiceover on IOS.
Thanks,
Tim
From: Patrick H. Lauke
Date: Tue, Oct 27 2015 1:00PM
Subject: Re: Touch Event Delay
← Previous message | Next message →
On 27/10/2015 16:45, Tim Harshbarger wrote:
> Patrick,
>
> Again, thanks for the link to the test results and tests you put together. As I read through the material, I noticed you mentioned a 300 millisecond delay. I am not quite sure I understand.
Browsers on touchscreen devices typically have a 300ms delay between the
moment your finger/stylus leaves the screen, and the mouse compatibility
and click events are fired.
Touch events are fired immediately (finger touches the screen -
touchstart; finger moves around - touchmove; finger leaves the screen -
touchend). Then 300ms delay. Only then are mouseover, mousedown etc and
click fired.
This delay is there because browsers need to wait if this was a single
tap, or if this was simply the first instance of a double-tap gesture.
If after 300ms there was no further tap, it's assumed that it was meant
as an activation, and the mouse and click events are fired.
(there's a slew of information I could go into about this, but see if
any of my presentation
http://patrickhlauke.github.io/getting-touchy-presentation/ makes sense)
> For example, with focus and blur events, is the situation that there is a 300ms delay before a focus or blur event is triggered? I am particularly interested in the delay as it relates to Voiceover on IOS.
When navigating with VO, you're unaffected by the delay, as VO itself is
responsible for managing your inputs and firing events. In fact, when
navigating with VO, no touch events are actually passed to the
underlying webpage/javascript at all (unless you use a passthrough
gesture in VO). In short, don't worry about it in this case :)
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Bryan Garaventa
Date: Tue, Oct 27 2015 1:24PM
Subject: Re: Touch Event Delay
← Previous message | No next message
> For example, with focus and blur events, is the situation that there is a 300ms delay before a focus or blur event is triggered? I am particularly interested
> in the delay as it relates to Voiceover on IOS.
> When navigating with VO, you're unaffected by the delay, as VO itself is responsible for managing your inputs and firing events. In fact, when navigating
> with VO, no touch events are actually passed to the underlying webpage/javascript at all (unless you use a passthrough gesture in VO). In short, don't
> worry about it in this case :)
To clarify one point, though the touch events are intercepted, the onFocus and onBlur handlers are triggered immediately as you move your finger around the screen with VO running.
This is why, if you have a Combobox control that uses onBlur to dismiss the Listbox, it will disappear before you have a chance to read what the Listbox contains unless this is programmed not to do so.