For what it's worth, using the viewport meta element to disable zoom is a WCAG AA accessibility violation: http://www.w3.org/TR/mobile-accessibility-mapping/#zoom-magn...

That seems to focus on font size adjustments, which would be unaffected by a meta viewport, no?

"Magnify browser's viewport (typically "pinch-zoom")"

That is exactly what is disabled when authors disable zoom via the meta property.

Right, but it's not what the relevant accessibility standard focuses on. It's the difference between zooming the whole page and making just the text bigger (i.e. through a browser's minimum font size setting), and it's only the former that's affected by meta viewport tags, no?

As some who also has terrible vision -- dedicated text sizing is awesome, but being able to just pinch-zoom makes ALL the difference for me. So many aspects of a web page are hard to use other than just text as well. (Those "X" close icons can get pretty damn hard to decipher at times.)

No solution is perfect, but allowing zooming is simple and a huge win for me. (Even if the site still has a sticky header that wont get out of the way...)

The only legitimate reason I know of: if your site is interpreting touch events directly, and you use pinch-to-zoom yourself; for instance, full-page maps. In that case, it's your responsibility to make all your non-zooming elements (such as the fixed UI overlay on the map) appropriately sized for the device.

This is a little off topic, but if you use Chrome on Android you can disable site's ability to disable zoom.

- Open Chrome (or Chrome Beta) on Android.

- Settings -> Accessibility

- Force enable zoom (check).

Sites may need to be reloaded after applying this setting.

For that matter, you can also set a default text-scaling level as well (mine is at 130%), which I tend to do in addition to force enable zoom. Many sites have fonts that are too small on a phone imho... they really should be at least 12pt for most text assuming that proper scaling meta is set... Too many sites use 9-10pt fonts which are just really hard to read.

I'm far sighted, so my phone is literally the hardest thing for me to use much of the time. One of the worst offenders was the Facebook app, which didn't seem to even follow Android's setting for using larger fonts. I've since stopped using the FB app (way too much battery usage), and just use the mobile site, which isn't much better in terms of usability.

I agree — disabling zooming is frustrating. Have you tried the "Reader" option in Safari? It works well for a lot of websites.

The reader option is awesome when it exists, but there's currently no way to set a site to always enable it. Safari itself makes the determination on a page by page basis. Or at least that used to be the case.

I believe one of the reasons for preventing zoom-in is because it plays havoc with any element that is "fixed" in your browser (ie pretty much every nav bar/fixed header you'll ever encounter).

While we're at it, please also get rid of fixed elements, especially on mobile devices. They obscure parts of the page for limited value, and they often break in horrible ways.

But with more and more mobile web browsers hiding the address bar, how is that person reading over your shoulder going to know what's the name of that awesome site you are viewing?

This is the solution...

Even 'zoom' on fixed elements as dastardly as it looks is easier to read than text that is too small.

If zooming is disabled, the browser can respond to clicks without a 300ms delay since it doesn't have to wait for a double-click zoom. It seems like the best solution to this problem would be to make a global toggle in settings.

Alternately, you can just require multitouch zoom and get rid of the antiquated notion that you can double-click to zoom.

Double tap to zoom is a standard gesture for mobile Safari, hardly antiquated.

That's true, but given that pinch to zoom is nearly ubiquitous, and given that the double tap gesture requires a 300ms lag before responding to single taps, the Web would arguably be better without it.

I can confirm that working around this issue is horrible. That dastardly 300ms makes quick operation of a mobile app a complete pain in the arse. Constantly having to wait for iOS to catch up with you. It really makes the experience horrible.

But that's how iOS want it. If they made webapps that performant then they'd have trouble imprisoning everyone in the App Store.

How? It should just zoom the viewport, there's no reason for any of the DOM elements to even be aware that it's happening. Or has this been implemented in a really stupid way?

I'm not too familiar with it myself, but if I had to hazard a guess it's because setting an element to display:fixed breaks it out into its own root stacking context[0], and browser zoom affects every stacking context[1].

Would love to hear from someone who's actually familiar with what's going on though.

[0] http://updates.html5rocks.com/2012/09/Stacking-Changes-Comin...

[1] https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Under...

Also screws with ad layout and visibility. For sites that are primarily beholden to ad revenue, that can be a dealbreaker.

I just ran into this very problem.

My workaround includes checking the window width with JQuery and changing the fixed status box (originally on the right side of the page) to floating at the top should the width be below a certain margin.

Is this an acceptable solution?

(I am just beginning web dev in lisp)

I think you can get the right result with a media query, assuming those are recomputed on zoom, which they should be.

Thanks, works perfectly. Now I can delete some unnecessary JS :)

That's a reason to set appropriate scale factors, not to prevent zooming entirely.