Live data from Hacker News

WebKit removes the 350ms click delay for iOS

trac.webkit.org

51–60 of 144 posts

Re: WebKit removes the 350ms click delay for iOS

#51

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.

So let's add pinch to zoom to native apps and the whole OS UI by default.

Re: WebKit removes the 350ms click delay for iOS

#52

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…

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 interact, on the other hand, are terrible. Either the text is too small and the page has disabled zooming, or content overflows and doesn't allow me to pan to see it, or some other terribleness. "Responsive" sites are actually some of the worst to interact with on mobile (for me).

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

#53
post #3

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).

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.

Not being able to zoom on Instagram is maybe the #1 most baffling UX decision I've ever encountered. You're a photosharing app but all I can see is a 2" square thumbnail image???

Re: WebKit removes the 350ms click delay for iOS

#54

Earlier 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.

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.

Re: WebKit removes the 350ms click delay for iOS

#58
post #56

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.

Re: WebKit removes the 350ms click delay for iOS

#59
post #52

Earlier 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…

And thats a perfectly reasonable complaint to make, my argument is simply that developers of 'desktop sites' should in fact care about mobile browsers as they make up over 50% of page views on most large properties. If they can't make the effort to accomodate a smaller browser to the point where loss of the zoom function breaks their functionality then I feel that this kick might get them to work out these issues.

Re: WebKit removes the 350ms click delay for iOS

#60
post #40

Earlier 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.

Delay page switches (and other interruptive things) then.
Post reply on HN