Vertical space issue between Chrome & Mozilla

[Linda_A]

I’ve been working for some time to implement a responsive design on my two sites. One lingering issue is a display difference between Chrome and Mozilla in terms of vertical space.

It is seen most clearly at http://www.hippoiathanatoi.com/ where, for example, the expected space between the top bar and the content area disappears and where the title in the topbar is pushed too far up.

I added the css and layout html to a code pen as well:

http://codepen.io/Linda_A/pen/OWOyZy

[Shikkediel]

Very strange, it’s the margin on the parent div that contains the h1 text that doesn’t get implemented. But only when the value is a percentage… if you change it to any other unit (pixels for example), it will have the expected effect. Looks like a Firefox bug to me – one that is related to flexbox and only affects top and bottom margin.

[Linda_A]

The #Wrapper, you mean? I am trying to see which percentage unit you mean.

A bug doesn’t sound like good news, either way.

[Shikkediel]

I was aiming at this direct parent:

<div class="col span_4_of_8">

And the relevant style (on line 170 of this file):

.col {
display: block;
float:left;
margin: 1% 0 1% 2%;
}

Only the last percentage there is working… and I don’t think there’s much you can do but change the value to 1vw for example which will be pretty much the same. Or anything else, as long as it’s not a percentage.

Another option would be to remove the flex values from the element below. Doesn’t look like they’re really needed here?

<div class="section group header">

[Beverleyh]

Yes – vertical margins expressed as percentages on flex items should be avoided. It’s part of the specs – more info here http://stackoverflow.com/a/23754080

[Shikkediel]

Ah, that makes it a Chrome quirk rather than a Firefox bug. :-D

[Linda_A]

Alright, thanks, will need to test and see what is best. I can’t remove the flex because the header will use it once everything’s finished, so I will have to see if switching the units will work out alright.

Thanks for explaining. :)

[Beverleyh]

Try switching from % to vw instead. It should work the same at small widths, when the parent container is 100% the width of the viewport. The difference is at wider widths when you’ve capped the layout – a % won’t get any bigger past a certain point because it’s based on the (capped) container width, but vw will continue to grow along with the browser window, regardless of any max-width cap on the container. The way to stop that is to switch in a fixed unit (em or whatever) with a media query once you hit the desired breakpoint. Hope that makes sense.

[Linda_A]

Thank you, will give that a try. I am quite new to attempting a responsive design, so I am not entirely sure I see how to make everything work right once I switch to a fixed unit.

Is it only the the vertical units that will be an issue, or the horizontal as well?

[Beverleyh]

Afterthought: I’m on mobile so please excuse the lack of CodePen demo, but I hit the same problem on this page here http://fofwebdesign.co.uk/template/_testing/filter/filter-multi-js.htm

If you view the source and look for the .filter-item CSS, you’ll notice the margin initially set as margin:0.75vw 0.75%; but at the min-width:64em media query, it changes to margin:0.5em 0.75%;

[Beverleyh]

And yes, only the vertical % margins are affected – the horizontal % ones work fine :)

[Linda_A]

Following up on this belatedly. As far as I can tell, switching out just the vertical % margins for vw margins seems to have done the trick. And unless I misunderstand, this should not require me to add a breakpoint where I change to a fixed unit, since it is height and not width?

[Beverleyh]

Using vw for vertical margin here is the closest to % because both will be calculated relative to the container width (important – horizontal and vertical padding/margin, when expressed as %, are both based on the width, not height, of containers). The main difference is that % is calculated and capped at the width of the immediate parent, whereas vw is calculated on screen width. It will therefore keep getting bigger and bigger along with whatever oversized monitor a potential user could be using (which you have no way of controlling or predicting) so you will need to cap it at an appropriate breakpoint or risk massive vertical margins.

[Linda_A]

Ah, hrm, didn’t realize that it is always the width that the % or vw is calculated from. That would of course make a difference. But I am still finding this a little hard to wrap my head around, so I am not sure how to figure out what an appropriate breakpoint would be (or what the appropriate fixed size would be, for that matter).

[Beverleyh]

You’d choose/set your breakpoint when the vertical vw margins start getting disproportionately large. You can do this just by eyeballing the page while you drag the browser window outwards. This is where your set your breakpoint for switching to a fixed (px?) vertical margin – again, by eyeballing. It might take a few trys but you should be able to get an almost seamless change that won’t keep on growing.

[Author]

Posts