javascript:document.querySelector('meta%5Bname=viewport%5D').setAttribute('content','width=device-width,initial-scale=1.0,maximum-scale=10.0,user-scalable=1');
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've turned on assistive zooming on my iPhone to overcome the limitation.
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.
<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 :(
* 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 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 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.
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.
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.
Setting the viewport meta this way is practically the definition of an accessibility micro aggression.
If you have an area you want to be scalable, you'll have to implement it in JavaScript or use a pre-made component.
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.
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.
I'm not trying to attack or being negative here... just a bit surprised.
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.
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).
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
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.
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.)