Nice Web Type

Stephen Morley:

Major web browsers automatically reduce the size of monospace text in a range of situations. They do this due to the greater width of many monospace typefaces in comparison to other fonts at the same text height. While well-intentioned, their handling of monospace fonts is fundamentally broken, and an unusual CSS rule is required to fix the problem.

(Via Joni Korpi.)

This is not a demo. I’m only explaining a need as I see it. I don’t have the JS chops to make it real. Maybe you do? — @nicewebtype / email hidden; JavaScript is required

When a responsive composition meets a viewport, there are different ways to fill space. What interests me most here is a fundamental triadic relationship in typesetting — that of a text’s font size, line height, and line length. Adjusting any one of these elements without also adjusting the others is a recipe for uncomfortable reading, which is one reason designers have such a difficult time with fluid web layout.

One way to fill space is to scale text while keeping its proportions intact. This preserves the size/leading/measure relationship, and can work really well for some experiences (see Mark Hurrell’s post on orientation and fluid grids). But an increase in font size can be jarring to readers; A larger font size affects reading distance comfort. If I were to rotate my iPad while reading, and the text scaled up, I can imagine needing to hold the device a few inches farther away as a result. This is not what designers want to have happen to text intended for reading.

Another way to fill space is to use fluid widths. The problem in this case is that CSS line-height is tied to font-size, which is rooted in browser font sizing and environmental resolution, while line length is based on width, which is rooted in viewport dimensions. So a carefully balanced relationship among font size, line height, and line length easily breaks down. We end up with line lengths that feel too long, font sizes that seem too small, line spacing that feels too tight or loose.

What we need is a fluid way to set line height. Web designers should be able to define line height as a range, like we do with min- and max-width. I made a simple page to visualize how I’m thinking about this. Molten leading would maintain a specific font-size while adjusting line-height based on width. In other words, I would essentially like to tween a paragraph from this:

width: 15em;
line-height: 1.3;

To this:

width: 36em;
line-height: 1.4;

So that it would be possible to find line height dynamically at any given point in between:

width: 30em;
line-height: 1.371428571;

To find that line-height value, I used this formula: ((current width − min-width)/(max-width − min-width)) × (line-height − min-line-height) + min-line-height = line-height. With actual values, that’s: ((30em−15em)/(36em−15em)) × (1.4−1.3) + 1.3 = 1.371428571.

What I’m not sure about is how to get the min/max widths of an element that are needed for this formula. If CSS authors routinely defined elements’ min-width, max-width, line-height, and some kind of min-line-height, that’d of course be ideal for this:

p {
  max-width: 36rem;
  min-width: 15rem;
  line-height: 1.4;
  -js-min-line-height: 1.3;
  }

But that’s not always practical. Often, the width limits of a given text block will be determined by percentage-based inheritance (66% of the parent element, which is 85% of its parent element…). It’d take some box model math to identify those narrow/wide limits. A script would have to figure out, for a given element, how wide/narrow can this grow?

If it’s possible to glean that information from existing CSS rules, then the only thing designers would need to define explicitly is a minimum line height. That value could be passed as a function argument, or maybe found in the CSS by looking for that -js-min-line-height rule in my example above.

This feels like a step toward more natural typographic behavior on the web. I’m just not sure where to go from here.

Also, for what it’s worth, Andy Clarke talked about this in 2010. His solution was to use media queries:

Type tip: As the width of the measure (line width) becomes wider, leading (line-height) should be increased to aid readability.

How can we solve this, and adjust the amount of leading as the width of a browser window changes? With CSS3 Media Queries.

What I’m talking about is augmenting CSS with range rules (effectively, min/max line-height) that don’t yet exist, but should for the sake of fluidity.

Nathan Ford argues for indented paragraphs on the web. I have begun to indent here at Nice Web Type, and I think it looks better. See also: Jon Tan’s post on The Paragraph in Web Typography.

Trent Walton:

If there’s anything I’ve had to learn the hard way through all of this, it’s that responsive web design isn’t bolt-on. Whereas progressive enhancements like border-radius, or web fonts can easily be added and removed from a site, responsive for me at least has required a complete redefinition of how I approach my craft down to the pixel.

Right on. Web fonts are indeed plug-and-play easy, but there is so much potential in type. Type is the constant upon which our responsive designs depend. Changing your typeface changes everything. That’s why, little by little, I’m building this Responsive Typography reference. Which, let’s face it, will inevitably be full of links to Trent’s blog.

Mike Swartz:

Designers package and present information. The content is nebulous until a designer forms it into a digestible package. Now I’m not just talking about just “capital D” design, but anything that interfaces between content and consumer. It could be an .txt file set in 10px Monaco, or it could be an illuminated manuscript. So the entire design profession as it exists today is about taking abstract information out of the heads of content producers (or ourselves if we do both) and getting it somewhere where people can read/see/hear/watch/whatever it.

I think by definition canvases must be involved. I’m not talking about break-points versus fluid. I’m talking about the fact that what designers do is make containers.

Sure, designers make containers in that we parse and present ideas. But as we make practical decisions about typesetting and layout on the web, “containers” is a problematic concept.

Containers have lids. Containers prevent spills. Containers can be half empty or too full. There are obvious advantages to a container labeled “nails” that has nails inside, but a coffee can and a warehouse can share that label — and on the web, the coffee can is the warehouse. They are one thing. And such a thing has very different spatial and behavioral properties than a container.

Web content isn’t a mess to be contained or a garage to be organized. It is an orchestrated collection of objects to be interpreted and forces to be felt. No wonder fluid layout – confounding as it may be – feels most natural.

Roger Black:

All my life I’ve been hearing about the distinction between high brow and low: the critics’ ignorance of rock and roll, magazines’ dismissal of TV as an art form, and the news media’s blindness to popular culture. The old guard never gets it.

Web designers aren’t real designers.

We’ve got to strive for higher Highs. As we’ve seen in magazine and web site design, if the bottom is [to] be raised, the best design has to be more than accurate, clean and professional. It has to hit it out of the park.

Mr. Black is right: We need to hit design home runs. In this regard we have much to learn from established design professionals, and we look to them. When it seems like they don’t respect what we’re going through with the web, it hurts. Never mind home runs, we’re still building the ballparks and writing the league rules, playing our games in vacant lots and overgrown grass fields. If we’re not doing the most intellectually or artistically stimulating work, it’s not for lack of skill or desire.

When we eventually do get this web design thing sorted, we will be doing the kind of emotionally powerful work that the “old guard” expects, that we all want to do. It will have taken generations of web designers, remix upon remix, and career after talented career spent laying the foundations for Design as we’ll later know it, but we’ll get there. When we do, let’s remember the values of community, sacrifice, heritage, and encouragement.

Stephanie Rieger:

Here’s the deal. Your grandma can now create a viewport. And so can the kid next door. These may not be ‘proper’ browsers, and they may not (yet) be fully interactive, but they can load a pretty sophisticated web page. A year from now, the most popular ‘browser’ may just be be the embedded web view full of ‘related’ links in a Stephen King iBooks bestseller.

Basing breakpoints on popular viewport dimensions is clearly a foolish pursuit.

Stephanie Rieger:

Major breakpoints are set using media queries in the document head. The minor breakpoints live within those 2-4 style sheets and provide (mostly) the tweaks needed to remove awkwardness. This in effect creates media queries within media queries and provides huge flexibility while keeping it clear why each breakpoint has been set.

One of many good pieces of advice from Stephanie’s On designing content-out.

Think about the responsive nature of any particular web experience as a continuum of being. Along this continuum, on one axis, the experience can grow wide or narrow. Along a different axis, it can be near or far. Along a still different axis, it can be coarse or fine. There are many axes.

As a designed experience moves along a particular axis, it grows uncomfortable for any number of reasons: paragraphs feel too narrow or wide; font size feels too large or too small; elements touch or become awkwardly distant from one another. To cope with this discomfort, we use breakpoints. Breakpoints are moments of change. They allow us to make design adjustments that are only possible by changing the value or presence of CSS properties. We should invoke breakpoints as they are needed by our designs.

However, some design adjustments just happen in ordinary CSS. Properties like floats, positioning, min- and max-width, and relative units of measurement (percentages, em, rem, unitless line-height) help us negotiate the collective moments between and among breakpoints. Think of these as range rules. Range rules are behavioral limits baked into CSS. For instance, if a column uses min- and max-widths, these are rules that govern its range of motion. When elements in a layout float, but then bump against the limits of adjacent elements, this is a natural part of CSS — there is a range of acceptable behavior.

Range rules are not bounded by breakpoints. A fluid composition could use no breakpoints at all, and still the natural interplay of CSS behaviors could be evident. In a case like this, elements could stack, float, reflow, and resize, with all behavior governed by flexible CSS rules that permit a range of possible existence.

Range rules are also permeable. Breakpoints can trigger changes at any point along any axis of an experience continuum, and have the potential to both purposefully modify and accidentally disrupt the range rules they intersect. For instance, a breakpoint may cause a composition’s font size to increase after a certain viewport width is reached, and this may occur before or after a paragraph within that composition has reached its max-width. And if that same paragraph’s max-width is em-based, the rule that governs its range now has different absolute limits than it once did (it can grow wider now, because the unit on which it is based has become larger).

Responsive design is about rules, not truths. When we design responsively, maybe it would help to think of elements in a composition as having range rules that coexist and do not necessarily align, rather than treating the continuum of experience between breakpoints as something to be hopped over.

Does this make sense?

I wrote this post in a pretty authoritative tone, but I don’t exactly mean it that way. I found it most comfortable to write as if I were, like, explaining the scientific properties of web design. I am still not sure that this makes sense. Please let me know what you think.

Thanks to Ray Schwartz and Chris Silverman for their feedback and general awesomeness. Thanks also to Mark Boulton, Nathan Ford, and Alex Morris, whose tweets today helped motivate me to articulate this all (those guys are incredible, they were already writing about zones/ranges last year!).

Stephen Coles invited me to review a typeface for Typographica’s famous yearly round-up, and it was my privilege to share thoughts on TypeTogether’s Abril. In response to a comment on my review, I was reminded of something:

I do feel as though I’ve missed out on contemporary typeface design and technology. Lots of web designers feel this way. What may seem like old news to print designers is brand new to us.

This is why I love Typographica, Fonts In Use, the educational resources at FontShop, and anything else Stephen Coles touches. These efforts are welcoming, and I never feel put down for lack of experience or knowledge.

There are many excellent reviews at Typographica, from this year and previous years, and they age well. Web designers: find the faces you know and read up.