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

101–110 of 144 posts

Re: WebKit removes the 350ms click delay for iOS

#101

Post by jakobegger »

PebblesHD wrote: post #7
nathancahill wrote: post #5

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…

The problem is that some designer whips up a mobile theme, disables scaling, and then an content editor posts some unexpected content that breaks the design, and the readers can't do anything about it.

It gets even worse when designers sell those themes to non-technical people, who have no way to fix the mess the designer caused by disabling scaling/scrolling.

Re: WebKit removes the 350ms click delay for iOS

#102

Post by dredmorbius »

nathancahill wrote: post #63
eru wrote: post #38

Earlier quoted context omitted.

It's a shame. HTML was originally meant to be quite device unaware, and display fine on toasters.

HTML is fine, it's the CSS/JavaScript that's the problem. If we were just displaying HTML we wouldn't be having this discussion.

It's more a matter of how the tools are used, and provisions for client side overrides. Reader mode is a godsend, though the delay on showing the icon and lack of a default option are both capital flaws.

Re: WebKit removes the 350ms click delay for iOS

#103

Post by smcl »

tracker1 wrote: post #89
achairapart wrote: post #51

Earlier quoted context omitted.

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.

I have bumped into this countless times - street names too small, I subconsciously pinch to zoom, street names get scaled accordingly and are still too small for me. The solution is simple - just move the i closer to my face - but it's thrown me a couple times. Not sure if this is a UX error or just me being daft.

Re: WebKit removes the 350ms click delay for iOS

#104

Post by TN1ck »

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?

You can use double-tap zooming with the hand you're holding the smartphone with, im using it more often than pinch to zoom.

Re: WebKit removes the 350ms click delay for iOS

#105

Post by jfoster »

eru wrote: post #64
untog wrote: post #61

Earlier quoted context omitted.

What if it sends an AJAX request? You can't exactly undo them. The browser JS environment is sufficiently complex that "just undo"ing something seems like it would be... complex.

Send GET requests, delay POST. Yes, the whole architecture would need to good undo-support.

At this point it's a good idea to keep in mind the effort/gains ratio. You're proposing massive changes to JavaScript engines in order to have double tapping work a certain way. Changing the gesture or tweaking the delays might yield a less optimal solution, but the effort is so much closer to 0. If you were going to invest the effort you're proposing into something, would improving this delay be the best knowable use of that effort?

Re: WebKit removes the 350ms click delay for iOS

#106

Post by briandear »

xenadu02 wrote: post #82
0x38B wrote: post #35

Earlier quoted context omitted.

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.

Responsive is good, however dictatorial coding isn't. No reason responsive ought not be user friendly as well. The problem is that many devs seem to thing that they know best for their users. However a larger number don't actually understand that their vision of how a web page should operate isn't necessarily how a web page should operate. Too many cooks trying to be chefs. I admit that I don't have an expert grasp on the nuances of great front end either-- that's why I do my best to stay out of the front end as much as possible!

Re: WebKit removes the 350ms click delay for iOS

#107

Post by stevetrewick »

achairapart wrote: post #31
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.

No, you're wrong. The meta tag is a problem. No matter how subjectively 'good' a design is, it should still not be up to the designer to decide to break a fundamental UX paradigm of my device, nor to decide what size of text I should be able to read.

Setting the viewport meta this way is practically the definition of an accessibility micro aggression.

Re: WebKit removes the 350ms click delay for iOS

#108

Post by briandear »

monochromatic wrote: post #8
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 right in principle, but in practice a lot of zoom-disabling websites have text that's smaller than it should be. Apps seem not to have this problem as much.

I agree. I think the issue is that apps are purpose built for a device while web attempts to 'average' the experience across a range. Honestly, I think many designers don't actually preview their pages on real devices either.

Re: WebKit removes the 350ms click delay for iOS

#109

Post by evook »

dredmorbius wrote: post #100
Flow wrote: post #85

Earlier quoted context omitted.

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.

Best answer so far. Print mode is also not bad.

Re: WebKit removes the 350ms click delay for iOS

#110

Post by zelos »

PebblesHD wrote: post #41
jeffehobbs wrote: post #20

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.

Define 'proper' mobile view. How can the designer know how the user is viewing their site? On a cheap device with low contrast? At an awkward angle at arm's length while trying to keep the baby asleep? Trying to read something quickly when you don't have your reading glasses on you?
Post reply on HN