Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebKit removes the 350ms click delay for iOS

trac.webkit.org

Post reply on HN
Print view View original

31–40 of 144 posts

Re: WebKit removes the 350ms click delay for iOS

#31

Post by achairapart »

untog wrote: post #6

While I do symapthise with those lamenting the lack of pinch-to-zoom, I'm confused: apps don't offer pinch to zoom, so how do you use them? If you can use an app fine without pinch to zoom, you should really be able to use a mobile website fine too. It seems to me that this is an either/or proposition: either you have a not-mobile, pinch-to-zoom-able web site, or you have a mobile-specific site with an app-like viewp…

Reading all the answers here and to me it seems that the problem is not the metatag nor the fastclick, but just poorly designed responsive websites.

Re: WebKit removes the 350ms click delay for iOS

#32

Post by [deleted] »

leeoniya wrote: post #25
ksenzee wrote: 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).

why would they not follow what browsers already do and solely rely on: this is basically a solved problem with pretty much all other vendors having already converged. instead, they're giving fastclick [1] a reason to live on to polyfill a single, non-conforming vendor :( [1] https://github.com/ftlabs/fastclick

[deleted]

Re: WebKit removes the 350ms click delay for iOS

#34

Post by nevir »

leeoniya wrote: post #25
ksenzee wrote: 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).

why would they not follow what browsers already do and solely rely on: this is basically a solved problem with pretty much all other vendors having already converged. instead, they're giving fastclick [1] a reason to live on to polyfill a single, non-conforming vendor :( [1] https://github.com/ftlabs/fastclick

Each browser tackles it in a different way (see https://github.com/ftlabs/fastclick#when-it-isnt-needed):

* Chrome checks the viewport meta, as you mention

* IE looks for CSS (touch-action: manipulation) on elements

The change being made to WebKit will allow it to honor the viewport meta approach (e.g. when it disables scaling), just like Chrome does. So, if anything, IE is the odd one out now.

Re: WebKit removes the 350ms click delay for iOS

#35

Post by 0x38B »

nathancahill wrote: post #5
ksenzee wrote: 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).

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.

Re: WebKit removes the 350ms click delay for iOS

#36

Post by themartorana »

ksenzee wrote: 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.

Re: WebKit removes the 350ms click delay for iOS

#38

Post by eru »

nathancahill wrote: post #12
untog wrote: post #6

While I do symapthise with those lamenting the lack of pinch-to-zoom, I'm confused: apps don't offer pinch to zoom, so how do you use them? If you can use an app fine without pinch to zoom, you should really be able to use a mobile website fine too. It seems to me that this is an either/or proposition: either you have a not-mobile, pinch-to-zoom-able web site, or you have a mobile-specific site with an app-like viewp…

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.

Re: WebKit removes the 350ms click delay for iOS

#39

Post by eru »

glhaynes wrote: post #24
jordanlev wrote: post #4

Ugh... This change is of course totally logical in isolation, but I fear that this will motivate designers and developers to disable pinch-zooming on their sites (more than they already are). I hate when websites do this, and it is generally considered terrible for accessibility.

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.

Re: WebKit removes the 350ms click delay for iOS

#40

Post by eru »

nevir wrote: post #28
dkonofalski wrote: post #11

What's the intended function of the previous functionality? Didn't double-tapping zoom in and out to a specific section? What problem does the delay solve that isn't present on unscalable viewports?

The delay allows webkit to detect a double tap. Otherwise, any element with a click handler would immediately fire, effectively disabling double tapping for their region.

An interesting choice would be to retroactively undo the effects of the single click if a second one was detected.
Post reply on HN