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.<p>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.<p>The proper solution: Do not make double-tap be a UI action. Done.<p>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.<p>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.
"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."<p>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 <i>key feature</i> 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 <i>pessimization</i>, and are almost always worse than the desktop page rendered on the mobile.<p>That's my opinion. I search in vain for a browser whose "view in desktop mode" actually works.
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.<p>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.<p>This along with the numerous improvements to Chrome's developer tools and remote debugging features (<a href="https://developers.google.com/chrome-developer-tools/docs/remote-debugging" rel="nofollow">https://developers.google.com/chrome-developer-tools/docs/re...</a>) coming soon really show an increased focus on making high performance web apps on mobile a realistic option.<p>Hopefully the next game we make will be able to launch on iOS and Android thanks to these speed improvements. :)
For what it's worth, this delay was already removed for sites that had user-scalable=no set. Most mobile "apps" used this.<p>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.<p>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.
Why not add a "Zoom on double-tap" tickbox in Chrome's Settings? Leave it ticked as default so users aren't adversely affected.<p>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 <i>think</i> 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).<p>If you want to put the icing on the cake, add a little applet in Settings to measure your double-tap speed.
Note that this is only different in the<p><pre><code> <meta name="viewport" content="width=device-width, user-scalable=no">
vs
<meta name="viewport" content="width=device-width">
</code></pre>
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.
For a solution for older browsers you can use fastclick.js (<a href="https://github.com/ftlabs/fastclick" rel="nofollow">https://github.com/ftlabs/fastclick</a>). For angularjs webapps there's also ngTouch.
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.<p>Wouldn't it make more sense to introduce a new setting something like "immediate-events=yes" that lets developers opt-in to this behaviour?
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.<p>I'm sure I'll adjust but I do wish this was an opt in/out thing.
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.
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.
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.
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.
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">.<p>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">?
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?
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>p.s. I think this is the Firefox bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=922896" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=922896</a>
> 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.<p>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.
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.
Latency sucks. You can apply this type of touch-click speedup on a site for other browsers with a bit of JS.<p><a href="https://gist.github.com/cagerton/7948779" rel="nofollow">https://gist.github.com/cagerton/7948779</a> (disclaimer: proof of concept, etc. )
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.
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.