WebKit removes the 350ms click delay for iOS
trac.webkit.orgThe 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).
Even worse, some sites disable scaling, but let their content overflow the width of the screen without any possible way to see it. If you're going to use user-scalable=no, at least make sure that your code blocks and images resize to fit on mobile screens (or viewable separately).
A solution for this is a JS bookmarklet that enables zooming:
I keep this on my bookmarks bar and use it most often to zoom in on text to read it better.javascript:document.querySelector('meta%5Bname=viewport%5D').setAttribute('content','width=device-width,initial-scale=1.0,maximum-scale=10.0,user-scalable=1');Oh God, thank you. You've restored the mobile web for me. I can't stand the stupid "responsive" design crap. There shouldn't be any way to disable user zooming on mobile. Web developers simply can't be trusted.
Responsive is good, however dictatorial coding isn't. No reason responsive ought not be user friendly as well. The problem is that many devs seem to thing that they know best for their users. However a larger number don't actually understand that their vision of how a web page should operate isn't necessarily how a web page should operate. Too many cooks trying to be chefs. I admit that I don't have an expert grasp on the nuances of great front end either-- that's why I do my best to stay out of the front end as much as possible!
>Responsive is good
I'll disagree. Responsive is a cop-out -- reminds me of the "mobile" versions of websites. Give me the full version, and stop messing with the layout and experience between the web and the phone.
But the full versions of the sites are often horrible for mobile. It is as simple as optimisation for vertical vs horizontal layout.
Also, responsive design does not mean disabling zoom at all.
>But the full versions of the sites are often horrible for mobile.
I've never found that to be the case. Or if I did, it was far less often than being annoyed with the lacking, scaled down, "horizontally enhanced" mobile layout.
As an example of a site that is not good at all on mobile I would cite this very one.
In portrait mode the text is way too small to read and zooming in results in text that goes over the edge. In horizontal mode the experience is a bit better but one still needs good eyes to read the comments. Luckily there are enough applications that mitigate the problem.
Bookmarklet to increase font size anyone?
Small font size makes it faster to scroll past long threads.
While it works, it is also a hack that very few people know how to use in general my guess would be less than 1%. This site being a huge exception, due to its nature. To scroll past a thread you can collapse it.
As more and more browsing happens on mobile, that should be the new default.
~"It's not the mobile internet, it's just the internet"
- Apple, at iPhone release
Yeah. And then we decided to break that and re-invent the mobile internet with "responsive".
A solution for this is also bouncing from sites that get it wrong.
Though, being unable to address the site's developers as to why you're leaving makes it a bit of a blackbox-ed gesture.
"Why aren't we keeping mobile traffic?"
"I don't know sir, maybe we need to use more viral headlines?"
This isn't necessarily a problem as more sites become responsive and make a proper effort to accomodate mobile browsers. Where this will be a problem is poorly written desktop only sites that just make the change to get faster mobile interactions. I hope this encourages more of the former and less of the latter.
EDIT: If you don't agree why not explain your point instead of randomly downvoting. I believe this change is overall a good thing as it means designers and developers can stop using nasty hacks to get around the delay as they have been doing. Hopefully it will also mean more developers make the effort to make their sites work on mobile instead of the half efforts that seem to be common now.
I didn't downvote you, but I also don't agree with your assumptions. First, I don't think that desktop sites are such a big problem on mobile (though some are, admittedly, unusable). At least with a desktop site I can zoom and figure out a way to get to the content I want (in fact iOS does, or used to, to let you double-tap on the content and it would intelligently zoom to fit). Most mobile sites with which I interact, on the other hand, are terrible. Either the text is too small and the page has disabled zooming, or content overflows and doesn't allow me to pan to see it, or some other terribleness. "Responsive" sites are actually some of the worst to interact with on mobile (for me).
I really don't believe that most developers of "desktop sites" care about mobile or do anything to optimize for it, and therefore wouldn't care about a 350ms delay, or even be aware of it. The people who are going to foul this up, it seems to me, are the "mobile web" developers who try to make their sites act like apps instead of just presenting content in a flexible manner.
This has been my experience too. I surf in landscape mode on an iPhone 5, and far too often there's a fat social-sharing-bar at the bottom, and a fancy site-header-bar at the top, leaving about 1cm of readable and scrollable content. Wtf are they smoking?
A tip: Hold down your finger on the reload circle-arrow to load the desktop version of the page.
Reader mode FTFW.
Fuck fixed headers / footers. Fuck social. And fuck fixed social header/footer bars specifically.
I hate fixed bars on desktop as well - I still scroll with my keyboard and it chops content off willy nilly.
Yep. I've been creating my own local stylesheets under Stylish, including a default which pretty effectively nukes social elements and fixed headers, with some collateral damage I _may_ fix selectively on specific sites.
If you're naming your primary elements, or ascribing them values of "share" or "social" (wildcard search), they're likely to get nuked.
Best answer so far. Print mode is also not bad.
Print mode (offered by websites) so often 1) launches the actual browser print dialog and 2) closes the fucking page when the dialog's closed that I've largely abandoned use of it.
I'll sooner copy/paste text into a vim buffer.
Oh man, this makes GitHub usable on my phone! Their mobile site is so shit.
Thanks for that tip!
Install a content blocker...
And thats a perfectly reasonable complaint to make, my argument is simply that developers of 'desktop sites' should in fact care about mobile browsers as they make up over 50% of page views on most large properties. If they can't make the effort to accomodate a smaller browser to the point where loss of the zoom function breaks their functionality then I feel that this kick might get them to work out these issues.
To be fair, people on mobile might have downvoted you by hitting the wrong button. That's very, very easy to accidentally do when reading HN on a phone, as well as being somewhat ironically on-topic here.
The trouble is really with poor or improper application of responsive features to desktop-first sites and applications. The more people try to build responsive sites, the more they'll get it wrong and introduce all sorts of experience errors that can't easily be circumvented on your mobile device.
Same thing happened through the development of desktop browsing though, and it's more or less gotten better (weird fixed scroll elements in nested tables isn't a thing anymore, mostly).
Enough frameworks and abstractions and hosted services will show up and it'll get better. But, it's going to be a problem (if not a growing one) for a while still. Or, convert-to-Reader mode on mobile browsers will get a ton better and people will just get used to wiping out all the uniqueness of the sites they're browsing.
And, as a browser I still want to be able to zoom in on the 70% column the site has or override the weird 10pt font they thought looked modern in order to read it.
Unscalable != Responsive. One does not preclude the other.
I didn't say it precluded the other, Just that as more sites have a proper mobile view scaling becomes less necessary.
The more sites attempt "proper mobile views" the worse it gets. In 2011, mobile safari was practically perfect. Now half the sites I visit have found some way to dick things up because they hired some nitwit designer to "mobile first" things to shit.
This has been my experience as well. I'm sure there're sensible things to tweak on a "regular" web site to make it more mobile friendly. The web development community just went to the extreme with gimmickry and the web suffers for it, desktop or mobile.
Amen brother! We could browse the web as it was intended to be on our iPhones in 2007-11, and then this responsive fad comes along and we're back to "mobile special" designs again...(remember WAP?)
Those "mobile special" layouts are annoying enough on their own on a phone (with their dumbing down of the UI), but they are doubly annoying when you're used to the web version of a website, and have to hunt for things in the "responsive" mobile version.
And we're saying that's not your decision to make. The user should always be able to scale and zoom.
So let's add pinch to zoom to native apps and the whole OS UI by default.
iOS supports zooming the entire screen as part of its accessibility feature set. Though you have to turn it on, and the gesture is three-finger-tap and drag instead of pinch.
That would be problematic for apps like maps (which I think the street name fonts are too small, and don't scale), or photo/picture programs.
I have bumped into this countless times - street names too small, I subconsciously pinch to zoom, street names get scaled accordingly and are still too small for me. The solution is simple - just move the i<Device> closer to my face - but it's thrown me a couple times. Not sure if this is a UX error or just me being daft.
Unfortunately, I'm far sighted, anything closer than about 12-18" from my face tends to be blurry... I know I can/should wear glasses... but really, the phone is the only device I typically have a problem with generally speaking.
Working with a visually disabled colleague recently iI'm becoming all to painfully aware of how much this is the exception. For Web, apps, OS, devices, and more.
I couldn't disagree more. There should always be a way to make the content I'm looking at bigger in order to see it more clearly, especially for users with poor eyesight.
"responsive design" does not magically eliminate this need, and I agree with the posters saying that disabling of user-scrolling should never have even been allowed in the first place.
And that's not even touching on the fact that most "responsive" sites I've seen get it horribly wrong.
You can't zoom in normal apps.
In apps properly coded against the UIFont APIs, you can: https://developer.apple.com/library/prerelease/ios//document...:
That's why web is/was better for many things, especially when you could increate fonts only (unfortunately, many sites have bad css that breaks this).
That's a deficiency in native apps, not something to be taken away when it does exist for web apps.
Not at all true... I am far sighted, since most of what I look at, including my monitors are more than a few feet away, I tend to see them fine.. my phone is the only device I really have a lot of trouble with. I run in "extra large" font mode, and set my browser zoom to 125%... even then many sites, I have trouble seeing stuff... if there's an image that isn't full width, then I likely can't make out the detail....
Not being able to zoom in to at least 2x, is a pain... if your content doesn't overflow, then sure set the minimum zoom to 1x, and the max to 2 or 3.. but disabling it altogether is just painful to experience... and many of the "suggestions" to fix mobile scaling include disabling zoom. I'm not even that old (40), but I imagine the problem is worse for people well into their 60's.
If you're using a font-size less than 12pt, you should emphatically NOT be disabling scaling... Unfortunately many sites/apps do just that, and often don't respect the usability settings in the OS (facebook on android was particularly bad, as in too small, before I uninstalled it).
Define 'proper' mobile view. How can the designer know how the user is viewing their site? On a cheap device with low contrast? At an awkward angle at arm's length while trying to keep the baby asleep? Trying to read something quickly when you don't have your reading glasses on you?
The problem is that some designer whips up a mobile theme, disables scaling, and then an content editor posts some unexpected content that breaks the design, and the readers can't do anything about it.
It gets even worse when designers sell those themes to non-technical people, who have no way to fix the mess the designer caused by disabling scaling/scrolling.
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.
Not being able to zoom on Instagram is maybe the #1 most baffling UX decision I've ever encountered. You're a photosharing app but all I can see is a 2" square thumbnail image???
> 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.
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).
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.
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.
Yeah, facebook (when I last used it) didn't even respect the accessability settings in android (for extra large fonts). It's a problem in a lot of applications.. if your app doesn't allow you to increase the fonts to at least 12pt, you're doing it wrong... there's a reason that was the default print size since forever and a day...
They probably do it to save bandwidth. Smaller images, smaller size.
why would they not follow what browsers already do and solely rely on:
this is basically a solved problem with pretty much all other vendors having already converged.<meta content="width=device-width, initial-scale=1.0" name="viewport">instead, they're giving fastclick [1] a reason to live on to polyfill a single, non-conforming vendor :(
Each browser tackles it in a different way (see https://github.com/ftlabs/fastclick#when-it-isnt-needed):
* Chrome checks the viewport meta, as you mention
* IE looks for CSS (touch-action: manipulation) on elements
The change being made to WebKit will allow it to honor the viewport meta approach (e.g. when it disables scaling), just like Chrome does. So, if anything, IE is the odd one out now.
I hope the UI team make going back, even if an ad opened a new windows, super easy.
I often accidentally touch the screen while preparing my finger for a scroll or zoom. I see links get highlighted, but if I'm fast to complete what I actually wanted, iOS will understand it was an accidental touch.
No longer it seems. Shame.
It's already super easy to go back. Just do an edge-swipe from the left, like you would in a normal navigation stack in most apps. And you can edge-swipe from the right to go forwards.
If you are going to do something active (disable zoom) you could also just modify click to be fast (which was always possible before, and for which there are drop-in solutions). Like, this seems to be a non-issue.
this is exactly the reason I sneaked in fastclick[1] at work when noone was looking
I'm usually at 260%.
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.
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.
It's a shame. HTML was originally meant to be quite device unaware, and display fine on toasters.
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.
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.
I dunno, 90s era table layouts weren't exactly flexible either…
Mobile now covers a wide range of scales.
You're right in principle, but in practice a lot of zoom-disabling websites have text that's smaller than it should be. Apps seem not to have this problem as much.
I agree. I think the issue is that apps are purpose built for a device while web attempts to 'average' the experience across a range. Honestly, I think many designers don't actually preview their pages on real devices either.
Because the middle ground is what happens in real life. Many sites have poorly designed mobile experiences that zoom helps fix. I personally have my mobile Chrome set to over-ride site viewport settings to always allow zoom.
For example wikipedia (used to?) disable zoom while making all their pictures small. But what if the picture has the information you want to see?
This is because a lot of content on the internet is long form reading with pictures, and ideally you'd want the middle ground, responsive quick scrolling with the ability to zoom on pictures, infographics, etc. and then zoom out again to carry on reading.
And before you say it, all picture viewers on mobile suck. We already have an amazing, built in solution.
Apps also support a lot more in the way of accessibility features, e.g. Dynamically resizable text.
Tell that to the guys behind the facebook app for android.. they don't respect the accessibility feature at all, and their text is too damned tiny... (haven't used it in nearly two years, since they started pushing messenger as a separate app, I don't need two battery zapping apps running all the time).
Reading all the answers here and to me it seems that the problem is not the metatag nor the fastclick, but just poorly designed responsive websites.
No, you're wrong. The meta tag is a problem. No matter how subjectively 'good' a design is, it should still not be up to the designer to decide to break a fundamental UX paradigm of my device, nor to decide what size of text I should be able to read.
Setting the viewport meta this way is practically the definition of an accessibility micro aggression.
I mean that if websites where more well designed users won't need to zoom at all most of the time. Not that they must not do it.
Pinch to zoom is a beautiful feature and part of the success of the early iPhone and iOS, and it was there because at the time there was no mobile web design at all.
The fact that so many users still go in panic mode today reveals how mobile web design is far from perfect.
That said, there'd be also legitimate design reasons to use the viewport metatag to disable the zoom. Good designers know the rules and know when they can break them. I don't believe in accessibility dogma.
Many apps do have pinch to zoom on viewports. Just about any app that displays pictures, for example, or any app that displays large amounts of text.
That's true but those are scalable components within the app specifically designed to be scalable. You're not scaling the entire app window.
If you have an area you want to be scalable, you'll have to implement it in JavaScript or use a pre-made component.
I actually find myself wishing I could scale whole apps on mobile sometimes.
Some apps are problematic, and many don't follow the accessability settings for font size, as an example... the facebook app on android is all but impossible for me to read (far sighted). Some devices don't set their dpi correctly, and are even worse since the default settings make things way too small.
If you can't display close to 12pt text in your app at least as a visability option, then there are probably quite a few people that can't use your app... lower than 10pt is almost inexcusable imho.
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.
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.
Unless it becomes a bullet point on someone's feature list.
there's allways fastclick
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...
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...
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.
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.
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?
Double-tap zoom is meant to be "smart" about what it zooms to, automatically. So if you're looking at a page with multiple regions and double tap one of them it will try to zoom to show you that region. I use this far more than pinch-to-zoom.
You can use double-tap zooming with the hand you're holding the smartphone with, im using it more often than pinch to zoom.
Try double tap zooming on a paragraph in a body of text. It should automatically zoom so that the paragraph occupies the full screen width. That's a pretty nice feature to just give up.
Seems like you'd still need the 350ms delay (or some amount of delay) for pinch-to-zoom because the two fingers don't touch the screen simultaneously. The sensor reads the first finger's touch and the software has to wait to see if a second finger touch comes in before it decides if the first touch is a tap or the start of a pinch.
I also never understood why you'd double tap on a link or a button.
You might double tap near a button, to expand it and give yourself a larger target.
Fat fingers.
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.
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.
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 ).
(c) you run into future compatibility problems (pen, force-clicks, other HIDs).
True. But that's where http://www.w3.org/TR/pointerevents/ comes in
Even if you use nothing but touch events on IOS, the 350ms delayed click can still cause problems. For example, suppose you want a button to pop open a small form over the top of the page and automatically focus the first input in the form. You can wire up a touch event so you don't have a delay, but then the input gets focused and then un-focused 350ms later, because a delayed click happened somewhere else on the page. Or maybe a different field gets focused because it's now directly above where that button used to be.
You on the other hand are making the assumption that developers are capable of making that decision informed and "correctly".
Well... Yeah. What's your point? That Apple knows better about the content and performance characteristics of my app than me?
No, the user gets to decide, when looking at your website, whether they want to zoom it or not. Based on whether or not they can comfortably read it.
(Yes, there's accessibility zoom, but I didn't know about that until this thread)
Can’t have it both ways. That’s the issue here.
How long until this makes it into the Mobile Safari on most people's iOS devices?
Generally, stuff that lands on webkit master is available in the next major iOS release, e.g. iOS 10.
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.
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
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.
God that's completely unintuitive.
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.
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.
Three-finger zoom is more inconvenient and a little inconsistent in my experience on iOS9. It is inconvenient in that scrolling a page is sometimes difficult to accomplish when zoomed in. I feel like three-finger zoom is a last resort for when something is not properly accessible. I am visually handicapped and being able to zoom is essential for me. I have a hard time using sites that disable zoom already, this is only going to exacerbate the problem.
This is a little bit off topic (from standard iOS) but here's how I force zoom stuff with a little tweak I made http://imgur.com/1WXHoPv (jailbroken devices only). The thing itself is not for zooming, but it is a happy little additional bonus feature.
Nice! Thanks.
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?
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.
An interesting choice would be to retroactively undo the effects of the single click if a second one was detected.
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.
Delay page switches (and other interruptive things) then.
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.
Send GET requests, delay POST.
Yes, the whole architecture would need to good undo-support.
At this point it's a good idea to keep in mind the effort/gains ratio. You're proposing massive changes to JavaScript engines in order to have double tapping work a certain way. Changing the gesture or tweaking the delays might yield a less optimal solution, but the effort is so much closer to 0. If you were going to invest the effort you're proposing into something, would improving this delay be the best knowable use of that effort?
You go down this road until you say to yourself... Ah next version, I'll just at a 350ms delay for now.
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!
You only delay non-idempotent actions.
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?
Can someone explain what this means for the non-IOS developers amongst us?
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.)
Also worth mentioning: Chrome for Android did this last year. GP was asking about iOS, but it's not an iOS-specific thing.
To continue the Chrome for Android tangent, you can re-enable zoom-in as an accessibility feature.
It means that un-optimized websites that have a certain meta tag set will feel (keyword here being "feel") faster when interacting with them.
Remind me: They originally had the 350ms delay in there to distinguish between a tap and a pinch, correct?
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.
As I recall, it's waiting for a double-tap.
yeah, it is a mechanism of iOS gesture recognizer
Good news for hybrid apps devs...
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.
Will removing this 350ms delay really make user feel faster response?
It's what FT Labs fastclick tries to mitigate - try it for yourself: http://ftlabs.github.io/fastclick/examples/layer.html