Hacker News Reader

Comment by jordanlev | Hacker News Reader

Looks really awesome!

One piece of feedback I have is that I don't think it's wise to put "maximum-scale=1" in the viewport meta-tag because it makes pages hard to read for people with less-than-perfect vision (because it prevents zooming in on phones). I created a github issue about this too: https://github.com/dhg/Skeleton/issues/173

Is there an actual benefit to having this on web pages? I see it a lot (unfortunately -- makes it very difficult when I'm on my iphone sometimes), and am not sure why people do this. Is it just "common wisdom" that has been copy-and-pasted down through the ages without anyone questioning it, or does it provide some benefit that outweighs the (pretty big) drawback of reduced accessibility?

Thanks!

View on HN

Is there an actual benefit to having this on web pages? I see it a lot (unfortunately -- makes it very difficult when I'm on my iphone sometimes), and am not sure why people do this.

There’s more than that specific viewport option, but often this kind of technique is an attempt to defeat mobile browsers that rescale your site when you rotate between portrait and landscape orientations.

If the site is designed to adapt gracefully to different screens using media queries, then what you probably want instead is for the browser to just reflow the layout according to the new page width.

In practice, many sites don’t adapt using media queries, and so popular mobile browsers may adjust the zoom level instead. That means whatever you could see horizontally before the orientation change is still what you can see afterwards but bigger/smaller.

One way to force the adaptive behaviour is to use the viewport settings so the zooming isn’t allowed. However, that also interferes with deliberate zooming by the user. Sometimes you see all kinds of complicated workarounds for that, such as detecting an orientation change and temporarily blocking zooming, or detecting an attempt to zoom and then disabling the restriction temporarily so if the user repeatedly tries to pinch-zoom then subsequent ones work. Sadly, a lot of developers just copy-paste the viewport hack without realising the full implications, and that is when we see problems for users who really do want to zoom in.

None of this is ideal, but as far as I know we still don’t have a reliable, standardised way for sites to specify how orientation change should be treated for best results, so for now viewport hackery seems to be the best known workaround.

Ah, thanks for the explanation. I do vaguely recall hearing about this issue a while back, but never grokked the details. I find it interesting that people would prefer to disable zooming just to avoid wonkiness on orientation changes -- seems like a way less important issue. But hey, design is all about making choices, so I can understand how other people might weight those issues differently than I do.

A followup question: you say that "In practice, many sites don’t adapt using media queries, and so popular mobile browsers may adjust the zoom level instead." ... does this imply that the orientation change issue isn't a problem if you use media queries properly? If that's the case, then the maximum-scale=1 seems like a moot point (because if you're adding a meta viewport tag to your markup, you're already thinking about responsive design, right?). Or am I misunderstanding what you said?

... does this imply that the orientation change issue isn't a problem if you use media queries properly?

I wouldn’t quite say that. It’s more that whatever effort you put into using media queries to adapt your site somewhat intelligently for visitors with different devices is wasted if those devices ignore your media queries and just naïvely scale everything instead.

For example, one site I work on has a single-column layout that works reasonably well on smartphone-size devices. It also looks OK on a typical tablet in portrait orientation, but there it wastes significant screen space, because it increases the horizontal margins rather than letting text lines run very long. If that tablet is rotated to landscape orientation, we have enough space to switch into a two-column layout, which happens to fit the structure and content we’re showing. This lets us fit more of the content onto the screen than the single-column layout, because we don’t waste that extra space at the horizontal margins any more.

This is all good stuff, and from time to time we get favourable comments from visitors who were pleasantly surprised that the site adapted. However, without some of the trickery we do with viewports, what would happen instead (at least on some devices) is that rotating portrait to landscape would wind up showing a zoomed-in version of our single-column layout, while rotating landscape to portrait would zoom out to fit our two-column layout with much smaller text than intended, or some variation on those ideas depending on the specific device/OS/browser.

The catch with all of this is that for various reasons people might genuinely want to zoom in on our site. Maybe their eyesight isn’t great and they just want the text bigger for comfortable reading. Maybe they want to zoom in on some of the graphics or videos we show for similar reasons. So we don’t want to block intentional zooming by the user, just the browser’s “borrowing” of that feature to second-guess our carefully adaptive design.

Thus today we wind up employing the sort of workarounds I mentioned before. What I’d like to do, though, is just to define the sensible layouts for the site using media queries, and then have browsers automatically fit the most appropriate layout based on the orientation and user-selected zoom level on each visitor’s device.

Thank you so much for the detailed explanation. Makes sense, and gives me a much better understanding of the trade-offs. Cheers!

For people using Chrome on Android phones you can force enable zoom by going into settings -> accessibility -> force enable zoom.

Maybe there is something similar on iphones?

It seems many people have trouble with this, and even though I have normal eyesight I can get annoyed when the site prevents me from zooming. It does make things easier when developing "native feeling UI" though.

It removes the 300ms delay while the browser waits for a double-tap (to make sure you really meant to click on that link and not zoom in), which is supposed to be a huge UX improvement.

Note that Android no longer applies the 300ms delay regardless of viewport scalability.

http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-a...

There are a number of plugins to remove the 300ms delay from other touch browsers. Here's one: https://github.com/ftlabs/fastclick

Fascinating... I never heard about this side-effect of disabling zoom! I did some googling and from what I can tell, this only applies to some Android browsers, not iOS?

If that's the case, it seems like throwing out the baby with the bathwater, since it does have the accessibility issue and removing the delay can be better-achieved on ALL devices with some of the JS libraries that others have linked to.

Here's a blog post I found that talks about the limitations of this "avoid touch delay by disabling zoom" technique: http://timkadlec.com/2013/11/Avoiding-the-300ms-click-delay-...

I can see your point, but want to add why I recently started to add this meta-tag on most of my responsive sites: 1. images start to look blurry 2. input fields change the scale of the page and seem to confuse some users (at least in some test-cases). On the other hand I try to improve accessability by making sites screen-reader-friendly and using high contrasts. I have also seen a lot of people using "bigger fonts" options in their browsers or on their phones, which solves this problem from my point of view.

I read a lot on my phone and I don't have great eyesight. If I cannot zoom the website I'm looking at, I often cannot read it.

I honestly hadn't considered this case. Let me dig into it and see if I can find a solution that works best all around.

Awesome, thanks!

An option to increase text size in the interface is probably going to be even better than allowing zoom, since it will reflow the text and not require the user to scan left and right around the zoomed-in text.

Of course, this is how our browsers used to work before the makers decided to remove or hide that feature. I've never seen it on a mobile device. Does anyone understand the reasons behind that move? Even if you think page zoom is 'better' than text scale, surely it doesn't make sense to disable the latter altogether?

>Sometimes you see all kinds of complicated workarounds for that, such as detecting an orientation change and temporarily blocking zooming, or detecting an attempt to zoom and then disabling the restriction temporarily so if the user repeatedly tries to pinch-zoom then subsequent ones work.

Chris_Newton's comment seems to have possible workarounds that can fix this issue. I'll trust your decision whatever you go with though, and thanks for Skeleton!

I've struggled with these issues before, and have tried then backed away from the same maximum-size solution.

Fortunately, #2 can be resolved easily by setting input,textarea{font-size:16px}. There are problems with 16px for all inputs (especially if using a custom font with different metrics than the default), but it preserves a significant usability feature. A fair trade, even if it means using system default inside of inputs.

Regarding blurry images, I favor suboptimal delivery of content over failure to deliver every time.

Great work on the framework, keep it up!

I created an account just so I could say that as a legally blind person, I cannot use some websites without being able to zoom in. It is extremely frustrating when I encounter a site that has disabled zoom. Please don't do it!

Thanks for opening the issue. Gonna dive into those very soon. appreciate you taking the time to add it to the list :)

Thank you for considering this. Skeleton is a great framework and I know a lot of people use it as a boilerplate. Regardless of your ultimate decision, I really do appreciate you looking into it.

Reply on news.ycombinator.com