Taking Typesetting Seriously

I've recently spent some time looking into declaring new or interesting fonts for websites. Declaring them, of course, is easy. The trick is being able to view them from any computer whether said font is installed or not. And that's where the @font-face css syntax comes in. After having had a play around with the usual methods, and looking up best practices, it becomes quite clear that the act of simply adding your own font to your website makes a huge impact to the look, feel and style of your work. Having seen how infrequently this technique is used, and how easy it is, it seems only fair to say that its about time people started taking typesetting seriously on the web. The rest of this article details how the font on this website was declared, general good practices, and a little bit of history to boot.

The best place to start, seems to me, is at the end product (for those of you too impatient to read the rest). So, below is what this site uses to declare this font.

/* Declare font-face New Haas by Unknown.  */
@font-face {
   font-family: "NewHaas";
   src: url("fonts/NewHaas.eot");
   src: url("fonts/NewHaas.woff2") format("woff2"),
        url("fonts/NewHaas.woff") format("woff"),
        url("fonts/NewHaas.ttf") format("truetype"),
        url("fonts/NewHaas.eot?#iefix") format("embedded-opentype"),
        url("fonts/NewHaas.svg#NewHaas-webfont") format("svg");
}

html {
   font-family: NewHaas, Helvetica, Arial, sans-serif;
   text-shadow: 0 0 1px rgba(0,0,0,0.01);
} 		

The above is a subtle alteration on what, on January 12^th 2015, CSS-TRICKS.com has declared "the deepest support possible right now". But, rather than trying to go into why this format currently offers the broadest support possible, I will start with a little history that will help us understand why this is the best we have.

When HTML was first created font-families could not be declared or altered at all, except by altering settings in your browser. In 1995 however, we see our first step forwards typesetting in HTML pages with the introduction of the <font> tag. At this point we didn't even have CSS though, and as soon as we got CSS (which was proposed in December 1996) the font tag became more or less obsolete. CSS1 gave us font-family, font-style, font-size, etc. Very useful, but... it relies on the end-user having the declared fonts already installed on their computer. Then, in 1997, Internet Explorer 4 was released which added support for basic font downloading from web-servers.

The star of our article @font-face, however, first appears in the CSS2 specification published in 1998. It's capabilities and uses have since been expanded in CSS3, but the support of its various features have only slowly been taken up by the big-name-browsers. And its the support of those features by different browser versions that dictates the format of our declaration above. So, lets go through this a few lines at a time.

/* Declare font-face New Haas by Unknown.  */
@font-face {
	font-family: "NewHaas";

First things first, give credit where credits due. If someone painstakingly creates a beautiful font, they deserve the credit. Also, at this point you will want to make sure that you are fulfilling any license terms. Usually this means putting the license terms before declaring the font. Some licenses specify exactly what CSS you are allowed to use. Remember to pay attention. Next we open our @font-face declaration block, hopefully there's no more clarification needed on that one. And lastly, we declare a name for our font-family. This is the name we will use to reference our font-family later in our CSS. Skipping a line (we'll come back to that one), we move onto;

src: url("fonts/NewHaas.woff2") format("woff2"),
        url("fonts/NewHaas.woff") format("woff"),
        url("fonts/NewHaas.ttf") format("truetype"),
        url("fonts/NewHaas.eot?#iefix") format("embedded-opentype"),
        url("fonts/NewHaas.svg#NewHaas-webfont") format("svg");
}

The src descriptor is there to declare where we have stored our fonts. The order determines our preference, where the top of the list is our most preferred and the bottom is our least. You might ask "Why not only reference your preferred choice?", and that's where browser support comes in. For example, the Android browser only supports .ttf and .otf font files. So even though we want to use a .woff2 file, Android checks it, doesn't want to use it, and then moves down the list until it finds one it can use. This is why we declare so many alternative files. On the .eot url, did you notice the ?#iefix postfix? Well, that's there as a work around to some kind of wierd bug associated with an earlier versions of Internet Explorer.

You might recall that I said the format in this article was a "subtle alteration" on what CSS-TRICKS.com has proposed. What have I changed? Just the order of preference. I have moved the .woff2 and .woff file types to the top. They are the most modern, smallest, and highest detailed formats with growing support amongst modern browsers. It seemed silly to me to have the .eot file above it, which is a much older file type that misses some font details. So, what about the line we skipped?

src: url("fonts/NewHaas.eot");

So, what exactly is this for? Well, essentially its there to support Internet Explorer 6-8 as well as Compatibility mode. Turns out, that in certain situations, older versions of IE have difficulty going down the list. They just try and use the first font they find, even if they can't use it. So this way, we put the file type we know the IE versions experiencing issues can use at the top to stop them from freaking out. It's a shame we have to do this, because modern browsers that support .eot and .woff could end up using the older lower quality font. Unfortunately, this is the price we pay for super high browser compatibility. There is light at the end of the tunnel though. The CCS3 specification says that if you declare two or more descriptors of the same type (our two src) that browsers should ignore everything but the last one. If modern browsers adhere to the spec, then they will go through our second prioritized list as normal.

All that's left at this point is to set your new font-family as the primary font-family for your web page. Add in some subtle text-shadow to act as anti-aliasing for low resolution screens, and all is well with the world. That's it for now. Thanks for reading. If you have any criticism, corrections, objections, or (Gods forbid) praise just drop me a comment under the article.