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

91–100 of 144 posts

Re: WebKit removes the 350ms click delay for iOS

#91

Post by tracker1 »

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…

Some apps are problematic, and many don't follow the accessability settings for font size, as an example... the facebook app on android is all but impossible for me to read (far sighted). Some devices don't set their dpi correctly, and are even worse since the default settings make things way too small.

If you can't display close to 12pt text in your app at least as a visability option, then there are probably quite a few people that can't use your app... lower than 10pt is almost inexcusable imho.

Re: WebKit removes the 350ms click delay for iOS

#92

Post by tracker1 »

AlphaSite wrote: post #30
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…

Apps also support a lot more in the way of accessibility features, e.g. Dynamically resizable text.

Tell that to the guys behind the facebook app for android.. they don't respect the accessibility feature at all, and their text is too damned tiny... (haven't used it in nearly two years, since they started pushing messenger as a separate app, I don't need two battery zapping apps running all the time).

Re: WebKit removes the 350ms click delay for iOS

#93

Post by stephenr »

paulvs wrote: 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?

Double-tap zoom is meant to be "smart" about what it zooms to, automatically. So if you're looking at a page with multiple regions and double tap one of them it will try to zoom to show you that region. I use this far more than pinch-to-zoom.

Re: WebKit removes the 350ms click delay for iOS

#94

Post by tracker1 »

zkhalique wrote: post #65

In our framework, we have for a very long time had a Q.Pointer class which contained functionality to normalize things between touchscreens and non-touchscreens. Among other things, it had the "fastclick" event: https://github.com/Qbix/Platform/blob/master/platform/plugin... There is far more than simply relying on a "click" in touchscreens. For example the "touchclick" event is for those times when the keyboard disa…

Cool.. as a side note... 10k lines in that file, is it maintained like that? I know modularizing and things like browserify have an overhead, it just seems excessively large for a single source file (was scrolling up to the top, so that I could star the project to look at later).

I'm not trying to attack or being negative here... just a bit surprised.

Re: WebKit removes the 350ms click delay for iOS

#95

Post by dredmorbius »

Sophistifunk wrote: post #47
PebblesHD wrote: post #41

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.

Working with a visually disabled colleague recently iI'm becoming all to painfully aware of how much this is the exception. For Web, apps, OS, devices, and more.

Re: WebKit removes the 350ms click delay for iOS

#96

Post by jakobegger »

Flow wrote: post #85
glesica wrote: post #52

Earlier quoted context omitted.

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.

Thanks for that tip!

Re: WebKit removes the 350ms click delay for iOS

#97

Post by dredmorbius »

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…

Mobile now covers a wide range of scales.

Re: WebKit removes the 350ms click delay for iOS

#98

Post by eridius »

Flow wrote: post #83
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).

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.

It's already super easy to go back. Just do an edge-swipe from the left, like you would in a normal navigation stack in most apps. And you can edge-swipe from the right to go forwards.

Re: WebKit removes the 350ms click delay for iOS

#99

Post by ori_b »

jakejake wrote: post #46
ori_b wrote: post #42

Earlier quoted context omitted.

Many apps do have pinch to zoom on viewports. Just about any app that displays pictures, for example, or any app that displays large amounts of text.

That's true but those are scalable components within the app specifically designed to be scalable. You're not scaling the entire app window. If you have an area you want to be scalable, you'll have to implement it in JavaScript or use a pre-made component.

I actually find myself wishing I could scale whole apps on mobile sometimes.

Re: WebKit removes the 350ms click delay for iOS

#100

Post by dredmorbius »

Flow wrote: post #85
glesica wrote: post #52

Earlier quoted context omitted.

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.

Reader mode FTFW.

Fuck fixed headers / footers. Fuck social. And fuck fixed social header/footer bars specifically.

Post reply on HN