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.
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.
The proper solution: Do not make double-tap be a UI action. Done.
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.
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.
I assume they discussed removing double-tap as an action but decided it would be too disruptive. I can't say I disagree with the choice they made.
I don't believe the problem you brought up is very important. Why do I care if there is a "constant, learnable latency", as long as each latency is reasonable? In the end I assume that the slowest response is the standard and any actions that happen faster are a pleasant surprise.
But more importantly this change doesn't preclude them from removing double-tap altogether in the future. I agree it is a half-solution now, but it's better than nothing if you are willing to grant that differing latency across pages is acceptable.
I do like the insight about stacking double-tap on top of single-tap, I'm just not sure how to apply it in the current world where single-tap means click/navigate and double-tap means zoom.
This has been a behaviour for many versions of Chrome and Firefox for a while (zoomable sites vs non-zoomable) and we haven't seen confusion around this.
"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."
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 key feature 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 pessimization, and are almost always worse than the desktop page rendered on the mobile.
That's my opinion. I search in vain for a browser whose "view in desktop mode" actually works.
Or a browser that leaves the font size alone and doesn't try and guess what size the font should be by some invisible algorithm that factors in things like the depth of the text node in the DOM.
You hit some sites, and fonts that should be the same size (and are on the desktop site) are just wildly different sizes.
I'm using Dolphin almost exclusively for this single reason.
> No! [...] then zoom in on the bit you're interested in.
??? Why "No"
Deskop pages also have a habit of being laid out with very long lines that don't reflow when you zoom in, this is
bad in general (narrow columns are more readable) but especially bad on a portrait-orientation device.
I still use a WinPhone7 phone and many of these "mobile" sites are completely broken on WP7 IE - they frequenetly have images or boxes that extend outside the bounds of the fixed-width area and don't allow me to zoom out or pan right to see the whole thing.
It is a problem with the user-agent if it does not allow the user to zoom, and I don't care what the page markup says. Zooming can be a function of the display and not the page layout. An, um, "content zoom" is a different thing entirely.
Amen. I wish there were a MobileSafari preference to ignore all the terrible viewport business (I am so fucking sick of websites with tiny type disabling my ability to zoom!) and send a desktop safari user-agent on top.
Even Motherfucking Website[1] cocks this one up and disables zooming.
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.
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.
This along with the numerous improvements to Chrome's developer tools and remote debugging features (https://developers.google.com/chrome-developer-tools/docs/re...) coming soon really show an increased focus on making high performance web apps on mobile a realistic option.
Hopefully the next game we make will be able to launch on iOS and Android thanks to these speed improvements. :)
There never was any delay for touchstart/touchend events.
If you're using onclick/mousedown in your game, then change them to touch events (touchstart and whatever Windows Phone does). These work without delay regardless of viewport settings.
If you have existing codebase that can't be easily changed to use touch events, you can use FT Labs' fastclick to emulate onclick with no delay (the library is aware of latest Chrome's change):
For multiplatform games you are still better off with Unity imo. Sure, from a developer standpoint, building on open tech is cool, but gamers don't care at all and when Unity gives you the best possible performance and development workflow i would stick with it.
They will also probably soon have a HTML5 export (they already have PNaCL)
For what it's worth, this delay was already removed for sites that had user-scalable=no set. Most mobile "apps" used this.
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.
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.
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 think 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).
If you want to put the icing on the cake, add a little applet in Settings to measure your double-tap speed.
<meta name="viewport" content="width=device-width, user-scalable=no">
vs
<meta name="viewport" content="width=device-width">
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.
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.
Wouldn't it make more sense to introduce a new setting something like "immediate-events=yes" that lets developers opt-in to this behaviour?
There is no spec that says how the events should be handled when the viewport is specified. IMO it shouldn't really be down to the developer to have immedidate-events etc because it is likely to be a user request (which they can currently override).
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.
I'm sure I'll adjust but I do wish this was an opt in/out thing.
This only affects mobile-optimsied sites where double-tap zoom is pretty useless. Is there a page you;d find broken with this new behaviour? We're open to use cases.
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">.
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?
You can actually try this out in Chrome Android Beta. Go to about:flags and enable "Disable tap delay".
Here are the problem cases:
* Delegated event listeners - as in the click handler is on the html/body element. The listener may do something when a click happens, it may not. This means everything is potentially clickable, and we can't know in advance.
* Large click areas - Areas where the article title, summary and picture are all part of the same link. It's not always clear at first, but you'd be surprised how often you trigger it by accident.
Indeed. That's how most desktop browsers handle double-click -- it only happens when the first click wasn't handled (preventDefault-ed). I guess they made this decision for usability reasons (double-tap-to-zoom should always work) but ended up creating a different problem instead.
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.
> 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.
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.
From the spec: "The user agent must dispatch a pointercancel (and subsequently a pointerout event) whenever all of the following are true, in order to end the stream of events for the pointer:
The user agent has determined (via methods out of scope for this specification) that touch input is to be consumed for a touch behavior,"
Touch behaviours are things like scrolling, double-tap to zoom, pinch zoom.
The browser's double-tap to zoom gesture is at a lower level than the click event in the browser. As in, a double-tab will be consumed by the browser and never hit the page.
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.
[+] [-] jblow|12 years ago|reply
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.
The proper solution: Do not make double-tap be a UI action. Done.
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.
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.
[+] [-] stanleydrew|12 years ago|reply
I don't believe the problem you brought up is very important. Why do I care if there is a "constant, learnable latency", as long as each latency is reasonable? In the end I assume that the slowest response is the standard and any actions that happen faster are a pleasant surprise.
But more importantly this change doesn't preclude them from removing double-tap altogether in the future. I agree it is a half-solution now, but it's better than nothing if you are willing to grant that differing latency across pages is acceptable.
I do like the insight about stacking double-tap on top of single-tap, I'm just not sure how to apply it in the current world where single-tap means click/navigate and double-tap means zoom.
[+] [-] jaffathecake|12 years ago|reply
This is why we have the beta, to test this stuff.
[+] [-] barrkel|12 years ago|reply
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 key feature 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 pessimization, and are almost always worse than the desktop page rendered on the mobile.
That's my opinion. I search in vain for a browser whose "view in desktop mode" actually works.
[+] [-] buro9|12 years ago|reply
You hit some sites, and fonts that should be the same size (and are on the desktop site) are just wildly different sizes.
I'm using Dolphin almost exclusively for this single reason.
[+] [-] gohrt|12 years ago|reply
> No! [...] then zoom in on the bit you're interested in.
??? Why "No"
[+] [-] bluthru|12 years ago|reply
[+] [-] Pxtl|12 years ago|reply
[+] [-] nfoz|12 years ago|reply
[+] [-] sneak|12 years ago|reply
Even Motherfucking Website[1] cocks this one up and disables zooming.
[1] http://motherfuckingwebsite.com
[+] [-] duaneb|12 years ago|reply
[+] [-] reubenmorais|12 years ago|reply
Have you tried Firefox for Android?
[+] [-] guelo|12 years ago|reply
[+] [-] primigenus|12 years ago|reply
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.
This along with the numerous improvements to Chrome's developer tools and remote debugging features (https://developers.google.com/chrome-developer-tools/docs/re...) coming soon really show an increased focus on making high performance web apps on mobile a realistic option.
Hopefully the next game we make will be able to launch on iOS and Android thanks to these speed improvements. :)
[+] [-] pornel|12 years ago|reply
If you're using onclick/mousedown in your game, then change them to touch events (touchstart and whatever Windows Phone does). These work without delay regardless of viewport settings.
If you have existing codebase that can't be easily changed to use touch events, you can use FT Labs' fastclick to emulate onclick with no delay (the library is aware of latest Chrome's change):
https://github.com/ftlabs/fastclick
[+] [-] kayoone|12 years ago|reply
[+] [-] timsayshey|12 years ago|reply
[+] [-] JoelSutherland|12 years ago|reply
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.
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.
[+] [-] sluukkonen|12 years ago|reply
Is this true for mobile Safari as well?
[+] [-] jackgavigan|12 years ago|reply
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 think 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).
If you want to put the icing on the cake, add a little applet in Settings to measure your double-tap speed.
[+] [-] daleharvey|12 years ago|reply
[+] [-] poxrud|12 years ago|reply
[+] [-] a-priori|12 years ago|reply
Wouldn't it make more sense to introduce a new setting something like "immediate-events=yes" that lets developers opt-in to this behaviour?
[+] [-] kinlan|12 years ago|reply
[+] [-] skizm|12 years ago|reply
I'm sure I'll adjust but I do wish this was an opt in/out thing.
[+] [-] jaffathecake|12 years ago|reply
[+] [-] kinlan|12 years ago|reply
[+] [-] cbr|12 years ago|reply
[+] [-] toadkick|12 years ago|reply
[+] [-] Pxtl|12 years ago|reply
[+] [-] sauravt|12 years ago|reply
[+] [-] eliot_sykes|12 years ago|reply
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">?
[+] [-] jaffathecake|12 years ago|reply
[+] [-] shawabawa3|12 years ago|reply
[+] [-] jaffathecake|12 years ago|reply
Here are the problem cases:
* Delegated event listeners - as in the click handler is on the html/body element. The listener may do something when a click happens, it may not. This means everything is potentially clickable, and we can't know in advance.
* Large click areas - Areas where the article title, summary and picture are all part of the same link. It's not always clear at first, but you'd be surprised how often you trigger it by accident.
But give it a go yourself!
[+] [-] marijn|12 years ago|reply
[+] [-] sp332|12 years ago|reply
[+] [-] hmottestad|12 years ago|reply
[+] [-] nodata|12 years ago|reply
p.s. I think this is the Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=922896
[+] [-] masklinn|12 years ago|reply
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.
[+] [-] jaffathecake|12 years ago|reply
The user agent has determined (via methods out of scope for this specification) that touch input is to be consumed for a touch behavior,"
Touch behaviours are things like scrolling, double-tap to zoom, pinch zoom.
The browser's double-tap to zoom gesture is at a lower level than the click event in the browser. As in, a double-tab will be consumed by the browser and never hit the page.
[+] [-] marcosscriven|12 years ago|reply
[+] [-] lm741|12 years ago|reply
https://gist.github.com/cagerton/7948779 (disclaimer: proof of concept, etc. )