WebKit removes the 350ms click delay for iOS • Hacker News Board

Re: WebKit removes the 350ms click delay for iOS

#111

Post by systoll » Thu, Oct 15, 2015, 8:39 AM UTC

somebehemoth wrote: post #50

achairapart wrote: post #44

Earlier quoted context omitted.

> There are plenty of apps that are guilty of this as well. Instagram comes immediately to mind. For native apps it's a design choice. For whatever reason (good or bad) they don't want you to zoom in. For websites instead, pinch to zoom exists for a design deficency, mostly for web pages not optimized for small sized screen. Responsive web design is helping but the gap is not filled yet. Hopefully it's just a matter…

While I agree with what you are saying I have a minor nit: "For websites instead, pinch to zoom exists for a design deficency, mostly for web pages not optimized for small sized screen." I understand what you mean, but in the context of sites specifically disabling zoom it seems to me that pinch to zoom is a design feature and not a deficiency of traditional web pages. Responsive helps, but there are definitely times…

Non-zooming sites can (and should) honour your system-wide font-size setting, giving you the ability to use the system's settings to achieve uniformly comfortable reading experiences across websites and apps.

Zooming doesn't do much to give users much control over the reading experience -- iOS does not let users set or change the viewport size, so everyone gets the same columns to zoom into/out of.

If you want text bigger than the single size the designer decided on, you're forced to scroll along each line of text -- which is a terrible experience.

If you wanted it smaller, zooming out won't 'reflow' the layout, so you'll just be losing screen real estate to peripheral content.

Re: WebKit removes the 350ms click delay for iOS

#112

Post by jedrek » Thu, Oct 15, 2015, 8:41 AM UTC

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.

I hate fixed bars on desktop as well - I still scroll with my keyboard and it chops content off willy nilly.

Re: WebKit removes the 350ms click delay for iOS

#113

Post by Tepix » Thu, Oct 15, 2015, 9:07 AM UTC

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.

Install a content blocker...

Re: WebKit removes the 350ms click delay for iOS

#114

Post by lexicality » Thu, Oct 15, 2015, 9:12 AM UTC

stormbeta wrote: post #87

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.

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

You can't zoom in normal apps.

Re: WebKit removes the 350ms click delay for iOS

#115

Post by nailer » Thu, Oct 15, 2015, 9:17 AM UTC

sesutton wrote: post #22

nailer wrote: post #2

Finally. Typing this on an iOS 9 device and I, as a human, cannot 'fast tap' enough for iOS to register a 'fast tap' and not delay. Try it here: http://output.jsbin.com/xiculayadu

It's a "slow tap" that eliminates the delay. Tap and hold your finger down for a moment. The delay registered with a "slow tap" is about 10 ms for me.

God that's completely unintuitive.

Re: WebKit removes the 350ms click delay for iOS

#116

Post by achairapart » Thu, Oct 15, 2015, 9:17 AM UTC

stevetrewick wrote: post #107

achairapart wrote: post #31

Earlier quoted context omitted.

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.

I mean that if websites where more well designed users won't need to zoom at all most of the time. Not that they must not do it.

Pinch to zoom is a beautiful feature and part of the success of the early iPhone and iOS, and it was there because at the time there was no mobile web design at all.

The fact that so many users still go in panic mode today reveals how mobile web design is far from perfect.

That said, there'd be also legitimate design reasons to use the viewport metatag to disable the zoom. Good designers know the rules and know when they can break them. I don't believe in accessibility dogma.

Re: WebKit removes the 350ms click delay for iOS

#117

Post by creshal » Thu, Oct 15, 2015, 9:39 AM UTC

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.

I dunno, 90s era table layouts weren't exactly flexible either…

Re: WebKit removes the 350ms click delay for iOS

#118

Post by creshal » Thu, Oct 15, 2015, 9:40 AM UTC

achairapart wrote: post #58

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?

I also never understood why you'd double tap on a link or a button.

Fat fingers.

Re: WebKit removes the 350ms click delay for iOS

#119

Post by mattlutze » Thu, Oct 15, 2015, 9:53 AM UTC

0x38B wrote: post #35

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

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.

A solution for this is also bouncing from sites that get it wrong.

Though, being unable to address the site's developers as to why you're leaving makes it a bit of a blackbox-ed gesture.

"Why aren't we keeping mobile traffic?"

"I don't know sir, maybe we need to use more viral headlines?"

Re: WebKit removes the 350ms click delay for iOS

#120

Post by mattlutze » Thu, Oct 15, 2015, 9:58 AM UTC

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 trouble is really with poor or improper application of responsive features to desktop-first sites and applications. The more people try to build responsive sites, the more they'll get it wrong and introduce all sorts of experience errors that can't easily be circumvented on your mobile device.

Same thing happened through the development of desktop browsing though, and it's more or less gotten better (weird fixed scroll elements in nested tables isn't a thing anymore, mostly).

Enough frameworks and abstractions and hosted services will show up and it'll get better. But, it's going to be a problem (if not a growing one) for a while still. Or, convert-to-Reader mode on mobile browsers will get a ton better and people will just get used to wiping out all the uniqueness of the sites they're browsing.

And, as a browser I still want to be able to zoom in on the 70% column the site has or override the weird 10pt font they thought looked modern in order to read it.