Hacker News Reader

Comment by Rifu | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com