Foundation-sites: Equalizer elements wrong height until page is resized

Created on 3 May 2017  Ā·  18Comments  Ā·  Source: foundation/foundation-sites

Updated to 6.3.1 from 6.2.4 but I am still seeing equalizer elements appearing too high on initial load of page. They contract to the correct height when the page is resized.

This issue seems to be only happening on webkit browsers. Safari on mac is affected but not Chrome & Firefox.

Also, there are no images in the Equalizer panels, just a header and paragraph.

How to reproduce this bug:

Install 6.3.1.
Add 3 columns with header and paragraph content and equalizer markup.
Load page in Safari on mac.
Then resize page to see correct rendering.

What should happen:

Equalizer elements should be equal height.

What happened instead:

Equalizer elements are equal height but almost double the required space with no content in the bottom half. On any page resize the elements reduce in size to appear correctly.

Browser(s) and Device(s) tested on:

Mac OS 10.12.4 - Safari (10.1)
Issue not present in Firefox & Chrome on same mac, but is visible in Espresso (Webkit also)

Can anyone help with this? The issue seems to be going on for some time as I have seen this happening since F5, so someone must have come across it?

Equalizer

Most helpful comment

I'm not using a Mac so I can't really help you understand why it is rendered like this on Safari (probably related to the way fonts are loaded by Safari) but that makes me think of what we call FOUT (Flash Of Unstyled Content).

Back to your issue: this is not Foundation responsibility to handle custom fonts loading but you can try to use something like Font Face Observer to wait for fonts to load and then initialize Foundation:

var font = new FontFaceObserver('YourFontName');

font.load().then(function() {
  $(document).foundation();
});

(I have never used this library so read the documentation if my example doesn't work)

If you want to know more about the way custom fonts are loaded by browsers and FOUT, you may want read this blog post: https://www.paulirish.com/2009/fighting-the-font-face-fout.

I hope it helps!

All 18 comments

Can you reproduce the issue in a CodePen please? You can fork this one.

I have not been able to reproduce the issue in a codepen - here is my example.

But I am seeing the issue in a new test I have created. I am not sure how Codepen renders the pages but I am seeing different results in codepen on Safari as opposed to viewing the page directly in Safari.

Anyway, from my tests I have isolated the issue to the inclusion of webfonts. Once I removed the web fonts from my test it works as expected. But when the content is using webfonts the Equalizer issue is present. I have attached screenshots of the issue I am referring to.

And here are my test links:

Test with Web Fonts (displays issue)

Test without Web Fonts (no issue)

screen shot 2017-05-04 at 11 46 32
screen shot 2017-05-04 at 11 49 42

I'm not using a Mac so I can't really help you understand why it is rendered like this on Safari (probably related to the way fonts are loaded by Safari) but that makes me think of what we call FOUT (Flash Of Unstyled Content).

Back to your issue: this is not Foundation responsibility to handle custom fonts loading but you can try to use something like Font Face Observer to wait for fonts to load and then initialize Foundation:

var font = new FontFaceObserver('YourFontName');

font.load().then(function() {
  $(document).foundation();
});

(I have never used this library so read the documentation if my example doesn't work)

If you want to know more about the way custom fonts are loaded by browsers and FOUT, you may want read this blog post: https://www.paulirish.com/2009/fighting-the-font-face-fout.

I hope it helps!

Closing this with above comment!
Again @Deckluhm to rescue on helping out an issue ... Thanks for all your good work Arnaud!

The FontFaceObserver fix worked great for me, thanks for the suggestion.

Hi all, I need to re-open this issue as I thought it was resolved but no...

The FontFaceObserver fix did work I thought, but there is a problem on devices that do not allow webfonts, as the page never gets initialised and therefore many elements do not work. My client (call centre) have all got IE9 browser with webfonts disabled.

So, I am stuck with not using the FontFaceObserver fix and because if this I get ugly blank spaces in Safari and other webkit browsers on mac which is not good.

This has become an issue since update to 6.3.1.

Did anything change in 6.3 that might have caused this, it was working fine before.

In my test link below, you can see gaps under the slider area and the bad initial rendering of equalizer elements in the content below.

Test Link

I’d really appreciate some help with this as it is beyond me,

Thanks.

cc @kball

@designchief can you clarify what the issue is that you're seeing, or what the outcome you're trying to achieve is? I'm looking at the test link on a few different browsers and not seeing an obvious problem. (See below screenshot on IE9)

dashboard_and_allianz_ireland

@kball - I will try to explain.

I saw an issue with a recent update in Safari, where my layout was rendering with gaps in the layouts on initial load like these screenshots:

screen shot 2017-05-24 at 18 46 14
screen shot 2017-05-24 at 18 46 23

The gaps disappear when you resize the page.
I only get these issues in latest webkit browsers.
I tested a fresh download of Foundation 6.3.1 and it did not exhibit these issues.
I tracked the issue down to when I added my web fonts, thats when the issue occurred.
Thats what lead me to the FontFaceObserver fix, which waits until the webfont is loaded before initialising the page. Although this is not very efficient, it seemed to solve my issues by init after webfont load.

But I then noticed that the site was no longer initialising in IE9 on my client browsers (IE9 with web fonts banned), so this fix was no good for me.

So, the version you see now works fine in IE9 as I have removed FontFaceObserver.

I am now asking for help trying to figure out how to solve the layout issues in latest webkits like Safari on Mac.

This was working fine before update to 6.3.1, so wanted to check if any of the Zurbians mights understand what is happening and how I can fix it in the best way...

Thanks.

Hi all, does anyone know what might be going on here?
I understand the issue only happens with the introduction of webfonts which is not a part of foundation etc, but this was working prior to 6.3.

Thanks

Just experienced the same issue, I've not been able to work out a solution but jumping on issue train

Same issue, increases height when the viewport is increased, when it is decreased the columns do not get smaller in height.

I'd like to help track this down - What would be super helpful is a codepen reproducing the issue. Can any of you put one together by chance @DanielRuf @Seanom @designchief?

I guess the issue is that the set height is not reset / removed and then a new check is done for the maximum height. First remove the fixed height (height:auto?), get the new natural heights and apply them. Did not yet take a look at the sourcecode but I think there is an issue regarding decreasing the height. Will check this later.

I've the same problem.
I solved with https://github.com/liabru/jquery-match-height

Is anyone able to reproduce this in a codepen?

I remember having lots of trouble with this last year (and ultimately using jquery-match-height above instead). But now when I look at the example designchief posted I can't reproduce it in Safari anymore (not in High Sierra nor in El Capitan). Maybe this was a Safari bug that got fixed?

Closing this out as it does not appear to be 100% Foundation specific (and we're trying to clean up some of these older tickets). Feel free to carry on the discussion.

Was this page helpful?
0 / 5 - 0 ratings