Web typography has come a long way from the days when the only way to get a custom typeface on a page was with images created in Photoshop. These days, thanks to widespread browser support for CSS @font-face and services like Typekit, a couple lines of code will add actual font files to your pages.
Go back to 2001 with that information and you would blow many a designer’s mind.
Of course if you’re not a designer, today’s overwhelming variety of type possibilities can be overwhelming. For some help deciphering it all and navigating the sometimes complex world of web typography, check out the video above of Typekit’s Jason Santa Maria‘s talk “On Web Typography.” The video comes from An Event Apart Boston in June of last year, but was only recently made available online (note that Santa Maria has since left Typekit).
After a whirlwind tour of the history of online typography, Santa Maria explores typography from a newcomer’s perspective, looking at how typography affects how you read and how to choose and combine typefaces for a better looking, easier to read site. It’s about an hour long, but you’d be hard pressed to find a better intro to and overview of the art of typography.
Good web typography needn’t be difficult, but typography can be a complicated and sometimes intimidating subject for newcomers.
To help you understand typography a bit better — and create better-looking websites with your new understanding — developer Tommi Kaikkonen created his Interactive Guide to Blog Typography. The guide offers a nice hand-holding walk through of the elements that make for good typography on the web, helping you not just make more readable sites, but understand why they’re more readable.
For most suggestions in Kaikkonen’s guide there’s an interactive button to toggle different line-heights, fonts and measures so you can see for yourself why those elements matter and how they contribute to making your site easier to read.
Among the suggestions in Kaikkonen’s guide are to set a readable measure (the number of characters on a line), frame content with white space (to put emphasis on the main part of the page), avoid pure black for text and, unless you really know what you’re doing, stick with just two different fonts.
There is one part of the guide we can’t totally endorse — the last suggestion, which is to use font-variant: small-caps; even if the font you’re using doesn’t actually have a small-caps variant. With some fonts — the traditional six fonts of web design, for example — you can get away with this, but if you’re using fancier fonts like those from Google Web Fonts or TypeKit this can make for some really awful results; proceed with caution on that one.
Forget The Homer; look at those sweet, sweet hyphens. Image: Screenshot/Webmonkey.
Last night, while reading Craig Mod’s excellent article, Subcompact Publishing, I noticed something that only type-obsessed nerds probably notice: some really good-looking hyphenation. A quick right-click to “inspect element” revealed this gem: -moz-hyphens: auto;.
It’s true; while we were sleeping Firefox, IE 10 and Safari all implemented the CSS hyphenation spec. In fact, Firefox has had hyphenation support for over year (starting with version 6). Sadly, Chrome doesn’t support hyphens just yet, nor does Opera. Still, if you’d like to do something really simple that will vastly improve the readability of your text for Firefox, IE 10 and Safari users, add this to your site’s stylesheet:
Right now the -o- prefix isn’t doing anything, but it future-proofs the code a bit for when Opera adds support. The only catch to hyphenation is that not only does the browser need to support it, it also needs to have a hyphenation dictionary for the language you’re using. The Mozilla Developer Network has a good rundown of which browsers support which languages.
There’s no real need for a fallback since the web has never had any hyphenation. Browsers that don’t support the CSS hyphens rule will simply render the page as they always have, but those that do will now be a bit more readable.
And, as a kind of footnote, if you have any interest in the future of publishing, Subcompact Publishing is well worth a read.
[Update: It looks like developer Peter Paul Koch just noticed hyphenation support as well. He’s got a short post that notes one potential problem with hyphens that I missed: you need to explicitly declare a language, as in <html lang="en"> in order to trigger hyphenation. See Koch’s post for more details.]
Building responsive websites means that your design has to adapt to different screen sizes. That there is no such thing as “pixel perfect” has long been a maxim of good web design, but nowhere is this more true than when you start working with percentage widths, em-based type and other flexible techniques of responsive design. While fluid grids, adaptive images and other tools help, sometimes even basic things like the flow of type can look wrong without a little extra help.
One common problem when designing for multiple devices is handling the changes that happen when the user rotates the screen. It’s frustrating to see your elegant portrait-oriented designs fall apart as the device moves to landscape mode (or vice versa). Frequently the problem is that images, videos and other embedded content in your page is sized in relation to the pixel width of the viewport, but the type is not. That means that the type fails to adapt to layout changes, leaving ugly gaps, whitespace or hard-to-read, overly long lines.
There are a number of ways to solve this problem, but one of the simplest and easiest is to use fluid typography in addition to your fluid grid. BBC developer Mark Hurrell wrote up an excellent tutorial some time ago that shows how, by specifying font sizes in rems, you can “adjust every font-size on the page by using media-queries to change the font-size set on the BODY or HTML element according to viewport width.”
To find the right size type for various screen widths, Hurrell calculates a resolution-independent font scale based on target widths. That is then applied using a series of media queries and the new CSS 3 unit rem. The rem unit means ems relative to the root (the HTML) element. That means your type gets proportionally larger overall, rather than in relation to its parent element as would happen with a simple em. As Hurrell notes, support is pretty much universal on tablets and phones (browsers that don’t support it will fall back to px sizing, so all is not lost).
In the end what you get using rems and media queries is fluid typography that scales just like a fluid grid. That means that when the device rotates the type resizes to fit the new screen dimensions. For more details on how to make it work on your site be sure to check out the Responsive News blog post, which also has a few links to websites already using this trick.
The power and potential impact of typography on the web has grown by leaps and bounds with the advent of widespread browser support for @font-face and font hosting services like Adobe’s Typekit.
Of course with new tools come new problems. Many web developers don’t know much about fonts and typography. After all it used to be there were only six reliable font choices on the web — why bother learning about something you couldn’t use? But that, like so many other things in web development, is no longer true.
If the web’s newfound typography options leave you feeling a bit behind, head over to Ellen Lupton’s Thinking With Type website. The site is a goldmine of information on typography dos and don’ts both on the web and off. The site is not, however, so much about fonts, but rather about type as a visual element and what it can do (both good and bad) within a design.