The Typekit Blog

Today’s guest post was written by Elliot Jay Stocks.

It’s nice when good things come together, isn’t it? Good things like independent publishing house Five Simple Steps and Typekit’s resident Type Manager Tim Brown, for instance. The result of this fruitful combination is a wonderful little book about typography. Specifically, a typography book about good things coming together.

Combining Typefaces is the latest title in Five Simple Steps’ series of Pocket Guides — concise e-books that focus on a specific topic — and Tim’s does exactly what it says on the tin: it helps readers become more proficient at combining typefaces by examining exactly how successful combinations work. As the official blurb states:

Combining typefaces is challenging and fun, but it takes practice. Successful combinations are partly a matter of good taste, which can be tough to develop. And finding typefaces that work well together often takes more time than we (or our managers, or our spouses!) think it should.

This pocket guide will give you a framework for efficient practice, lead you to founts of knowledge and help you judge the work you see, including your own work. It will encourage you to be selective, patient and reasonable, focusing on web contexts and your design goals.

You can buy ‘Combining Typefaces’ for a mere £2 on its own, or as part of The Pocket Guide series: Collection 2 for £6.

Elliot Jay Stocks is a designer, speaker, and author based in Bristol, England. He is the founder of typography magazine 8 Faces and the co-founder of Viewport Industries.

Our digital world is often a textual world. We take in information via news sites, blogs, and e-books. We communicate with our friends and co-workers via email, chat, Twitter, or Facebook. Some of us even use text to interact with the computers themselves via terminals and source code.

Most of our time using computers, smartphones, and tablets is spent reading and writing, and reading is one way the digital world becomes physical. Our eyes are physical organs that can get tired—especially if the text we spend hours looking at is rendered poorly. Because we read so much when looking at screens, it’s vitally important that the text before us is as readable as possible.

Hi-DPI displays can be a huge boon to readability. At first, high-resolution text can seem like a luxury — after all, modern operating systems are generally capable of producing good-looking text. But even though anti-aliased text on regular displays is much better than what came before, it’s still far more pixelated and “fuzzy” than print—and even the best, most screen-optimized text can strain the eyes over a long day of reading. In apps with hi-DPI support, text is rendered with less anti-aliasing (that is, less pixel “fuzz”) so letterforms are crisper and easier for the eye to distinguish. And in apps or on devices with this support turned on, you get all of this great, text-beautifying behavior automatically.

Historically, the fonts that look best on-screen at text sizes have been ones specifically optimized for that purpose, via hinting instructions. (Our own Tim Ahrens explained hinting and why it’s important in an earlier post.)

On hi-DPI displays, hinting is useful but far less important. Whereas a standard-resolution device needs the hinting instructions to avoid blurry lines and edges, hi-DPI devices—having many more pixels to work with—can make a font look crisper and more readable, at any size.

Not only does this make a wide range of unhinted or less-well-hinted fonts potentially available for screen use, it also broadens the range of weights one can safely use on screen. For example, at a standard screen resolution it might not be a great idea to use a very thin font such as Helvetica Neue Light or Source Sans Pro Thin. Most text rendering engines have a hard time rendering such ultra-thin lines at anything but large display sizes. Even as headings or titles (say, around 24 px size), text set in one of these fonts tends to look like a blurry spray of pixels.

Light weights of Source Sans Pro at 1x resolution. The heading is set in Extra Light (200), body text in Light (300).

But at higher resolutions, light fonts can offer the same clean, elegant look as in print.

Comparison of Source Sans Pro light weights, as rendered at 1x (left) and 2x (right).

This gives web and app designers a much broader palette of type to work with, but also some new constraints to think about.

Consider the laptop

While most current smartphones have hi-DPI displays, many tablets and most PCs do not. And even as more platforms start to offer and support high-resolution screens, the way that they are supported can vary a lot from platform to platform, or even from device to device.

With so many different kinds of screens out in the world, I find it helpful to establish a good, working definition of what makes a device “hi-DPI” or not. In general, a device is hi-DPI if it has both of these things:

• A display with a (relatively) high pixel density, say, over 200 pixels per inch (PPI) for mobile devices or over 150 PPI for laptops.
• Pixel scaling, where the on-screen graphics are rendered using extra physical pixels so that they appear sharper and clearer than on a standard display.

Pixel scaling works by turning the pixel from a physical unit of measurement—measuring a number of actual, physical pixels—into an abstract one. That is, what we’re used to thinking of as “1px” might be rendered onto the screen using more than one physical pixel.

The best way to understand these new, abstract pixels—which Peter-Paul Koch calls CSS pixels—is relative to the viewport. For example, on an iPad with Retina display, the screen (when held in portrait orientation) may be 1,536 physical pixels wide, yet Safari will report the width of the browser viewport as just 768 CSS pixels, just like the non-Retina iPad 2. The number of physical pixels per CSS pixel is called the device pixel ratio or scaling factor.

While it’s tempting to think these two things—high density displays and pixel scaling—always come together in a device, let’s consider the Asus Zenbook Prime, a Windows 7-based laptop released in 2012. The 13.3″ Zenbook’s display resolution is 1920×1080 pixels, which works out to a hefty 168 PPI. (As if that weren’t crazy enough, Asus also sells an 11.1″ Zenbook with the same screen resolution, which works out to 189 pixels per inch. Yikes!)

At the time of writing, both Zenbooks ship with Windows 7 installed, which has no hi-DPI mode, so web type sized at 16 pixels in CSS is rendered at the normal 1x scale—i.e., with 16 physical pixels. This is how most computers work, of course, but that’s because most computer displays (on both laptops and desktops) shipped in the last decade fall into the same comfortable 96–115 PPI range. (As far as Windows 7 knows, the Zenbook’s screen is a 24″ desktop monitor.) On one of these typical displays, 16px web type renders at around 0.14 inches, or just over 10 pt, which is a more or less decent size for reading.

On the Zenbook’s high-density display, however, the same text is just 0.09 inches high, or 6.48 pt—49% smaller.

This simulated example shows the difference in physical size between 16px web type rendered on a “normal” display (left), versus the high-density display on the Asus Zenbook (right). As you can see, the Zenbook text is 49% smaller.

That’s a big difference, especially when you consider that these two laptop screens are the same physical size. Unlike a tablet or smartphone, readers are unlikely to hold a laptop screen closer to their eyes. And unfortunately, because of Windows 7’s lack of support for hi-DPI displays, there’s no way for us as designers to detect the Zenbook’s high screen resolution and respond accordingly.

The value of pixel scaling, beyond making it possible to deliver higher-quality graphics to our users, is that it gives us a framework for understanding how devices are different from one another so that we can provide the best experience. Most of the hard work is done for us by the operating system, by scaling type automatically to an appropriate, readable size.

However, there are still some things we can and should do in the hi-DPI era to ensure a great reading experience for all users. Using CSS media queries, we can show users the most appropriate font for their screen resolution, and improve readability on screens with no pixel scaling by increasing the font size based on the viewport width.

Responsive, hi-DPI typography

As I mentioned earlier, hi-DPI displays make it possible to use lighter text weights, and to use them in more places. For example, on a Retina display paragraph text set in a light (300) weight can look cleaner, more readable, and just prettier than at the normal weight. However, on standard displays, that lighter text will be even more anti-aliased than normal, making it less readable.

Here’s an example from the Gmail mobile site. Much of its UI text is set in Helvetica Neue Light, looking thin but readable on Retina displays, but very pixelated on regular displays:

The solution to this and other problems can be found in responsive web design: use CSS media queries to set the most appropriate typeface, weight, and size for each kind of screen.

Because hi-DPI browser support is still fairly new, there isn’t yet a standard media query for detecting hi-DPI displays. However, all major browsers do support at least one syntax for detecting screen resolution, and you can combine the most common syntaxes to produce a “bulletproof” query for styling hi-DPI web content.

The CSS code below sets body text at a normal weight on standard-resolution displays, but switches to a lighter weight on hi-DPI displays:

.body-text {
  font-weight: normal;
}

@media only screen and (-webkit-min-device-pixel-ratio: 1.5),
        only screen and (-o-min-device-pixel-ratio: '150/100'),
        only screen and (min-resolution: 96dpi),
        only screen and (min-resolution: 1.5dppx) {
   font-weight: 300;
}

(If you’re using Sass, you can save some typing by wrapping this in a mixin. Here’s a Gist showing how to set it up.)

Responsive typography also affords us at least one option for handling devices like the Zenbook, which have very high resolution screens but no hi-DPI support. As I alluded to earlier, what makes the Zenbook such a strange device is that it’s a small screen (an ultraportable laptop) that, due to its pixel density, behaves like a very big one (a TV or desktop monitor). We can adapt to it, however, through a bit of forced-perspective trickery, by treating it as a big screen seen from far away.

First, following Ethan Marcotte’s advice in these very pages, start by sizing type and other elements with relative units, such as ems, rems, or percentages. On most devices, the default 16px (or 100%) font size on the body element will be the right size. But on very wide screens, we’ll increase the body font size by 25%.

body {
  font-size: 100%;
}

@media screen and (min-width: 1200px) {
  body {
    font-size: 125%;
  }
}

Now, if someone using a high-density laptop (or even big-screen desktop) visits our site, and their browser window is maximized (which is fairly common), this media query will help improve readability by simply making the type larger. If all our other measurements are specified relative to the body text size, everything should scale up to fit, maintaining a consistent design that also adjusts itself to the user’s device. While not as nice a reading experience as true hi-DPI rendering, this large-print version of our web site does what it can to make text more readable and, in turn, avoid or alleviate eye strain.

Above all, the best way to make sure your web sites are readable is to test them on as many different kinds of screens as possible. Media queries are wonderful tools for responding to strange new devices, but only by using — rather, reading — your site on different screens can you find out which responses are necessary and useful. Choose a page of your site and read it on your computer, then read it again on your phone. Look at it on a standard display and on Retina displays. As you read, look out for the aspects of the reading experience that feel uncomfortable, compare those aspects across different kinds of screens, and adapt accordingly.

Today’s guest post was written by Billy Whited, a software designer in Chicago, IL.

With the growing popularity of type design, the sea of typefaces from which to choose gets bigger every year. I’ll be the first to admit that, at times, the waters can be difficult to navigate. There are a lot of variables one must consider when selecting type, and these can be a struggle to prioritize.

Following up on my previous blog post, “Setting Type for User Interfaces”, I’ve chosen a few exemplary fonts from the Typekit library to serve as a reference for your next project. I believe each of the following three typefaces possesses the necessary qualities for distinguished employ within the realm of user interface design.

FF Meta

This example uses FF Meta Web Pro, FF Meta Web Pro Condensed Bold, and FF Meta SC Web Pro.

Originally intended for use at small sizes on low-quality paper, FF Meta was designed to be “very legible, neutral, and space-saving [1].” With its flared strokes, angled terminals, open apertures, and sharp intersections, it possesses highly distinguishable letterforms and an approachability that belies its ruggedness.

FF Meta’s unique charm and combination of features lends it an adaptability that is likely responsible for its widespread popularity. Over the years, an untold variety of corporations, publications, and websites have adopted it. Typographers and soccer fans alike will appreciate it’s prominent and tasteful use on the website for the famous EPL club Arsenal.

Typekit hosts a manually hinted version of FF Meta that is available in a variety of weight and styles (including true italics), making it well-suited for a design project with a variety of typographic needs.

Source Sans Pro

This example uses Source Sans Pro Regular and Bold.

A relatively recent arrival, Source Sans Pro is Adobe’s first open source typeface family. Designed “primarily as a typeface for user interfaces [2],” Source Sans Pro features a hardworking simplicity, elegantly-drawn letterforms, and a familiarity derived from allusions to the “legibility of twentieth-century American gothic typeface designs [2].”

With comparatively wide proportions, large x-height, and balanced upper and lowercase forms, it remains highly readable in both shorter text strings and longer passages. Recently, it has become a staple of Stanford University’s identity, recommended for use in the school’s print and online communications [3].

Manually hinted for cross-platform consistency and available via Typekit in a whopping nine weights (with true italics), Source Sans Pro is an attractive, clinical typeface that can harmonize an interface without drawing undue attention to itself.

LFT Etica

This example uses LFT Etica Web Book and Bold.

LFT Etica by TypeTogether is a brilliant option when you find yourself at odds with a client who really loves Helvetica. Billed as a cure for thoughtlessly prescribed “common” and “cold” grotesque sans serifs (like, ahem, Helvetica), LFT Etica is a delightfully understated typeface. It retains the neutral appeal of Helvetica, but does so in a way that is much more welcoming. It’s got an endearing, unexpected warmth.

Unfortunately, LFT Etica does suffer from a visual conflation of its capital “I” and lowercase “l” letterforms—an affliction that also befalls its austere grandfather, Helvetica. It makes up for this drawback with open counters, large apertures, generous proportions, a large x-height, and personality.

Typekit hosts 6 weights of LFT Etica, which was featured in the recent high-profile redesign of Digg.com.

A place for typography in UI design

By some accounts, web design is 95% typography. And while I don’t intend to examine the scientific truthfulness of this sentiment, I think it is difficult to overstate the importance of good typography. It operates at a functional, almost subliminal level distinct from decidedly more ornamental concerns like graphics, texture, and color. The quality of your typesetting can support your client’s message (and their application’s functionality)—or can detract from it by drawing undue attention to itself.

Even the most tasteful color scheme or well-apportioned graphical treatment cannot make up for a site or application that is difficult to read. Simply put, poor legibility is not a mistake that’s easily forgiven, or overcome. Having a solid grasp of typographic principles will do a great deal to steer you in the right direction—and it never hurts to have a few favorite fonts in mind, either.

References

1. http://spiekermann.com/wp-content/uploads/2008/10/baseline0785.pdf [PDF]
2. http://store1.adobe.com/cfusion/store/html/index.cfm?store=OLS-US&event=displayFontPackage&code=1959
3. http://identity.stanford.edu/overview/fonts

Today’s guest post was written by Billy Whited, a software designer in Chicago, IL.

As a UI designer, I do my best work within the bounds of a clear hierarchy of constraints. Because typography is the catalyst for my design work, the most important step I take at the beginning of a project is to select a typeface (or a set of them). Once this choice is made, I can develop a system to aid my decision-making process and, in so doing, avoid the terror of a blank canvas.

To narrow down the vast number of typeface options, I start out by defining the scope of the design problem before me in broad terms. This usually requires that I make a decision about the essential purpose of the project I’m working on. Is it a content-driven website that serves up information to be read at leisure? A task-driven web application oriented towards getting stuff done in a timely way? Or is it a site possessing both content-driven and task-oriented elements (like a CMS)?

Content-driven websites (foreground) and task-driven web applications (background) often differ in the way they utilize text.

The differences between these types of sites have implications for the way we approach the process of choosing type for them. Content-driven websites frequently make extensive use of contiguous, flowing paragraphs of text, whereas primarily task-driven web applications may favor shorter, more linear staccatos of text. Awareness of this functional distinction can help narrow our focus at the outset of a project by providing a set of meaningful constraints which, in turn, can help us make more intelligent decisions about our type.

Today, I’ll examine some of the issues that specifically affect setting type for task-driven web applications (user interfaces), beginning with our own biological constraints for interpreting text and then exploring how this informs type design. My express goal is to provide you with a few hints that will aid your typographic decision-making and help set your future designs apart—both functionally and visually.

The implications of how we read

In user interfaces, it’s common to encounter screens that are nothing more, typographically speaking, than a collection of singular words displayed in isolation from one another. Examples of this abound: web forms, navigation menus, control panels, etc. This is a key difference between primarily content-driven web sites and task-oriented web applications. So, why does it matter?

As it turns out, the efficiency/ease with which we read is a function of the amount of text available to us as we do so. Within a certain perceptual threshold (up to 15–20 letters) there is a linear relationship between reading speed and the number of letters that are visible to the eye [1]. This means an isolated word that is comprised of fewer than 20 characters will be read more slowly than a word that forms part of a longer sentence.

To fully appreciate this phenomenon, it’s helpful to understand one of the basic mechanicals of reading: saccades. Instead of moving smoothly across the page when we read, our eyes actually make discrete jumps between words, fixating on one word for a short period of time before making a ballistic movement to another one. We call these movements saccades [1].

While we read, our eyes move unpredictably from word to word, rather than in a linear fashion.

But despite their “ballistic” nature, these rapid eye movements actually improve our reading capabilities. While we process the words immediately within our focus, we use the additional information just outside of it to further guide our reading. As readers, our time to comprehension is aided by the context of adjacent words—to the extent that we are often able to automatically process (and thus skip over) shorter functional words like and, the, of, and but.

This revelation profoundly affects typographic decision-making for user interfaces. By necessity, our task-oriented web applications tend to collect more isolated words and sentence fragments than their content-driven counterparts. Because of this, we cannot rely on the contextualizing effects of saccades to help improve comprehension of the textual elements of our designs, nor can we rely on the sheer presence of additional letters to assuage the unfortunate consequences of a poorly-chosen font. This makes our choice of typeface extremely important on task-driven sites.

The importance of well formed skeletons

Given that the latest research in the field of cognitive psychology supports the notion that we recognize words by first identifying their constituent letters, it follows that any typeface suitable for UI work should possess an unimpeachable clarity of form.

Several years ago, researchers in the University of Victoria’s department of psychology conducted an empirical study that sought to reveal which features readers used to tell the difference between visually similar letters.

Results from University of Victoria study conducted by Fiset, et al. The highlighted areas denote the features readers used to distinguish between individual letterforms at a variety of different resolutions. Image source.

The authors of the study concluded that “line terminations (terminals) are the most important features for letter identification [2],” but I feel that designer Ralf Herrmann’s insightful analysis of the results is more applicable to our discussion:

[Looking at the left most column] We can clearly see that we mostly pay attention to the features of a letter skeleton that make them unique…the crossbar of the e, the stroke endings of the c and the existence and shape of ascenders and descenders in general [3].

Indeed, these skeletal features play a crucial role when it comes time for readers to discriminate between frequently misrecognized letters of the alphabet, such as c/e, a/o, I/l, and O/0.

Geometric sans-serif typefaces like Futura PT (above at 15px) have many similar letterforms and can be difficult to distinguish at text sizes.

A well-crafted and legible typeface will counteract these formal conflicts with letters that, while still familiar, are highly discernible from one another. Interestingly, such feature recognizability is a hallmark of monospaced typefaces, which makes sense due to their widespread adoption by computer programmers (whose livelihoods depend on character-level accuracy).

Many monospaced typefaces like Source Code Pro (above at 14px) are renowned for their distinguishable letterforms and high degree of readability.

The coarseness of screens and counteractive letter shapes

Due to the technological nature of our medium, the visual fidelity of our work is constrained by the precision of the pixelated screens on which it is displayed. Consequently, no exploration of UI typesetting would be complete without a discussion about the challenges that arise from the peculiar way text is rendered on screen.

With the exception a few notable “Retina” or “High Definition” devices, most computer screens have relatively poor resolution: in the ballpark of 100–150 pixels per inch for a high-end display[4]. (To put this in perspective, this is less than 20% of the maximum resolution the average person can perceive—which is somewhere around 800 ppi, depending on how you run the calculations[5].)

This limited resolution presents a problem, since most fonts were originally designed for the much-higher resolution of printed media. At text sizes (usually 18px and below), the coarse pixel grids of our monitors can restrict users’ ability to resolve the fine details that make letters recognizable. In turn, this can make our designs exceedingly difficult to read. Type designer Peter Bil’ak outlines the core of the problem:

The letterforms are designed and stored as outlines, mathematically perfect lines and curves which look great at high resolutions, but can be distorted or even illegible when converted into groups of pixels…[6]

At text sizes, the coarse pixel grids of monitors can grossly distort letterforms (above, 24px Bodoni magnified 600 times).

To counteract this well-known problem, some typefaces destined for onscreen use are subjected to an optimization process known as “hinting,” whereby “mathematically ideal [vector] outlines [of letters] are mapped onto a monitor’s pixels [6].” In theory, a typeface that has been hinted will display more accurately—or at least more legibly—onscreen and should perform more consistently across browsers. And certainly, when selecting a typeface for a user interface, hinting is a feature to look for; it can serve as a deciding factor between two otherwise comparable fonts. But it’s a supplement—not a guarantee.

Hinting can improve font rendering, but because different platforms and applications use different rasterizing technologies, results can vary widely. Moreover, according to Bil’ak, “hinting is tedious, time-consuming and widely believed to be nearly obsolete,” and because of this, “99% of all fonts, even commercial ones, are non-hinted.” As a result, we cannot rely on technology alone to solve the problems presented by low resolution screens.

Instead, we must redouble our focus on letter shape and accept the demands the low fidelity environment of the screen places on the typefaces we choose. Specifically, a good screen font will tend toward an aesthetic middle ground: not too delicate or showy, nor too bold or imposing, it will favor recognizable, workmanlike features over those that may be be more visually interesting or unique. Structurally, such typefaces exhibit a subset of features like these:

• A large x-height.
• Open counters and apertures.
• Familiar/recognizable features that follow established design patterns.
• Modest ascenders/descenders.
• Wide proportions.
• Breathing room in-between letters (letter-spacing).
• Low/minimal stroke contrast.
• Sturdy, well-formed or unbracketed serifs, or none at all.
• A rational (vertical) axis (pixel grid-friendly).

Verdana (designed by Matthew Carter) exhibits many of the hallmark features of a good UI typeface.

I will illustrate this more clearly, using real fonts set in UI contexts, in a forthcoming post.

Typography enables productivity

Ultimately, learning the distinction between typesetting for web sites and web applications is of lesser importance than mastering the basic principles of good typography. In fact, many of the same guidelines I’ve covered here for choosing type will apply whether you’re setting lengthy paragraphs or shorter, more isolated strings of text: you should understand how people read text, and then choose type that helps them do this as efficiently as possible given other design constraints.

Good typesetting is an exercise in subtlety, and a demonstration of skill and sensitivity—to context, form, and user needs. As UI designers, it’s important to remember that our goal is not to distract users with superfluous details, but to ease the burden of their work and help them get stuff done.

References

1. http://www.microsoft.com/typography/ctfonts/wordrecognition.aspx#con
2. http://www.mapageweb.umontreal.ca/gosselif/FISET_PSYCHSCIENCE_2008.pdf
3. http://opentype.info/blog/2011/08/01/what-makes-letters-legible/
4. http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density
5. http://www.clarkvision.com/articles/printer-ppi/
6. http://www.typotheque.com/articles/hinting

Type study is an ongoing series of guest posts about typography on the web. In this article, Aura Seltzer provides tips and tricks for pairing type well.

Pairing typefaces is much like choosing flavors at an ice cream shop. We approach the counter with a strategy. We know about common “go-to” pairings like chocolate with vanilla, but we try to find inspiring combinations where each flavor highlights something special about the other. Okay, I think ice cream is great and all, but with so many combinations and “flavors” of typefaces, how do you even begin to decide which to pair?

Let me rip off the bandaid quickly: there are no clear formulas for pairing typefaces. There are no absolute rights and wrongs. But, this is good news. Without formulas, you can create beautiful surprises so your websites won’t look exactly like the one you have open in your browser three tabs over. Don’t worry, there are some techniques that will help make this process less daunting. Let’s walk through four methods for pairing typefaces. I’ll share some tips, define some terms, and suggest some Typekit pairings along the way.

The power of superfamilies

One of the simplest techniques for combining typefaces is to pair typefaces that belong to the same superfamily. Superfamilies — also known as type systems — are extended type families. They contain a large set of weights and widths and typically span different type classifications (e.g., there may be both a sans serif and a serif). Superfamilies also sometimes contain families that are meant to be used at specific sizes, such as caption, subhead, and display. Superfamilies can provide an extensive typographic palette for designs. Because designers build each font with the same proportions and structure, each font works in harmony with the others and can stand out at the same time.

Typekit offers several superfamilies in its collection. FF Dax and Nimbus Sans come with extended weights and widths. Abril, Aviano, and Calluna all feature a sans serif and serif companion. Let’s look at one of Typekit’s superfamilies, Freight Sans and Freight Text, and visualize some of the aspects that lend it to pairing.

Letters of Freight SansPro and Freight Text, when overlaid, show similar structure.

Freight Sans and Freight Text each come equipped with six weights with corresponding italics. They were built with the same chiseled edges, cap height, x-height (the height of the lowercase letters typically illustrated by the letter x), and baseline. Because each was designed with the other in mind, text occupies the same line length and height no matter which face is used; this means either can take the lead as a headline and you can mix them together seamlessly.

Looking for look alikes

A second method for pairing typefaces is to choose typefaces that have similar physical attributes. Similar typefaces can establish a consistent tone for your content. This strategy requires a careful balance. You’ll want to look for typefaces that are similar enough to create visual uniformity but not too similar that there is an uncanny resemblance. With too many similarities, readers won’t be able to tell your typefaces apart, and their eyes will focus on the slight differences between letterforms instead of on your writing. That’d be a total bummer.

How do you achieve this balance? Start with the x-height. A typeface’s x-height serves as a reliable measure for that face’s proportions. Use one face’s features as a guide. Try looking for similar heights for the typefaces’ capitals, ascenders (the part of a lowercase letter that extends above the x-height, e.g. in the lowercase b), and descenders (the part of a lowercase letter that extends below the baseline, e.g. in the letter g). Also, try to pick typefaces with similarly-sized apertures (the partially-enclosed parts of letters, e.g. in the letters a and c) and counters (the enclosed negative space, like in the letter o). The orientation of a letter’s axis, the thicks/thins of its strokes, and the shape of its terminals are extra points for comparison to add to this laundry list.

This may seem like a lot, but there are tricks. Many type designers test their work using the phrase “Handgloves” or “Hamburgefontsiv” because they account for the different strokes and shapes of a typeface. Comparing these words between typefaces will cover the bases and give you a reliable picture of your pairing. I prefer using “Gaboscegqtf” typeset forwards for one typeface and backwards for another, because the letters let you examine key anatomies, and the phrase doesn’t distract by spelling a word. You can type these phrases right into Typekit’s Type Tester, too!

Typekit’s font browsing features can also help limit your options. When you have one typeface already in mind and are browsing for a similar companion, select the buttons under “Properties” with the same x-height, contrast, width, and weight as your base typeface. And since you might not want your companion to look too similar, limit the classification to one that differs from your base typeface.

Let’s take a look at two pairing possibilities using “Gaboscegqtf” and talk about why they do and don’t work.

Below, I’ve paired Apolline STD and Calluna. Both are small, serif text faces that lean forward horizontally and have slightly-inclined crossbars (see the lowercase letter e?). They share a fairly high x-height and mix pointy edges with curved terminals. But, you can see that when the two typefaces are used together, it’s very hard to tell the difference. They are so similar I might as well just have used one of the two typefaces exclusively.

Letters set in Apolline and Calluna show how the two typefaces are too similar to be paired.

But, if we look at Rooney and Skolar, we can see how pairing with look alikes can be seamless and also add pep to the page. Skolar is grittier with its sharp edges, but thick strokes and similar letter widths make this pairing work well. Also, notice how I’ve selected two typefaces with diagonally-protruding “ears” on the lowercase g. It’s all about the details with this technique.

Letters set in Rooney and Skolar reveal that the two typefaces are a good match.

Bump up the contrast

Choosing typefaces that are not similar is another approach to pairing typefaces. Pairing with contrast can reinforce visual hierarchy, eliminate monotony, and add balance to the overall page. Too much contrast can be jarring, so opt for just a few points of difference. Many successful pairs feature a serif typeface with a sans serif typeface or an outspoken voice with a neutral one. You can mix big and small, light and dark, round and sharp. Try everything, but make sure to designate distinct roles for each face — headline, body copy, caption, etc. Doing so will enable readers to deduce order of importance on the page so they’ll know what to read first (and last).

What are some reliable ways to evaluate contrast? Take a look at differences in weight, scale, spacing, and texture. While typesetting “Gaboscegqtf” is always useful for analyzing type anatomy, typesetting both typefaces in a composition with different sizes for headlines and paragraphs can give you a sense if there is enough difference.

The first pairing below features Brandon Grotesque and Proxima Nova, which both land between humanist and geometric sans serifs. Even though there is a difference in x-height, counter size, and the lowercase g, this pairing isn’t the best for showing contrast. The warm touch on their geometric curves makes them too similar.

Letters set in Brandon Grotesque and Proxima Nova exhibit how there is not enough contrast between the two typefaces.

On the other hand, FF Meta Serif and Urbana nicely contrast condensed, illustrative lettering with cleaner curves and angles.

Letters set in FF Meta Serif and Urbana illustrate contrast. The two typefaces make a balanced but dynamic pair.

The rest is history

One last technique for pairing typefaces is to focus on the backstory of each typeface — the context for its creation. You can combine typefaces that were informed by the same tool, output medium, historic era, or concept. For example, you can pair typefaces that were both inspired by calligraphic brushwork, were both designed for low-resolution printers, were both designed in the early 1900s, or were both conceived to address legibility. More specifically, Old Style serif typefaces typically go well with humanist sans serifs despite being years apart, because both were inspired by the pen. Here is one example of how we might visualize that pairing using Dederon Sans and Minion.

Letters set in Dederon Sans and Minion reveal their shared inspiration.

With this historic method, it’s important to be mindful of anachronism and to acknowledge the historic likelihood of a typeface appearing in a particular context. Because this strategy is more research-focused than visual, it is not mutually exclusive with the preceding methods. Feel free to examine typographic anatomy, look for similarity or contrast, and experiment with hierarchy just like you would with the preceding techniques. It will only make your pairings stronger.

With these four methods to guide you, I hope that you’ll feel excited by all of the typefaces still yet to be paired (and all of the ice cream flavor combinations still yet to be tasted!). With a fitting combination, you’ll design visually consistent and stimulating content that will engage your readers. Plus, you’ll be able to justify your type choices to friends and clients, and you’ll learn a ton about typography.

Aura Seltzer recently received her MFA in Graphic Design from Maryland Institute College of Art. She shares more about how to pair typefaces with her typographic dating game Type Connection.

Type study is an ongoing series of guest posts about typography on the web. In this article, Meagan Fisher dishes up advice on novelty fonts.

Ah, novelty fonts. They make up the majority of free fonts available on the web; usually they are pre-grunged-up and have exciting names like “fallen angel” or “cowboy whisper.” You used them liberally on your LiveJournal, but now that you’re a real designer you avoid them like the plague. Right?

Maybe not. When used well, decorative, display, or handwritten fonts can make the difference in a design. We’ll take a look at a blog design, and examine techniques for swapping standard fonts and novelty fonts to make the design more…well, novel.

The case study

I have a confession to make: I am a huge fan of dribbble. Whenever I have a spare second, am stuck for inspiration, or just need a little beauty in my life, I turn to the dribbble everyone feed. I’m amazed how many designers I’ve discovered who I wouldn’t have known about otherwise. For some time now I’ve wanted to create a blog that catalogues my favorites. Hence, bbballer.

I whipped up this mockup rather quickly, and felt pretty good about it as an early design. However it’s relatively sparse in terms of imagery (with the exception of the winsome mascot), and I’d like to give it more personality.

Technique 1: A logo that isn’t really a logo

There have been plenty of times when I’ve wanted to give the title of a site a little added flair, while also ensuring that the text remained dynamic. If you’re crafting a theme or template, you can’t use static images for the blog name, but that doesn’t mean it can’t have style. Using a typeface with a little flamboyance sets the site name apart in situations where you can’t incorporate an actual logo. For bbballer, I decided to set the site title in the delightful FF Prater Script, a nod at dribbble’s scripty logo.

You’ll notice the site title has a subtle embossed effect; this detail is added using CSS3’s text-shadow property. The CSS reads as follows:

#header h1 {
  text-shadow: 0 -1px 2px rgba(0,0,0,.2);
  }

Let’s break down that syntax, since text-shadow is used throughout this design in a variety of ways:

• The first value, set to 0, represents the horizontal offset of the shadow.
• The second value, shown here at -1px, represents the vertical offset. In this example I decided to set the shadow above the text, so it appears to be pressed into the page.
• The third value, shown here at 2px, determines the amount of blur. Since I want the effect to be subtle, I chose to make the shadow fairly soft.
• The fourth value determines the color of the shadow. I’ve used CSS3’s rgba property to set the color to a transparent black, so that the background shade will blend through.

Now that our site title is looking lovely, let’s give our headlines a little character as well.

Technique 2: Let your headlines do the talking

I love crafting interfaces that call for gorgeous photography, whimsical illustrations, or engaging videos, but sometimes media-rich designs can distract from the content. One way to maintain a minimal approach, while still injecting personality into the design, is to selectively use fonts with lots of character. Here I chose a font that fits the vintage athletic theme of the design: LTC Squareface.

Display fonts are meant to be on display; cramming them into body text or tiny headlines will create an illegible mess. So be selective, and use ornate fonts at larger sizes. The striking slab serif used in bbballer gives a nod to varsity letter jackets, but it’s only used once in the design to avoid overpowering the content. It’s also set at a large enough size for the reader to enjoy all those thick serifs.

You’ll notice that we’re using text-shadow once again; in this case we have a light shadow coming from the bottom of the headline. Again, this detail creates the illusion that the text is letter pressed, and adds an extra layer of visual interest. Here’s the markup for the text-shadow applied to headlines:

#masthead h2 {
  text-shadow: 0 1px 0 rgba(255,255,255,.5);
  }

As you can see, here we’re using a sharp 1px vertical shadow, set in a transparent shade of white. It’s a simple addition that makes our headlines just a bit more interesting.

Technique 3: Amped up ampersands

One of my first assignments as Deputy Designer at SimpleBits back in 2008 was to help Dan Cederholm with a post about using the best available ampersand on the web. The goal of the article was to highlight the ampersands available with web-safe fonts. If I were given that assignment today, four years later, it would be a completely different undertaking. Today there are hundreds (if not thousands) of ampersands available via @font-face.

Even with the explosion of fonts available for use on the web, Robert Bringhurst’s guideline still applies:

Since the ampersand is more often used in display work than in ordinary text, the more creative versions are often the more useful.

While researching this article I found many fonts which would rarely have an appropriate use in everyday contexts, but contain gorgeous, attention-worthy ampersands. These can be sprinkled throughout headlines to add elegance or playfulness to a design.

I’ve marked up my lovely ampersand using the technique recommended by Dan back in 2008. The ampersand is wrapped in a <span> which is given a class of amp. Then this <span> is styled by our CSS. Here are the styles from the example shown above:

#masthead h2 .amp {
  font-family: "bello-caps";
  font-size: 2em;
  color: #ae5076;
  }

Our ampersand is displayed in the lovely Bello Caps font, at a slightly larger size than the rest of the headline. It’s also rendered with bbballer’s signature pink, for a little extra pizzazz.

A note about semantics

After taking an informal Twitter poll, I’ve found that there’s some debate amongst web developers about the most semantically correct way to mark up an ampersand. It may be that there is no absolutely right answer, but here are a few approaches you might consider:

• Jeremy Keith made the case for using <abbr> instead of <span> for markup, since some consider the ampersand to be an abbreviation. Ethan Marcotte concurs.
• Mat Marquis suggests we use the <b> tag, since it is used for content that is “stylistically offset from surrounding text,” according to the W3C.
• Jonathan Snook wrote an article for 24ways suggesting that we embed only a single character (in this case, the ampersand), rather than the entire font.
• Drew McLellan also wrote a 24ways post about styling ampersands. His approach uses the unicode-range descriptor to style ampersands, thus negating the need for additional markup.

Whichever approach you settle on, be sure to choose an ampersand that fits the tone of your design. To help with the search for the best possible ampersand, I’ve used my Deputy Designer training and assembled over 200 of my favorite ampersands on Typekit. There’s a preview below, and you can view the full page as well.

Technique 4: Notable notations

Handwriting fonts are one of the trickier novelty fonts to utilize successfully. When overused they can be illegible and ugly. However, when incorporated selectively, handwriting fonts can make a design more usable, playful, and engaging.

One technique that’s been emerging in app and web design is the use of coach marks. These phrases, usually set in a handwritten font and paired with an arrow, can help guide a user through the setup process of an app, or draw attention to key content in a site. (Note: it’s important to consider how and why to use coach marks in a design; Khoi Vinh wrote an interesting post discussing the pitfalls of coach marks, which is worth checking out.)

One recent redesign which employs this technique is the Basecamp marketing site.

Basecamp is using images to achieve this affect, but with font-face friendly handwriting and a few hand-drawn arrows, we can create coach marks that use dynamic text.

In the bbballer design I’m using this technique at smaller sizes, so I want to choose a typeface that’s clear and legible. At larger sizes a handwriting font that’s more stylized may be appropriate, but here we’ll use the simple Felt Tip Woman.

Along with the typeface, we’ll adorn these elements with hand drawn arrows. You can draw and scan your own, or use one of the many sets that are available freely. Here we see bbballer with coach marks added:

For a last little detail to reinforce the handwritten feel, we can use CSS3’s transform property to rotate these little notes a bit. It’s an understated way to set these elements apart, and adds to the slightly quirky feel.

The syntax for rotate transform reads as follows:

.notation {  
  -ms-transform: rotate(2deg); /* IE 9 */
  -moz-transform: rotate(2deg); /* Firefox */
  -webkit-transform: rotate(2deg); /* Safari and Chrome */
  -o-transform: rotate(2deg); /* Opera */
  transform: rotate(2deg);
  }

As you can see, we’re using vendor-prefixes to ensure that this effect appears in as many cases as possible. The syntax is fairly straightforward; simply use CSS3’s transform property, along with the type of transform you’d like to apply. There are a number of transform functions available, including scale, rotate, and skew. In this case, rotate is the most appropriate. After the transform value, state the number of degrees the element should rotate. Here we’re using a subtle two degree rotation. With this technique in place, your design has an added level of personality and warmth.

Technique 5: Fun forms

Oftentimes forms on the web can feel impersonal; handwritten fonts are a great way to bring some character to a simple contact form. By applying a handwritten web font to our form’s input and textarea fields, we remind users of the good ol’ days when people still wrote each other notes. Perhaps using this technique will remind the author of their humanity, and discreetly encourage them to be polite in their message.

I first noticed this technique on the gorgeous Foundation Six web site:

Adapting this style for bbballer, our form might look something like this:

You’ll notice that in both cases the input font size is set to be fairly large, which is important for legibility. This technique may also be too difficult to sustain for long forms, so I’d recommend reserving this style for quick interactions.

So there you have it! Five techniques for using once cringe-inducing novelty fonts. Perhaps you are now inspired to broaden your range of go-to typefaces; at the very least you’ve found a great excuse to spend the afternoon browsing type. Now if only we could find a way to use Comic Sans unironically.

Meagan Fisher is a web designer living in Brooklyn. In her seven year career, she has partnered with legendary design firms such as SimpleBits, Happy Cog West, Hoefler & Frere-Jones, and MetaLab. She writes about web design at Owltastic.

Type study is an ongoing series of guest posts about typography on the web. In this article, Ethan Marcotte dishes up advice on font size.

Yes, it’s true. This is a blog entry about sizing text for the web.

…look, I know you’re still out there. I can hear you breathing.

Sure, sizing text isn’t the most glamorous topic. What’s more, it can get downright contentious, with camps forming around their favorite units of measurement. The truth is, each approach has its own unique strengths and limitations. So below, let’s dive into a few popular methods, discuss them with a bit of equanimity, and wrap up this little essay with a better understanding of our options for font-size.

Our old friend, the pixel

Let’s dive in with a quick little demo. To start us off, I pulled a short passage from an old, favorite book, marked it up in some basic HTML5, and applied some light CSS. If you’d like, you can view my little page.

Now, sharp-eyed reader that you are, you’ve probably noticed the markup’s as modest as the design:

<article>
  <header>
    <h1 class="main-title">
      <img src="dorothy.png" alt="" />A Brief Excerpt from <cite>The Wonderful Wizard of&nbsp;Oz</cite>
    </h1>
    <h2 class="byline">by <a class="person" href="#">L. Frank Baum</a></h2>
  </header>

  <div class="article-body">
    <p><b class="caps">The Lion hesitated</b> no longer, but drank till…</p>
    …
  </div><!-- /end .article-body -->

  <footer>
    <p>Words by …</p>
  </footer>
</article>

Our page is essentially one big article element, which contains:

1. A header to house the headline (h1.main-title) and byline (marked up oh-so-imaginatively as h2.byline).
2. The primary text is contained inside a div with a class of article-body.
3. Finally, a footer element rounds out the copy with some attribution.

Nothing too fancy, right? Well, the styling’s just as unassuming. Now, since this is an article about font sizing, let’s not worry our pretty little heads about layout. Instead, let’s focus on the fonts:

body {
  font: normal 16px/24px adobe-text-pro, Cambria, Georgia, "Times New Roman", Times, serif;
}

.main-title {
  font: normal 30px/36px abril-display, Palatino, Georgia, Times, serif;
}

.main-title cite {
  font-size: 42px;
  line-height: 50px;
}

.article-body {
  font-size: 18px;
}

.caps,
figure,
footer {
  font-size: 14px;
}

From the outset, it’s obvious the page relies heavily on Adobe Text Pro set on the body, with TypeTogether’s elegant (and new!) Abril Display prettying up our .main-title headline. And with those defaults established, the rest of the CSS is dedicated to specifying a few different font sizes: five rules, five different font-size values, each set in pixels. And that’s basically it.

Easy, right? I think that’s half the appeal of the mighty pixel, actually: just how easy it is to use. We can transfer a few pixel values from Photoshop into CSS, and — voilà — your work’s nearly finished. But efficiency aside, I think there’s something appealing about the promise of control that comes with declaring a few quick pixel values, a control that’s so darn appealing to us designers. But for all its strengths, px isn’t the best game in town.

In fact, there’s one well-known drawback to sizing type in pixels: Internet Explorer’s “Text Size” tool (still) won’t resize any text set in pixels. Now, it’s true that many desktop browsers, including more recent versions of IE, include some form of page zoom, which can magnify the size of your entire design, including its text. But older versions of IE are, alas, still out there.

Moreover, exploring alternatives to the venerable pixel might result in some real, practical benefits. Ever built a menu that allowed the user to dynamically change the size of text on a page? I’ve worked on a few, including one that launched recently. If your design’s universally set in pixels, each text size “level” would require you to redeclare sizes for every px-based element of your design. So it’s very possible that on some projects, pixels simply won’t scale. (Pun unfortunate, but intended.)

Now that I’ve stepped off my soapbox, let’s take a look at a slightly more proportional alternative, a unit of measurement that does play nicely with resizing: namely, the em.

Becoming context-aware with ems

Because I’m a sucker for nostalgia, let’s revisit our body rule. Here’s what we’re currently working with:

body {
  font: normal 16px adobe-text-pro, Cambria, Georgia, "Times New Roman", Times, serif;
}

Before we start getting more proportional, let’s tweak it ever so slightly:

body {
  font: normal 100% adobe-text-pro, Cambria, Georgia, "Times New Roman", Times, serif;
}

Catch the difference? All we’ve done is change the font-size value to 100%, setting our document’s base type size to the browser’s default, which is usually 16px. As a result, we’re left with a flexible baseline, a point of reference from which we can size our text up or down using relative units of measurement—specifically, the em.

It’s worth mentioning that some folks prefer setting the body to a font-size of 62.5%, as this gives us a relative baseline of approximately 10px—which can make relative font sizing much, much easier. Richard Rutter, author of the original 62.5% technique, wrote a fantastic article for A List Apart recommending 100% as a better baseline, one that ensured more consistent cross-browser results.

But I digress. Regardless of what your baseline preference might be, our job at this point is to convert our pixel-based font-size values into their em equivalents. To do so, we’ll need to do a teensy bit of math: we’ll simply take the target pixel value we’ve already set, and then divide it by the font-size of its containing element — in other words, its context. The result is our desired font-size, but converted neatly into relative terms, which we can then drop directly into our CSS as ems.

In other words, relative font sizes can be calculated like so:

target ÷ context = result

Let’s take a quick example. Remember our main headline?

.main-title {
  font: normal 30px/36px abril-display, Palatino, Georgia, Times, serif;
}

In order to turn the headline’s 30px size into an em-based value, we need to define it in relationship to its context — that is, the font-size of the body element. Let’s assume our font-size: 100% is roughly equivalent to 16px. So let’s plug our .main-title’s target font size (30px) and its context (16px) into our formula:

30 ÷ 16 = 1.875

Boom. 30px is 1.875 times greater than 16px, so our font size is 1.875em.

Now you may recall that the book’s title was wrapped in a cite element inside our main headline, and sized a bit larger than the text that preceded it:

.main-title cite {
  font-size: 42px;
}

If we want to convert that 42px to ems, it’s important to note that our context has changed. Since we’ve set a font-size on our .main-title headline, the font-size of any elements within need to be expressed in relation to that value. In other words, our cite’s target value of 42px needs to be divided not by 16px, the body’s font-size, but by the 30px we set on our headline:

42 ÷ 30 = 1.4

And that’s it. With a little bit of contextual awareness, we’re left with a proportional font-size for our .main-title headline, as well as the cite inside it:

.main-title {
  font: normal 1.875em/36px abril-display, Palatino, Georgia, Times, serif;  /* 30 / 18 */
}

.main-title cite {
  font-size: 1.4em;  /* 42 / 30 */
  line-height: 50px;
}

(I personally like including the target and context values as comments in my CSS, usually off to the right of the relevant property. I’ve found it makes revising these relative values much easier, especially since the origin of a value like 1.875em might not be immediately apparent.)

Sizing text proportionally simply requires a little contextual awareness. And that applies to setting our document’s line-height, too. For example:

.main-title {
  font: normal 1.875em/36px abril-display, Palatino, Georgia, Times, serif;  /* 30 / 18 */
}

.main-title cite {
  font-size: 1.4em;  /* 42 / 30 */
  line-height: 50px;
}

The line height in both rules — 36px for .main-title, and 50px for the cite within it — are still in pixels, which means the line-height values won’t scale along with their respective relative font-size values. Presumably because they hate freedom.

But thankfully, we can quickly move those pixel-based values into something more proportional. But this time, our context is the font-size itself, our target the pixel-based line-heights. So with that in mind, let’s do a little bit more math:

36 ÷ 30 = 1.2

50 ÷ 42 = 1.2

There we are: both .main-title and the cite within it have a line-height of 1.2. And since the two elements share the same line height, we can actually just set the value once on the higher element, and let its descendants inherit it:

.main-title {
  font: normal 1.875em/1.2 abril-display, Palatino, Georgia, Times, serif;  /* 30 / 18; 36 / 30 */
}

.main-title cite {
  font-size: 1.4em;  /* 42 / 30 */
}

That is, as the kids say, that. What’s more, we don’t actually need to add units to the line-height, as Eric Meyer’s covered so ably before. Instead, we can leave that proportional value in place, sans pixels, percentages, or ems.

But yes! Context rocks! And armed with that knowledge, we can turn to our remaining pixel-based rules:

.article-body {
  font-size: 18px;
}

.caps,
figure,
footer {
  font-size: 14px;
}

As before, with some simple math and an awareness of a given element’s context, we can turn those values into oh-so-flexible ems:

.article-body {
  font-size: 1.125em;  /* 18 / 16 */
}

/* figure and .caps are children of .article-body, so their context is 18px */
figure,
.caps {
  font-size: 0.777777778em;  /* 14 / 18 */
}

/* The footer's context is the body element, so we'll use 16px here */
footer {
  font-size: 0.875em;  /* 14 / 16 */
}

And with that, we’ve successfully moved our page beyond the pixel. The design’s identical to the original px-based version, but considerably more flexible, proportional, and accessible.

Meet the rem

The em is powerful voodoo indeed, but it’s not without its limitations. Obviously, it requires an awareness of an element’s context, which can be unwieldy at best. What’s more, it can complicate moving modules within your design, as their font-size might be tied to a specific position in the document’s hierarchy. So for especially complicated, content-heavy sites, this could potentially require some work.

Thankfully, there’s been some traction on improving our old friend the em. Introduced in the CSS3 specification, the rem behaves much like the em: it’s a relative unit of measurement, sizing text up or down from a baseline value. But the rem is sized relative to the root of your document—in other words, the value set on the body element.

Here’s what our CSS looks like, once we switch everything over to rems:

body {
  font: normal 100%/1.5 adobe-text-pro, Cambria, Georgia, "Times New Roman", Times, serif;
}

.main-title {
  font: normal 1.875rem abril-display, Palatino, Georgia, Times, serif;  /* 30 / 16 */
}

.main-title cite {
  font-size: 2.625rem;  /* 42 / 16 */
}

.article-body {
  font-size: 1.125rem;  /* 18 / 16 */
}

.caps,
figure,
footer {
  font-size: 0.875rem;  /* 14 / 16 */
}

This is still relative font sizing, so we’re still using our target ÷ context formula. But now, our context is 16px throughout the CSS. That’s right: no more tracking various context values, worrying about which element’s inheriting which font-size value and going slowly mad. And as someone who hates math, this consistency is kind of exciting.

Sadly, support for the rem is still evolving. Firefox 3.6+, Chrome, Safari 5, and IE9 all support the rem. (And IE9+ even resizes text set in rems!) Unfortunately, while support’s broad, that doesn’t mean it’s universal. So if you’re supporting a significant number of browsers beyond that list, you might need to declare a fallback in pixels:

body {
  font: normal 100% adobe-text-pro, Cambria, Georgia, "Times New Roman", Times, serif;
}

.main-title {
  font: normal 30px abril-display, Palatino, Georgia, Times, serif;
  font-size: 1.875rem;  /* 30 / 16 */
}

.main-title cite {
  font-size: 42px;
  font-size: 2.625rem;  /* 42 / 16 */
}

.article-body {
  font-size: 18px;
  font-size: 1.125rem;  /* 18 / 16 */
}

.caps,
figure,
footer {
  font-size: 14px;
  font-size: 0.875rem;  /* 14 / 16 */
}

Sexy? Maybe not. But this hybrid approach leaves us with resizable text in rem-compliant browsers, with a pixel-based fallback for older ones — a match made in heaven.

Pixels, ems, and rems—oh my!

Whether you prefer slinging px or em, or have started dabbling in rem — each approach has its unique drawbacks and strengths, its own unique contributions to the project you’re working on.

Pixels afford a high degree of precision, but at the expense of versatility. And while ems offer us both the control we crave and the accessibility we need, there’s a certain amount of overhead with the contextual math involved. I hope better browser support means rems offer a way forward — but personally, those px-based fallbacks don’t feel like an appropriate trade-off. Hopefully, we’ll be able to move past those fallbacks soon.

Ethan Marcotte is an independent designer/developer who’s passionate about web standards, gorgeous design, and how the two intersect. He’s perhaps best known for starting that whole “responsive web design” thing, and even wrote a little book on the topic.

Type study is an ongoing series of guest posts about typography on the web. In this article, we hear from Russ Maschmeyer on a nifty trick for creating a responsive 3D text effect.

While perusing the Lettering.js website, I saw this example post by Trent Walton. When I saw that dynamically-generated graphic and the words “My site is responsive,” I assumed those letters would fold and unfold like an accordion to accommodate any browser width. Suddenly all seemed right and good in the world.

Trent Walton’s inspiring blog post.

Alas! As I pushed and pulled on my browser’s window pane, the graphic folded not. But what a great idea! Why hadn’t it been done? My life had new purpose. The result was foldup.js.

Foldup.js works with jQuery and Paravel’s Lettering.js to create an adaptive folding and unfolding effect for headlines, body copy, or any other text deemed worthy. Let’s walk through how to use it.

Example

Before we begin, let’s see it in action; the demo works in Safari, Chrome, Firefox, and Opera, but not Internet Explorer. (Think of it as an experiment.) Be sure to stretch and squish your browser’s window pane to really get the full effect.

The demo, at a wide browser width.

The demo again, but at a narrow width; the letters fold like an accordion.

Getting started

The goal is to get this working with as little HTML as possible, so, we’ll start very simply:

<html>
  <head>
    <link rel="stylesheet" type="text/css" href="css/style.css">
  </head>
  <body>
    <div id="page">		
      <p class="stranger foldup">Hello World!</p>
    </div>
  </body>
</html>

We’ve created an <html> document, added a generic style sheet called style.css, and created a <div> element which will become our page within the browser window. Finally, we’ve included some paragraph content that we’d like to fold up, and added a class of foldup to that paragraph. This will allow us to identify which elements on the page we actually want to fold up.

Adding style

We’ve got our content marked up, so it’s time to add some CSS so that our letters and words look and behave properly.

First, we’ll set the body background to orange (#ffa500) and declare our font stack — featuring Brevia, plus some appropriate fallback fonts. Next up, we want to set up a responsive, centered page to put our text in. We’ll give our #page element a width of 80% and center it with margin: 0 auto.

body {
  background-color: #ffa500;
  font-family: brevia, helvetica, verdana, sans-serif;
}

#page {
  width: 80%;
  margin: 0 auto;
}

Next, we’ll style the element to be folded up. In this case, we’re going for large, uppercase, and center-aligned for our folded letters.

.foldup {
  text-transform: uppercase;
  font-size: 3em;
  text-align: center;
  color: #FFF;
}

Now for the fun part. Lettering.js will dynamically wrap each word in its own span and label them sequentially (e.g. .word1, .word2, .word3, etc.). We can then use the child selector (.foldup > span) to style every span element within .foldup without having to know how many there are going to be. We’ll also set a display property of inline-block to keep long words from breaking into two lines and use margin: 20px 10px to set both the line height (20px) and the word spacing (10px).

.foldup > span {
  display: inline-block;
  margin: 20px 10px;
  border-radius: 12px;
}

Lettering.js will also wrap each letter of each word in its own sequential span element. We can reference these new child letters using another child selector: .foldup span > span. We’ll again set display to inline-block; next, we’ll set the width for each letter to 1.5em to make sure they have a consistent width which adjusts appropriately to the font size. We’ll also set the top and bottom padding to .2em and set position: relative; the latter allows us to adjust the vertical position of the letters with our JavaScript for the accordion effect. If you also wanted to add a background texture to each letter, this would be the place to do it!

.foldup span > span {
  display: inline-block;
  width: 1.5em;
  padding: .2em 0;
  position: relative;
}

The last three lines of CSS combine child selectors and pseudo selectors to round the corners of the first and last letters in each word; if there’s only one letter in the word, it rounds both the left and right side of the single letter.

.foldup span > span:first-child { 
  border-radius: 10px 0 0 10px; 
}

.foldup span > span:last-child { 
  border-radius: 0 10px 10px 0; 
}

.foldup span > span:only-child { 
  border-radius: 10px; 
}

Making it happen

Now that we’ve got our content and style prepped, it’s time to make it dynamic. First, let’s add our script files to our HTML document, like so:

<!-- Add Typekit Fonts -->
<script type="text/javascript" src="http://use.typekit.com/xxxxxxx.js"></script>
<script type="text/javascript">try{Typekit.load();}catch(e){}</script>

<!-- Add jQuery -->
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js"></script>

<!-- Apply our foldup plugin to our text -->
(function(){
  var foldEverything = function(){
    $('.stranger').foldup();
  }
  $(document).ready(foldEverything);
  $(window).resize(foldEverything);
})();

<!-- Add our foldup plugin to this page -->
<script src="js/foldup.js"></script>

The first two <script> elements enable our Typekit fonts (where the “xxxxxxx” is your kit ID). The third <script> element adds jQuery. The fourth <script> element applies the foldup effect to our .stranger element. The final script element adds our foldup.js.

Now let’s dive into the foldup function. Thanks to the help of Typekit’s David Demaree, the plugin is set up with some default parameters that you can change when initializing the function:

(function(){
  var foldEverything = function(){
    $('.stranger').foldup({
      containerWidth: 0.8,  // Width at which the effect begins working
      startColor: [255, 165, 0],  // Card starting background-color
      lowlightColor: [172, 111, 0],  // Card will dark to become this color
      highlightColor: [255, 194, 83],  // Card will lighten to become this color
      minShadow: 0.3,  // Lightest shadow, 1= darkest, 0 = no shadow
      maxShadow: 0.4  // Darkest shadow, 1= darkest, 0 = no shadow
    });
  }
	
  $(document).ready(foldEverything);
  $(window).resize(foldEverything);
})();

You can use all of these or just a few to customize how your foldup looks.

So, how does the foldup plugin actually work? Well, we start by figuring out how much the browser window is currently squished by comparing the current window width against our threshold for beginning the effect; then we determine how far past that threshold we are. Based on that, we dynamically adjust the values for the CSS3 translation properties, skewY and scaleX.

To change the color, we determine how far past our threshold we are and set our current color values for the highlight and lowlight based on how much we’ve squished our window. The more you squish, the closer the starting color gets to the highlight and lowlight colors.

For the shadow, we’re grabbing the span which wraps the whole word, setting the background to black, and then varying the shadow from sharp to blurry by adding a black CSS3 box-shadow which increases in size the more we squish.

When you put it all together it creates the rather convincing foldup effect!

Get the source

Well, that was fun, wasn’t it? If you’re not in the mood to recode this from scratch, I’ve put it all up on github (thanks again to David Demaree for his helpful suggestions). I hope this has thoroughly inspired you to try your hand at creating your own dynamic lettering work using Typekit, CSS, jQuery, and Lettering.js.

Russ Maschmeyer — also known as Strange Native — is an Interaction and
Product Designer at Facebook. He’s also 1/2 of dontfeartheinternet.com, a resource dedicated to teaching web design basics to even the most tech averse.

Type study is an ongoing series of guest posts about typography (and related disciplines) on the web. In this article, Pictory’s Laura Brunow Miner shows us how to use smart editorial to keep the focus of a distracted reader.

I don’t have a formal design education, but I’ve found common sense and psychology go a long way when designing for readers on the web (or anywhere else). In my eight years of publication design I’ve learned that the basics of editorial structure come down to pretending your reader has a short attention span. (They do.) A scattered reader might not be your ideal consumer, but it’s your most likely one — and understanding that can help you turn an occasional reader into a regular one.

Basics of editorial structure

Remember that thing I said about short attention spans? Or did you skim that part? No judgment. Everybody skims, so it’s the job of the designer to make it easy for a reader to dive back in at any point.

Maybe you don’t think this is necessary. Maybe you think, “If I make my content good enough, people will read it.” But think back to the television series Arrested Development. Remember how they subverted the classic “scenes from the next” and “previously on” segments into funny, non sequitur gags? Instead of, say, catching the viewer up or pulling them into the plot? This was fine for the rabid fans (and later, DVD viewers) but alienated anyone who tried to pop in for an episode. And it’s one of the reasons that a fantastic show was cancelled.

It’s easy for content creators, who spend their time immersed in a topic or publication, to lose sight of what it’s like for someone just discovering their work. That’s why focusing on specific strategies can be helpful. In magazine speak, we call the time-honored ways of catching reader attention “points of entry.” I’ll share a few of them here:

The headline is king

Your headline or title is your first chance to gain someone’s attention, and usually has the highest priority in a design hierarchy. This could mean that it’s in the top left, largest, or in the boldest font; in general, you just want to lasso the reader’s eye with your headline. If you’ve got budget for an illustrator, even better.

Beyond the design of the headline, you should also consider wording. You’ll want to try to accurately and concisely sum up your content, but it’s also helpful to imply a conflict (actual or metaphorical), contradiction, question, or other intrigue in your wording. For example: “New Life in the Face of Destruction” or “A Violent, Beautiful City.” (Note: There’s a difference between intrigue and sensationalism, and while inflammatory or accusatory headlines get a lot of short term attention, they undermine your integrity in the long run.)

Headline from a Pictory showcase. The word “secret” in a headline is an overused but effective method of gaining reader attention.

Decks for supporting information

A deck is a line that appears directly after your headline, and with a hierarchy generally lesser than the headline but greater than the body copy; it’s an optional opportunity to fill in your reader on the nuts and bolts of the content. The reason the deck is a high visual priority is that you’re a lot more likely to nab a skimmer with an informative one-sentence summary of the piece than any length of body copy. For example, the Pictory showcase headline “The One Who Got Away” needed no further explanation: it’s intriguing, relatable, describes the content, and has a bonus benefit of being a common phrase that people search for. But a title like “Local Legends” benefits from the supportive deck of “NPR and Pictory team up to share your stories of neighborhood heroes”; the latter helps clarify the intent of the photo essay.

Decks help people skimming your site understand your content at a glance and land on content that interests them.

Subheads, pull quotes, and image captions, oh my!

Subheads, or titles for each paragraph like the one directly above, don’t just summarize and break up blocks of content, they also act as another potential landing strip for your skimming reader. Pull quotes, or oversized repeats of a sentence or two of interesting content, do the same. A pullquote could be a similar size or even bigger than your deck (sometimes even dramatically large in a gorgeous font like LTC Bodoni), but should be tucked into the middle of your piece rather than at the beginning. This placement helps keep the deck higher up in visual priority.

Your reader may not think he is interested in your main topic, but may find something grabbing in a word or phrase in the subhead or pullquote. Similarly, it may seem unnecessary to caption a photo if it’s in support of your article, but this offers another point of entry into your topic from another direction.

Pullquotes aren’t just good for the reader — they’re also a fun way for the editor to share her favorite gems from a piece.

Image captions, like the one you’re reading, offer the reader quick, satisfying insight into what they’re looking at, without them having to re-read or search body paragraphs for the relevance.

Social media FTW

Designers of print magazines have to think about newsstand draw. Those of us with online publications have to think about pulling people in through social media. Many publications use Tumblr to showcase bite-sized pieces of a larger work, Twitter as an unofficial RSS feed of latest content, and Facebook to engage in interaction with the readers. In any of these cases, using the same rules as in headlines (implied conflict or a question) is a good way to grab attention.

Sharing bite-sized pieces through Twitter and Tumblr is a great way to support your publication’s main content.

It’s difficult to be objective about your own work, and impossible to see content you’ve put a lot of time into with fresh eyes. But putting care into your points of entry can help someone who is new to the content stay focused — and maybe even lead to loyal new readers.

Editor, designer, and photography lover, Laura Brunow Miner is founder of Pictory and Phoot Camp.

Last Thursday in New Orleans I attended a glass gilding workshop with John Downer and Leonard Otillio, part of TypeCon 2011. It was excellent, and I cannot recommend the experience highly enough. As a web designer, it felt great to use physical materials. And to be around John and Leonard, such careful stewards of their craft, was an education I could abstract; it’s easy to see opportunities for similar craftsmanship in the subtle and practical details of web typesetting.

During the workshop I picked up a few sign painting terms that were new to me, and relevant to web designers as browser support for CSS text-shadows becomes more widespread. Check out these various shading techniques on the demo page I made to accompany this post. Each of my examples uses multiple text-shadow values, which is pretty well supported (and even possible in Internet Explorer), but I encourage you to design with progressive enhancement in mind.

Bello Pro with a relief shade

h1.drop .relief {
  font-family: bello-pro, serif;
  font-weight: 400;
  background-color: #3a50d9;
  color: #e0eff2;
  text-shadow: -4px 3px 0 #3a50d9, -14px 7px 0 #0a0e27;
  }

The drop shade is a technique with which web designers are already familiar. There is a clear separation between the text and its shadow. It is as if the text is made of cut paper, floating above a surface. With a relief shade, there is a visible gap between the letter and its shadow. A relief shade can be achieved using two text-shadow values — one nearer to the letterform, and matching the background color. If the background is something other than a solid color, this won’t work.

Freight Sans Pro with a two-toned close shade

h1.close {
  font-family: freight-sans-pro, sans-serif;
  font-weight: 900;
  background-color: #fff;	
  color: #202c2d;
  text-shadow:
    0 1px #808d93,
    -1px 0 #cdd2d5,
    -1px 2px #808d93,
    -2px 1px #cdd2d5,
    -2px 3px #808d93,
    -3px 2px #cdd2d5,
    -3px 4px #808d93,
    -4px 3px #cdd2d5,
    -4px 5px #808d93,
    -5px 4px #cdd2d5,
    -5px 6px #808d93,
    -6px 5px #cdd2d5,
    -6px 7px #808d93,
    -7px 6px #cdd2d5,
    -7px 8px #808d93,
    -8px 7px #cdd2d5;
  }

With a close shade, the text shadow is connected to the text, which appears to give the letterforms thickness. Sign painters often include lighting effects too, varying the hue and value of a shade’s colors depending on where the hypothetical light source is positioned. This can be a particularly cool effect on storefront signage when the close shade is in sync with natural sunlight the sign receives. The close shade above uses diagonally staggered text-shadows in two different colors, so that the letters appear to have dimensional lighting applied.

I use the same staggered text-shadow technique for the printer’s shade below, with one small difference: toward the middle of the stack of text-shadows, I add a subtle blur. This smoothes out some of the LCD striping artifacts, and gives the type a painterly look.

News Gothic STD with a slightly blurred, two-toned printer’s shade

h1.printers {
  font-family: news-gothic-std, sans-serif;
  font-weight: 400;
  font-style: italic;
  background-color: #edde9c;
  color: #bc2e1e;
  text-shadow:
    0 1px 0px #378ab4,
    1px 0 0px #5dabcd,
    1px 2px 1px #378ab4,
    2px 1px 1px #5dabcd,
    2px 3px 2px #378ab4,
    3px 2px 2px #5dabcd,
    3px 4px 2px #378ab4,
    4px 3px 3px #5dabcd,
    4px 5px 3px #378ab4,
    5px 4px 2px #5dabcd,
    5px 6px 2px #378ab4,
    6px 5px 2px #5dabcd,
    6px 7px 1px #378ab4,
    7px 6px 1px #5dabcd,
    7px 8px 0px #378ab4,
    8px 7px 0px #5dabcd;
  }

A printer’s shade, to the right and on the bottom of letters, is something sign painters only occasionally use — because shades on the right sides of letters generally take more brush strokes to achieve. This is not a problem for printers (or web designers), and for that reason we don’t avoid it. But most styles of sign painting shade (see every other example in this post) appear to the left and on the bottom of letters.

Heirloom terminology like this helps us remember where we came from. Although browsers have only just begun to support CSS3, graphic design mechanisms like text shadows aren’t a new thing. We have boundless precedent on which to rely, if we know where to look for inspiration.