I realized today at work that this site’s title font-face wasn’t loading. Figuring a long night ahead of debugging the WebFont Loader that’s trying to grab the Raleway font (it is quite elegant, the fallback “sans-serif” font decidedly less so) from Google web fonts. Five minutes and one <link> statement later, it’s fixed – well, at least for browsers that support web fonts. Incidentally, the font is supposed to look like this:
It used to be much harder.
A bit on the basics. Your HTML and CSS has a little control over the fonts that shape your page; you can request a particular font-face, but if the user’s machine does not have that font installed, you’re stuck. Hence, the font-family CSS rule was created so you can fall back to more and more generic fonts, eventually ending up in something like serif, sans-serif, or monospace. So if your creative ambitions reached beyond the tendrils of Helvetica, Arial, and possibly Tahoma, best practices meant you did something like this:
h2 {
background: url(/title/insert-title.png) no-repeat left top;
display: block;
height: 1.4em;
width: 5em;
}
h2 span {
display: none;
}
That is, you would crop the title as an image from your Photoshop mockup, then set it as the background of the title element. The extra bit with the <span> tag has to do with keeping semantic content inside the header element so search engines can still pick up your intentions.
Taking it a step further1, if you had images of each letter in the alphabet in the target font, you could do a letter-by-letter replacement of any piece of text if you didn’t mind the horrid loading of images and static font sizes. Put those individual letters together in a CSS sprite sheet, and you have an ad hoc “sprite font” technique/hack.
Just one of those things that lets your front-end engineer earn his keep.
You can always take it a step further in computer science, or in this case web development.↩
