6 ms·
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/fix
by Rifu 11y ago
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).
- jameshart 11y agoAlso screws with ad layout and visibility. For sites that are primarily beholden to ad revenue, that can be a dealbreaker.
- locokoko 11y agoI 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)
- JoshTriplett 11y agoI think you can get the right result with a media query, assuming those are recomputed on zoom, which they should be.
- locokoko 11y agoThanks, works perfectly. Now I can delete some unnecessary JS :)
- JoshTriplett 11y agoThat's a reason to set appropriate scale factors, not to prevent zooming entirely.
- JoelSutherland 11y agoIf 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.
- amyjess 11y agoAlternately, you can just require multitouch zoom and get rid of the antiquated notion that you can double-click to zoom.
- agos 11y agoDouble tap to zoom is a standard gesture for mobile Safari, hardly antiquated.
- SerpentJoe 11y agoThat'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.
- socceroos 11y agoI 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.
- deleted 11y ago[deleted]
- pjc50 11y agoHow? 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?
- Rifu 11y agoI'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-Coming-to-position-fixed-elements http://updates.html5rocks.com/2012/09/Stacking-Changes-Comin... [1] https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Understanding_z_index/The_stacking_context https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Under...
- jakobegger 11y agoWhile 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.
- leppr 11y agoBut 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?
- cycomachead 11y agoThis is the solution... Even 'zoom' on fixed elements as dastardly as it looks is easier to read than text that is too small.