WebKit removes the 350ms click delay for iOS
trac.webkit.org
trac.webkit.org
EDIT: If you don't agree why not explain your point instead of randomly downvoting. I believe this change is overall a good thing as it means designers and developers can stop using nasty hacks to get around the delay as they have been doing. Hopefully it will also mean more developers make the effort to make their sites work on mobile instead of the half efforts that seem to be common now.
Those "mobile special" layouts are annoying enough on their own on a phone (with their dumbing down of the UI), but they are doubly annoying when you're used to the web version of a website, and have to hunt for things in the "responsive" mobile version.
"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.
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).
I really don't believe that most developers of "desktop sites" care about mobile or do anything to optimize for it, and therefore wouldn't care about a 350ms delay, or even be aware of it. The people who are going to foul this up, it seems to me, are the "mobile web" developers who try to make their sites act like apps instead of just presenting content in a flexible manner.
A tip: Hold down your finger on the reload circle-arrow to load the desktop version of the page.
Fuck fixed headers / footers. Fuck social. And fuck fixed social header/footer bars specifically.
I'll sooner copy/paste text into a vim buffer.
If you're naming your primary elements, or ascribing them values of "share" or "social" (wildcard search), they're likely to get nuked.
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.
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.
javascript:document.querySelector('meta%5Bname=viewport%5D').setAttribute('content','width=device-width,initial-scale=1.0,maximum-scale=10.0,user-scalable=1');
I'll disagree. Responsive is a cop-out -- reminds me of the "mobile" versions of websites. Give me the full version, and stop messing with the layout and experience between the web and the phone.
Also, responsive design does not mean disabling zoom at all.
I've never found that to be the case. Or if I did, it was far less often than being annoyed with the lacking, scaled down, "horizontally enhanced" mobile layout.
In portrait mode the text is way too small to read and zooming in results in text that goes over the edge. In horizontal mode the experience is a bit better but one still needs good eyes to read the comments. Luckily there are enough applications that mitigate the problem.
Small font size makes it faster to scroll past long threads.
As more and more browsing happens on mobile, that should be the new default.
- Apple, at iPhone release
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?"
<meta content="width=device-width, initial-scale=1.0" name="viewport">
instead, they're giving fastclick [1] a reason to live on to polyfill a single, non-conforming vendor :(
* 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.
I've turned on assistive zooming on my iPhone to overcome the limitation.
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 of time and we'll experience beautiful mobile websites.
For all other needs, there is OS assistive zoom.
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 when I wish the developers would provide only a desktop view so I can use my browser features to optimize my own user experience. (I am not representative of the general public, I know).
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.
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 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 viewport that does not allow pinch to zoom. Both of these seem like fine options to me, and I don't think it's a huge loss to lose the middle ground.
For example wikipedia (used to?) disable zoom while making all their pictures small. But what if the picture has the information you want to see?
This is because a lot of content on the internet is long form reading with pictures, and ideally you'd want the middle ground, responsive quick scrolling with the ability to zoom on pictures, infographics, etc. and then zoom out again to carry on reading.
And before you say it, all picture viewers on mobile suck. We already have an amazing, built in solution.
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 that crosses over from desktop to mobile. When you add disabled scaling on top of that, many things break, like content being too wide or font sizes being too small.
Setting the viewport meta this way is practically the definition of an accessibility micro aggression.
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.
If you have an area you want to be scalable, you'll have to implement it in JavaScript or use a pre-made component.
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.
There is far more than simply relying on a "click" in touchscreens. For example the "touchclick" event is for those times when the keyboard disappears because focus has been lost in a textbox, but the click will still succeed: https://github.com/Qbix/Platform/blob/master/platform/plugin...
Also, drag-drop is broken in touchscreens WebKit so you have to roll your own, and much more.
You're better off using a library.
I'm not trying to attack or being negative here... just a bit surprised.
If a 350ms click delay is actually a performance bottleneck on the app you are building, it's very likely user scaling is something you want disabled anyway.
The underlying issues are that
(a) it is hard to make touchstart/touchend act the same as a native click event (touch-scroll interactions, different fat finger slippage, text selection, press duration, etc).
(b) you only want to do this for iOS and not any other browser (different browsers and OSes and pointing devices introduce a huge number of other issues: cant prevent the click on the touchend, mouse or pen support is difficult, avoiding ghost taps https://www.google.com/#q=ghost+click+tap ).
(c) you run into future compatibility problems (pen, force-clicks, other HIDs).
(Yes, there's accessibility zoom, but I didn't know about that until this thread)
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
If I'm looking at a site that presents a massive image scaled to my display, the browser zoom will add more information as you zoom in. The 3-finger zoom will make the existing pixels larger.
Most of the time this difference isn't an issue, but it is a difference.
Yes, the whole architecture would need to good undo-support.
In any case, once you start delaying things you ruin the original point of getting rid of the click delay - to make things faster!
However, in order to implement this, when you do a single tap, the browser has to wait to make sure that you don't do a double-tap. So there's a 350ms delay while it's waiting on your second tap, before delivering a single-tap event, e.g. to click on a link.
There's a meta tag you can use to disable user control of the zoom level, e.g. with pinch-to-zoom. One of the things that this disables is the double-tap behavior. Given that double-tap is disabled on those websites, there's no need to sit around waiting for a second tap; you can treat it as a single tap immediately. This change removes the delay.
(People are upset because this is an incentive to use that meta tag if you otherwise wouldn't need it, and being able to zoom on a mobile browser is useful.)