I came cross a CSS bug in Safari today that seems to be more common than I expected. This article is a writeup of the issue I faced and the current possible work-around(s).

The bug

Jan Persiel—who I’m currently collaborating on a client project with—reported that the type scale we have set up in our pattern library was not working the way it is supposed to. More specifically, in Safari on macOS, the fluid text wasn’t really fluid—resizing the viewport did nothing to the font size, even though the latter is supposed to respond to the change in viewport width.

I am using a fluid typography system and scale that I’ve been using for almost two years with no issues to be mentioned. Instead of writing it from scratch like I did for Prismic’s Slice Machine in 2019, I generated the CSS code for the type scale using the excellent Utopia generator. So I was perplexed at first, unsure what was happening.

Following is a Codepen including a reduced test case. Open this demo in Safari and try resizing the browser to see the text not respond to the viewport width changes.

Unsure what was causing the buggy behavior, I started double-checking my own code at first, making sure no weird syntax issues were in the CSS file. I kept checking and tweaking stuff, but nothing worked. So I started googling.

I came across this article on CSS-Tricks from 2017 about creating fluid typography using Mike Riethmuller’s responsive type formula (which I believe is the base of all fluid typography formulas we know today).

Reading through the comments I found Mike’s comment in which he noted that there’s a bug in some versions of Safari (and IE11) that means it won’t be calculated on resize. Similarly, Chris had also mentioned the same buggy behavior in another article from 2012 (!) (emphasis mine):

When the browser window is resized, the font doesn’t adjust itself according to the new viewport size. […] Perhaps not a huge disaster as it’s pretty much just us design nerds that go around adjusting browser windows, but still. The font does adjust on a fresh page load.

Indeed, refreshing the page on different viewport sizes would render the text in the font size intended for that viewport size. But that was not enough. It was clearly a bug, one that has been reported and supposedly fixed.

The workaround

Responses to the comment on the first CSS-Tricks article included a few “fixes” to work around the buggy behavior in Safari. And Chris also mentions in his other article that causing a repaint on the element (using jQuery in his article) would help “fix” the issue.

I tried all of the workarounds mentioned. The only one that worked for me was the “font-size: 1vw on the parent hack”. I set the font size to 1vw on the root element. That did make the text size respond to viewport size changes, but it had a clear and obvious side effect on the size of the text across the pattern library.

What I ended up doing is setting min-height: 1vw on the body element, which should be enough to cause a repaint but have no side effects on the remaining styles whatsoever:

body {
    min-height: 1vw;
}

A better workaround targeting Safari only

Unsurprisingly, I’m not the only one who has come across this buggy behavior. Folks on Twitter responded to my tweet reporting that they have had the same issue with their responsive type scales in Safari.

Among the replies to my tweet, Martin Auswöger suggested a smarter way to “fix” Safari’s bug using the (currently Webkit-only) -webkit-marquee-increment property. By setting the property to any value using vw as a unit, the text would scale again on resize. Martin was kind enough to create a reduced test case that I included in the bug report I filed. Here is the demo including Martin’s fix:

See the Pen Reduced test case + workaround for Safari's fluid typography bug by Sara Soueidan (@SaraSoueidan) on CodePen.