Earlier quoted context omitted.
I didn't say it precluded the other, Just that as more sites have a proper mobile view scaling becomes less necessary.
And we're saying that's not your decision to make. The user should always be able to scale and zoom.
WebKit removes the 350ms click delay for iOS
51–60 of 144 posts
Re: WebKit removes the 350ms click delay for iOS
#52Earlier 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…
I really don't believe that most developers of "desktop sites" care about mobile or do anything to optimize for it, and therefore wouldn't care about a 350ms delay, or even be aware of it. The people who are going to foul this up, it seems to me, are the "mobile web" developers who try to make their sites act like apps instead of just presenting content in a flexible manner.
Re: WebKit removes the 350ms click delay for iOS
#53The 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).
There are plenty of apps that are guilty of this as well. Instagram comes immediately to mind. Not allowing pinch zoom on pictures I'm viewing on a tiny pocket screen (when there's no good technological reason for it) is a shame. I've turned on assistive zooming on my iPhone to overcome the limitation.
Re: WebKit removes the 350ms click delay for iOS
#54Earlier quoted context omitted.
Unscalable != Responsive. One does not preclude the other.
I didn't say it precluded the other, Just that as more sites have a proper mobile view scaling becomes less necessary.
Re: WebKit removes the 350ms click delay for iOS
#55Re: WebKit removes the 350ms click delay for iOS
#56Re: WebKit removes the 350ms click delay for iOS
#57Re: WebKit removes the 350ms click delay for iOS
#58As 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?
Re: WebKit removes the 350ms click delay for iOS
#59Earlier quoted context omitted.
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…
I didn't downvote you, but I also don't agree with your assumptions. First, I don't think that desktop sites are such a big problem on mobile (though some are, admittedly, unusable). At least with a desktop site I can zoom and figure out a way to get to the content I want (in fact iOS does, or used to, to let you double-tap on the content and it would intelligently zoom to fit). Most mobile sites with which I interac…
Re: WebKit removes the 350ms click delay for iOS
#60Earlier quoted context omitted.
An interesting choice would be to retroactively undo the effects of the single click if a second one was detected.
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.