Hypsometry. Modal Synthesis.

On tradition, harmony, pitch, the atonal, typography, Fibonacci, and coincidence.

Harmony and pitch.

In §3.1.1 of The Elements of Typographic Style, Robert Bringhurst draws an analogy between the sequence of type sizes traditionally used by typographers and the diatonic scale.

In the sixteenth century, a series of common sizes developed among European typographers, and the series survived with little change and few additions for 400 years. [...] This is the typographic equivalent of the diatonic scale. But modern equipment makes it possible to set, in addition to these sizes, all the sharps and flats and microtonal intervals between.

In other words, modern typesetting – done via software and printer, instead of type and press – allows the atonal. Unlike in music, however, alternate systems have not arisen.

Further, typesetting on the web makes it not just possible to avoid the traditional sizes, but actually difficult to set them. There are so many issues involved: Which browser is being used, what its defaults are, what units you use to specify sizes, the flow of inheritance of sizes through the page, etc. If you’ve done more than a dab of web design, you’re well familiar with how complex type sizing can be.

But what’s important here is not the precise size of each piece of text on your site, as rendered on the client by a browser. What matters is the size of each piece of text relative to the others.

To put it again in musical terms, the specific frequency of the note is less important than the overall structure of the scale containing that note. Harmony, not pitch. As if typesetting had returned to the days when one orchestra’s A was quite different from another’s.

The tradition.

Here’s a section of that traditional sequence, set for the web:

Long primer (10 point).
Small pica (11 point).
Pica (12 point).
English (14 point).
Columbian (16 point).
Great primer (18 point).
Double small pica (21 point).
Double pica (24 point).
Double great primer (36 point).

The traditional scale continues both above and below the sizes shown here. But this seems pretty much enough for the web. Much smaller, and the type is hard to read. Much bigger, and you’re dealing with a strange case.

Implementing this system is simple. Sticking to it rigorously, in the absence of any external constraints, is the hard part.

Implementation, in theory.

Following Richard Rutter’s text sizing method, I start by declaring the font-size of the document’s body:

body {
font-size: 100%;
}

This minimizes text size variation across browsers, especially in the extreme (large and small) sizes. 100% is, in theory, equal to 16px. User defaults and zooming can easily change that, even if nothing else does. But that’s okay: All I’m concerned with is the relative sizing of the type.

All the sites I’ve designed recently have had a wrapper div containing the entire contents of the page. Like so:

<body>
<div class="everything">
The whole damn page.
</div>
</body>

I can take advantage of that wrapper div to bring down the whole page’s font-size to 10px:

#everything {
font-size: 0.625em; /* 16px * 0.625 ≈ 10px, or long primer size. */
}

10px is great, both because it’s about the smallest size I care to use normally and because it simplifies the following math tremendously. All the visible contents of the page are contained within div#everything, so all the elements will inherit a computed font-size of 10px. So I can resize them in in terms of em, which is effectively a simple multiplier. To get 14px type all I have to do is multiply the inherited value by 1.4: font-size: 1.4em.

You might note that I’ve blurred the distinction between points and pixels. (Oh lord. Let’s not get into the whole pixel unit discussion.) And I’m talking about things in terms of pixels as if their sizes could be possibly be fixed. But again, neither matters here. What matters are the relationships between the numbers, not the actual numbers themselves. It’s a matter of harmony, not frequency.

You might further note that I’m not declaring the line-height of anything, nor discussing it at all. line-height is another story entirely, and one I’ll deal with separately.

At any rate, I can go on and declare the type sizes of some common elements based on the page-wide default of 10px I’ve set:

h1 {
font-size: 2.4em; /* 10px * 2.4 = 24px, or double pica size. */
}

h2 {
font-size: 2.1em; /* 10px * 2.1 = 21px, or double small pica size. */
}

p {
font-size: 1.2em; /* 10px * 1.2 = 12px, or pica size. */
}

Simple enough. Though, as I said above, the theory of the implementation is easy.

Systems.

This is not about blind adherence to tradition. A coherent, harmonious system is more likely to produce elegant and satisfying results than a haphazard jumble.

Other systems are, of course, possible. Bringhurst, in §8.2, suggests alternatives based on the Fibonacci sequence and the golden section, including two different double-stranded Fibonacci series, one used by Le Corbusier in his Modulor scale.

Those are intellectually satisfying, but their actual make-up seems less useful for typesetting on the web. The Modulor system uses fractional sizes, and browser sub-pixel rendering problems are ample enough in normal usage – no need to encourage them. And both sequences are lighter on sizes in the low end of the range, which seems the most useful part of it for web work.

The traditional sequence seems good enough for my purposes.

Coincidence.

Also note that today’s date, as written in the States, is 3-5-8, which makes today a sort of Fibonacci day.

On WebKit fanciness.

WebKit is kicking ass. It’s getting more use: First the iPhone, and now Android. More attention from the bloggers. Amazing downloadable font support. Futuristic HTML5 features: Clientside database storage, along with a slick query browser, as well as sophisticated media embedding and controlling.

But what’s got me most excited is how the WebKit team is pushing CSS out of its rut. In the past few weeks they’ve implemented a group of related features allowing for powerful CSS-based display manipulation.

Before I get into any details, just take a look at the following examples. (Of course, to see them properly, you’ll need a recent WebKit nightly build.) And be sure you hover over the paragraphs.

Testing this newfangled fanciness.

This one is scaled by 2.

This one is translated by 5em.

This one is rotated by 45°.

This one is skewed by 0, -45°.

In case you can’t see what’s going on here – and you really should check this out; it’s only a download away – all but the first paragraph are transformed, in the manners described. But the best part is that when you hover over a paragraph the transformation is removed, in a 1 second long animation. (The colors reverse too, just for kicks.)

This is accomplished through two extensions to CSS: -webkit-transform and -webkit-transition. The -webkit-transform property allows you to transform your objects, and -webkit-transition allows you to animate any CSS display property. Dave Hyatt described it thus:

The simplest kind of animation that we’ve added support for is called a transition. Normally when the value of a CSS property changes, the rendered result is instantly updated, with the element in question changing immediately from the old property value to the new property value. Transitions describe how to instead execute an animation from the old state to the new state over time.

That’s hot.

-webkit-transform takes a type of transformation – scale, rotate, translate, or skew – and a value, in parentheses. scale takes a unit-less value, like -webkit-transform: scale(2); rotate takes one CSS angle, and skew takes two, like -webkit-transform: rotate(45deg); and translate takes a length or percentage, like -webkit-transform: translate(5em).

(There’s also matrix, which allows you to “specify a full affine transform matrix”, and takes six values. I’ll be damned if I can get it to work though. So perhaps more on that another time.)

-webkit-transition allows you to specify a property, a duration, and a timing function. The property can be none, all, or the name of a specific property, like color, position, or -webkit-transform. The duration is a time in seconds, like 2s. The timing function can be the default, linear, ease-in, ease-out, ease-in-out, or your can specify your own cubic bezier function with cubic-bezier(x1, y1, x2, y2). In the examples above, I’ve specified -webkit-transition: all 1s ease-in-out.

There are clearly some kinks to be worked out. Just in the super simple examples above you can see that I had to set a different opacity value for the translated paragraph, and that the side borders of the rotated paragraph seem to have vanished. But it’s a hell of a start.

And it seems that these simple transforms and transitions are only the first of a range of visual effects that WebKit is adding to CSS. I’m looking forward to seeing what else they implement.

For more information, check out Hyatt’s two posts on Surfing Safari: CSS Transforms and CSS Animation.