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.
Before you leave
I know, "another newsletter pitch" - but hear me out. Most JavaScript newsletters are terrible. When's the last time you actually looked forward to getting one? Even worse, when's the last time you actually read one rather than just skim it?
We wanted to change that, which is why we created Bytes. The goal was to create a JavaScript newsletter that was both educational and entertaining. 101,892 subscribers and an almost 50% weekly open rate later, it looks like we did it.
Delivered to 101,892 developers every Monday

Sdu
@sduduzo_g
This is the first ever newsletter that I open a music playlist for and maximize my browser window just to read it in peace. Kudos to @uidotdev for great weekly content.

Brandon Bayer
@flybayer
The Bytes newsletter is a work of art! It's the only dev newsletter I'm subscribed too. They somehow take semi boring stuff and infuse it with just the right amount of comedy to make you chuckle.

John Hawley
@johnhawly
Bytes has been my favorite newsletter since its inception. It's my favorite thing I look forward to on Mondays. Goes great with a hot cup of coffee!

Garrett Green
@garrettgreen
I subscribe to A LOT of dev (especially JS/TS/Node) newsletters and Bytes by @uidotdev is always such a welcomed, enjoyable change of pace to most (funny, lighthearted, etc) but still comprehensive/useful.

Muhammad
@mhashim6_
Literally the only newsletter I’m waiting for every week.

Grayson Hicks
@graysonhicks
Bytes is the developer newsletter I most look forward to each week. Great balance of content and context! Thanks @uidotdev.

Mitchell Wright
@mitchellbwright
I know I've said it before, but @tylermcginnis doesn't miss with the Bytes email. If you're a developer, you really need to subscribe

Ali Spittel
@aspittel
Can I just say that I giggle every time I get the @uidotdev email each week? You should definitely subscribe.

Chris Finn
@thefinnomenon
Every JavaScript programmer should be subscribed to the newsletter from @uidotdev. Not only do they manage to succinctly cover the hot news in the JavaScript world for the week but it they manage to add a refreshing humor to it all.