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.
The impact of variable latency is well-known among people who actually study human factors. It makes it hard for your brain to internalize interactions and make them automatic, and it increases the feeling of frustration.
In video games specifically, where I work, it is well-known that you would rather have a game that runs slower, but with a solid frame rate, than a game that has a highly-variable frame rate that is faster on average. (This is more of a continuum situation than a discrete action like a tap, but the basic principle holds).
P.S./edit: Double-tap only means zoom because that is what they happened to implement. It is a convention easily changed. Look at how heavily Apple just revamped their entire interface, for an audience that is arguably much less savvy than the Android audience.
Using double-tap in this way was a mistake; it is an easy mistake to fix if you have enough design vision to know where you are going.
Within a given game (site), I'd prefer to have consistent frame-rate (latency). But if GTA (Gmail.com) is consistently faster than Need For Speed (NYTimes.com), that would bother me less.
Variable frame rates is a different issue. For example, reacting within 100ms feels instant, whereas an animation running at 10fps (one frame every 100ms) looks awful.
Not true. I am talking specifically about interaction response, not the rate of animation display. It is about your brain learning responses to its actions so that it can better plan its actions. That cannot happen when the responses are semi-randomized.
Seriously, there are tons of studies on this. I am not making it up.
He already did, human factors and the need for consistent performance, even if that means that the lack of speed in performance is consistently bad is in it's own way an advantage. The fact that we now have wildly inconsistent performance depending on the pages we're viewing is bad in terms of human factors. If you want precise scientific references try google but these are basic known facts.
Overall I'm not sure how I feel about this topic myself but I do understand jblow's point and somewhat agree with his rant.
> Why do I care if there is a "constant, learnable latency", as long as each latency is reasonable?
Because people would rather have slower and more predictable than faster and less predictable. Especially when it comes to user interface actions where things get pushed down into muscle memory.
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.
I don't think "we haven't seen confusion around this" is a good answer. Most users will not even understand what is happening, they will just have an ambient level of uncomfortability with the UI that they don't know how to explain (not only due to this, but to many other factors as well, all of which contribute).
Don't tell me that your users don't have an ambient level of uncomfortability with the UI, because we all know that is the case (it is even the case on iOS, now much more than it was with iOS 6!)
If I were the UI lead for Android, I would be scouring the system from top to bottom, looking for ways to simplify and streamline, to increase predictability. All kinds of current UI actions would get thrown away (hint to Google Maps people: Shake is not an intentional UI action, it is what happens accidentally 5 times per minute when I am using your software. It should not be bound to anything, ever. [Apple is just as bad for binding shake to Undo, but at least theirs has a higher threshold now]. It is nice that at least now you can finally turn it off after it activates a few times, but haven't you noticed how everyone turns it off all the time, and nobody ever uses it for the intended action ["leave feedback"]? Get rid of it.)
Anyway, all I can say to this response: "This is why we have the beta, to test this stuff."
Is that if this attitude were actually solving all the problems that need to be solved, Android would have an amazing UI that everybody raves about. That is not the case! Why is it not the case?
I disagree with the fact that it happens inconsistently and creates a more-complicated situation for me to internalize; and even if I know the rules (which most users don't), it may not always be clear which are happening unless I engage in experimentation -- can I tell just by looking which pages are going to have delay and which aren't? Sometimes it will be obvious, but will it always? Of course not. So sometimes I have to tap before I know. And that is if I am an extremely experienced and knowledgeable user, which most people are not. For most people this will be just one more small piece of inconsistency in the pile of confusion that is Android.
Removing the delay 100% of the time, always, would be a big win.
This assumes that if we leave things as they were before, every interaction takes the same amount of time. Because of the network, and JavaScript processing beyond our control, this is not true. Not true on any mobile device.
... And what about the actual action of double-tapping? On some pages it zooms, and on some pages it does nothing, and in fact the first tap fires off a link. How is that simple, predictable, or solid-feeling? It isn't.
I agree (a) inconsistency is bad and (b) latency is bad, but double-click-to-zoom is very useful (for operating the phone with your thumb when your other hand isn't free), and I think removing it would be bad overall.
Perhaps people will be more inclined to write mobile-optimized sites that don't need to be zoomed if they can get reduced latency as a bonus.
Double-click-to-zoom is useful, but not on mobile-optimised sites, which is why we only disabled it there. Although, if you know of a mobile-optimised site it's useful on, let us know, it'll affect how the feature lands in stable.
The fact that mobile sites somehow assume that zooming is bad is the exact reason for why they are useless and most people, that know what they are doing, are not browsing mobile sites at all but going to great lengths to get the full blown version that lets you get an overview and zoom in on the interesting parts instead of endless scrolling to find what you are looking for.
I've yet to experience a mobile site I prefer to the real thing, on any of my mobile devices.
Lol. "Most people that know what they're doing", don't pull up the desktop version, because they're pretty okay with mobile sites. But I guess I've no idea what I'm doing when browsing on my iPhone, and my analytics showing far better engagement with a mobile site vs desktop site on mobile just shows me a lot of people who don't "know what they're doing".
You're talking about badly built sites here. The change to Chrome discussed in the article doesn't make the situation you describe any better or worse.
I could say all mobile-versions are badly built, but I'd be wrong.
Not all mobile-optimised sites have endless scrolling. Presenting the same amount of data to mobile as you would desktop, but linearised, is bad design. Having to pan and zoom is also bad design.
I do this in a minor way on my blog http://jakearchibald.com/ - the side bar doesn't appear on mobile, as it would linearise below the main content where few would see it. Instead, it becomes a navigation item at the top of the page.
That is to say that it usually isn't the best when paired with pages made for desktop browsers. But it is the best we've got.
Your blog is very simple, and that's great, but it hardly represents the difficulties that people have to address when creating a mobile site.
Also, having to press "Who" requires a new page to be loaded as compared to it being there in the first place (conditional loading is most definitely not ideal).
But, why is your mobile version better than the desktop version when on a phone? Honestly?
The desktop version gives me an overview, I can get a better glimpse of the topics (and you on your sidebar) and I quickly and literally dive in on the content I'm after without having to load a new page (which is expensive). And I bet that the desktop version would be just as readable and fast as your mobile version. But I can't test it out because your page does not respect the "request desktop site" option on the latest Chrome on android (4.4.2). That is really bad.
Your page is so simplistic that I would assume, only being served a mobile page, that if I didn't find what I was looking for I'd wonder if it were present on the "real" site. That is reason alone not to have a mobile version at all for a simple site. Yes, that's only a consequence of the pathetic state of affairs that is mobile web pages but it is the reality.
So, you agree that a mobile site with endless scrolling is bad. How have you imagined to solve that when your blog count increases? With pagination every 10 posts? That is bad enough on a workstation but traversing pages on a phone is a nightmare. Just give me the whole list in the desktop version and with a flip of a finger I can scroll through the content with breeze.
I hate non-zoomable sites, even when "mobile friendly" sometimes the fonts on my phone are too small, even in mobile, or I'd like to zoom in on an image a bit.. I'd rather have the delay... (actually I'd rather nuke double-tap to zoom)
Chrome on Android has the Accessibility setting "force enable zoom" that can be ticked to achieve that
Mobile Safari allows the viewport settings to be changed at runtime, so you could make a JavaScript bookmarklet to achieve the same. EDIT: already done https://gist.github.com/jasonbarry/6047338 as per user andrethegiant below.
Absolutely...what do you do when a non-zoomable site is too small or too big? It's much better to have the flexibility. Double tap is less useful to me than retaining the ability to zoom any site I want to.
"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.
Is that what Android Chrome is doing on Hacker News? I remember reading it sometimes and seeing some comments being larger than others. I thought it was some crazy mobile optimization based on votes but it didn't seem to have any logic it to it.
Yes, I that's Android Chrome with its crazy font size guessing :/
Chrome has also more HTML5 related bugs than all other modern browser combined, as JQuery devs mentioned in their blog (2.0 release). It correlates with my own web dev expierence as well. It would be great if Google would employ some QA managers.
Dolphin just lets the web page describe the font size... thus it's all correct.
Chrome and Firefox both try and guess what the font size should be and ignore the web page telling it. Thus the font varies all over the place, though the pattern seems to be depth of text in DOM.
Just set the font size to a minimum in Firefox preference and it will stop doing this font resizing. To make text bigger change browser.viewport.desktopWidth in about:config to some smaller value.
> 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.
My phone has the same resolution as my computer monitor and 45" TV. But due to size and viewing distance, the same font & image sizes shouldn't be used on all.
This is why we have ppx/device-pixel-ratio on the web.
Your link appears to agree with me. That ppx/device-pixel-ratio is used to make CSS pixels an angular measurement. Although I haven't encountered a TV browser that does this properly yet.
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.
This isn't just your phone. I encounter this specific problem a lot on an iPhone 5 running iOS 6. (And it is just one of the many irritating bugs with mobile sites that I see regularly).
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.
Disabling the viewport on websites that need zoom is really bad design, but if you have a website that is optimized or at least scales well to mobile sizes then disabling zoom is better. If the user doesn't have a reason to zoom on to content then accidentally zooming makes for a worse experience.
Although I agree that there should be an option to disable the disabling of viewport zooming; I think it makes for a better UX for most mobile website viewers.
Firefox for Android is my primary browser on my Nexus 5 now that the AOSP browser has been removed. On my Nexus 4, I rooted the phone to get back to the AOSP browser, but when KitKat came out, it broke root. I haven't gotten around to re-rooting either phone.
And no, the "view in desktop mode" toggle in Firefox for Android almost never works. I've considered rage-reporting bugs for all the URLs it fails on, but it's an idle fantasy right now. It clearly isn't a priority for Mozilla.
I haven't seen it fail, but I have only used the desktop view when coming from a page that then gets redirected to a mobile page. Firefox handles that well.
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 performance you're better of with Unity. For distribution you're better off with HTML5. You can get in the app stores & have distribution on the mobile web, have the game instantly playable in webviews, etc...
Sounds great in theory, in practice mobile web views are pretty slow for games, as op already stated. Besides Unity will have a HTML5 export soon which will make it the most efficient tool for creating web games anyway.
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.
Ah, that's too bad. It would be nice if setting user-scalable=no was all you had to do to disable the delay. And anyway, despite using an iPhone for god knows how many years, I didn't even know that a double tap on iOS scrolls the page!
Edit: I mean double tapping on an unzoomable page.
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.
Settings don't get used. It's good to have nice flexible settings so people who investigate can make the device work the way they want, but most of the time people are using defaults, and developers spend the most time worrying about how to make their app/website work well with the defaults.
Are users adversely affected by this change? In what way?
This change is designed to make the existing web faster. If we improve the performance of rendering, JavaScript, or scrolling, we don't put it behind an opt-in option. Why should this be?
Well, I'm not suggesting they do my idea instead of what they've done. I'm suggesting they do it in addition to what they've done.
I hate the delay between tapping the screen and the "click" being recognised. It drives me up the wall. I'd far rather switch off "Double-tap to zoom" for all pages (not just those with the relevant meta-tag) and use pinch-to-zoom instead.
There are obviously very good reasons to not disable "Double-tap to zoom" entirely or by default (primarily accessibility, but also the fact that people have gotten used to it) but where's the downside in making it a Setting so that people like me can choose to disable it? Okay, maybe the upside is quite small but there's zero downside and (given that they've already implemented the ability to switch "Double-tap to zoom" off if the webpage has the relevant meta-tag) it would be relatively easy to implement.
Making stuff like this user-configurable is a Good Thing. It's like when Apple changed the behaviour of the iPad's side switch in iOS 4.2 to switch it from rotation lock to audio mute and Steve Jobs said there wouldn't be a configuration option to let users change the switch back to rotation-lock [1]. A lot of people (including me) were disappointed. Fortunately, he changed his mind and iOS 4.3 made the function of the side-switch user-configurable in the Settings.
It's not so much the change as letting websites disable zoom. Letting websites disable zoom is a braindead user-hostile decision that could only have been made by people with perfect eyesight (or perfect glasses.)
I have good eyesight. I don't need glasses. I still like to zoom in on text by double-tapping and pinching to zoom. What if I'm on a bus and it's easier to read larger text?
You can add 'with an under-developed theory of mind' to the end of that list.
Or you can get rid of this uncharitable list altogether and replace it with something like 'with a mandate to balance complex trade-offs between technological constraints and competing user, web page, and web application designer needs'.
That's a trade-off. Choosing "Do A but let the user change it to B in the Settings" is very similar to "Choose A", because nobody changes settings. You just move the debate to what the default should be. Not to mention that "Should we or shouldn't we have crap-tons of settings?" is its own trade-off.
> That's a trade-off. Choosing "Do A but let the user change it to B in the Settings" is very similar to "Choose A", because nobody changes settings. You just move the debate to what the default should be.
Okay, smart-ass, what's your solution? Maybe we should put the GUI inside a box with the "A or B" decision delegated to a mechanism that monitors a radioactive source. We'll call it Schrodinger's GUI.
I wasn't being a smart-ass at all. I said "you have to balance trade-offs", you said "no, you don't have to, here's a non-trade-off solution", and I said "no, you've just changed the trade-off". Many people seem to think that moving things into configuration is a "free" solution, and I am very non-sarcastically saying that no, it is not. My solution is to be aware that there is no "solution", and you have to balance trade-offs (which is what I said to start!).
That's the thing though (I agree, it's not a nice list, but it's not nice to remove features either). Who says they have a mandate to do the balancing this way? It's their software to do with as they want. That's less mandate and more unilateral.
I wouldn't mind swapping a bit of a delay for a checkbox in the settings. I wouldn't even mind the checkbox being unticked by default.
<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.
ngTouch is why I ought to get round to upgrading to Angular 1.2.x (currently on 1.0.x).
One of the things ngTouch gives is "A more powerful replacement for the default ngClick designed to be used on touchscreen"[1]. Oh, I see its not bundled in the core angular.js file.
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 only affects mobile-optimsied sites where double-tap zoom is pretty useless.
Sweet. I was thinking mostly about non-mobile sites so then this works. The only thing I can think of (and this isn't very often) is maybe images. For example on the mobile Wikipedia site there is often an image at the top of an article that I will double tap to zoom into and then another double tap to revert to normal zoom level. Definitely not the typical use case but something to consider. Maybe only have the 300ms when the first tap is on an image that is not a link. Just spit-balling here.
Either way if it is only for mobile optimized sites, I don't see this being a problem.
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">?
So to be clear, as long as the content attribute contains "width=device-width", regardless of what comes after it, the 300ms is removed in those browsers?
In the current versions of Chrome & Firefox, the viewport needs to be unzoomable to remove the 300ms delay. However, in Chrome Beta, the 300ms is removed as long as the viewport is <= device-width.
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.
If you double tap a link on a desktop you will go to that link 'twice'. If you double tap a link on ios you will zoom to that link. Unless you wait for as long as a double tap takes you won't know if the user meant to zoom or to click the link. This is why there is discussion going on about the default view port and user zoomable content.
I get that, but was thrown by your reference to "native" behavior - if you want to be able to double tap a clickable element, you'll need to wait long enough to discriminate the two behaviors.
On the other hand - the desktop solution would be fine too; just don't solve the problem (i.e. you can't double-tap clickable content).
I think I'd rather have fast responsive taps rather than double-tapping even on links; regardless of the zoomability settings.
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.
That, and also if you tap too quickly, it will just trigger the tap to zoom feature. So you have to wait that long anyway regardless of where your hand is placed.
> 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.
> But touch/pointer events can preclude the double-tap.
Your previous comment seems to imply otherwise: if the UA must dispatch pointercancel rather than pointerup on a double-tap, it has to wait until it can determine whether a double tap happened.
But that still means that the browser has to determine if it's a single tap or double tap before sending the pointerup, so it'll arrive after the 300ms delay.
No, it doesn't. The double tap gesture comes after pointer events. Pointer events can prevent double tap. Whereas click comes after the opportunity for double-tap, and double-tap will prevent click.
Try it in IE, or another browser using touch events.
> The double tap gesture comes after pointer events.
You make no sense, by your own description the double tap gesture changes what pointer events fire, pointerup can not fire until the UA knows for certain it's not going to be a doubletap, same as click.
If you don't trust me on this, that's fine. Test it for yourself.
Double tap does not change pointer events (https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEve...), they come first. But 'click' is not a pointer event, it's the result of some pointer events, and the lack of the browser doing something else, such as scrolling, double tap etc.
But seriously, don't take my word for it. Test it.
If I'm not explaining it properly, see the test and work it out yourself. Touch & pointer events happen before double tap (and can prevent it) click happens after all those and can be prevented.
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.
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.
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.