It’s worth mentioning that IE6 and below can go a bit extreme when resizing fonts set as ems.

You can fix this by applying font-size: 100% to html. Don’t know why this works, it just does.

Oh, if you’re working in quirks mode you’ll also need to apply it to thead, tbody and tfoot, beacuse the fix doesn’t inherit (don’t apply it to table unless you want table to inherit font-sizes). You don’t need thead, tbody or tfoot in your tables as tbody is implied.

Obviously, you can’t then apply your own font-sizes to html or tbody etc, else you’ll overwrite the fix, which is why I chose those particular elements as they’re rarely used for font-sizes.

Jake.

You’ve said in a few pages what has taken me years to figure out and refine :) – great info!

Interesting stuff. Also worth reading Eric Meyer’s post on unitless line-heights:

http://meyerweb.com/eric/thoughts/2006/02/08/unitless-line-heights/

Mike – you’re right about being able to simplify the line-height specifications, but it doesn’t require setting unitless line-heights. In the example I use, I’ve set the font-size to be 12px on the body and calculated line-heights for all the subsequent elements. As I required one line height – 18px – for all elements I can remove the multiple statements and simply set line-height:1.5em on the body. The calculated line-height of 18px is inherited by all elements on the page. I’ve modifed the example to show this (checked in Firefox, Safari and IE6):

http://webtypography.net/24ways2006/24ways-v2.html

However the maths would still need to be performed to calculate the correct margins, so while the extra line-height specifications are not strictly necessary (at least while the same line height for all text is required) you unfortunately don’t save much on the calculations.

Great article… and AWESOME site design. Inspirational!

In the article next rule is used to reset margins:
body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,form,fieldset,p,blockquote,th,td {
margin:0;
padding:0;
}
I think it easier to use universal selector (* { margin: 0; padding: 0 }) instead.

To fix table font-size inheritance it’s enough to set
table { font-size: 1em }

Opera AFAIK don’t change font-size if it set in pixels, but it can zoom pages (so does IE7).

Theodore, I think you would enjoy Richard’s article entitled “Choose a comfortable measure” over at webtypography.net :)

http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2/

Typesetting for websites is the future, like all things content-related. The Google knows it :). Thank you for that useful post. You webdesigners take care of your text!

Thanks for your article. I have run into an interesting problem and am in search of further information.
I am trying to set my base css’s font-size / line-height to:
100%/1.618034em (phi).

When I do this (by defining the default in the body definition), I notice small 1px deviations between paragraph blocks but not within. Floating 2 sections next to one another betrays the difference when defining more paragraphs in one of the sections. My reset.css sets the vertical-align for relevant elements to baseline. The usual elements like padding, border and margin are set to 0 for all relevant elements.
No specific display properties are set for the paragraphs.
The problem is probably caused by rounding differences.

I could work around this if i knew the rounding algorithms for gecko and webkit. (Btw, webkit browsers show larger deviations. I have not yet tested with ie8).
Or i could avoid the problem altogether by setting a better roundable line-height or one for which no rounding is required. But again, i would have to know how specific i can be.

Do you know of sources where i can find more information? The Internet behaves like an oister on this subject.

I’m wondering how many digits after the dot you really need. 1.667 rounds up to either 1.67 or even 1.7. At 12 pixels (which is, as I understand it, the way CSS interprets the em of a 12 px font) the errors amount to 0.04 and 0.4 pixels respectively, which in and of themselves can’t really exist. My LCD has no half-pixels.

Wouldn’t it be OK to just round up and be done with the whole fractions business? Surely, if there is any kind of rounding difference between engines, rounding ourselves eliminates errors.

(A late) thank you for this article.

Awesome article. Really helpful. Can you please explain how this would extend to ordered lists?

thanks so much, this is great.

Hmmmmm, interesting! I’ve not tried this but I think there might be an easier way to set those heights… What if the line-height is set to, say, 1.5em on the body and 1 (unit-less – it’s valid!) on each descendant element? Or maybe some variation on that. It might force the 18px to inherit into the children without awkward calculations.

Great article, Richard! Web typography—like all typography—deserves this level of detailed thinking, and I hope to see more designers embracing it.

I’ve been working on something similar recently, and I’ve discovered that if you set the line-height in pixels, most browsers will still scale it proportionally along with the text. As IE6’s numbers fall off, I hope we can leave all this black magic scaling math behind and go back to setting font sizes in pixels and letting the browsers handle the scaling.

Jake – the extreme text sizing in IE can be fixed by applying any percentage font size to the body – it doesn’t have to be 100% (hence my use of 75% fixed this too).

You’re right about the tables though. This rule does the job nicely to inherit the text size:

table, thead, tbody, tr, th, td {font-size:1em}

If an optimal line length for print is 66 characters, line lengths for web should be even smaller.

You’re right to mention line length as something that is overlooked, but on the screen it is not as simple as setting the measure in ems as their are more factors involved (screen size, liquid layouts, etc). Also I’d disagree that web line lengths should be shorter on the web. My personal preference would be for them to be longer – I find short line lengths on screen extremely hard work to read. That’s just my opinion though.

IE7 does not allow users to resize text sized in pixels. The layout can be zoomed, but the text can not be resized.

If you think of the reasons for changing text size then zooming a layout is just another form of resizing text and achieves the same goal.

I really enjoyed this article. I have read your Elements of….for the web, as well as your blog about sizing text in ems. I have really been looking in to using this and getting the best ‘flow’ with my typography. I also ordered the book Elements of Typographic Style just to give a better understanding.

I think its a common misconception that text on the web will always look bland, and you have proved that it can have rhythm and style.

I’ve just been using some of these techniques on a client’s site who needed 8 tabs all the same width, which fill the available space – I had it working fine in Firefox, but the tabs didn’t fill the space in Safari or IE. I found that you really have to do the maths, rather than just use trial and error – they all round the numbers slightly differently. Once I’d checked my calculations, rather than tinkered with the numbers, it works fine everywhere, at least at standard font size.

One other correction from someone’s comment earlier on – you can resize text in IE7 – click the page icon at top right. Why you need both this and the ability to zoom, I’m not sure, but it’s there at any rate.

Can you set the margin above or below headings or paragraphs to less than your 18px base measurement? Won’t margin collapsing cause whichever the largest margin is to take effect?

Ben

Inline bolding of elements (I’m using Helvetica, e.g.) seems to add a px of height on any line that uses it, and that subtly throws off the vertical rhythm for each line and it can add up depending — anybody else run into this and solve it?

Does this truly keep the vertical rhythm? If you zoom in on the example, you’ll see that the descender of the letter g in the H1 header “New England” crosses your rhythm marker’s background line, while a lowercase g in the following paragraph does not. There appears to be some fudging going on.

I find it humorous that this site itself does not compose to a vertical rhythm. I’ve seen very few online that do. It’s so difficult to implement across browsers it is usually brushed aside except for in the most simple design schemes.

this helps a lot, one question, could you base your gutter widths on the V rhythym, line height 18, gutter 18px?
tanx

Wow this is a good article.

Good introduction to typography theory, but I am convinced that the Owen Briggs method is the best approach to sizing.

http://thenoodleincident.com/tutorials/box_lesson/font/index.html

GreLI – using the universal selector like that to zero all margins and padding can cause unpredictable results in some form controls (e.g. SELECT elements) in certain browsers.

Rich – great article; now all someone needs to do is knock up a nice little app that spits out the right line-heights and margins for the elements you tell it… :)

It’s unfortunate that pretty much no one composes with a scale when publishing for the web. Your article is a great step forward.

Also overlooked are line lengths. Since the beginning of the web, It has been a standard practice to expand the line lengths out with the width of the browser (like your site is currently :), causing line lengths to expand way too long. If an optimal line length for print is 66 characters, line lengths for web should be even smaller.

I don’t see it mentioned in the comments yet, but your quote above:

“...Firefox, Safari, IE7, Opera and other modern browsers which allow users to resize text sized in pixels.”

is not correct, as IE7 does not allow users to resize text sized in pixels. The layout can be zoomed, but the text can not be resized.

I’ve been using this article as the basis for designing my site with some “vertical rhythm”. Everything is going well except with forms (input, textarea, etc.). I just haven’t been able to use css to maintain the vertical rhythm (based on total line height of 18px).

Any advise or insight as to how to get forms to play nicely?

I wanted to clarify something about the default browser text size and using the em unit. The article was a tad misleading when it covered the default browser text size and the em unit. A lot of designers have it in their heads that an em is equivalent to 16 pixels. An em is not equivalent to 16 pixels. It is equivalent to whatever is set in the user’s browser, which is commonly 16px but depending on the user, it can be 20px or 12px or whatever they have set in their browser’s settings. I hope after reading that statement, designers will start to realise that they have little control over how their website appears in other users’ browsers. The majority of the control lies in the user’s hands. Other than that, the article was very good.

I’ve yet to see any empirical evidence that “vertical rhythm” applied to this degree has any impact on how well a reader is able to extract signal from the noise of the page.

Meanwhile, I’ve seen many, many examples of mis-applied “vertical rhythms” resulting in squashed headings where the underlning on a link impinges on the text below. Which just looks clunky.

When you’ve got something other than an aesthetic opinion from the margins — maybe some actual data — then I’ll be interested in expending the effort needed to support real vertical rhythm. Until then, I just don’t see how it’s cost-effective.

Now, that was the kind of article I was looking for. That goes a lot deeper than I’ve been into the realms of line-spacing, leading (no kerning here though – can we do kerning with css?).

I love the analogy to musical rhythym > therefore probably following on to mathematics/geometry/proportion. That is a great lead-in. Is there any room for the ‘golden ratio’ in web design? Do graphic designers use it with/without realising it? Just that I haven’t seen it discussed in the myriad pages concerning page layout/design that I’ve read so far…

Thanks,
Darren

Slight correction to the article. In the .footnote, 1.5 lines is 2.25ems. I would clarify what the ½ is:

“I have added a margin of 1½ lines above the border (1.5 × 18 ÷ 12 = 2.25ems), so to maintain the rhythm the border + padding must equal a ½ line (9px)”