What if it sends an AJAX request? You can't exactly undo them. The browser JS environment is sufficiently complex that "just undo"ing something seems like it would be... complex.
Send GET requests, delay POST. Yes, the whole architecture would need to good undo-support.
A lot of sites out there perform actions on GET requests, though. I just don't see it working out.
In any case, once you start delaying things you ruin the original point of getting rid of the click delay - to make things faster!
A 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.
If you're building your website to behave well on mobile devices, you're likely implementing your own touch handlers and are not using click events to begin with.
Even if you use nothing but touch events on IOS, the 350ms delayed click can still cause problems.
For example, suppose you want a button to pop open a small form over the top of the page and automatically focus the first input in the form. You can wire up a touch event so you don't have a delay, but then the input gets focused and then un-focused 350ms later, because a delayed click happened somewhere else on the page. Or maybe a different field gets focused because it's now directly above where that button used to be.
The change applies only to unscalable viewports. That's a shame, because it means some developers will disable pinch-to-zoom to get a faster click response. That makes this yet another unfortunate conflict between usability and accessibility. The older I get, the more I appreciate being able to zoom (I'm viewing this page at 125% on desktop right now).
If you are going to do something active (disable zoom) you could also just modify click to be fast (which was always possible before, and for which there are drop-in solutions). Like, this seems to be a non-issue.
I didn't say it precluded the other, Just that as more sites have a proper mobile view scaling becomes less necessary.
The more sites attempt "proper mobile views" the worse it gets. In 2011, mobile safari was practically perfect. Now half the sites I visit have found some way to dick things up because they hired some nitwit designer to "mobile first" things to shit.
This has been my experience as well. I'm sure there're sensible things to tweak on a "regular" web site to make it more mobile friendly. The web development community just went to the extreme with gimmickry and the web suffers for it, desktop or mobile.
If you're building your website to behave well on mobile devices, you're likely implementing your own touch handlers and are not using click events to begin with.
This is actually very hard to implement. 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…
And we're saying that's not your decision to make. The user should always be able to scale and zoom.
So let's add pinch to zoom to native apps and the whole OS UI by default.
iOS supports zooming the entire screen as part of its accessibility feature set. Though you have to turn it on, and the gesture is three-finger-tap and drag instead of pinch.
A 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.
You on the other hand are making the assumption that developers are capable of making that decision informed and "correctly".
Well... Yeah. What's your point? That Apple knows better about the content and performance characteristics of my app than me?