
WebKit removes the 350ms click delay for iOS - asyncwords
https://trac.webkit.org/changeset/191072
======
ksenzee
The change applies only to unscalable viewports. That's a shame, because it
means some developers will disable pinch-to-zoom to get a faster click
response. That makes this yet another unfortunate conflict between usability
and accessibility. The older I get, the more I appreciate being able to zoom
(I'm viewing this page at 125% on desktop right now).

~~~
themartorana
There are plenty of apps that are guilty of this as well. Instagram comes
immediately to mind. Not allowing pinch zoom on pictures I'm viewing on a tiny
pocket screen (when there's no good technological reason for it) is a shame.

I've turned on assistive zooming on my iPhone to overcome the limitation.

~~~
achairapart
> There are plenty of apps that are guilty of this as well. Instagram comes
> immediately to mind.

For native apps it's a design choice. For whatever reason (good or bad) they
don't want you to zoom in.

For websites instead, pinch to zoom exists for a design deficency, mostly for
web pages not optimized for small sized screen. Responsive web design is
helping but the gap is not filled yet. Hopefully it's just a matter of time
and we'll experience beautiful mobile websites.

For all other needs, there is OS assistive zoom.

~~~
somebehemoth
While I agree with what you are saying I have a minor nit: "For websites
instead, pinch to zoom exists for a design deficency, mostly for web pages not
optimized for small sized screen."

I understand what you mean, but in the context of sites specifically disabling
zoom it seems to me that pinch to zoom is a design feature and not a
deficiency of traditional web pages. Responsive helps, but there are
definitely times when I wish the developers would provide only a desktop view
so I can use my browser features to optimize my own user experience. (I am not
representative of the general public, I know).

~~~
systoll
Non-zooming sites can (and should) honour your system-wide font-size setting,
giving you the ability to use the system's settings to achieve uniformly
comfortable reading experiences across websites and apps.

Zooming doesn't do much to give users much control over the reading experience
-- iOS does not let users set or change the viewport size, so everyone gets
the same columns to zoom into/out of.

If you want text bigger than the single size the designer decided on, you're
forced to scroll along each line of text -- which is a terrible experience.

If you wanted it smaller, zooming out won't 'reflow' the layout, so you'll
just be losing screen real estate to peripheral content.

~~~
somebehemoth
I meant to refer to the ability to zoom in on images for the purpose of
observing greater detail (which I did not include my comment). I do not
disagree with your comment.

------
untog
While I do symapthise with those lamenting the lack of pinch-to-zoom, I'm
confused: apps don't offer pinch to zoom, so how do you use them? If you can
use an app fine without pinch to zoom, you should really be able to use a
mobile website fine too.

It seems to me that this is an either/or proposition: either you have a not-
mobile, pinch-to-zoom-able web site, or you have a mobile-specific site with
an app-like viewport that does not allow pinch to zoom. Both of these seem
like fine options to me, and I don't think it's a huge loss to lose the middle
ground.

~~~
nathancahill
You're talking about two fundamentally different things. Apps are designed
specifically for mobile, so of course they will work well fine at the scale
they were designed at.

Ideally, websites would be designed to work fine at any scale from mobile to
desktop (responsive design). However, many mobile websites are delivered today
as downscaled/simplified versions of the desktop site. This means there's a
lot of design that crosses over from desktop to mobile. When you add disabled
scaling on top of that, many things break, like content being too wide or font
sizes being too small.

~~~
eru
It's a shame. HTML was originally meant to be quite device unaware, and
display fine on toasters.

~~~
nathancahill
HTML is fine, it's the CSS/JavaScript that's the problem. If we were just
displaying HTML we wouldn't be having this discussion.

~~~
dredmorbius
It's more a matter of how the tools are used, and provisions for client side
overrides. Reader mode is a godsend, though the delay on showing the icon and
lack of a default option are both capital flaws.

------
jordanlev
Ugh... This change is of course totally logical in isolation, but I fear that
this will motivate designers and developers to disable pinch-zooming on their
sites (more than they already are). I _hate_ when websites do this, and it is
generally considered terrible for accessibility.

~~~
glhaynes
Hopefully the intersection of "knows/cares about things like the 350ms tap
delay" and "cares about whether the site is too small to read" will be large.

~~~
eru
Unless it becomes a bullet point on someone's feature list.

~~~
thecatspaw
there's allways fastclick

------
zkhalique
In our framework, we have for a very long time had a Q.Pointer class which
contained functionality to normalize things between touchscreens and non-
touchscreens. Among other things, it had the "fastclick" event:
[https://github.com/Qbix/Platform/blob/master/platform/plugin...](https://github.com/Qbix/Platform/blob/master/platform/plugins/Q/web/js/Q.js#L8825)

There is far more than simply relying on a "click" in touchscreens. For
example the "touchclick" event is for those times when the keyboard disappears
because focus has been lost in a textbox, but the click will still succeed:
[https://github.com/Qbix/Platform/blob/master/platform/plugin...](https://github.com/Qbix/Platform/blob/master/platform/plugins/Q/web/js/Q.js#L8825)

Also, drag-drop is broken in touchscreens WebKit so you have to roll your own,
and much more.

You're better off using a library.

~~~
tracker1
Cool.. as a side note... 10k lines in that file, is it maintained like that? I
know modularizing and things like browserify have an overhead, it just seems
excessively large for a single source file (was scrolling up to the top, so
that I could star the project to look at later).

I'm not trying to attack or being negative here... just a bit surprised.

------
paulvs
As I see it, the 350ms delay was added to support zooming via double-tap. What
I don't understand is why double-tap zooming is necessary when we have pinch-
to-zoom? Can't zoom via double-tap be sacrificed for instant clicks and
everyone is happy?

~~~
achairapart
I also never understood why you'd double tap on a link or a button.

~~~
christianmann
You might double tap near a button, to expand it and give yourself a larger
target.

------
jamesrom
A lot of commenters here are afraid of developers disabling user scaling to
get better performance. That is incorrectly making the assumption that user
scaling is good thing for every kind of website.

If a 350ms click delay is actually a performance bottleneck on the app you are
building, it's very likely user scaling is something you want disabled anyway.

~~~
nevir
If you're building your website to behave well on mobile devices, you're
likely implementing your own touch handlers and are not using click events to
begin with.

~~~
robocat
This is actually very hard to implement.

The underlying issues are that

(a) it is hard to make touchstart/touchend act the same as a native click
event (touch-scroll interactions, different fat finger slippage, text
selection, press duration, etc).

(b) you only want to do this for iOS and not any other browser (different
browsers and OSes and pointing devices introduce a huge number of other
issues: cant prevent the click on the touchend, mouse or pen support is
difficult, avoiding ghost taps
[https://www.google.com/#q=ghost+click+tap](https://www.google.com/#q=ghost+click+tap)
).

(c) you run into future compatibility problems (pen, force-clicks, other
HIDs).

~~~
nevir
True. But that's where
[http://www.w3.org/TR/pointerevents/](http://www.w3.org/TR/pointerevents/)
comes in

------
RoboTeddy
How long until this makes it into the Mobile Safari on most people's iOS
devices?

~~~
dfabulich
Generally, stuff that lands on webkit master is available in the next major
iOS release, e.g. iOS 10.

~~~
ash_gti
There is a chance it could be in 9.1 or 9.2 but your right, this kind of
change has a much better chance of appearing in the next major release.

------
nailer
Finally.

Typing this on an iOS 9 device and I, as a human, cannot 'fast tap' enough for
iOS to register a 'fast tap' and not delay. Try it here:
[http://output.jsbin.com/xiculayadu](http://output.jsbin.com/xiculayadu)

~~~
sesutton
It's a "slow tap" that eliminates the delay. Tap and hold your finger down for
a moment. The delay registered with a "slow tap" is about 10 ms for me.

~~~
nailer
God that's completely unintuitive.

------
escherize
I really don't understand the lamentation around pinch to zoom. There's a
fantastic os-level zoom built into ios! Set it up and three-finger-click to
activate. And it works great.

~~~
function_seven
I am a huge fan of the 3-finger zoom, but it's not exaclty the same as
browser-provided zooming. The screen zooming provided by the 3-finger tap will
not add resolution to downscaled images.

If I'm looking at a site that presents a massive image scaled to my display,
the browser zoom will add more information as you zoom in. The 3-finger zoom
will make the existing pixels larger.

Most of the time this difference isn't an issue, but it is a difference.

------
dkonofalski
What's the intended function of the previous functionality? Didn't double-
tapping zoom in and out to a specific section? What problem does the delay
solve that isn't present on unscalable viewports?

~~~
nevir
The delay allows webkit to _detect_ a double tap. Otherwise, any element with
a click handler would immediately fire, effectively disabling double tapping
for their region.

~~~
eru
An interesting choice would be to retroactively undo the effects of the single
click if a second one was detected.

~~~
russjr08
That sounds interesting at first, but then what happens if say, the element
takes you to another page? Then you'd have to go back a page, which would be a
clunky experience.

~~~
eru
Delay page switches (and other interruptive things) then.

~~~
untog
What if it sends an AJAX request? You can't exactly undo them. The browser JS
environment is sufficiently complex that "just undo"ing something seems like
it would be... complex.

~~~
eru
Send GET requests, delay POST.

Yes, the whole architecture would need to good undo-support.

~~~
untog
A lot of sites out there perform actions on GET requests, though. I just don't
see it working out.

In any case, once you start delaying things you ruin the original point of
getting rid of the click delay - to make things faster!

~~~
eru
You only delay non-idempotent actions.

------
mozumder
Any idea when this makes it into an iOS release? Does Apple usually implement
this in point releases? Or do we wait until iOS10 next year?

------
kristianp
Can someone explain what this means for the non-IOS developers amongst us?

~~~
geofft
As I understand it... If you're using Mobile Safari (or many other mobile
browsers), and you double-tap something, it's interpreted as meaning "zoom in
to this element". This is useful for pages with narrow columns and things on
the sides, etc.

However, in order to implement this, when you do a _single_ tap, the browser
has to wait to make sure that you don't do a double-tap. So there's a 350ms
delay while it's waiting on your second tap, before delivering a single-tap
event, e.g. to click on a link.

There's a meta tag you can use to disable user control of the zoom level, e.g.
with pinch-to-zoom. One of the things that this disables is the double-tap
behavior. Given that double-tap is disabled on those websites, there's no need
to sit around waiting for a second tap; you can treat it as a single tap
immediately. This change removes the delay.

(People are upset because this is an incentive to use that meta tag if you
otherwise wouldn't need it, and being able to zoom on a mobile browser is
useful.)

~~~
toggle
Also worth mentioning: Chrome for Android did this last year. GP was asking
about iOS, but it's not an iOS-specific thing.

~~~
stephengillie
To continue the Chrome for Android tangent, you can re-enable zoom-in as an
accessibility feature.

------
outside1234
Remind me: They originally had the 350ms delay in there to distinguish between
a tap and a pinch, correct?

~~~
matthewmacleod
A tap and a double-tap, AFAIK. Since the latter is used for zooming, if the
page is not scalable then the possibility that the user has double-tapped can
be disregarded.

------
joeyspn
Good news for hybrid apps devs...

~~~
lsorese
Incredible news for hybrid app devs. This has been a longstanding annoyance on
iDevices that has only been superficially fixed with polyfills on iOS and
dumping your app into Crosswalk on Android.

------
fogisland
Will removing this 350ms delay really make user feel faster response?

~~~
duncans
It's what FT Labs fastclick tries to mitigate - try it for yourself:
[http://ftlabs.github.io/fastclick/examples/layer.html](http://ftlabs.github.io/fastclick/examples/layer.html)

