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?
WebKit removes the 350ms click delay for iOS
11–20 of 144 posts
Re: WebKit removes the 350ms click delay for iOS
#12While 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 viewp…
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.
Re: WebKit removes the 350ms click delay for iOS
#13A 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.
Re: WebKit removes the 350ms click delay for iOS
#14Can 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.)
Re: WebKit removes the 350ms click delay for iOS
#15Can someone explain what this means for the non-IOS developers amongst us?
It means that un-optimized websites that have a certain meta tag set will feel (keyword here being "feel") faster when interacting with them.
Re: WebKit removes the 350ms click delay for iOS
#16Remind me: They originally had the 350ms delay in there to distinguish between a tap and a pinch, correct?
Re: WebKit removes the 350ms click delay for iOS
#17Good news for hybrid apps devs...
Re: WebKit removes the 350ms click delay for iOS
#18I 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.
Re: WebKit removes the 350ms click delay for iOS
#19I 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.
Nice! Thanks.
Re: WebKit removes the 350ms click delay for iOS
#20Earlier quoted context omitted.
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).
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…
Unscalable != Responsive. One does not preclude the other.