Skip navigation
Help

X-height

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.
Original author: 
(author unknown)

For ideal typography, web designers need to know as much as possible about each user’s reading environment. That may seem obvious, but the act of specifying web typography is currently like ordering slices of pizza without knowing how large the slices are or what toppings they are covered with.

If someone asked me how many slices of pizza I wanted for lunch, I would probably say it depends on how large the slices are. Then—even if they told me that each slice was one eighth of a whole pie, or that they themselves were ordering two slices, or even that the slices were coming from Joe’s Pizza—any answer I might give would still be based on relative knowledge and inexact assumptions.

Such is the current situation with the physical presentation of responsive typography on the web. The information at a designer’s disposal for responsive design is virtually nonexistent outside the realm of software. Very little knowledge about the physical presentation of content is available to inform the design. The media query features of today can only relay a very fragmented view of the content’s actual presentation, and related terms from CSS are confusing if not downright misleading.

The immeasurable pachyderm

Among all the physical qualities of web typography, the elephant in the room is the issue of size. I’m not talking about em or rem or “reference pixels” ¹ or even device pixels. I’m talking about real, actual, physical, bona fide, measurable, size!

It’s ridiculous that we can send robots to Mars yet it’s still virtually impossible to render a glyph on a web page and say with confidence: “If you measure this glyph on your screen with a ruler, it will be exactly 10 millimeters wide.” Although actual physical size isn’t always the most important factor in web design, in some cases it is critical. For example, consider content for partially-sighted or low-vision readers: the ability to tweak designs according to physical sizes would enable designers to make conscious design decisions with much more sensitivity to how the type is actually being seen. And even where physical sizing is secondary to relative sizing, why shouldn’t we nevertheless be able to factor in physical size when establishing the relationships between different elements?

Physical considerations ≠ print design

I don’t believe web typography should be a screen-based imitation of print typography. One of the greatest benefits of web typography, and web design in general, is that it is flexible, adaptable, fluidly adjustable, without being locked into any one specific configuration. However(!), that doesn’t mean web designers should be forced to design without any means to address the issues of physical presentation. On the contrary, responsive design will not reach its full potential until it allows the ability to respond to the very important physical variables of digital media.

Please pardon the cliché, but when it comes to typography, on screens or otherwise, size matters. Physical size affects optical issues that change how the eye and brain process typographic images. Not surprisingly, typographers and typeface designers have been compensating for optical size-related issues as far back as Gutenberg.

You can’t expect a paragraph of type with the same relative line-height, column width, letter-spacing, and glyph proportions to function just as well on two different displays that have the same number of pixels but completely different physical sizes. It’s great that designers can adjust proportions between typographic elements if the canvas varies in relative size, but any such compensation is still based on guesswork and assumptions about the physical size of that canvas. When people disagree about the size or spacing of type on a website, there’s a very good chance that their opinions are based on completely different physical manifestations of the same content, even if their software and settings are identical.

Resolute resolution, absolute absolution

One of the most crucial factors in the size equation is resolution. And when I say resolution, I don’t just mean “how many pixels is this?”, or even “how many device pixels is this?”, but also “how large are these pixels?”

This is very different from the W3C’s “resolution” media feature in the current draft of the Media Queries Level 4 spec. You will note that the spec refers to resolution in terms of “CSS ‘inches’”—the quotes around “inches” are theirs, implying that they are not actually inches at all.

For an example of why physical resolution matters, imagine you are rendering text on a digital billboard with a physical resolution of one pixel per inch (1 PPI). Now imagine you are rendering the same text on a 200 PPI mobile device display. Even if you knew the actual number of device pixels that would be used to render your type (which itself is difficult to do with confidence these days), you would want to treat the two compositions very differently, both in terms of the typeface as well as typographic layout. The billboard type would likely require less space between letters. The letterforms themselves would benefit from narrower proportions, and could endure a higher ratio between thick and thin strokes. The type might even require different colors to optimize contrast at that size. These are all basics of typography and typeface design.

Unfortunately, in the current landscape of media query features, there is no way to know the difference between 16 device pixels on a crude LED billboard and 16 device pixels on a high-density mobile display. Heck, there isn’t even a reliable way to know if your type is 16 device pixels at all, regardless of how large the pixels are!

Pixels still rule, for better or worse

I know what some em-based enthusiasts might be thinking: “But you shouldn’t be specifying type sizes in pixel units to start with! All type sizes should be spec’d abstractly in relation to each other or a base font size!” However, in the current world of web typography, no matter what unit of measure you use to spec your onscreen type sizes—em, rem, px, pt, in, %, vh, or whatever else—at the end of the line, your specification is being mapped to pixels. Even if you leave the base size of your document to the defaults and specify everything else with em, there is still a base size which all other sizes will ultimately refer to, and it is defined in pixels.

This is because, currently, the only unit of measure that can be rendered onscreen by any operating system with absolute confidence is the lowly pixel. Until we have media query features that allow us to spec for situations like:

@media (physical-resolution: 1device-pixels-per-physical-inch) { … }

or:

@media (device-width: 10physical-centimeters) { … }

… any compensation for physical size is based entirely on rough guesses about the devices our content will be presented on.²

It’s a complete fallacy that the official CSS spec allows so-called “absolute” units of measure like inches, points, and centimeters to be mapped to anything but actual physical units. Ironically, previous versions of CSS treated these things as you would hope and expect, but a change was made “because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.” Call me idealistic if you will, but I am more of the mind that a spec should be written based on what is best for the future, not to cater to things that were made in the past.³

Getting physical

Any ability to leverage physical variables for web design will require a joint effort by several groups:

  • Device manufacturers will need to provide APIs that can inform the operating system—and, by extension, web browsers and web designers—of the actual physical properties of the hardware being used to present content to the user. Some device APIs are already beginning to show up in the world, but there is a long way to go before functionality and adoption are anywhere near dependable.
  • Standards organizations—the W3C in particular—will need to establish specifications for how to reference physical properties when formatting content. They will need to update (or at least augment) their existing “absolute” units of measure to be more meaningful, so they are more than just multipliers of sizeless pixels.
  • Software manufacturers will need to implement support for new specs relating to physical media features. Browsers are the most obvious software that will need to implement support, but the biggest challenge might be in getting native support for device APIs in operating system software.
  • Type manufacturers and type services will need to provide more diverse ranges of typefaces that have been optimized for a variety of physical properties. Ideally, many of the needed variations could even be provided on the fly using a broader approach to the ideas of font hinting.
  • Web designers and developers, last but not least, will need to build their sites to respond to physical properties, leveraging all variables to the benefit of their users.

Size and resolution are just the tip of the iceberg of physical variables that could be considered when improving web typography. Things like viewing distance, ambient light, display luminance, contrast ratio, black levels, etc., etc., could all be factored in to improve the reading experience. Even the ability to know some variables within the realm of software, like the user’s rendering engine or the presence of subpixel positioning, would go a long way toward helping web typographers design a better reading experience.

In the meantime, I’d love to see more of the players mentioned above start to at least experiment with what’s possible when physical features can be specified, detected, and factored into responsive designs in structured, meaningful, and predictable ways. Until we can do that, we’re all just ordering pizza without knowing exactly what will end up on our plate.

0
Your rating: None

  

Vertical rhythm is clearly an important part of Web design, yet on the subject of baseline, our community seems divided and there is no consensus as to how it fits in — if at all — with our growing and evolving toolkit for designing online.

This may be due to a lack of understanding and appreciation of the benefits that follow from a baseline grid, but it is more likely because baseline is notoriously difficult to get right, and no one yet holds the blueprint to its successful implementation.

Some even argue baseline is redundant online, as typographic terminology and behavior on the Web follow different rules than those used in print, the frustrating discrepancy between line-height and leading being the most obvious example.

For now, however, let’s assume baseline is, to some degree at least, a useful tool for Web designers. What exactly is it, what tools do we have at our disposal in order to execute it, and, crucially, is it worth the hassle?

Baseline.

Vertical Rhythm And Pattern Recognition

Before tackling the mathematical, potentially pixel-nudging implementation of baseline alignment, it’s a good idea to get an understanding of its parent principle: vertical rhythm. By understanding the why of the baseline, we’ll be better equipped and more motivated to come to grips with the sometimes tedious and obsessive how.

Vertical rhythm, in simplest terms, concerns the structural height and spacing of vertically stacked elements, perhaps most commonly the padding, margins and line height. Just like a horizontal grid achieves harmony by restricting the layout to a set of predefined unit sizes, the vertical rhythm (or grid, if you like) solidifies the structure by offering consistent, predictable measures as the user scrolls down the content.

Grids are not only helpful on the horizontal axis, but also on the vertical axis.
Grids are not only helpful on the horizontal axis, but also on the vertical axis.

Why is vertical rhythm important? Well, it has to do with how our mind works and how we use pattern recognition to decipher the world around us. Without going into the subject at length (other people much smarter than me would be more suited to that task), one can say that pattern recognition allows the human brain to store similar or identical impressions (such as primary shapes or colors) in a pattern library and retrieve them for quick analysis of new stimuli. This is the reason why we don’t look at individual letters when reading, but instead recognize whole words at a time (by pulling previous instances of the same pattern from our memory bank). It’s also the reason why we instantly recognize the letters themselves (“A,” “B,” “C,” etc.), even if the font, size and color vary — the basic shapes are stored in our pattern library.

Now it follows that any stimuli that doesn’t match any of your existing pattern records will prompt a new entry in the memory bank, which, in turn, requires more brain processing power — and that’s where the importance of design structure and grids, whether horizontal or vertical, comes in. Imagine a simple layout with a consistent paragraph spacing of X. Having analyzed the first space, your brain will instantly recognize all other identical spaces as part of the same pattern. If, on the other hand, the same layout uses different spacing between each element, the reader’s brain would have to analyze all individual spaces in order to understand their meaning. In other words: the more different shapes there are for the brain to analyze, the longer it’s going to take.

Irregular shapes (left) require more processing power than regular shapes (right).
Irregular shapes (left) require more processing power than regular shapes (right).

As any irregularity in a structure will break the automatic flow of pattern recognition (thus wasting brain activity that could otherwise have been used on good content), a regular, consistent and predictable structure will, naturally, aid the legibility and cognitive interpretation of your design. Establishing a solid baseline grid is a great method to achieve just that.

Furthermore, utilizing a consistent system in which every vertical (and horizontal) space or element derives from a predetermined unit size not only eliminates arbitrary inconsistencies, but also makes the designer’s job easier by basing structural decisions on an overarching framework. Establishing a standard where, for example, headers always have two baselines of white space below them, and the padding of every box always equals three baselines, adds logic to our layouts and makes them easier not only to design, but also to build and, most importantly, digest.

Now, if vertical rhythm seem like an abstract concept, the second benefit of baseline — horizontal alignment across multiple columns — should be easier to grasp. Most commonly seen in print design, particularly magazines and newspapers that frequently use multi-column layouts, the baseline alignment of adjacent paragraphs (or headers) is delightfully calm when done right, and annoyingly disruptive when implemented badly or not at all. The quiet order arriving from horizontal alignment exhibits a visual confidence, an invisible scaffolding that holds everything in place and reassures the readers at a subconscious level. A book with every line on a left hand page aligning with their counterparts on the right simply feels trustworthy; a book where the lines don’t match up at all somewhat less so.

Horizontal baseline alignment across multiple columns.
Horizontal baseline alignment across multiple columns.

The Trouble With line-height

Traditionally, the baseline is the invisible line upon which most letters “sit,” and the distance between each baseline forms the basis of the baseline grid, which, as we just discussed, aids not only the vertical rhythm but also the horizontal alignment of elements in adjacent columns. Having defined a baseline grid, what follows is the forced alignment of all other elements, ensuring that any line of text, any border, any image or boxed element will always match up and adhere to the same vertical structure.

The trouble is that where tools like InDesign let you do this by clicking a button (literally switching the grid on and off) and allow you to easily resize shapes to fit, when it comes to CSS, there’s no other way to do it than meticulous restriction and monitoring of line height, padding, margin, size — anything that may affect the total height of an object.

The traditional baseline is the line upon which most letters sit and from which the total height of elements should derive.
The traditional baseline is the line upon which most letters sit and from which the total height of elements should derive.

To make matters worse, the CSS line-height property doesn’t have an inherent concept of baseline, and each line of text is placed roughly in the middle of the element’s total height. This means that perfectly aligning the actual base of your text (which is to say the baseline) across different styles and fonts requires further manual, time-consuming tweaking and pixel nudging.

So how does one go about implementing CSS baseline? Well, due to the lack of a native baseline syntax, snap-in-place or browser functionality to force vertical alignment, we’re left to experiment. But let’s start with the basics.

The Good: Basic CSS Baseline

To date, at least as far as I’m aware, no consensus on a right way to do CSS baseline has formed. Some people are happy as long as the line height and spacing follow a set of guiding rules, others are more obsessed and meticulous — for better or for worse — and are not satisfied until every line of text sits beautifully on the baseline, and images, borders, boxes and other elements perfectly align to the same grid. The good news for all of us, however, is that basic CSS baseline really isn’t that hard at all. By making a few design decisions up front (and sticking to them), all it takes is a bit of elementary math.

To define your baseline, it’s a good idea to start with the smallest text size you’ll be using, in most cases your body text, and work upwards from there. In my examples below, I’m using 14 pixel font-size on a 22 pixel line-height, which means 22 pixels is my baseline. This definition has the consequence that all line-heights and the total height (including borders, padding and margin) of all elements must be a multiple of 22 pixels, like so:

h1 { 
	font-size: 40px; 
	line-height: 44px;
	margin-bottom: 22px;
}
p { 
	font-size: 14px; 
	line-height: 22px;
	margin-bottom: 22px; 
}

Now defining our line-height and font-size in pixels is contentious at best, so in the name of scalability let’s convert them both to ems. Doing so makes the code a little harder to scan, but the math is fairly simple — just remember to recalculate the line-height if you change the font-size!

h1 { 
	font-size: 2.5em; /* = 40px/16px */
	line-height: 1.1em; /* = 44px/40px */
	margin-bottom: 22px; 
}
p { 
	font-size: 0.875em; /* 16px is the default em size */
	line-height: 1.5714285714285714em; /* = 22px/14px */
	margin-bottom: 22px; 
}

Note that I will invariably be referring to font-size and line-height in pixels throughout this article, as this will indicate more clearly the “physical” sizes and proportions in the examples given. All code, however, will stick to ems.

Utilizing a visible grid (many people use a background PNG or GIF, others use tools like Baseliner), we can put this to the test and monitor the alignment of all our styles as we go along. At this point, we may find that the lines of text don’t “sit” on the baseline, but rather float in between the gridlines. That’s nothing to worry about at this stage — we can simply offset our background image or add some arbitrary padding to the top of our body to fix it.

A visible grid can be very helpful during the design process.
A visible grid can be very helpful during the design process.

So far so good, but our code is still extremely basic. What happens when we include more pizzazz — for example a top border — to our elements? Naturally, the numbers have to be adjusted to incorporate the height of the border to ensure that the total height of the object adds up to a multiple of the baseline.

h1 { 
	border-top: 3px; 
	padding-top: 22px; 
	margin-bottom: 19px; /* 22px-3px */ 
}

Note how the 3 pixel border-top and the 19 pixel margin-bottom adds up to our baseline of 22 pixels.
Note how the 3 pixel border-top and the 19 pixel margin-bottom adds up to our baseline of 22 pixels.

Using Sass or REM

Although it’s not exactly rocket science, getting the numbers to add up when working on complex websites can be a challenge, especially when using relative units. If you’re in a position to sacrifice the scalability of ems and stick to pixels, however, frameworks like Sass can take a some of the sting out of it. With Sass we can define the baseline as a variable ($baseline, in my example) and use simple equations to define multiples of this, making the whole process a lot simpler and the CSS much easier to scan. Should you want to change your baseline halfway through the process, you only have to do it one place. Although my example below concerns Sass, the same principle would apply when using rems — defining the baseline in one place makes it easier to implement across your code.

$baseline: 22px;

.box { 
	padding-top: 3px; 
	height: $baseline*15; 
}
h1 { 
	font-size: 40px; 
	line-height: $baseline*2; 
	margin-bottom: $baseline; 
}
p { 
	font-size: 16px; 
	line-height: $baseline; 
	margin-bottom: $baseline; 
}

Using JavaScript for Images and Complex Layouts

Applying a baseline to a simple typographic layout is, well, rather simple. But we must also ensure other elements, including images, align to the grid. For containers, buttons, dividers, etc., this is a matter of restricting, by means of CSS, any unit to a multiple of the baseline. Images, on the other hand, rarely adhere to this restriction and are often served at a range of arbitrary heights, and in such cases a little bit of JavaScript can make our lives easier. I won’t go into the detail here, but both the jQuery plugin Baseline.js and this article on vertical rhythm by Matthew Wilcox are worth looking into. If you work on more complex layouts, you might want to check out FtColumnflow — a polyfill that “fixes the inadequacies of CSS column layouts.” It’s extensively used on the Financial Times Web app and may well be of use if you’re looking for something a bit more robust.

And that’s it for the basics. By making sure our line heights, paddings, margins, heights — everything — always add up to a multiple of our baseline, we can rest assured the integrity of our vertical rhythm remains unscathed. Simple, right?

Of course, you wouldn’t be reading this article if there wasn’t more to it…

The Bad: Improvising For Variety

The bad news is this. As much as designers thrive in restricted environments, sometimes a 22 pixel baseline can feel more like a frustrating barrier than a helpful constraint. For example, following the golden ratio, a paragraph body size of 16 pixels infers a paragraph header at around 26 pixels (though the below may apply to anything above 20 pixels, depending on the font). Keeping our baseline of 22 pixels, you may find that a single baseline is too tight a line height for comfortable reading, yet a double baseline (44 pixels) is too wide. Of course, arguably this only becomes a problem if the h2 runs onto two lines, and in theory one could get away with assuming the column width was big enough for that never to happen. Ahem. In theory.

h2 at an awkwardly small or large line-height.
h2 at an awkwardly small or large line-height.

If there was such a thing as snap-in-place, this wouldn’t be an issue, as we could simply choose not to apply our baseline to our h2 and watch in wonder as the the following paragraphs magically slotted back into place. But alas, no such sorcery is currently available and we’re forced to think pragmatically to come up with a solution.

At the start of this article I recommended defining your baseline from the line-height of your smallest text element, like the body text. As we’ve just seen, however, a fixed, minimum unit of 22 pixels (or whatever your body line-height may be) can make for awkward line heights for certain font sizes. But what if we were to halve our original baseline? Our body text would now technically have a line-height of two baselines, but that’s only semantics. In most cases, the resulting possibilities of variation and typographical freedom are worth it. Using the golden ratio to quickly define a few header sizes (rounded up or down to make our ems neater), we can easily see that a comfortable line-height is available at every increment: 16px/22px, 28px/33px, 40px/44px, etc.

h1 { 
	font-size: 2.5em; 
	line-height: 1.1em; 
	margin-bottom: 22px; 
} 
h2 { 
	font-size: 1.625em; /* 26px/16px */ 
	line-height: 1.2692307692307692em; /* 33px/26px */ 
	margin-bottom: 11px; 
}

h1, h2, and p all aligning to the baseline grid.
h1, h2, and p all aligning to the baseline grid.

The Ugly: Offsetting Type

Before I go any further, let me be the first to acknowledge that the following is completely experimental and some of you may even call it bad practice. If you’re willing to humor me, however, keep reading even as it gets ugly. Well, ugly from a “clean code” point of view. From a design point of view, it might get very pretty indeed.

Between the basics and a bit of pragmatic (but optional) improvisation to increase variety, we now have the knowledge and tools to improve the vertical rhythm of most layouts. But the baseline? Not quite. As mentioned before, the way CSS line-height is calculated means the characters are positioned roughly at the vertical center of the line height, rather than sitting neatly on the baseline of it with descenders protruding (like in InDesign or Quark). Many of you will rightly point out that this is what’s supposed to happen. This is how CSS line-height works, and there’s nothing we can do about it. That’s true. But our eyes don’t know CSS semantics. Our eyes are not trained to follow the x-axis center of characters when scanning lines of text — they’re trained to follow the baseline, the bottom of the characters, and when two adjacent lines are misaligned the readability suffers.

Take a look at the following example:

 h1 { 
	font-size: 2.5em; 
	line-height: 1.1em; 
	margin-bottom: 22px; 
} 
h2 { 
	font-size: 1.625em; /* 26px/16px */ 
	line-height: 1.2692307692307692em; /* 33px/26px */ 
	margin-bottom: 11px; 
} 
p { 
	font-size: 0.875em;
	line-height: 1.5714285714285714em; 
	margin-bottom: 11px; 
}
p.intro {
	font-size: 1.125em; /* 18px/16px */
	line-height: 1.22222222em; /* 22px/16px */
	margin-bottom: 22px; 
}

Placed in adjacent columns, even thought the baseline has been applied correctly to the intro paragraph, the base of the letters won’t line up to those of the main paragraph because of the font’s calculated line-height position.

CSS line-height makes alignment across adjacent columns inaccurate.
CSS line-height makes alignment across adjacent columns inaccurate.

Now this is where it gets ugly. In order to accurately align the base of all lines of text across all columns (which, of course, is one of the main points of having a baseline grid to start with), we have to offset the type manually. A simple way to do this is to add padding-top until the characters rest on the baseline and adjust the margin-bottom to reflect the offset.

h1 { 
	font-size: 2.5em; 
	line-height: 1.1em; 
	padding-top: Xpx; /* This requires trial and error, as X depends on your font and line-height */ 
	margin-bottom: 22px-Xpx; 
} 
h2 { 
	font-size: 1.625em; /* 26px/16px */ 
	line-height: 1.2692307692307692em; /* 33px/26px */ 
	padding-top: Xpx;
	margin-bottom: 11px-Xpx; 
} 
p {
	font-size: 0.875em; 
	line-height: 1.5714285714285714em;
	padding-top: Xpx; 
	margin-bottom: 11px-Xpx; 
} 
p.intro {
	font-size: 1.125em; /* 18px */
	line-height: 1.22222222em; /* 22px */
	padding-top: Xpx; 
	margin-bottom: 11px-Xpx; 
}

Messy? Perhaps. Tedious? Indeed. But very gratifying and wonderful at the same time. There’s nothing quite like turning on the baseline overlay on a complex layout to reveal the magic that is perfectly aligned typography.

All elements align across multiple columns.
All elements align across multiple columns.

Phew. If you’re still with me you’re probably either a masochist or have an unhealthy obsession with detail — either way I congratulate you, as your baseline is no doubt as solid as a brick outhouse.

Is It Worth It?

So there we have it. Basic CSS baseline is relatively easy and requires no more than a little math and organization to improve your layout. At the other end of the scale, we can manually adjust padding and margins to mimic the more sophisticated baseline of print design, a notion that will no doubt bring scowls to the faces of CSS purists. The real question, of course, is whether the visual benefits from manually offsetting type are worth it. In some cases, for example design-led campaigns and microsites, it could well be.

In others, particularly larger, more complex websites (your project managers will be scratching their heads wondering why it takes you so long to build the initial template) or collaborative projects with several developers working on the same code, well, it probably isn’t. Let’s face it — what we’re talking about in the most extreme examples not only adds manual labor, but also makes the code more intricate and harder to maintain. It will even affect the load time of your website if applied on a large enough project.

But consider this: just a few years ago, less-than-favorable techniques like “sliding doors” were advocated by industry leaders to hack attributes that CSS3 has now made commonplace. Were rounded corners really worth using two divs instead of one? Well, obviously, to some people they were — yet others may have considered them a waste of time, resulting in bad practice and semantically flawed code. But the point to take away is this: if no one experimented with such labor- and code-intensive techniques, we probably wouldn’t have native syntax for this technique today.

Experimentation, bad practice, hacks, ugly code — whatever we call it — has pushed, and continues to push, our syntax forward, reinventing the tools we will use to create and publish the next generation of online content. To echo Mark Boulton, “How cool would it be for CSS to be able to give you pain-free baseline grid?” Whatever your level of obsessiveness — whether your characters sit neatly upon their baselines or float in between them — vertical rhythm is always an important consideration, and following any of the approaches outlined in this article should result in a satisfactory baseline grid.

There will, of course, still be cases where the restrictions feel too impeding, and sometimes elements like captions, navigation or list items don’t seem to sit right in your predefined structure. In those cases, it’s worth remembering that a few compromises are not the end of the world. Some designers, including the eminent Khoi Vinh, argue that baseline is most important in the context of the main body of your content, and peripheral elements may break the baseline without breaking the layout.

Hopefully the understanding that there’s no right or wrong way of approaching baseline will incite further experimentation on your part, and I encourage anyone with a typographical affection to contribute to the ongoing process of making vertical rhythm an equal priority to horizontal grids in the future of Web design.

Good luck!

Resources

(cp)

© Espen Brunborg for Smashing Magazine, 2012.

0
Your rating: None

The new Myspace, designed by Josephmark, is unlike anything you remember from the infamous user-customizable disarray of the old social network. The design approach is more authoritarian/top-down, but results in a much cleaner, more sophisticated look. A large variety of views and layouts are supported entirely by multiple weights of Benton Sans.

We”ll have a more in-depth report when the site is fully available, but for now you can read more at Co.design and The Next Web. TNW coincidentally just relaunched with Benton Sans, too. No wonder they're a fan.

via Fonts In Use: Staff Picks

0
Your rating: None

What an amazing site. An exhaustive research on the Typographische Monatsblätter (TM) focussing on the issues from 1960 till 1990.

The Typographische Monatsblätter was one of the most important journals to successfully disseminate the phenomenon of ‘Swiss typography’ to an international audience. With more than 70 years in existence, the journal witnessed significant moments in the history of typography and graphic design. Its contributors include some of the most influential designers. Although the issues before 1960 are extremely rich in revealing the development of modernist typography, the years 1960–90 correspond to a period of transition in which many factors such as technology, socio-political contexts and aesthetic ideologies, profoundly affected and transformed the fields of typography and graphic design. From this general turbulence, new forms emerged and new models were explicitly manifested. The examination of the Typographische Monatsblätter during these specific years enables a greater understanding of the development of late 20th century typography and graphic design.

Via Aisleone.

0
Your rating: None

  

For years you have been searching for it. You hear the question being asked in your dreams as you go on an Indiana-Jones-type-crusade to find the answer. When the answer comes to you, you know that the confetti will fall from the ceiling and the band will start playing your favorite song. You might even get a kiss from that special someone. So what is this question?

What is the secret to Web design?

A tough question and one that might not have an answer. In 2006, Oliver Reichenstein wrote Web Design is 95% Typography. Some people loved it, others were not so amused. If Web design was based that much on typography, then what was the point of learning anything else? All you needed to do is understand the elements of typography and you were good to go.

Of course typography doesn’t mean font selection. With the advent of @font-face and services such as Typekit, Webtype, Fontdeck, and Google Web fonts, your skills in typography won’t improve. You can easily create wonderful designs with one font for the rest of your life if you choose to—they had to do it centuries ago and they didn’t have Photoshop sticking things to guides for them. If anything, more font selection will make things worse for you because creativity and beauty become hard to achieves when more options are given to us.

More toys means more fun though, right? If you want to go that route, then by all means go for it. I love to look at the different fonts being used and admire anyone that can successfully pull off using newer fonts for the Web. However, I’ve seen too many times what can happen when development options are given to the masses, and it isn’t pretty (re: Myspace). Instead of having a user agreement it would be cool if Typekit made you read a book on typography before you could begin using a font—the Web would improve tenfold, if that was the case.

I’m not being sarcastic, saying that is all you need to know for a majority of websites. Try going through all of the Web designs that you love, strip out the images and ask yourself “how would that website look with just text and spacing?”. When designers say “text is the interface”, they really do mean it. The iA site is a great example of that.

Information Architects
Information Architects is based around strong typography.

One of my all time favorite designs is A Working Library. The site is a showcase of text being the interface. The spacing is just right and the typography is on point.

A Working Library
A Working Library by Mandy Brown.

Some people find design like this to be dull and boring, they feel that design should have more pop to it. At the end of the day some extra visual flair might be what separates your design from the rest, but you need to get the first 95% down. The website that you are reading this article on now has done a wonderful job of presenting a visual design that isn’t reliant on images to be beautiful.

Well That Isn’t Hard

It’s possible to create a wonderful design without the use of images at all. I know that sounds crazy, but it is possible. I’m not saying it should be done, but if we can create elegance simply with typography and white space, then why shouldn’t we be able to create greatness when we start throwing in images, videos and other effects?

With the use of images I’m not talking about images that are needed to represent something such as icons, but images that are there for flare. Sometimes a picture is worth at least ten better words than any word you could use, so it’s better to go with an image (but you still need to consider using white space with it).

Here are two more examples of beautiful websites that place a heavy emphasis on typography to control the design. The first is Blake Allen Design and the second is The Harriet Series (both use images to represent their typography, but you get the point).

Blake Allen Design
Blake Allen Design uses images, but with great typography.

The Harriet Series
The Harriet Series by OkayType.

What makes the two designs above so interesting to me is that the typography not only guides you along a journey, but it does so with personality. You almost feel as if the typography is an expression of the person that designed it. Blake Allen uses Helvetica which gives the website a Swiss, clean and structured personality. On the opposite side of the spectrum, the Harriet Series website is a bit more playful and experimental—there is beauty in the organized chaos that the typography creates.

For 99% of the designs out there, typography and white space are going to be your underlying foundation. So if you can’t get them right, then the rest of your design has nothing to stand on. Stop worrying about the pop of your design and first worry about how it will stand tall. Once you get that down then you can begin to dress it up.

Clear is a very simple to do list application for iOS devices. While the majority of the excitement around it are the gestures used to control the interface, you will notice that the typography does enough to get out of the way and allow you to enjoy the application. Sure it is nothing more than Helvetica, but what if it was Comic Sans and had bad spacing all around? Great typography doesn’t have to stand out in a good way, but that doesn’t mean it should do enough harm when it stands out in a negative way, either.

Typography In Other Disciplines

Art of the Menu
Art of the Menu is a great website on menu design.

The Art of the Menu does a great job of showing the importance of typography in menu design. While a lot of restaurants like to add images and illustrations to their menus to give them a bit more pizzaz, they fail in providing a decent typographical structure that allows you to easily browse through the menu.

If you are a designer you have no excuse to say you can’t come up with a decent design. When you create a design that lacks a strong foundation, anything else you add to it is just going to make it worse. Too many designers attempt to save their designs with fluff without understanding they are pouring gasoline onto the fire. If a design is not enjoyable to read then it is not an enjoyable experience, no matter how many images, colors or sounds you decide to add to it.

Looking to understand typography a little bit better? Not too long ago Smashing Magazine did a comprehensive overview of some wonderful typography tools and resources.

(jvb)

© Paul Scrivens for Smashing Magazine, 2012.

0
Your rating: None

As someone who works with typography and design every day, I have a few books I turn to when I need to clear my mind of clutter. One of my favorites is Robert Bringhurst’s “The Elements of Typographic Style”, which includes this rumination on the sanctity of the title page: “Think of the blank page as alpine meadow, or as the purity of undifferentiated being. The typographer enters this space and must change it. The reader will enter it later, to see what the typographer has done.” Lines like this refresh my understanding of the task at hand and clarify my sense of purpose.

Carolina de Bartolo’s new book “Explorations in Typography” has a similar effect, albeit via entirely different means.

“Explorations in Typography” is arranged as a series of twenty-four chapters — the “explorations”. Using a short excerpt from Erik Spiekermann’s classic text, “Stop Stealing Sheep and Find Out How Type Works”, as a mantra, the book guides the reader through a kind of typographical meditation.

In 24 explorations spanning 188 pages, the Spiekermann text is repeatedly typeset, using a variety of techniques to indicate paragraphs and hierarchy. Each exploration shows several examples of a different method of indicating paragraphs in text (and a few later chapters explore different alignments and hierarchies). A new pair of typefaces is used for each example. A colophon and additional side notes about the typesetting and the history of the typefaces are included with each setting.

The explorations are thorough, covering typesetting techniques from the most basic (using indents, for example) to the unusual (using varying directions of text to indicate paragraphs). Typeface choices also range from classic to cheerfully odd. Throughout, the typesetting and page design remain austere and exemplary. As the author explains, the book is meant to further typographical education through an “extended visual taxonomy”, and the broad palette of techniques and typefaces is true to that spirit.

The book is primarily a teaching device, which de Bartolo created “specifically for more advanced typographic study”. She is serious about the book’s potential as a textbook, including advice for both teachers and students on how best to use the book. The depth to which the explorations go is beyond the interest of the non-designer and probably most neophyte designers. This is a book for people who care deeply about text design and typesetting — and for those who are required to care about it, in the case of students. For those of us who fit at least one of those descriptions, “Explorations in Typography” is a valuable resource, and a reminder of the extensive possibilities of digital typesetting. It’s also pleasing, and motivating, to page through the book and study the evolving settings of the text.

The book itself is a lovely thing. At 9.25″ × 12″, it’s large enough to house a letter-size page of typography plus annotations in the margins. The volume is casebound with thin boards and a sewn binding, so it’s sturdy but lightweight. The page design is clean and spare, with a transparent modular grid that provides a flexible canvas for the multitude of typographical settings. The text of the authorial voice is designed to guide the reader through the myriad design samples within. It’s a squeaky-clean, high-contrast treatment that presents a cool yet quirky sophistication.

My one complaint about “Explorations in Typography” is in its free-wheeling use of typefaces. No less than 171 different typefaces are used in the book — at least two for every setting. The type pairings are often interesting, but too often they distract from the typography itself. This is, after all, a book about fine typesetting, not a font catalog. I appreciate that the author included an appendix with a page of advice about choosing typefaces and a complete list of fonts used. But I often wondered whether the book would be improved by simplifying the type. To go to the opposite extreme, what if the exercises were all set in the same serif text face, with one sans face chosen for the headlines? Or choose five or six pairings. In either case, the particular typefaces chosen would be less important than the restraint itself — a book such as this, which seeks to show a variety of typographical tools through demonstration, would be well served by a solid, unchanging typeface selection. The typesetting would then be seen clearly as typesetting, free of the distractions provided by a new pair of fonts on every page. Additionally, the fonts, nearly all of which are drawn from the FontShop catalog, are mostly of the modern, late-20th-Century variety, a choice that will give the book a dated appearance in short order. Exercising some restraint on typeface usage would not only serve the book’s purpose, it would serve its continuing relevance.

The book’s companion website is as well designed as the book, in form as well as function. The site provides information and examples from the book, and includes a terrific and easy to use interactive page that allows the casual user to try out some typographical explorations of her own.

“Explorations in Typography” is a well-conceived, well-designed book that fulfills its goal. It is a unique and valuable catalyst of typographical contemplation. In addition, it’s a solid teaching tool, and a worthy addition to the libraries of design studios, type enthusiasts, and design instructors.

Patrick Barber is a graphic designer, photographer, style maven, and community food activist living in Portland, Oregon.

0
Your rating: None