Marcin Wichary has a fantastic series of posts documenting Medium’s commitment to beautiful web typography. Apart from being intrigued about some of the little tricks they use to enforce better typing habits, like disallowing users from entering two spaces in a row, I was also interested to read the technical supplement for designers and developers. It reminded me of a few things I’ve been meaning to add to my main theme and introduced several things I hadn’t really thought about.
Sass Font Stacker is a small library of web-safe font stacks bundled with some utility functions and a simple mixin to make
font-family declarations a breeze. The syntax is similar to what you’d be writing anyway. For example:
@include k-font-family("Open Sans", helvetica);
This will output:
font-family: "Open Sans", "Helvetica Neue", Helvetica, Arial, "Nimbus Sans L", "Liberation Sans", Arimo, sans-serif;
The mixin (and related utility function
k-font-stack() accepts an arbitrary list of fonts but requires the last (or only) argument to match one of the pre-defined font stacks. This way you can specify naming variations or even entirely different fonts at the head of a custom font stack.
I won’t list all the font stacks included in this project (as this information is likely to change) but will cite a few of the more commonly used fonts in web design:
- Andale Mono
- Book Antiqua
- Century Gothic
- Helvetica Neue Light
- Hoefler Text
- Lucida Grande
- Times New Roman
- Trebuchet MS
Crafting web-safe font stacks is more an art than a science these days. Usage data is neither current nor of a sufficient quality to make anything better than an educated guess in my estimation. But hey, a good guess is better than nothing—and the use of a Sass library allows for those good guesses to be formalized and consistent across projects. If anyone out there has expect knowledge to contribute please consider opening an issue or sending a pull request. Here’s that GitHub link again: Sass Font Stacker.
Dashicons is an icon font designed for use on the WordPress admin panel. You may be tempted to use these icons in front-end theme and plugin development—after all, it’s easy to include Dashicons as a dependency when enqueuing your stylesheet.
There are several problems with Dashicons, however. Steve Ush has penned an excellent critique after opening an issue on GitHub outlining some of these problems, most of which pertain to the non-standard use of default CSS and various quirks of sizing and alignment. The authors of this icon font don’t seem to really grasp what the problems are—or maybe it is the WordPress community that is out of touch, recommending Dashicons for use on the front-end where it doesn’t belong. After all, one of the authors outright says
it’s not intended as a general use icon font in this comment. (This might not have always been the case; see this Make WordPress thread for further discussions of Dashicons in the lead-up to version 3.8.)
The truth is that Dashicons are optimized for use in the WordPress admin panel, not the front-end. You are, of course, free to use this font in the front-end, but I would not advise it, particularly not with all the other options out there (check out Font Awesome, Genericons, Fontello, or IcoMoon for some options). The default CSS is annoying to override and there’s no real help for the weird alignment issues. There are, perhaps, a few valid use cases like this one, but on the whole there’s no advantage to using Dashicons on the front-end despite it being baked into the WordPress core. Just because it’s there doesn’t mean you should use it.
Recently I noticed that pinyin tone marks weren’t rendering properly on my personal blog. The requisite characters did not appear to be included in the Google web font that I was using at the time. As such, my browser was falling back to whatever font listed in my font stack happened to contain that character. The result was a bit of a jumble, not something especially noticeable, but certainly of concern to anyone interested in web typography and Chinese language blogging.