I upgraded the version of Sass on my computer to 3.4.5. I thought this was a mistake, but the mistake was mine.

I was trying to get the Font Awesome project to build. I wasn’t having a whole lot of luck (read: none), so I updated the bundled version in my WordPress theme (which desperately, desperately needs a better name than “Cover,” but that’s a post for a different day).

Fun fact: when I started building my theme — long before I started experimenting with preprocessors like Sass or Less — I was just loading the Font Awesome stylesheet separately. Now, though, I’ve bundled the Sass version into my compiled stylesheet. It’s one less resource to load. :)

So I had downloaded the latest version of Font Awesome, and in my efforts to get the project itself to build, I ran this in my command line:

$ gem update

This updated all the Ruby gems I have installed, which included Sass. So I went from version 3.3.8 to 3.4.5. Now, there is some code in my WordPress theme that depends on a feature available in 3.3 — @each multiple assignment — but I really have had no need of an update since.

I thought nothing of it, and deployed my latest stylesheet and fonts out to my website. I clicked the hamburger icon to make sure the icons still worked. I expected no surprises, but what I saw instead was this:

whoops
Surprise! Your font is broken.

Upon inspecting the font elements, I discovered this:

.overlay .social-navigation .menu a[href*='github']:before {
content: "";
}

Prior to updating Sass to version 3.4.5, this was the output:

.overlay .social-navigation .menu a[href*='github']:before {
content: "\f09b";
}

So it would seem that it was an encoding issue. A quick Google search revealed this issue in the Sass project on Github, where other people seemed to have the same problem.

The problem was, I thought the encoding difference was throwing off the font. But as this gist in SassMeister proves, the conversion from ASCII to UTF-8 was not causing a broken font.

So I did a little more digging.

Then I noticed that Font Awesome’s _variables.scss include sets the directory path to the fonts:

$fa-font-path: "../fonts" !default;

Do you see what that’s doing? It’s telling the stylesheet (which, for me, is located at the theme’s root) to go up a level in order to search for the /fonts directory. At that location, it would never find it. So I changed the path to this:

$fa-font-path: "fonts" !default;

Now it’s telling the stylesheet to look for a /fonts directory at the same level as the stylesheet itself. And voila, the font works again.

mlfw2608_medium
Sigh.
Husband. Daddy. Programmer. Artist. I'm not an expert, I just play one in real life.

Responses

  1. Are you sure there wasn’t something else you did in combination to changing your fonts directory path that may have fixed this? Are you getting the @charset “UTF-8” added to the top of your stylesheet? I was really hoping you had the fix, but unfortunately I’m still having issues after upgrading to Sass v3.4.12.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.