giant robots smashing into other giant robots
Written by thoughtbot
Get your type back in shape with these simple tricks
Type looking a little flabby? Overweight? Want to give it a kick in the pants? Take a look at some of these tricks to really give your web type a workout.
Refine the Windows physique
Looking to make your type render a bit better for your Windows and Linux users? Try text-rendering: optimizeLegibility;. It will enable ligatures and kerning tables in the font file making the type look extra nice. It takes the text a little longer to load which could be a problem. It’s best to use it on headers, especially on those @font-face fonts, and refrain from using it on really large blocks of text.
Shed some Webkit weight
Everyone’s reversed Webkit type has a little extra weight in the hips. -webkit-font-smoothing: antialiased; will help you lose a little of that weight around the middle by using antialias rendering instead of the default subpixel rendering. It will make type just a hairline thiner when using light type on a dark background. Read -webkit-font-smoothing reloaded and check out the test page for more information.
Remove those pesky widows
Have a problem with widows? Use jQWidont to zap those problem spots away. It will remove all those pesky widows for you by inserting a non-breaking space right before the last word.
Get some rhythm in your step
Create rhythm the easy way. Try using tools like typograph and Modular Scale to create a nice flow within your type. Both use traditional type scales to calculate sizes to help with your vertical spacing.
Feel Justified
Using justified type on the web can sometimes be a disaster. Hyphenator and text-justify: newspaper; (Only in IE - WHAT?) will help make sure that you’re shaping up the word-spacing and not letting it get too big. Hyphenator adds in semantic soft hyphens for you but it could be dangerous leaving your hyphenating up to a script. text-justify: newspaper; will adjust the spacing between letters and words instead of relaying solely on word-spacing.
Do-it-yourself @font-face web service
Phil recently designed Developers Developers Developers Developers, an event we’re running for Boston-area high school and college students:
It looks awesome in part because of liberal use of @font-face.
These days, it’s simple to use @font-face. Just use a stylesheet referencing a web service like Google Font Directory:
<link href='http://fonts.googleapis.com/css?family=Lobster&subset=latin' rel='stylesheet' type='text/css'>
… then use the font as part of a normal CSS font stack:
#schedule .event-time {
font-family: 'Lobster', arial, sans-serif;
}
What if the font isn’t on an @font-face web service?
There are plenty of commercial @font-face web services, which Kyle has covered in detail.
However, there are cases where the font you want to use isn’t on an existing service. Or, the font you want to use requires explicit permission from the font’s creator before you can use it.
We ran into this problem on Developers Developers Developers Developers.
First attempt: serve fonts from the app
To solve it, we included the font files in our git repository. This worked, but wasn’t ideal:
- Unnecessarily adds large files to the repo.
- No HTTP caching by default, downloading font files on subsequent requests.
- Repetition. Soon after, I wanted to use League Gothic again on another app.
Second attempt: serve fonts directly from Amazon S3
So our next attempt was to upload the @font-face stylesheet and font files to S3 and serve them directly from there like:
<link href='http://our-bucket.s3.amazonaws.com' type='text/css'>
At first, this seemed to work well. We could set some HTTP headers to handle caching and everything seemed like it was in the right place:
- application code in version control
- assets in an asset host (S3)
However, Firefox (and probably some versions of IE), balks at this technique because of the same origin policy.
On S3, you’re not allowed to tweak the Access-Control-Allow-Origin HTTP header to allow Firefox to serve your font from S3. There’s a long Amazon thread where S3 customers are asking for this ability.
However, even if you could set the Access-Control-Allow-Origin header on S3, you also want the Content-Type, Cache-Control, and Expires to all also be set in a standard way. It’s a pain to have to do that manually.
Solution: serve fonts from a DIY web service
Our final solution was a small Sinatra app called Fist Face. It is now open source under the MIT License and it solves all the problems we experienced.
Fist Face
It works exactly the same way as Google Font Directory, Typekit, or any other @font-face web service, except that you have full control over it:
<link href='http://your-font-face-service.com/league-gothic.css' rel='stylesheet' type='text/css'>
To use Fist Face, this is all you have to write:
# Gemfile
source 'http://rubygems.org'
gem 'sinatra', '~> 1.1'
gem 'fistface', '~> 1.0'
# config.ru
require 'rubygems'
require 'bundler'
Bundler.require
run FistFace
Then deploy it. Follow a few conventions in the README regarding your asset host (ex: S3) and a few minutes later, you’ll be serving fonts via your own @font-face web service.
Why would I want to do it myself?
If you’ve run into the same issues that we did, have you solved this problem differently?
Among the weaknesses of this approach are:
- No CDN. (patches welcome!)
- Up to you to write a decent cross-browser CSS file.
- The font files you use might be old-school (not “hinted” for computer screens).
- Requires deeper knowledge of typefaces.
With an open mind, the last weakness is actually a strength. Typography is pretty interesting. You’ve got all these independent type foundries doing beautiful work and some release their fonts for free under permissive licensing.
In that way, hunting great typefaces for your @font-face web service is like building your own art collection. It can differentiate your work.
So, when your friends ask you, “whoa, what font is that?”, you can tell them, “you’ve probably never heard of it” … which I’ve heard is hip.
Written by Dan Croak.
Recap: Design for Developers
We ran our first Design for Developers workshop this week. Kyle and I had a great time teaching it and were really pleased with the quality of the work the students were able to produce by the end of the workshop.
The main project the students worked on was a page for a fictional furniture company. We gave them a completely unstyled page and asked them to slowly transform it using grid systems, refined typography, and effective color schemes. The students sketched out their ideas on paper, then worked directly in HTML and CSS to implement their ideas. At the end of the last night, we had a group presentation of all the pages, where the students talked through their approach and we offered our critique.
We asked a few students to let us share their work with you.
This page was designed by Javan Makhmali (click for full-size image):
And this page was designed by Chuck Vose (click for full-size image):
At the end of the workshop, students walked away with a solid grasp of some fundamental principles of design along with practice building a well-structured, good looking web page.
If you’re a developer who wants to improve your design skills, consider taking our next Design for Developers workshop, which we’ve scheduled for Feb 21-23.
To em, or to err.
There’s been some talk about ditching ems as the proper unit for measuring type in stylesheets. This is as many things are; while possible, probably not a great idea.
Units allow us to speak on common ground. Almost everything has a unit of measure. For type, we use ems. so what’s an ‘em’?
em: the square of a body of any size of type
The argument for ditching ems suggests instead defining font size in pixels. How 1999 of you. Pixels are a unit of measure for bitmap images. This may shock some of you, but images and type are not the same. Think about it this way - would you measure BAC in dB?
IE6 doesn’t allow resizing of pixel-sized type. There’s a reason for this. How do you resize a pixel? Better yet, how do you easily standardize something like that?
So we’ve covered why not to use pixels - but why ems? Because they’re relative units. Get back here, coward!
This can be easy.
Let’s start with a simple case. We set our base text-size to 10px, or 1em (62.5% of 16px which is a typical browser default). That makes the following math a bit friendlier.
body {
font-size: 62.5%
}
Next we decide a typographic scale.
h1 {
font-size: 2.4em;
}
p {
font-size: 1.2em;
}
This part is optional, but the classic scale has worked well for type setters for centuries. I’d recommend sticking to one. Next we define a standard line-height of 1.8em.
h1 {
font-size: 2.4em;
line-height: .75em;
}
p {
font-size: 1.2em;
line-height: 1.5em;
}
To get these values, divide your font-size by the desired line-height value. For example, take 1.8 (our line-height) and divide by 2.4 (the font-size of h1). Your result (.75) is the line-height for h1.
So far, basic arithmetic. Still with us? Great! Let’s add a ‘line’ between each paragraph, and set some appropriate margins on our headers.
h1 {
font-size: 2.4em;
line-height: .75em;
margin: .75em 0;
}
p {
font-size: 1.2em;
line-height: 1.5em;
margin-bottom: 1.5em;
}
I bet I know what you’re thinking. Where does he come up with these crazy numbers? Hint: Check the line-height value.
Okay, so now let’s handle the heckler in the back of the room. Here’s how I’d probably handle some pesky h2’s.
h1 {
font-size: 2.4em;
line-height: 0.75em;
margin: .75em 0;
}
h2 {
font-size: 1.8em;
line-height: 1em;
margin: 1em 0;
}
p {
font-size: 1.2em;
line-height: 1.5em;
margin-bottom: 1.5em;
}
It fits in our typographic scale. Our design holds up. If you’re curious about how all this looks I’ve thrown together a quick example using h3’s as well. My solution? Knock all the headers up one notch on the scale.
Things can get out of hand if you start with unsound values, or start mixing units of measure. But stick to your guns! It lends tremendous persuasive resources, and provides benefits that justify the foresight of this technique.
