Live data from Hacker News

WebKit removes the 350ms click delay for iOS

trac.webkit.org

81–90 of 144 posts

Re: WebKit removes the 350ms click delay for iOS

#81
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.

They probably do it to save bandwidth. Smaller images, smaller size.

Re: WebKit removes the 350ms click delay for iOS

#82
post #35

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

A solution for this is a JS bookmarklet that enables zooming: javascript:document.querySelector('meta%5Bname=viewport%5D').setAttribute('content','width=device-width,initial-scale=1.0,maximum-scale=10.0,user-scalable=1'); I keep this on my bookmarks bar and use it most often to zoom in on text to read it better.

Oh God, thank you. You've restored the mobile web for me. I can't stand the stupid "responsive" design crap. There shouldn't be any way to disable user zooming on mobile. Web developers simply can't be trusted.

Re: WebKit removes the 350ms click delay for iOS

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

I hope the UI team make going back, even if an ad opened a new windows, super easy.

I often accidentally touch the screen while preparing my finger for a scroll or zoom. I see links get highlighted, but if I'm fast to complete what I actually wanted, iOS will understand it was an accidental touch.

No longer it seems. Shame.

Re: WebKit removes the 350ms click delay for iOS

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

this is exactly the reason I sneaked in fastclick[1] at work when noone was looking

[1] https://github.com/ftlabs/fastclick

Re: WebKit removes the 350ms click delay for iOS

#85
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…

This has been my experience too. I surf in landscape mode on an iPhone 5, and far too often there's a fat social-sharing-bar at the bottom, and a fancy site-header-bar at the top, leaving about 1cm of readable and scrollable content. Wtf are they smoking?

A tip: Hold down your finger on the reload circle-arrow to load the desktop version of the page.

Re: WebKit removes the 350ms click delay for iOS

#86
post #39

Earlier quoted context omitted.

Hopefully the intersection of "knows/cares about things like the 350ms tap delay" and "cares about whether the site is too small to read" will be large.

Unless it becomes a bullet point on someone's feature list.

there's allways fastclick

Re: WebKit removes the 350ms click delay for iOS

#87

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.

I couldn't disagree more. There should always be a way to make the content I'm looking at bigger in order to see it more clearly, especially for users with poor eyesight.

"responsive design" does not magically eliminate this need, and I agree with the posters saying that disabling of user-scrolling should never have even been allowed in the first place.

And that's not even touching on the fact that most "responsive" sites I've seen get it horribly wrong.

Re: WebKit removes the 350ms click delay for iOS

#88

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.

Not at all true... I am far sighted, since most of what I look at, including my monitors are more than a few feet away, I tend to see them fine.. my phone is the only device I really have a lot of trouble with. I run in "extra large" font mode, and set my browser zoom to 125%... even then many sites, I have trouble seeing stuff... if there's an image that isn't full width, then I likely can't make out the detail....

Not being able to zoom in to at least 2x, is a pain... if your content doesn't overflow, then sure set the minimum zoom to 1x, and the max to 2 or 3.. but disabling it altogether is just painful to experience... and many of the "suggestions" to fix mobile scaling include disabling zoom. I'm not even that old (40), but I imagine the problem is worse for people well into their 60's.

If you're using a font-size less than 12pt, you should emphatically NOT be disabling scaling... Unfortunately many sites/apps do just that, and often don't respect the usability settings in the OS (facebook on android was particularly bad, as in too small, before I uninstalled it).

Re: WebKit removes the 350ms click delay for iOS

#89

Earlier quoted context omitted.

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.

That would be problematic for apps like maps (which I think the street name fonts are too small, and don't scale), or photo/picture programs.

Re: WebKit removes the 350ms click delay for iOS

#90
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.

Yeah, facebook (when I last used it) didn't even respect the accessability settings in android (for extra large fonts). It's a problem in a lot of applications.. if your app doesn't allow you to increase the fonts to at least 12pt, you're doing it wrong... there's a reason that was the default print size since forever and a day...
Post reply on HN