One small, but quite good, reason to rejoice at the coming of a widely useable @font-face: True small capitals are now possible on the web.

Small capitals are, as Alec Julien put it, “upper case glyphs drawn at a lower case scale.” They are not, however, simply regular capitals shrunk down; they are properly their own font, with their own characteristics, designed to work with both regular capital and lower case letters.

To be more precise: 1. The cap height of a small capital is the same as, or just slightly larger than, the x-height of the typeface’s lower case letters. 2. The weight of the strokes of a small capital are comparable, visually speaking, to the weight of the strokes of the typeface in general, at the size being used. 3. The proportions of a small capital are also comparable, visually speaking, to the proportions of the characters of the typeface in general, at the size being used.

Two implications of the latter two points are that the strokes and proportions of a given small capital letter will be heavier and more spread out than the strokes and proportions of the same letter upper cased, at the same point size. This is because small capitals have the form of regular capital letters, but the characteristics of the lower case.

Unfortunately, true small capitals are hard to come by these days. Computer software, as a rule, uses fake small capitals, created simply by scaling down upper case letters so that they are smaller than the originals, but larger than the associated lower case. This is true of web browsers as well as word processors, desktop publishing applications, and vector editors.

For instance, the second line above should look about like this, using true, properly designed small capitals: But, had I not @font-face to rely on, your web browser’s fake small capitals would make it look more like this: Not at all the same thing, clearly. The proportions of the second example are all wrong – simultaneously too big and too thin, tracked too tightly, and rather difficult to read. The first example is balanced, strong, eminently legible.

Using true small capitals on the web was not possible until recently, at least not with type that is actually type. Let’s look at how it works, and also, along the way, at several ways to fake small capitals. Comparing them all side by side will make even clearer the import of the differences I described above.

1. Setting the font-variant property to small-caps.

This is what should work. The W3C CSS standard tells us that font-variant: small-caps will instruct the browser to do the right thing. “A value of ‘small-caps’ selects a small-caps font”, it says.

This is how your browser interprets font-variant: small-caps:

Giambattista Bodoni: February 16, 1740 in Saluzzo – November 29, 1813 in Parma.

That looks okay, I guess. In comparison to the small capitals, the upper case letters and numerals look overly heavy. Some of the small capital letters – the t and the m, for instance – have strokes that are so thin as to almost vanish.

Let’s look at a second example, to make the differences clearer:

A a a — M m m — X x x

Now you can see quite clearly that the cap height of the small capitals is substantially larger than the x-height of the lower case letters, to say nothing of the overshoot of letters like a and m. Also, you can see how the proportions and weights of these fake small capitals match neither the upper case nor the lower case. All in all, this style of fake small capitals works quite poorly.

But why is this? The typeface in which this page is set – IM Fell Great Primer – has a small capitals variant, so why do the browsers not use it? After all, the CSS standard says that they should when font-variant: small-caps is used.

Sadly, no browser has actually implemented this. Instead of looking to see whether true small capitals are available, they all jump to the next portion of the standard:

It is acceptable (but not required) if the small-caps font is a created by taking a normal font and replacing the lower case letters by scaled upper case characters.

I’m not sure who, precisely, thinks that that is acceptable, but even if it were, it is surely not acceptable to ignore existing small capital fonts created by proper methods in favor of bogus ones created on the fly.

2. The Joe Clark method.

Faced with the problems above, Joe Clark suggested a simple alternative: Convert the text to capitals and reduce its size. This is, of course, exactly what the browsers do when you specify font-variant: small-caps. The slight theoretical advantage provided by Joe Clark’s method is that you can more precisely and carefully control how much the fake small capitals are scaled down, leading, perhaps to better matching of heights, proportions, and weights. A simple example:

Giambattista Bodoni: February 16, 1740 in Saluzzo – November 29, 1813 in Parma.

Of course, applied like that, Joe Clark’s method forces all letters and numerals to small capitals, even if that’s not what you desired. A slightly more sophisticated version of his method would apply the technique selectively – say, to letters that are already lower cased. Let’s assume that you have an automatic way to do so – a CMS plugin, for example, or a clever piece of Javascript:

Giambattista Bodoni: February 16, 1740 in Saluzzo – November 29, 1813 in Parma.

This, of course, is a total pain in the ass, and it makes a bit of a hash of the text’s HTML. On the other hand, it does allow for more precise control of the size of the fake small capitals, which might be helpful.

To see that more clearly, here is a third example – the same as the one in §1:

A a a — M m m — X x x

You see the same problems as in §1: The Joe Clark small capitals are too big and their proportions are wrong. The weights, however, are not quite as bad. Let’s look at a fourth example, comparing the font-variant method and the Joe Clark method, in that order, to see how the two compare:

a a — m m — x x

The proportions and weights of Joe Clark’s fake small capitals are better than those of the font-variant method, but only because the letters themselves are even larger. Hard to call that an improvement.

3. The Nick Shinn method.

This problem of how to fake small capitals when no proper ones exist, or the software will not let you access them, is not unique to the web. Nick Shinn has suggested that, in addition to capitalizing and reducing the size of the text, you should increase its weight. This allows for making the small capitals a little smaller – a little closer to the actual x-height of the typeface – while better preserving their weights and proportions.

A simple example:

Giambattista Bodoni: February 16, 1740 in Saluzzo – November 29, 1813 in Parma.

A more sophisticated example, again – as in §2 – imagining some sort of automated helper, and ignoring the complexity of the technique and the hash it makes of the HTML:

Giambattista Bodoni: February 16, 1740 in Saluzzo – November 29, 1813 in Parma.

This looks better in some ways, and worse in others. It is still basically unacceptable. Perhaps in some contexts, with some combinations of typeface and size, this might work well. Here, despite the improvement in small capital size, the overly heavy weight is too much. Of course, the typeface you see here has no true bold weight, so your browser is faking it; perhaps it is too much to hope that a faked heavy weight could help us, in turn, fake small capitals.

Let’s compare upper case, lower case, and Nick Shinn small capitals:

A a a — M m m — X x x

Correct height and proportions with excessively heavy weight is no better than incorrect height. And it turns out that the x-heights are not in fact correct: They only appear correct at this size of type. Try resizing the text in your browser window, and you’ll see that the evenness is limited to the sizes I’ve set here.

A fourth example, this time comparing the font-variant method, the Joe Clark method, and the Nick Shinn method, presented in that order:

a a a — m m m — x x x

Of these three, the browser scaling method seems the best, despite is many flaws. None produce good results, and it’s far and away the simplest.

4. Using @font-face.

There is an additional problem here, besides the technical failings of the browsers and the limits of what you can express using CSS: Proper small capital fonts are a rarity. Type designers design them, foundries sell them, but few non–professionals have them on their computers.

The typeface in which the Hypsometry Blog is set is IM Fell Great Primer, a beautiful typeface first cut by Peter de Walpergen, acquired by John Fell in the late 1680s, and digitally revived by Igino Marini. In its original metal, IM Fell Great Primer consisted of romans, italics, and small capitals. Sr Marini has created OpenType versions of all three, and made them freely available. As such, I can use @font-face to specify the use of the small capitals variant.

An example:

Giambattista Bodoni: February 16, 1740 in Saluzzo – November 29, 1813 in Parma.

And, again, a comparison with the upper and lower cases:

A a a — M m m — X x x

Glorious. The cap height of the small capital x is precisely the same as the x-height of the lower case x – and this holds true even if you resize the text away from how I’ve set it here. The cap heights of the small capitals a and m are smaller than the overshoot of the lowercase a and m. The visual weight and proportions of the small capitals are all quite similar to those of the lower case letters, even while the forms of the small capitals remain true to the appearance of the upper case.

Just to be absolutely clear, let’s see all four methods lined up side by side – font-variant: small-caps on the left, followed by the Joe Clark method, the Nick Shinn method, and the true small capitals of @font-face:

a a a a — m m m m — x x x x

The @font-face method is far and away the best. Unfortunately, it is the best in appearance and the worst to use.

The biggest problem, as mentioned above, is that few typefaces have proper small capital variants. Of those that do, some include them within the regular roman file, which puts them off limits to web use. Unicode currently does not define a place for small capitals, which means that browser cannot access them.

For example, you’re likely to have the typeface Didot on your computer. The roman of that Didot includes small capitals, but as glyphs 264–389, located in the Unicode range called “Glyph Variants”, which you cannot access within a browser.

Assuming that you’re using a typeface that includes proper small capitals, and that those small capitals are included as their own distinct font file, then you must declare a @font-face rule that makes use of them. In theory, you would do have already defined your romans and italics something like this:

@font-face {
  font-family: "IM Fell Great Primer";
  src: local("IM FELL Great Primer");
}

@font-face {
  font-family: "IM Fell Great Primer";
  font-style: italic;
  src: local("IM FELL Great Primer Italic");
}

In other words, we’re defining a font family named IM Fell Great Primer, the roman of which can be found locally as “IM FELL Great Primer”, and the italic of which as “IM FELL Great Primer Italic.” The browser loads both of those fonts, and when a reference to font-family: IM Fell Great Primer is found it uses the former when font-style is normal, and the latter when italic.

According to the W3C standard, there should be no difference when defining a small capitals variant:

@font-face {
  font-family: "IM Fell Great Primer";
  font-variant: small-caps;
  src: local("IM FELL Great Primer SC");
}

In other words, the font referred to by this @font-face rule is the small capitals variant of the IM Fell Great Primer family, and can be found locally under the name “IM FELL Great Primer SC.” When the browser encounters a reference to font-family: IM Fell Great Primer with font-variant: small-caps, it should then go ahead and use the font referenced above. An example of such a reference:

p strong {
  font-variant: small-caps;
}

However, the browsers do not yet understand this. Firefox, for instance, only understands font-weight and font-style within @font-face rules. That means that you cannot rely on the browsers to automatically use the proper small capitals variant, even when you have explicitly told them the necessary details. Instead, you must define a redundant rule like this:

@font-face {
  font-family: "IM Fell Great Primer SC";
  src: local("IM FELL Great Primer SC");
}

And then use it like this:

p strong {
  font-family: "IM Fell Great Primer SC";
}

That way you have explicitly told your browser where to find the small capitals variant and when to use it. And, when forced in this fashion, the browsers do finally get things right.

5. Other details.

It’s a bit convoluted, all this, and I haven’t even touched on how to properly prepare your font files for browser use, or how to really make use of @font-face. To summarize, use the Font Squirrel.

To see the CSS for all the methods discussed above, take a look at my Hypsometric CSS project. If you have any questions or suggestions, do let me know.

Over at Hypsography my work is continuing apace, and that pace is increasing. I’m continuing my explorations of humane typography there. The site is now set in Sorts Mill Goudy, an excellent revival of Frederic Goudy’s incomparable Goudy Old Style.

If you view the site using a recent version of Firefox, you’ll even see that the f and i of field are joined into one ligature – as they should be. Firefox is currently the only browser that supports serious OpenType typographic enhancements. Where by serious I mean kerning and ligatures. Yes, 460 years have passed since Gutenberg began printing with moveable type, and we are just now returning to those basic capabilities.

At any rate, Sorts Mill Goudy is a beautifully rendered typeface. Barry Schwartz is its author, and he has made it available under both the Open Font License and the MIT License: OFL Sorts Mill Goudy and MIT Sorts Mill Goudy. You can also find it in the Typedia, along with another excellent, though less completely realized, Goudy revival by Mr Schwartz: Goudy Bookletter 1911.

I used the Font Squirrel’s @font-face generator to prepare the files for Hypsography, and I highly recommend it. To make the process even simpler, the Font Squirrel already has OFL Sorts Mill Goudy in its archive, along with a pre-generated @font-face kit. Or, if you prefer, both Kernest and Typekit also include Mr Schwartz’s Goudy revival.

From the information available on the project site, Sorts Mill Goudy appears to be a work in progress. Nonetheless, it seems quite ready for use right now. Using Tim Brown’s web font specimen, I’ve put up a demonstration page for Sorts Mill Goudy on Hypsography, for your further inspection.

To return to my initial point: Hypsography has a new look, a new section for news and other ephemera, and a newly added tetraptych. Enjoy.

While updating my reset stylesheet last week, I realized that if I wanted to reset the new HTML5 elements I would have to determine precisely how they were supposed to be styled. Which proved to be a challenge, since no browser yet supports anything like the full array of new elements and styles.

Luckily, the current HTML5 specification contains extremely detailed descriptions of how browsers should render HTML documents. These are not requirements, of course, but rather “a set of suggestions.” These descriptions, found in §11 Rendering, are of reasonable expectations; and thus it seems reasonable, in turn, that I base my expectations for the future behavior of browsers on them. (Realizing full well how deeply foolhardy that might be.)

Within the many suggestions listed in §11 – and they are many and detailed – there is one in particular that is relevant here: §11.2 The CSS user agent style sheet and presentational hints. This section walks through the varieties of default styles and describes how each HTML element is to be handled. Specific CSS is provided, and additional instructions and suggestions are noted. From time to time, the additional notes refer to styles best handled by CSS, though for the most part they don’t.

Regarding the new HTML5 elements, my goals are to:

1. Set up the appropriate display properties, so that blocks display as blocks by default.
2. Make sure that any elements that shouldn’t be visible are not.
3. Counteract, in a speculative, preventative manner, any styling that browsers are likely to apply.

§11 contains all the information I need to meet these goals. It describes the display types of the elements, including their visibility, and it describes all the other styling that should be applied by the browsers, once they support HTML5 more completely.

Therefore I compiled all the recommended CSS into one stylesheet. In doing so, I realized that the styles recommended are entirely too comprehensive. Styles for deprecated elements and elements modified by deprecated attributes are listed, so I removed them from my stylesheet. CSS bindings for each element are listed in §11.4 – but only Gecko supports that functionality, and it currently only supports it in a proprietary way; so I left out the bindings styles too.

In other ways, the recommended CSS does not go far enough. Two sets of styles, describing the appearance of h1 elements nested within the new semantic content elements, are so complicated that the draft standard only summarizes how they are supposed to work. Both §11.2.3 and §11.2.5 note that the styling of an h1 element varies depending on its context. Of course, h1 has its own default styling – font-size: 2.00em, for instance. But when you have an h1 nested within a section element – section h1, that is – it should receive font-size: 1.50em. And if you have another heading, nested even further - article section aside h1, for example – that should have font-size: 1.00em applied. This is important, since HTML5 has radically redefined how we are supposed to use headings.

Sadly, the draft standard authors have left it as an exercise to the reader to actually write the relevant styles, for all the nesting depths. I have done so, though I’m not entirely sure I’ve done so correctly. The permutations involved are reasonably complicated, particularly since section elements can nest within each other, though none of the others can.

There is only one additional change that I’ve made, a quite small one, but potentially useful. §11.2.2 Display types describes how each element should be displayed by default – head is hidden, blockquote is a block, table is a table, ruby elements are displayed like ruby characters, et cetera. The list of block level elements, however, does not include the details element.

An element new to HTML5, “the details element represents a disclosure widget from which the user can obtain additional information or controls”, according to §4.11.1. It is what the standard calls an interactive element, and is meant to act as a wrapper for other content which may be displayed or hidden as the reader prefers. The usage example provided – as well as the description of how to use the details element – suggests wrapping it around a dt and a dd, as if it were a special type of definition list. As such, it seems appropriate to style the details element as a block, and I’ve done so.

You can see the stylesheet that resulted from my compilation and editing on GitHub, along with some notes. You’re free to use it as you like. As always, please do let me know if you notice any problems or have any suggestions.

There are two important reset stylesheets out there, on the loose: Eric Meyer’s reset.css and YUI’s CSS Reset. Both are highly useful, though they differ slightly in the details of their approach and implementation. Eric intends for you to take his CSS and alter it to your needs, creating a reset stylesheet that works for your own projects. He describes it as:

The reset styles given here are intentionally very generic.… In other words, this is a starting point, not a self-contained black box of no-touchiness.

Yahoo, on the other hand, is aiming for a more complete resetting. They write:

The foundational CSS Reset removes the inconsistent styling of HTML elements provided by browsers. This creates a dependably flat foundation to built upon.

For a couple of years now, since Eric first described his ideas, I’ve used my own reset.css. A combination of Eric’s original code and YUI’s more comprehensive styles, modified here and there as needed. It has served well on many projects.

Now that HTML5 is at last upon us, my reset.css no longer quite fits the bill. For one thing, there are new elements that bring with them new default styles, which of course need resetting. For a second, other elements have been deprecated, and so I no longer need to worry about them. (Of course, you might, since your project might be different.) And for a third, and possibly most important, few of the new elements are supported sufficiently by the browsers.

Given all this, I’ve updated my reset stylesheet. It ignores deprecated elements, and gives the new ones display styles as needed. This also is not a self-contained box of resetting, but I do find it quite useful. You can find it on GitHub, along with some additional notes. You’re free to use it as you like. As always, please do let me know if you notice any problems or have any suggestions.

It’s not yet a new year, but I have a new home, this blog has a new life, and I’ve begun work on a new — though long overdue — project. The project is the realization of Hypsography, my field guide. This blog was given new form based on the beautiful typography of Cities of the Plain. And I’ve moved back across the country, to a valley limited by the Cascade and Siskiyou mountain ranges.

Let’s begin with the mountains. They call this valley the Rogue, but the Rogue River is north of here. The Klamath is to the south. Both rivers run from the Cascades to the Pacific, along vaguely parallel courses. Between the two lies a range of mountains called the Siskiyous, which are the northernmost of the Klamath ranges. The Klamath ranges extend inland from the Coast, covering the territory of what are — to the north and south, that is — the Coast ranges, though they are not two parts of the same system of mountains in geological or historical terms. Just south of here, around the border, the Siskiyous finish their eastern push where they collide with the Cascades. Ashland, the town where I now live, sits in the valley of a creek that flows into the Rogue, just north of that Siskiyou-Cascade intersection.

And, as you can see, the Hypsometry blog is back, for yet another go round. I’ve lost count of what incarnation this is — perhaps the sixth? The driving force here, this time, is simplicity.

The design was inspired by the gorgeous work done on Cormac McCarthy’s border trilogy; in particular, the title page of the first edition of Cities of the Plain, the concluding volume of the three.

In technical terms also, this site is as simple as it has ever been. Since I began designing and building websites — five years ago now — I’ve worked with a wide array of techniques for producing blogs. None has ever been quite right for my needs, so I’m trying yet another. With luck, this new system will have a little more sticking power. Whether it does or does not, expect my notes on the subject sometime soon.

Hypsography is my newest project, though I’ve been planning it for a couple years now. I have a hard time summarizing exactly what it is that I’m working on, in part because there’s so much to come and — so far — so little to show. I’ve written a few words about it on the site itself. But really, it’d be better if you just took a look yourself.