
300ms tap delay removed on Chrome for Android - groodt
http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away
======
jblow
I agree that latency is terrible, but this is bad design that actually makes
the situation worse. Now instead of a constant, learnable latency, you have
latency that varies wildly depending on what page you are on.

This is the wrong solution, in that it makes things more complicated and
results in a generally poor experience even after the change. But that is what
Google does all the time in UI, so I guess I have no reason to be surprised by
this.

The proper solution: Do not make double-tap be a UI action. Done.

Or, if you insist on double-tap, make it only be an action that stacks
transparently with single-tap. For example, in touch controls for The Witness,
single-tap makes you walk toward the target. Double-tap makes you run. So as
soon as we read a single tap, we can start doing the action without delay, and
if we see the second tap we just kick up your target speed. It works great.

In short, hey Google, please stop doing band-aid solutions that make things
worse, and hire some people who really have solid design vision, and give them
the power to get things done.

~~~
stanleydrew
I assume they discussed removing double-tap as an action but decided it would
be too disruptive. I can't say I disagree with the choice they made.

I don't believe the problem you brought up is very important. Why do I care if
there is a "constant, learnable latency", as long as each latency is
reasonable? In the end I assume that the slowest response is the standard and
any actions that happen faster are a pleasant surprise.

But more importantly this change doesn't preclude them from removing double-
tap altogether in the future. I agree it is a half-solution now, but it's
better than nothing if you are willing to grant that differing latency across
pages is acceptable.

I do like the insight about stacking double-tap on top of single-tap, I'm just
not sure how to apply it in the current world where single-tap means
click/navigate and double-tap means zoom.

~~~
jblow
The impact of variable latency is well-known among people who actually study
human factors. It makes it hard for your brain to internalize interactions and
make them automatic, and it increases the feeling of frustration.

In video games specifically, where I work, it is well-known that you would
rather have a game that runs slower, but with a solid frame rate, than a game
that has a highly-variable frame rate that is faster on average. (This is more
of a continuum situation than a discrete action like a tap, but the basic
principle holds).

P.S./edit: Double-tap only means zoom because that is what they happened to
implement. It is a convention easily changed. Look at how heavily Apple just
revamped their entire interface, for an audience that is arguably much less
savvy than the Android audience.

Using double-tap in this way was a mistake; it is an easy mistake to fix if
you have enough design vision to know where you are going.

~~~
jaffathecake
Variable frame rates is a different issue. For example, reacting within 100ms
feels instant, whereas an animation running at 10fps (one frame every 100ms)
looks awful.

With interaction response, the faster the better.

~~~
jblow
Not true. I am talking specifically about interaction response, not the rate
of animation display. It is about your brain learning responses to its actions
so that it can better plan its actions. That cannot happen when the responses
are semi-randomized.

Seriously, there are tons of studies on this. I am not making it up.

~~~
skj
Then provide some citations, instead of vague appeals to authority?

~~~
eternalseven
He already did, human factors and the need for consistent performance, even if
that means that the lack of speed in performance is consistently bad is in
it's own way an advantage. The fact that we now have wildly inconsistent
performance depending on the pages we're viewing is bad in terms of human
factors. If you want precise scientific references try google but these are
basic known facts.

Overall I'm not sure how I feel about this topic myself but I do understand
jblow's point and somewhat agree with his rant.

~~~
skj
I'm not sure why you say "He already did" when I suggested providing
citations. I don't see any.

------
barrkel
"Pinch-zooming is great for taking a closer look at a photo, some small print,
or dealing with a set buttons/links that are placed too closely together. It's
an out-of-the-box accessibility feature."

No! Pinch-zooming is fantastic for navigating content. It lets you see an
overview of the whole page, then zoom in on the bit you're interested in. It
lets you control how much is seen on screen depending whether you want to read
it in depth or skim it. It is a _key feature_ of browsing the web on mobile
devices. Mobile websites that disable pinch-zoom by using enormous text on
extremely narrow fixed-width pages are a _pessimization_ , and are almost
always worse than the desktop page rendered on the mobile.

That's my opinion. I search in vain for a browser whose "view in desktop mode"
actually works.

~~~
Pxtl
I still use a WinPhone7 phone and many of these "mobile" sites are completely
broken on WP7 IE - they frequenetly have images or boxes that extend outside
the bounds of the fixed-width area and don't allow me to zoom out or pan right
to see the whole thing.

~~~
untog
That's because the Windows Phone 7 browser is unfathomably awful. I say this
as a one-time WP7 user and a web developer.

I felt guilty for using it because there was an outside chance it might make
someone have to develop for it.

~~~
Already__Taken
They changed the browser in the Mango update that's all I know. Came out with
the WP8 update.

~~~
untog
The WP8 browser is a lot better. WP7 was (IIRC) IE9-level.

------
primigenus
We recently had to change our plans for a HTML5 game for smartphones because
it performed like crap on Android. Now we're rebuilding it in Unity (with the
recent 2d features they added) and it performs great. That's too bad, because
we really believe in the idea of HTML5 as a cross-platform development
environment.

So I'm really happy with the obsessive pursuit of speed, responsiveness and
user experience by the Chrome team. It's probably a good idea to seek feedback
on this for accessibility reasons, but it feels like this change would be for
the better when applying the 80/20 rule.

This along with the numerous improvements to Chrome's developer tools and
remote debugging features ([https://developers.google.com/chrome-developer-
tools/docs/re...](https://developers.google.com/chrome-developer-
tools/docs/remote-debugging)) coming soon really show an increased focus on
making high performance web apps on mobile a realistic option.

Hopefully the next game we make will be able to launch on iOS and Android
thanks to these speed improvements. :)

~~~
timsayshey
Too bad android chrome is not the same as the AOSP browser that is built in to
android which is what the webview uses...

~~~
martinml
That's starting to change!

 _Android 4.4 (KitKat) includes a new WebView component based on the Chromium
open source project_

 _Will the new WebView auto-update? (...) There are large engineering and
logistical challenges. We 're not quite there yet, but we're working on it._

[https://developers.google.com/chrome/mobile/docs/webview/ove...](https://developers.google.com/chrome/mobile/docs/webview/overview)

~~~
timsayshey
Wow that's awesome news! I had no idea :)

------
JoelSutherland
For what it's worth, this delay was already removed for sites that had user-
scalable=no set. Most mobile "apps" used this.

The change here is that if the computed viewport is smaller or equal to the
device width, fast clicks will be enabled without having to disable scaling.
Double clicking won't work, but pinch-to-zoom will.

Overall it's a fairly minor change for those thinking about making HTML5 apps,
but it is a big positive change for users visiting existing web sites that
have mobile/responsive versions that haven't disallowed scaling.

~~~
sluukkonen
> For what it's worth, this delay was already removed for sites that had user-
> scalable=no set. Most mobile "apps" used this.

Is this true for mobile Safari as well?

~~~
jaffathecake
No, see the "Will other browsers do the same?" section of the article.

~~~
sluukkonen
Ah, that's too bad. It would be nice if setting user-scalable=no was all you
had to do to disable the delay. And anyway, despite using an iPhone for god
knows how many years, I didn't even know that a double tap on iOS scrolls the
page!

Edit: I mean double tapping on an unzoomable page.

~~~
jaffathecake
Even then, I think being able to pinch-zoom is a great feature and gives you
some accessibility out-of-the-box.

~~~
sanderjd
Note that the chrome change from the OP is specifically so that you don't have
to sacrifice pinch-zoom to get rid of the 300ms delay.

------
jackgavigan
Why not add a "Zoom on double-tap" tickbox in Chrome's Settings? Leave it
ticked as default so users aren't adversely affected.

Even better, add another Setting to let users change the amount of time the
browser waits for the second tap. Windows has had this since at least Windows
XP (Start → Settings → Control Panel → Mouse → Double-Click) and I _think_
since Windows 95. Set it to 300ms as default so existing users aren't
adversely affected. People like me can set it to 180ms (which is what the iOS
stopwatch indicates my maximum double-click delay is).

If you want to put the icing on the cake, add a little applet in Settings to
measure your double-tap speed.

~~~
jaffathecake
Are users adversely affected by this change? In what way?

This change is designed to make the existing web faster. If we improve the
performance of rendering, JavaScript, or scrolling, we don't put it behind an
opt-in option. Why should this be?

~~~
jackgavigan
Well, I'm not suggesting they do my idea _instead of_ what they've done. I'm
suggesting they do it _in addition to_ what they've done.

I _hate_ the delay between tapping the screen and the "click" being
recognised. It drives me up the wall. I'd far rather switch off "Double-tap to
zoom" for _all_ pages (not just those with the relevant meta-tag) and use
pinch-to-zoom instead.

There are obviously very good reasons to _not_ disable "Double-tap to zoom"
entirely or by default (primarily accessibility, but also the fact that people
have gotten used to it) but where's the downside in making it a Setting so
that people like me can choose to disable it? Okay, maybe the upside is quite
small but there's zero downside and (given that they've already implemented
the ability to switch "Double-tap to zoom" off if the webpage has the relevant
meta-tag) it would be relatively easy to implement.

Making stuff like this user-configurable is a Good Thing. It's like when Apple
changed the behaviour of the iPad's side switch in iOS 4.2 to switch it from
rotation lock to audio mute and Steve Jobs said there wouldn't be a
configuration option to let users change the switch back to rotation-lock [1].
A lot of people (including me) were disappointed. Fortunately, he changed his
mind and iOS 4.3 made the function of the side-switch user-configurable in the
Settings.

[1]: [http://9to5mac.com/2010/10/23/jobs-there-wont-be-a-mute-
swit...](http://9to5mac.com/2010/10/23/jobs-there-wont-be-a-mute-switch-
becomes-an-orientation-lock-option-for-ipad/)

~~~
jaffathecake
You can actually disable tab delay all together in Chrome Beta. Go to
about:flags and enable "Disable tap delay".

~~~
jackgavigan
I'm on iOS so that's just cruel.

------
daleharvey
Note that this is only different in the

    
    
       <meta name="viewport" content="width=device-width, user-scalable=no"> 
       vs 
       <meta name="viewport" content="width=device-width">
    

case, almost all browsers already remove the delay for user-scalable=no pages,
but its a good improvement to be fast and still allow zooming, the article
explains that, but I got confused skimming the title + first paragraph.

~~~
jaffathecake
Not "almost all browsers", only Chrome and Firefox optimise it at the moment.
IE and most importantly iOS Safari do not.

------
poxrud
For a solution for older browsers you can use fastclick.js
([https://github.com/ftlabs/fastclick](https://github.com/ftlabs/fastclick)).
For angularjs webapps there's also ngTouch.

~~~
eliot_sykes
ngTouch is why I ought to get round to upgrading to Angular 1.2.x (currently
on 1.0.x).

One of the things ngTouch gives is "A more powerful replacement for the
default ngClick designed to be used on touchscreen"[1]. Oh, I see its not
bundled in the core angular.js file.

[1]
[http://docs.angularjs.org/api/ngTouch](http://docs.angularjs.org/api/ngTouch)

------
a-priori
This is cool and all, but it's a hack and it confuses the meanings of the
viewport meta tags. Why should a "width=device-width" setting magically alter
how touch events are processed? It makes no sense.

Wouldn't it make more sense to introduce a new setting something like
"immediate-events=yes" that lets developers opt-in to this behaviour?

~~~
kinlan
There is no spec that says how the events should be handled when the viewport
is specified. IMO it shouldn't really be down to the developer to have
immedidate-events etc because it is likely to be a user request (which they
can currently override).

------
skizm
I'm a big fan of the double tap to zoom. The browser figures out the zoom
level you want with surprising accuracy and if it is wrong, or you want
something specific you can always fall back to pinch zoom.

I'm sure I'll adjust but I do wish this was an opt in/out thing.

~~~
jaffathecake
This only affects mobile-optimsied sites where double-tap zoom is pretty
useless. Is there a page you;d find broken with this new behaviour? We're open
to use cases.

~~~
skizm
> This only affects mobile-optimsied sites where double-tap zoom is pretty
> useless.

Sweet. I was thinking mostly about non-mobile sites so then this works. The
only thing I can think of (and this isn't very often) is maybe images. For
example on the mobile Wikipedia site there is often an image at the top of an
article that I will double tap to zoom into and then another double tap to
revert to normal zoom level. Definitely not the typical use case but something
to consider. Maybe only have the 300ms when the first tap is on an image that
is not a link. Just spit-balling here.

Either way if it is only for mobile optimized sites, I don't see this being a
problem.

------
kinlan
The team are looking for a lot of feedback based on usage on this. Please
either comment on the post or file feedback at crbug.com.

------
cbr
This is excellent. Previously developers had to choose between their mobile
site feeling snappy and supporting pinch-zooming. Now we can have both, and I
can go back to being annoyed with developers who disable pinch-to-zoom.

------
toadkick
How about we instead stop turning off page zooming on mobile sites. The least
of my concerns here is the stupid 300ms lag, when it seems like 80% of mobile
sites these days don't even allow pinch-zooming anyway. Remember when one of
the great things about smartphones was that you could use the "real" internet?
Yeah. My poor eyeballs (and fat fingers) miss those days.

~~~
jaffathecake
I don't know if you read the article, but the whole point is to drop the 300ms
delay while _retaining_ zooming.

~~~
toadkick
I did read the article. Sorry, I conflated pinch-zoom with double-tap zooming.
_facepalm_

------
Pxtl
Double-tap to auto-zoom seems like a misfeature anyways. Wasting a useful
gesture like that on a somewhat-redundant action seems odd. A 2-finger tap
gesture would've made more sense since it would be related to the pinch-
operation.

~~~
jaffathecake
Can't disagree with this. 2-finger tap to zoom to content. If only we could go
back in time…

~~~
snogglethorpe
A two-finger tap is extremely awkward to do with just your thumb... (often the
only finger actually available)

------
sauravt
With this feature implemented in stable branch of chrome and Chrome apps for
android going stable in january 14, a lot of android.ios development will
shift to making chrome apps that run on mobile.

------
eliot_sykes
I don't recall why I've set it up like this, but I'm using the following in an
app: <meta name="viewport" content="width=device-width, initial-scale=1.0,
maximum-scale=1.0">.

Should the 300ms tap delay be gone in this case too, or is it only apps with
precisely <meta name="viewport" content="width=device-width"> OR <meta
name="viewport" content="width=device-width, user-scalable=no">?

~~~
jaffathecake
That removes the 300ms delay in Chrome and Firefox. Although you lose pinch
zooming too, which can be a nice usability & accessibility feature.

~~~
eliot_sykes
So to be clear, as long as the content attribute contains "width=device-
width", regardless of what comes after it, the 300ms is removed in those
browsers?

~~~
mbrubeck
Firefox currently disables the 300ms delay only if zooming is disabled (either
with user-scalable=no or by setting identical min-zoom and max-zoom).

We are discussing whether to follow Chromium's lead and also disable double-
tap on pages with width=device-width:

[https://bugzilla.mozilla.org/show_bug.cgi?id=941995](https://bugzilla.mozilla.org/show_bug.cgi?id=941995)

(I am a mobile Firefox developer.)

~~~
kinlan
What would be the convincing factor and how can we share any data/lessons with
you?

~~~
mbrubeck
I think we're already pretty convinced - at least, I am. :) We're just
checking to make sure we have consensus; so far I haven't seen any objections.

------
shawabawa3
I'm not sure why you need to wait for potential double taps on clickable
elements anyway, couldn't you just have clickable elements not be double
tappable?

~~~
hmottestad
Double tap to zoom is native support.

~~~
emn13
I'm not sure how this matters - can you explain?

~~~
hmottestad
If you double tap a link on a desktop you will go to that link 'twice'. If you
double tap a link on ios you will zoom to that link. Unless you wait for as
long as a double tap takes you won't know if the user meant to zoom or to
click the link. This is why there is discussion going on about the default
view port and user zoomable content.

~~~
emn13
I get that, but was thrown by your reference to "native" behavior - if you
want to be able to double tap a clickable element, you'll need to wait long
enough to discriminate the two behaviors.

On the other hand - the desktop solution would be fine too; just don't solve
the problem (i.e. you can't double-tap clickable content).

I think I'd rather have fast responsive taps rather than double-tapping even
on links; regardless of the zoomability settings.

------
nodata
Nice, but the video is unfair: in the slower video he moves his hand off
camera and back every time, in the faster video he keeps it hovering above the
phone.

p.s. I think this is the Firefox bug
[https://bugzilla.mozilla.org/show_bug.cgi?id=922896](https://bugzilla.mozilla.org/show_bug.cgi?id=922896)

~~~
spydum
I think that is to enforce the point, his hand could move away before the
interaction registered visually.

~~~
bbrks
That, and also if you tap too quickly, it will just trigger the tap to zoom
feature. So you have to wait that long anyway regardless of where your hand is
placed.

------
masklinn
> Microsoft's PointerEvents spec does the right thing and only fires pointerup
> if the touch doesn't trigger a lower-level action such as scrolling.

I don't get how that helps for the use-case which triggered the original
introduction of the tap delay: a double-tap is not a "lower-level" action than
tap.

~~~
jaffathecake
From the spec: "The user agent must dispatch a pointercancel (and subsequently
a pointerout event) whenever all of the following are true, in order to end
the stream of events for the pointer:

The user agent has determined (via methods out of scope for this
specification) that touch input is to be consumed for a touch behavior,"

Touch behaviours are things like scrolling, double-tap to zoom, pinch zoom.

The browser's double-tap to zoom gesture is at a lower level than the click
event in the browser. As in, a double-tab will be consumed by the browser and
never hit the page.

~~~
masklinn
That precludes removing the delay, since that very delay is necessary to know
whether it's a double tap.

~~~
jaffathecake
Double-tap precludes the click event. But touch/pointer events can preclude
the double-tap.

~~~
masklinn
> But touch/pointer events can preclude the double-tap.

Your previous comment seems to imply otherwise: if the UA must dispatch
pointercancel rather than pointerup on a double-tap, it has to wait until it
can determine whether a double tap happened.

~~~
jaffathecake
Omitting mouse & touch events, a tap goes: pointerdown, pointerup, click.

A double tap goes: pointerdown, pointercancel.

If the pointerdown event does event.preventDefault, it goes pointerdown,
pointerdown.

The double-tap prevents the click. Preventing default in the pointerdown
prevents the double-tap and also the click.

~~~
Anderkent
But that still means that the browser has to determine if it's a single tap or
double tap before sending the pointerup, so it'll arrive after the 300ms
delay.

~~~
jaffathecake
No, it doesn't. The double tap gesture comes after pointer events. Pointer
events can prevent double tap. Whereas click comes after the opportunity for
double-tap, and double-tap will prevent click.

Try it in IE, or another browser using touch events.

~~~
masklinn
> The double tap gesture comes after pointer events.

You make no sense, by your own description the double tap gesture changes what
pointer events fire, pointerup can not fire until the UA knows for certain
it's _not_ going to be a doubletap, same as click.

~~~
jaffathecake
If you don't trust me on this, that's fine. Test it for yourself.

Double tap does not change pointer events
([https://dvcs.w3.org/hg/pointerevents/raw-
file/tip/pointerEve...](https://dvcs.w3.org/hg/pointerevents/raw-
file/tip/pointerEvents.html)), they come first. But 'click' is not a pointer
event, it's the result of some pointer events, and the lack of the browser
doing something else, such as scrolling, double tap etc.

But seriously, don't take my word for it. Test it.

~~~
masklinn
> If you don't trust me on this, that's fine.

For the third time (might just be the charm), _you contradict yourself_ , it's
not that I don't trust you it's that you're internally inconsistent.

~~~
jaffathecake
If I'm not explaining it properly, see the test and work it out yourself.
Touch & pointer events happen before double tap (and can prevent it) click
happens after all those and can be prevented.

------
marcosscriven
I think a single 'long' press for zoom would have been a better way. By long
I'd say 300ms or so. Then a short tap could act the moment you lifted your
finger, assuming it was below the long tap threshold. iOS uses a long tap to
select text though.

------
lm741
Latency sucks. You can apply this type of touch-click speedup on a site for
other browsers with a bit of JS.

[https://gist.github.com/cagerton/7948779](https://gist.github.com/cagerton/7948779)
(disclaimer: proof of concept, etc. )

------
thegladiator
developers developing a site that is 'mobile friendly' is already overriding
touch events to work around this latency issues. So OP's complaint about
inconsistency is not valid. I'm sure many developers welcome this change.

------
Raphael
If one attempts a pinch now, won't the first finger to hit be interpreted as a
drag instead? Or I suppose there is a drag delay but not a click delay.

------
ajasmin
When taping a link, couldn't the browser start to load the page in the
background even though the gesture may turn out to be a double-tap.

