61–70 of 144 posts
Earlier quoted context omitted.
That sounds interesting at first, but then what happens if say, the element takes you to another page? Then you'd have to go back a page, which would be a clunky experience.
Delay page switches (and other interruptive things) then.
I really don't understand the lamentation around pinch to zoom. There's a fantastic os-level zoom built into ios! Set it up and three-finger-click to activate. And it works great.
Earlier quoted context omitted.
You're talking about two fundamentally different things. Apps are designed specifically for mobile, so of course they will work well fine at the scale they were designed at. 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…
It's a shame. HTML was originally meant to be quite device unaware, and display fine on toasters.
Earlier quoted context omitted.
Delay page switches (and other interruptive things) then.
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.
Yes, the whole architecture would need to good undo-support.
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.
As I see it, the 350ms delay was added to support zooming via double-tap. What I don't understand is why double-tap zooming is necessary when we have pinch-to-zoom? Can't zoom via double-tap be sacrificed for instant clicks and everyone is happy?
I also never understood why you'd double tap on a link or a button.
Earlier quoted context omitted.
Even worse, some sites disable scaling, but let their content overflow the width of the screen without any possible way to see it. If you're going to use user-scalable=no, at least make sure that your code blocks and images resize to fit on mobile screens (or viewable separately).
This isn't necessarily a problem as more sites become responsive and make a proper effort to accomodate mobile browsers. Where this will be a problem is poorly written desktop only sites that just make the change to get faster mobile interactions. I hope this encourages more of the former and less of the latter. EDIT: If you don't agree why not explain your point instead of randomly downvoting. I believe this change…
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.
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).
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).
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.