This guest post was authored by designer Nathan Ford.

I like to start with type when exploring the aesthetics of a project. From there, layout and other design considerations can take their cues from the content itself. But how does a type-centered approach to layout look on the web? And how does such a process work with the fluidity of the web to produce unique, engaging compositions at any viewport size?

To explore these questions, I’ll walk through my process for building fluid compositions that reflect the characteristics of a typeface, using three exceptional web fonts from Typekit as examples: DIN Condensed Web, JAF Herb, and Chaparral Pro.

Note: on each layout you can hit Cmd + G in OSX, or Ctrl + G in Windows to see an overlay of the grid system.

DIN layout
View the layout, and the grid system.

DIN Condensed Web

The first incarnations of DIN were originally designed in 1931 for the Deutsches Institut für Normung, the German standards organization. DIN 1451 was most famously used on German road signage for decades, and in the 90s it gained a broader popularity due to being one of the first quality sans-serifs released in the PostScript format. DIN Condensed Web, cut by ParaType and delivered through Typekit, again deftly adapts these classic letterforms for a new context.

The type

Given the heaviness of DIN, I had to set a base font size of 20px to make it readable for copy, and gave it a generous line-height. The historical relationship to “standards” made me think of uniformity and simple mathematics, so to honor this, I kept the the size and spacing of the text to increments of 0.5em. The lead-in text is 1.5em, while the body copy is 1em. Margins are set in whole ems as well.

The one exception is the headline, “DIN Condensed Web”, which I set with the viewport width (vw) unit. I tweaked this font size at various viewport widths to align it with the grid, rather than using ems to relate it to the other font sizes. I felt this created a stronger connection between type and layout.

The grid system

In consideration of DIN’s historical relationship to standardization, I knew I wanted to build this layout on one uniform grid, which necessitates more columns to inject variety into the composition. To me, this sounded like a standard we’ve had in the web industry for a while: the 12-column grid. But to make it interesting, I ditched any gutters so the basic unit of the grid, the column, is given more exposure in the layout.

DIN grid
12 column grid, no gutters

The layout

I tried to build a composition that was dynamic and felt as bold as the typeface itself. Starting with a comfortable, mid-sized viewport (around 1200px wide), I tried to push DIN into a more radical tone, with asymmetry and interesting whitespace.

Layout decisions came directly from the needs of the content. For example, the “Overview” section is thinner and shorter, allowing the deeper “History” content on the right more space. The margins above and below the lead-in copy are echoes of grid column widths, exploiting how top and bottom margins in CSS are based on the width (not height) of the page. Once I felt the composition was working at one size, I then started looking at various sizes by resizing my browser window, adapting the layout where it started to feel pinched or stretched. Later, in my testing phase, I fine-tuned the layouts on real devices.

Herb layout
View the layout, and the grid system.

JAF Herb

I truly respect what Just Another Foundry has accomplished with Herb. A throwback (way back) to the broken scripts of 16th-century Europe, Herb is not derived from frakturs as it may first appear, but instead is uniquely inspired by gothic cursives of that era. By blending blackletter qualities with roman forms, Herb is at once historic, fresh, and surprisingly readable.

The type

The aesthetic power of proportions, such as the Golden Ratio, shaped design in the 16th century — both in architecture and print. Book dimensions have not veered far from this proportion since the mid-16th century, and I found even the proportions of Herb’s thin and thick strokes fall close to (if not right at) 1:1.618. For me, this seems like a logical way to tie together the characters, layout, and history of this typeface, so every font-size, padding, and margin value is derived from this ratio.

Herb, showing proportions

The thin to thick proportions are roughly 1:1.618

The line-height of the copy is set to 1.618, providing ample space between the heavyset lines of text, and margins and paddings are set to either 1em or 1.618em. The large drop cap is 1.618em of the heading’s font size, which is set to 25vw to align with the grid.

The grid system

Building up from the type, the grid system is also derived from the Golden Ratio, with the viewport size determining which grid to swap in. On viewports larger than 960px, the main layout grid comprises three columns, each 161.8% larger than the last. The largest column is used for the main text body, while the two columns on either side provide a cohesive asymmetry. The outer padding, applied to the body, is 61.8% of the smallest column in the layout grid, again pulling from my chosen ratio.

Herb layout grid
Layout grid for mid-ranged viewports, based on the golden ratio

Within the main body of text, modular content grids are used to set margins and to place the block quote on viewports larger than 530px.

Herb content grid
Content grid for mid-ranged viewports, based on the golden ratio

The layout

By using an asymmetrical grid for larger layouts, I wanted to emulate the feel of a right-facing page from one of the Renaissance books that inspired this typeface and design. I pushed the Golden Ratio to tie the layout together as it expands and contracts on different viewports, showcasing the durability and character of Herb at all sizes.

Golden sections across facing pages
Golden section applied to book proportions, left and right-facing pages. Source: Wikipedia

Continuing with the 16th century inspiration, I fully justified the type, but also adjusted the grid and breakpoints to make sure that the measure mitigates rivers and holes in the text. To emphasize the dense, monolithic effect blackletter texts can impose, I ran the P tags inline and used pilcrows to break each thought, as was the (waning) fashion of that era. Perhaps unsurprisingly, JAF took the time to design a beautiful pilcrow for Herb. As unusual as this reading experience may be at first, the strengths of Herb allow for adapted Renaissance techniques to shine in a responsive environment.

Chaparral layout
View the layout, and the grid system.


Carol Twombly’s Chaparral is the most capable typeface I’ve worked with on screen, besides maybe Georgia. It is elegant at display sizes, distinct and readable even when tiny, and its italic is stunning. Those chunky semi-slab serifs also make it perfectly suited for backlit, pixel-based displays. Originally released by Adobe in 1997, Chaparral Pro still feels contemporary for web use.

The type

For this composition, I chose to take inspiration from the forms of Chaparral itself; specifically, I measured the proportion of the x-height to the cap-height, which is roughly 66:100. This correlation to the font’s x-height gave me the idea to experiment with CSS’s ex unit. Unlike the em unit, which is defined in CSS by the set font-size only, the ex unit is derived from the x-height of the font (as determined by the browser). Browser rendering of ex sizes is surprisingly consistent, as illustrated in this Codepen example highlighting ex-based line-heights on various fonts. By using the ex unit, I can keep the type size and spacing tied to both the layout and the typeface proportions.

Chaparral proportions
The cap-height to x-height proportion is roughly 66:100.

The grid system

This grid system was less of a preconceived plan, and more the result of adapting to the needs of the content and composition. To start, I approached the grid system in a similar way to my Herb layout, using the 66:100 ratio to derive a scale for creating both layout and content grids. To create a dynamic, novel layout worthy of showcasing Chaparral, I wanted to push the asymmetrical possibilities of the available space with the arrangement of columns. I revisited the grids numerous times while working on this layout, adapting it as needed to improve the balance of the design and provide enough readable space for the text.

Chaparral layout grid
The resulting layout grid for mid-sized viewports.

The layout

The long, tapered slab-serifs of Chaparral made me think of outdented headers, which grew to be a general theme of creating text overhangs. For a more comfortable measure and efficient use of space on larger screens, I split the body text into two uneven columns, using a short, thin left column paired with a wide right column. This leads to a text shape that again nods to Chaparral’s tapering serifs in the first two sections, and keeps the text comfortably within the height of the viewport for the last.

Chaparral content grid
The resulting layout grid for mid-sized viewports, showing content.

A foundation in type

By building up from the smallest component of our design — the type itself — we can more fluidly adapt our compositions from the smallest viewports to the largest, giving our content and type priority from the start. Pulling together a layout from the type may not always be practical, but this exercise has shown that on the web, we have unique new space to explore in the connections between layout and typeface, and this is just a start. What type and layout correlations can you find in your next design?


Nathan Ford

Nathan Ford is the creative director at Mark Boulton Design and the product lead at Gridset.

Kerning on the Web

February 5, 2014

Kerning can refer to one of two things: spacing instructions that type designers put into font files to mitigate awkward character combinations, or spacing adjustments that graphic designers make as they typeset text. In today’s post, we’re talking about the former, though we’ve covered the use of Kern.js and Lettering.js here before for readers interested in learning even more.

Imagine each character in a string of text has a box drawn around its outer edges. Without kerning, characters would line up at the edges of these boxes. Kerning enables these edges to overlap so the space between each character can be adjusted to be tighter or looser.

The word AWAY without and with kerning set in JAF Facit.
The word “AWAY” without and with kerning set in JAF Facit.

In the illustration there are three kerning values: “A-W”, “W-A” and “A-Y”. The “A-W” and “W-A” pairs share the same kerning value, while the “A-Y” pair has a larger kerning value. All kerning values in this illustration are negative, but it is also possible to have positive kerning values, which increases the distance between each character.

Browser support for kerning is surprisingly good. With the exception of Chrome on Windows, all modern browsers support kerning. There are, however, some differences in how kerning is enabled, and whether it is turned on by default or not.

There are currently two ways to enable kerning in CSS. The first is the text-rendering property introduced by the SVG specification to give hints to the text rendering engine. It was adopted by Gecko and WebKit based browsers (such as Firefox, Safari, and Chrome) to control text rendering for HTML as well. The optimizeLegibility value of the text-rendering property not only enables kerning, it also enables ligatures and other typographic features. However, it is not an official CSS property.

The second way to enable kerning is by using the CSS font-feature-settings property. This property can be used to enable or disable specific OpenType features, such as ligatures, old style numerals, stylistic sets, and kerning.

Browser support for these two properties is shown in the table below.

Browser text-rendering font-feature-settings
IE6 n/a n/a
IE7 n/a n/a
IE8 n/a n/a
IE9 n/a n/a
IE10 No Yes
IE11 No Yes
Chrome (Windows) No No
Chrome (OS X) Yes Yes
Chrome (Android) Yes Yes
Firefox Yes Yes
Opera <=12 n/a n/a
Opera 15+ Yes Yes
Safari 6 Yes No
Safari 7 Yes No
iOS 4.3.2 Yes No
iOS 5.1 Yes No
iOS 6 Yes No
iOS 7 Yes No
Android 4.1 Yes No
Android 4.2 No No
Android 4.3 No No
Android 4.4 Yes Yes

Chrome on Windows does not support kerning at all, which is caused by their use of GDI for rendering text. Chrome will soon switch to rendering text using DirectWrite and should then also support kerning and other OpenType features on Windows Vista and above. Kerning is enabled by default in Firefox and Safari 7 (on both OS X and iOS).

Surprisingly, the default browsers in Android 4.2 and 4.3 do not support kerning, while the default browsers in Android 4.1 and 4.4 do. This is caused by a bug in the support for the text-rendering property in Android 4.2 and 4.3. Android 4.4 uses Chrome as its default browser, which does not exhibit the bug.

To enable kerning in all browsers with kerning support, you’ll have to use a combination of the text-rendering and font-feature-settings CSS properties.

p {
  text-rendering: optimizeLegibility;
  font-feature-settings: "kern" 1;

Unfortunately, the font-feature-settings property is still new and requires vendor prefixes (and vendor-specific syntax for older versions of Firefox), so you’ll need to include those as well.

p {
  text-rendering: optimizeLegibility;
  font-feature-settings: "kern";
  -webkit-font-feature-settings: "kern";
  -moz-font-feature-settings: "kern";
  -moz-font-feature-settings: "kern=1";

In the future, you’ll be able to use the font-kerning CSS property to enable or disable kerning. The font-kerning property accepts three values: none to disable kerning, normal to enable kerning, or auto to let the browser decide whether or not to use a font’s kerning. At the time of writing this, the only browser that supports the font-kerning property is Safari 7 (on both OS X and iOS). In order to write forward-compatible CSS, you could write your CSS to include the font-kerning property.

p {
  text-rendering: optimizeLegibility;
  font-feature-settings: "kern" 1;
  font-kerning: normal;

Fonts served by Typekit include kerning data by default, so all you need to do is enable kerning through CSS. If you have questions about kerning or other OpenType features, please let us know at

On Weights & Styles

October 9, 2013

Today’s guest post is authored by designer Brian Warren.

While I was at Happy Cog, we designed and built our own blog called Cognition. It was one of our first projects using web fonts. We knew from the get-go that we were going to use web fonts, and settled on Clarendon for headlines and Franklin Gothic for a sans-serif that we used for navigation, captions, and various ephemera throughout the site.

Cognition homepage

I had a lot of fun as I started coding the site with type in mind. I’m sure you can relate to the feeling we got the first time we saw all of these beautiful typefaces in the web browser. However, we realized we had made a bit of an oversight.

In our excitement in getting to use web fonts, we had used far too many weights of Franklin Gothic, which was now bogging down the page weight. So I sat down with Chris Cashdollar, the designer for this project, and we made some tough decisions to pare the choices down to a few solid weights.

In retrospect, the final result was even better. The consistency offered by using fewer weights of the typeface, though somewhat forced upon us at the time, made for a more stable, effective design.

Respecting your constraints

What we learned is that it’s easy, way too easy, to get carried away with web fonts. I don’t know about you, but when I come across a really well-made typeface that has loads of weights and styles, all beautifully hinted and looking stellar across all the sizes you need, I can’t help but want to use them all.

But just because you can doesn’t mean you should. This is an important design lesson that applies far beyond typographic choices, but for the purposes of selecting type for a design, Robert Bringhurst summed it up succinctly in The Elements of Typographic Style: “Don’t use a font you don’t need.”

He goes on to say: “The marriage of type and text requires courtesy to the in-laws, but it does not mean that all of them ought to move in, nor that all must come to visit.”

Bringhurst is suggesting a simple, very deliberate approach to choosing typefaces for a design. Let’s work through an example.

Here is a sample of text set in Chaparral. It’s a simple paragraph with a headline. When choosing how to style the headline, my gut reaction is to make it bold and big. Again, Bringhurst suggests exercising a bit of restraint: “Change one parameter at a time.”

Modest headline example

So, perhaps choosing to set it in italic, at text size, is a solid move that allows some flexibility as we move up through the hierarchy. As we start to style the more important headlines (in web design parlance, moving from h6, h5, and so on up to h1), we can proceed to make small adjustments. Let’s keep going:

Two more headline examples

For the “slightly more important” headline, I removed the italic and chose the bold weight. The size is still the original text size.

For the “quite important” headline, I went back to regular text weight, and used a larger type size. In the end I have three rather useful and diverse headlines that were built from regular, italic, and bold text. I intentionally stuck with those three, because since we’re working with our main text typeface, bold and italic are already going be in my webfont kit. Of course you can pack whatever you want in your kit to start, but in my case, the body text has the regular weight, the bold, and the italic.

Mocking up the rest of the set is a simple matter of making more small parameter changes while staying true to the typeface.

Headline styles from h1 to h6

We’ve made it from h6 to h1 making only modest adjustments to the type, all the while sticking with either the regular, italic, or bold versions of Chaparral. I feel like we’ve only barely scratched the surface of what’s possible here. Other modest ways to differentiate might be to use color, or you could even (gasp) employ a line.

Does this mean you avoid using anything other than the main text typeface in your headlines at all cost? Of course not. Maybe a semibold ends up being the best choice for some of the headlines, or, jeepers, why not a sans serif? However, this exercise is enormously helpful in forcing us to carefully consider which typefaces make it into our project and which ones have to wait until next time. Giving extra weight (pun!) to these decisions is important from the perspective of both design and site performance.

When designing a full set of headlines like this, it’s a great idea to start with the smallest headline and work your way up like we did today. While you’re at it, make sure you design how bolds and italics look in a paragraph, as well as lists, blockquotes, and all the common styles that will show up in a page. We call this a “General Styles” page. You can include tables, images, captions, and even form elements. Planning ahead for the styles you might need in the future helps you build a more complete typographic system and avoid any surprises.

Be Good Not Bad

When I was redesigning my own site, Be Good Not Bad, I decided to put this idea of working within constraints to the test. From the headlines down to the body copy, and everywhere in between, I used a single typeface.

Be Good Not Bad blog homepage

The typeface I picked was Eric Olson’s Colfax a semi-oval sans serif with tons of spunk. The lowercase “a” immediately drew me in and didn’t let go. I knew when I saw it I could use it exclusively for my site.

I used three weights: Regular, Bold, and Black. It worked great for this design, kept my web font load nice and small, and was a fun exercise in restraint.

In the end, I don’t mean to rail too hard against web fonts or even using a few different weights and styles. I absolutely love that web fonts like Franklin ship with a bevy of different options. It’s beautiful, and there’s certainly a time and place for every single one of them.

The route I took with my blog is definitely not a prescription for designing every site. I love to mix it up, and you should too. What I do recommend, however, is to start small and keep it lean from the get-go. That will open up your options for when you flesh out the rest of your design.

Brian Warren

Brian Warren is a designer living in Seattle, Washington. He drinks a lot of coffee, brews his own beer, and adores playing with his kids. Read his blog at or follow him on Twitter at @mrwarren.

Understanding Letters

August 14, 2013

Today’s post was authored by Dan Mall, the founder and design director of Superfriendly design studio.

In order to choose appropriate typefaces to set beautiful passages of text, it helps if we have a baseline for what constitutes ‘appropriateness’. The art and science of choosing a great typeface is in the details, and demands that we attempt to understand the fundamental building block of typography: a letter.

In his book The Elements of Typographic Style—a book I consider to be a must-read for any student of typography—Robert Bringhurst begins with this powerful phrase:

Typography exists to honor content.

If ever there was one sentiment to summarize everything ever written about typography, this is it. Some content shouts; other content whispers. Similarly, some typefaces shout while others whisper. Letters—and, by that, I actually mean glyphs—and the differences among them are what make this possible.

The right configuration of letters within the right combination of words set in the right typeface or typefaces sends the clearest messages. To see this in action, who better to study than the masters of letters: logo designers!

Perhaps the most pervasive example of a logo that demonstrates such a command of letters is the FedEx logo, designed by Lindon Leader. At first glance, it appears to be a standard employment of Futura Bold. However, upon closer inspection, it’s very clear how masterfully the letterforms were modified to create the desired shapes, most famously the arrow hidden between the “E” and the “x.”

FedEx logo

Some of my favorite logos were created by the late Herb Lubalin. To call him a master of typography is an understatement. He’s created some incredible pieces of design:

Herb Lubalin logo samples

Guidelines for readable letterforms

Looking at and extrapolating from great examples can teach us some very useful lessons. Have a look at this beautiful logo by Volkan Eksi:

Pause logo

What a great balance of conceptual thinking without compromising readability! Why does this work so well?

Let’s look at two variations that might make this clearer. As quickly as you can, try to read each version aloud:

Paragraph samples with partial text

I’m betting version A was easier to read. (If you thought version B was easier, you probably have some special talents that you should be profiting from!) Version A is easier because the tops of English words are easier to read than the bottoms.

(For reference, here’s the full text.)

Full paragraph sample

This demonstrates a valuable lesson: when modifying letterforms, it’s safer to modify the bottom than the top in order to preserve legibility. The shape of a word—which we’ll get into in just a minute—is generally more unique at the top because there’s more variation in ascenders and majuscules; keeping the top intact preserves that uniqueness. Notice that all of these great pieces of lettering have most of the ornamentation and variation at the bottom rather than the top.

Ornamental text samples
Credit: Wedding lettering by James T. Edmondson, Greater by Chandler Van De Water, Melt by Agency26

Let’s look at another example that makes a different point about readability:

Mixed caps paragraph samples

Version A again! (Seriously, you version B-ers really need to join the circus or something.) This one tells us that mixed case is easier to read than uppercase. The reason is because we don’t read individual letters—we react to the shapes of words. Years of reading have gotten us accustomed to what words actually look like. Uppercase text creates more rigid rectangles, decreasing readability because we lose more of the shape of the word.

Word shape illustration

You may have seen an article passed around a while ago about readability. “Aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it deosn’t mttaer in waht oredr the ltteers in a wrod are, the olny iprmoatnt tihng is taht the frist and lsat ltteer be at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe.”

The reason you can still read this relatively easily is that the word shapes generally don’t change. It’s no coincidence that words whose shapes change drastically are the most difficult to read.

Word shape examples

So, back to the Pause logo we previously discussed. Why does it work so well?

  1. The modified “u” is only altered at the bottom of the letterform, not the top. Readability remains intact.
  2. The word shape was unchanged.

Pause logo with word shaping

Given the simple guidelines we’ve discussed, you’re now equipped to start—or continue!—playing with letters without sacrificing legibility. Good luck!

You can catch Dan talking more about typography at his full-day workshop at Smashing Conference.

Dan Mall

Dan Mall is the Founder & Design Director of SuperFriendly, a design studio that makes brave sites and apps for screens of all sizes. Dan is the co-founder of Typedia and The Businessology Show. Dan writes about design and other issues on Twitter as @danielmall and on his site,

Today’s post was written by Marko Dugonjić, a designer based in Velika Gorica, Croatia.

Subheads are typographic devices that establish content structure for the reader, providing a short overview of the content that follows. We can use them as points of visual interest or as simple navigational aids that gradually disclose the content. However, default subhead styles rendered by the browser can be too generic. If you’re looking for some variety, you can achieve some interesting effects with a pinch of CSS.

To start, we will bring together a few basic methods that can be combined and expanded upon:

  • sizing to a typographic scale
  • variations in style
  • hanging subheads
  • running-in subheads
  • non-alphabet symbols
  • crossbars

As we look at each of the methods, you can follow along on this demo page to see these—and even more—variations in action.

Sizing to a typographic scale

When designing a hierarchy for the web, a safe approach is to size subheads using a typographic scale—either a custom scale or a more established scale, such as the traditional Typographic Scale (16, 18, 21, 24, 36, 48, 60, 72) developed by Renaissance typographers back in the 16th century.

Start with setting the font size for the body, and then order the subhead sizes from least to most important. In my experience, h5 and h6 are rarely needed on the Web, so we shall start with h4 and move up to h1, applying the default Typographic Scale (16, 18, 21, 24, 36, 48, 60, 72).[1]

 p { font-size: 100%; } /* 16px */
h4 { font-size: 1.125em; } /* 18px */
h3 { font-size: 1.3125em; } /* 21px */
h2 { font-size: 1.5em; } /* 24px */


As you can see, the subhead values are too close to one another to be able to clearly distinguish between them, especially if the page is scanned quickly. This is where a different scale might be preferable, such as one based on the ratio 2:3 (perfect fifth), which we can use to increase subhead sizes in 50% increments.[2]

 p { font-size: 100%; } /* 16px */
h4 { font-size: 1.5em; } /* 24px */
h3 { font-size: 2.25em; } /* 36px */
h2 { font-size: 3.375em; } /* 54px */


The result is a much bolder design that’s also easier for readers to interpret.

Different styles at the same letter size

Web designers are accustomed to using the default bold weight for subheads, but now that we have much better screens and more capable fonts, we don’t necessarily need to use bolding to increase the importance of an element. Instead, we can experiment with different styles—such as all caps, small caps, and italics.

We will require a family with many styles for these tests, and I’ve picked Proxima Nova because an accompanying small caps style is available, as well as a range of widths. Whether you use Proxima Nova or another favorite font of your choice, be sure to keep versatility in mind here—especially since not all fonts feature small caps.


As with everything else in web design with CSS, there are a few methods you can use to style with small caps. One option is to apply the CSS3 OpenType feature rule.

h3 {
  font-family: proxima-nova, sans-serif;
  -moz-font-feature-settings: "smcp";
  -ms-font-feature-settings: "smcp";
  -webkit-font-feature-settings: "smcp";
  -o-font-feature-settings: "smcp";
  font-feature-settings: "smcp";
  text-transform: lowercase;

Another option is to load a separate small caps font. This has the added benefit of ensuring that small caps are present even in browsers that don’t support CSS OpenType features via the font-feature-settings property.

h3 {
  font-family: proxima-nova-sc-osf, sans-serif;
  text-transform: lowercase;

Hanging subheads

To expand the previous method even further, especially when we need to put emphasis on a document’s structure, we can use hanging subheads. This was a no-brainer when we were designing fixed layouts, but with the advent of responsive web design, relative units such as percentages can be challenging.[3]


We can use the following formula to calculate the width of a hanging subhead:

  • x = article’s left padding in %
  • subhead’s width in % = (x / (100 – x)) * 100
article {
  padding-left: 33.33333333%;

h2 {
  float: left;
  margin-left: -50%;
  width: 50%;

For more flare, a simple horizontal line can be just as elegant. Pseudo-elements :before and :after are perfect for such progressive enhancements to the basic design. We can style them either by applying borders or by applying backgrounds (or both).

Keep in mind that the inherited width of the pseudo-element equals the width of the subhead. In order to extend the pseudo-element to span the full article width, we must increase the pseudo-element’s width. Calculate the percentage of this extension by starting with the percent-based value of the article element’s padding. (As a formula, this looks like: (100 / padding of article in %) * 100 = pseudo element width in %)

h2:before {
  content: " ";
  float: none;
  display: block;
  width: 300%;
  height: .7em;
  border-top: .0625em solid #ccc;

Or, we could just apply a border to the paragraph that follows the subhead with CSS adjacent selectors:

article {
  padding-left: 33.33333333%;

h2 {
  float: left;
  margin-left: -50%;
  margin-top: 1.5em;
  width: 50%;
  text-align: right;

h2 + p {
  border-top: .0625em solid #ccc;
  padding-top: 1.4375em;


Finally, a hanging first letter is easy to achieve, and adds a touch of elegance. Try to match the hanging letter to a baseline to create visual unity—for instance, set it to span two lines of the adjacent text.

h2 {
  margin: 0;
  font-weight: bold;

h2:first-letter {
  float: left;
  width: 1em;
  margin-left: -1.1em;
  font-size: 3.4em;
  line-height: .9em;
  text-align: right;


Running-in subheads

Running-in subheads can be achieved by simple floats. An important consideration for this method is to match and preserve the x- and line-height for both the subheading and the adjacent paragraph.

h2 {
  float: left;
  font-size: 1em;
  line-height: 1.5;
  padding-right: .5em;
  margin: 0;


Again, this option can be expanded with variations in size and with accompanying bars. Use a light touch with these effects, however, to avoid overwhelming or distracting your readers.

Non-alphabet symbols

Pseudo-elements :before and :after can be very useful in a situation when decorative details are needed, because the markup can remain semantic. For example, to surround text with curly brackets, we’d simply add the following rule:

h2:before {
  content: "{";

h2:after {
  content: "}";

We can add a series of asterisks or just a simple dash under the heading, too. Simply set a display: block rule to an :after pseudo-element and increase its font size, thus bringing the finer details into focus. Even some common glyphs found in almost every font can look quite interesting when increased in size.[4]


The code is quite simple:

h2:after {
  content: "—";
  display: block;
  font-size: 2em;

Pseudo-elements are positioned inside the element, but precede and follow the string of text or child elements. That’s why it’s easy to position them relative to the element itself.


If you play with the paragraph alignment of your subheads, do so with consideration for how it affects the overall grid on the page. On their own, subheads flushed right are easily overlooked, and don’t serve as adequate document landmarks. The combination of paragraphs flushed left and subheads aligned centrally or to the right can result in a muddled-looking page.


Crossbars help to preserve the underlying grid of your page, particularly when the subheads are right- or center-aligned. To add a crossbar, we can use our old friend the :after pseudo element.

h2 {
  display: table;
  width: auto;
  padding: 0 .5em 0 0;
  position: relative;

h2:after {
  content: " ";
  display: block;
  height: .5em;
  width: 9999%;
  overflow: hidden;
  position: absolute;
  top: .6em;
  background: #ccc;

Go wild!

Feel free to use these examples as a starting point, and experiment by adding different styles and hues, combining typefaces, and modulating contrast. Combined with a carefully-selected body copy typeface, subheads can establish a clear, solid hierarchy that guides your readers to the finish line.

Marko Dugonjic portrait

Marko Dugonjić is a designer, speaker and author based in Velika Gorica, Croatia. As the creative and user experience director at Creative Nights, he improves customers’ digital experience for local and international clients. He founded FFWD.PRO, a micro-conference for internet professionals and his favorite pet project is Typetester, an online tool for testing screen fonts. He is @markodugonjic on Twitter.

Notes and resources

  1. Be sure to reset any line spacing defaults in your CSS, or you might see some unexpected results here. This code will do the trick:
    * { 
      margin: 0;
      padding: 0;
      font-weight: normal;
    html {
      font-size: 100%;
      line-height: 1.5; 
  2. For more inspiration and to quickly test a few different scales, bookmark Tim Brown’s Modular Scale calculator.
  3. The trick to maintaining flexible hanging subheads is quite simple, and is described in detail in my article, Offsetting an HTML element in a flexible container.
  4. If you need more ideas for glyphs you can use, just check out the table of UTF characters.

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

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.

Example of Source Sans Pro Light and Extra Light at 1x resolution

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 rendered at 1x and 2x resolutions

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.

Simulated example of type rendering on normal or high density notebook display

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

FF Meta in use as UI text

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

Source Sans in a UI context

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

UI text set in 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

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.

Billy Whited's portrait

Billy Whited works as a software designer for Centro, LLC in Chicago, IL. He holds a master’s degree in sculpture and occasionally tweets as @rocketspops.


  1. [PDF]

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)?

Two webpages, one task-oriented, one content-oriented.

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].

Illustration of how saccades work

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.

Illustration of letterform distinguishing details

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.

Similar letterforms in Futura PT

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).

Distinguishable letterforms in monotype

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]

Pixellated edges

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 shows good clarity of form

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.

Billy Whited's portrait

Billy Whited works as a software designer for Centro, LLC in Chicago, IL. He holds a master’s degree in sculpture and occasionally tweets as @rocketspops.



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 Sans and Freight Text, when overlaid, show similar structure.

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.

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.

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.

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.

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.

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

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.