A couple websites we've developed with Zurb Foundation 4 & 5 exhibit a strange (edge case) behaviour when zoomed out to varying levels on IE11. For example, with one website when zoomed out < 63% on IE11 (window maximised IE11/Win7 running on VMWare Fusion on 1440w screen; mileage may vary so zoom out less than 50% to be more likely to see the behaviour), the main content div moves off center. The threshold at which the block goes off center seems to have some relation with the zoom level vs window width.
Normal Layout:
Exhibiting layout issue on IE11 when zoomed out:
The sites have been tested across a variety of devices and browsers (Chrome, Firefox, Safari, Opera, iOS Safari, Android Chrome, Android FF) and all render properly and zoom out with no problems. It is interesting to note that zooming out to similar levels doesn't break the layout even on IE8.
Is this a strange IE11 bug? I consider it a bit of an edge case because I'd wouldn't imagine many would regularly zoom out to that degree, but it's a bit of a curiosity because it doesn't occur on IE8 and I've only observed it on Foundation 4+ sites.
I took a quick look in IE11 and can duplicate the issue when I zoom out to 50%.
div#contentContainer has max-width set to 62.5rem. Change the value to 100rem and the panel will center-align appropriately to the screen.
You may want to consider switching from a rem value to em.
Related
Problem: The sizing and layout is different from the two browsers and I'm not sure how I can fix this
Note: They are both shown in full screen
In Chrome
In Microsoft Edge
It looks like your Edge browser's zoom is larger than it in Chrome. Please check the zoom in Edge and Chrome and make sure they're both 100%.
I was testing a scrolling element and found some strange differences between mobile (iOS) and desktop browsers. If you load this test website in an iPhone and desktop and inspect the content of the scrolling container I noticed that on iOS the calculated content height of the <p> elements is greater than on desktop.
This seems to be a font rendering related thing as the css of the example site is very minimal. I checked all the relevant css props I could think of (like font-size, line-height, etc) but they all have the same value on both sides.
In the images below <p> elements have a total height of 40px (20px margin + 20px content) on iOS and 38px (20px margin + 18px content) on desktop. This makes the total scrollHeight of the container element to be 4000px on iOS and 3800px on desktop.
I couldn't find any bug related in webkit bug tracker and I don't have at the moment an android device to test or any kind of table, so I could only test on my iPhone vs desktop. This behaviour can be reproduced in any browser.
Things that I tried
Other fonts and still could find differences of more than one pixel
Embed a google font to test if it had to do with native fonts on mobile vs desktop
Instead of 100 paragraphs used only one paragraph but with 100 lines of text
Set -webkit-text-size-adjust prop to none
Used some css resets but the difference persisted
Does anybody have a hint on this?
Desktop Browser
Mobile Browser
I'm quite new to webdev, but I would try using a specific line height for the paragraphs
Safari applies my styles normally on page load for any size. However, it won't apply desktop styles if the window has been sized for mobile since at any point since the last reload.
To most easily see/trigger the behavior, open the site in Safari 13 at desktop size and see the desired layout (most notable here is the navigation bar). Resize the browser down to mobile layout (be sure the navigation switches to hamburger mode), then back up to the desktop layout. (You may also load the site at mobile first, then simply widen the window.)
See test case here: https://www.davincilabs.com/
Normal behavior (as on load):
After browser resize (Safari 13 only):
If you inspect menu elements, you will see that styles-l.css and navigation-desktop.css apply. After resizing up, the style sheets no longer apply.
IMPORTANT: This does not appear to be a JavaScript problem! The behavior still occurs if you disable JavaScript from the develop menu.
To recap:
Found in Safari 13 ONLY. Earlier versions of Safari that we have tested so far do not experience this. Other browsers tested (Chrome, Firefox, Edge) do not experience this.
I have only experienced on desktop. This might affect phones as well but it's impossible to reproduce with my test case; I'm not using any breakpoints small enough.
Initial page load is always correct
Issue triggers when window is enlarged greater than the mobile breakpoint
Safari appears to be no longer applying an entire loaded style sheet file (styles-l.css) to the page layout
Occurs even with JavaScript shut off
This must be fairly rare as I can't find other occurrences after a lot of searching, but it's affecting multiple sites I am working on. Finally, if you cause Safari to reconsider CSS rules in the inspector, (such as by manually editing the parameters of a media query,) Safari will instantly redraw the page correctly.
I had the same problem.
I don't know why but I have this problem just with the store on Magento 2 and with Safari 13. (Also others big e-commerce like The Protein Works, Bulk Powders, sigmabeauty ecc)
I fixed it with macOS Catalina 10.15.7 and Safari 14.
When designing the UI for a web application, what are the things to look out for to ensure the UI doesn't break when someone zooms in or out with their web browser?
Also, how do the different browser zoom types play into this (i.e. I know IE6 zooms differently than Chrome, and I assume mobile browsers are different from that too)?
Most modern web browsers use proper zooming. By this I mean that the page zooms in an out as you'd expect if you were using a lense to zoom in and out.
IE6 and some older versions of Firefox etc use text increasing rather than proper zooming. For those browsers, the unit type you use to size your elements will change how the zoom affects the look of your site.
For example, in IE6, setting widths/heights in px will result in a fixed layout that once zoomed, only changes the size of the text and not the containers themselves. Setting these same elements to use % or em then allows the elements to resize.
With regard to "what do I look out for" I think it depends on what browsers you're wanting to support. My own preference is to develop for modern browsers. If an IE6 user wants to zoom and it breaks the layout then I'm happy to live with that.
I have a web site that has had a fluid layout for years. That is the body's text size is defined and from there all other sizes are relative and are specified in terms of ems. This made the page fully scalable on IE 5.5 upwards, old FF versions etc. Nowadays it isn't really that important anymore since in modern browsers there is page zoom opposed to text zoom. Page zoom works on all browsers for me IE, FF, Opera and zooming in works on Webkit based browsers, too. But zooming out (to less than 100%) breaks the layout and I don't understand why that is.
here is an example page from the page as it stands to try this:
Why does the layout break in Safari (I used 5.0.5 to test) and Chrome when zooming out? In Chrome it works for like two steps of zooming out and then breaks. There is little use to zooming out so this is more of an academic question I guess. I'd like to understand what's happening.
Thanks.
It's might because of some default browser styles that are based on px instead of ems. For example, if you use the webkit inspector in Safari <ol class="navi_rechts"> has a user agent stylesheet that includes -webkit-padding-start: 40px. It might be worth using a CSS reset or checking for things like this on any messed up elements.
EDIT It may also be a rounding issue with some of your values. I'm not sure how many decimal places Safari will look at, but I'm guessing things like padding: 0.46154em 0em 0em 0.92308em; on h1.navi_parent_rechts might be too specific.