Yesterday we were taking a live event website through its paces to see if we had everything covered off from a logistics side. The event itself is a 24 hour thing which contains a number of challenges throughout the 24 hours, with each challenge being live streamed. When there is no live stream for the challenge, a countdown timer will appear for the next challenge and visitors will be able to vote on a subtle twist for the upcoming challenge (do we include ice or fire for example).

All of that is nice to know, but kinda useless for the point of this article :)

As we were testing the different stages of the site we noticed that one of the Headings appeared to have a thicker stroke than the other headings.

The heading font used for this is Intro Rust with the idea that it appears rugged (the event is an ourdoorsy type event).

The challenge number didn't appear so rugged though, and the font seemed to be smoothing itself out in comparison to the other headings. The below clip shows the difference between the two headings.

Subtle, but it's certainly there.

After digging into the dev tools I found that the challenge number was missing the following code

-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;

With these lines applied to the heading it made all the difference.

But then it got me thinking, why would I ever want my Font to appear as though it had this issue outside of headings on this specific font? Probably never, and if I did it would be an outlier that I could reset the font to behave differently.

I've now began to include this as part of the CSS (and I'd love to know if there's a reason this is a bad idea).

body {
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}

In my subsequent research this isn't a new technique. David Walsh wrote about this back in 2015 with the exact same code block, and it appears as though frameworks like Zurb's Foundation has had it in their code base for just about as long.

Should I use font smoothing antialiased?

Up until I started writing this post my answer was

Of course you should, it looks better.

Of course, "looks" is subjective and while researching the foundations of this code I've been convinced that it is more of a hack in that it 'fixes' a problem that shouldn't be there.

Stop fixing font smoothing (Dmitry Fadeyev) is a great article that picks apart what happens when you enable antialiasing, but also why we sometimes think it's fixing a problem.

font-smooth has also been removed from the CSS standards and the MDN documents strongly recommend you not to use it on production websites.

It's mainly for dark backgrounds

If you're design is placing text onto a dark background then you have a good reason to look towards using the WebKit and Firefox prefixed font-smoothing options to make the text look lighter, but you should be warned that these only work on Mac and OSX and leaves the billions of other users with a sub-standard view.

What should I do?

I recommend not using it, and instead if you're looking to get a lighter version of the font then use the font-weight to control this so that it appears nicely across both Mac and Windows, and works across all browsers without the need of a browser prefix.

One of the reasons that we end up facing issues where we need to use this as a hack is because traditionally we will design inside of a graphics program like Photoshop.

The design produced from this will have particular font variations applied through the program to get it to look just right and then exported as an image.

That image is then viewed by clients on windows machines — or on occasion on the client's Mac — but because they're viewing an image of a website, and not a rendered website, the fonts will look just as the design wants and not what the browser will provide. It is here, in the browser, that the client will view the final product before signing off the final product.