June 15th, 2007
Incremental leading
There has been a lot said recently about Vertical Rhythm. Richard Rutter began the work on 24ways last year with the piece ‘Compose to a Vertical Rhythm’. This was built upon by Wilson Minor on A List Apart recently with his article on Baseline Grids. All sound typographic advice. If you haven’t read both of them, I’d urge you to do so now otherwise you know what I’m on about it in this post.
At @media this year, I presented ‘Five Simple Steps to Better Typography’. Step two in my presentation was was Vertical Rhythm where I reiterated some of the excellent points Richard made in his article and also the presentation we both gave in at SXSW in March. I also added something of my own: Incremental leading, or Incremental line-height.
Too much leading in the sidenote
Working through both Richard’s and Wilson’s articles, they both treat the sidenote in the same way. They align it directly to the vertical rhythm unit. This is correct of course. But, to my eye, the line-height in those sidenotes, as it’s a smaller type-size, is too large. 10px on 18px leading is stretching it. So, how do we reduce that line-height whilst still adhering to the vertical rhythm we’ve established. Once again, we look to print design for that answer.
In editorial design, there is a technique used for sidenotes and boxouts that aligns to the baseline grid, or vertical rhythm. It’s called incremental leading.
Incremental leading
Here we have a simple page of text based upon Richard’s example. There is an H1, some text, a sidenote and a footer. They all align to an 18px vertical rhythm shown in red.
A simple document set to an 18px vertical rhythm
To my eyes, there is too much line-height to the sidenote. So, how can we reduce this line-height, but adhere to the 18px rhythm?
Instead of aligning every line in the sidenote with the vertical rhythm, when you use incremental leading, you align, say, one in every four or one in every five.
Here’s an example with incremental leading set to align every fifth line of the sidenote to every fourth line in the main content.
Sidenote set to vertical rhythm using an incremental ratio of 5:4
Adding in the vertical rhythm grid once more we can see the line alignment.
Here you can see the ratio of 5:4 incremental leading
But how do I do this in CSS?
Firsty, make sure you read Richard’s article and apply the rules to body of text. Once you’ve got the 18px rhythm set up and everything’s aligning as it should, then you can look at the sidenote.
As we’ve decided we want to align 4 rows of the main content to 5 rows of the sidenote, we begin by finding the value, in pixels, of 4 rows combined.
Four lines of the main content.
18px x 4 = 72px
Then we find the value for 5 lines of the sidenote.
72px ÷ 5 = 14.4px
To calculate what 14.4px is in ems (in relation to the body, and the type size for the sidenote)
14.4px ÷ 10px = 1.44em
We then add the values to the CSS for the sidenote.
.sidenote {
text-indent:-0.7em;
width:12em;
margin-right:0;
margin-top: 0.28em;
font-size:0.8333em;
line-height:1.44em;
position:absolute;
top:0;
left:42.6em;
}
You can see this working in this example.
However, note the top margin. I really had to fiddle around with this manually to make sure the alignment was correct. I did try and work out the maths for it, but it proved to be very difficult as really I needed to find the cap-height value of the typeface in order to provide a margin.
Martyn, a bloke I now share an office with (who is also a Mathematics graduate), provided me with this diagram to illustrate my problems.
Diagram showing relationship between baselines, vertical rhythm and how line-height is applied in CSS
As you can see, the problem is I needed to find the value of ‘x’. In order to do that, I’d need to know the value of ‘b’. The difficulty arises from trying to align the baselines and the only way of doing it was aligning it by eye. But, if you can fathom it out, then I’d be grateful.
Now, all I need to do is find the time to apply to this site and the new business site.
I love the attention to detail, something that is what separates an ‘OK’ layout to an inspiring one.
I have to praise you also on taking the time to visualise your findings!
Thanks James. Theory is one thing, but putting into practice is another. I’ve yet to practice what I preach with this one…
I know exactly what you mean. The amount of ‘best practices’ and techniques I would love to implement always tend to get pushed aside by time constraints/distractions. Its the knowing how/why that excites me, though.
Yes, but what is what here? Red and green are the respective line-heights, blue is baseline grid?
GB: Yes, sorry, I was assuming that was obvious.
One of the other recommendations I gave in the SxSW talk was to use plenty of decimal places in your CSS rules. This is because Safari will round to the nearest pixel, and so you want it to round in the right direction. In fact this is also a potential problem with Mark’s design above. The requirement for line-height to be 14.4px works well in Gecko-based browsers, but Safari rounds down to 14px (even if the line-height is specified in ems) and the desired rhythm is lost.
Safari does a lot of annoying rounding (also does it with percentage widths).
Really nice article. Thanks a lot. I’ll use it daily.
Richard Rutter: I’ve come across a few problems with this. The theory is sound, but the implementation in CSS is proving to be tricky. To get a larger decimal place value, it might be worth trying to align it 5:6, or 8:10, something like that.
Good point though Rich.
One thing I’ve run into is that different fonts seem to have different baselines, so any equation for X, will go right out the windowif you set the sidebar in a different font than the body (i.e. the body in a serif, and the sidebar in sans-serif). The difference is minimal at small sizes, but pretty obvious for headings and larger stuff.
After getting the rhythm setup, I usually use ‘position: relative; top: Xem;’ to line it up by eye. Relative positioning is nice because it won’t affect elements around (and especially under) the one you’re adjuststing.
ok, I got it. I’ve tried with a few fonts and at many sizes, and Firefox puts the baseline at 2/3 of the lineheight (approx.)
So let’s add ‘d’ which is the distance between the top of the containing element and the baseline.
d = 2a/3 = x + 2b/3
thus :
x = (2a/3) — (2b/3)
x = 2(a — b) / 3
where a and b are respectively the lineheight of the main content and the sidenote.
in this case; margin-top should be :
2(18px — 14.4px)/ 3 = 2.4 px
I’m letting it over to you to transform that to ems and to test it out :)
This is a nice addition to an already interesting topic for the web. After reading Richard’s, and then later reading Wilson’s (and one from Jeff Croft along the way) — I was very intrigued. I am not a designer by trade, but there is something about the vertical rhythm that really sets a page off.
Just when I thought I was getting good at the vertical rhythm with multiple elements on a page (images, headers, different layouts, etc) — you go and throw another wrench in the scenario. Time to go play and work out my math skills. he. Thanks for the great article.
GB: Thanks for the effort with that. However, can we really assume that Firefox puts the baseline at 2/3 the line-height?
With the differences that exist between different typefaces in terms of the descender values and the baseline (and therefore subsequent differences in the 2/3 value you’re talking about) — can we really make those kinds of assumptions?
As nice as it would be.
Thanks for this post. I too didn’t like the over-strecthed white space and went along with the comments at ALA that the side bar shouldn’t have to align itself along the same base line as the main text.
Your idea works as a good inbetween and i think we’ll use this as part of our site’s redesign.
Ah, perfect! I actually do this a lot, I just left it out of the article to keep things simpler. It’s also very handy for lists, which often can use some extra space between items, which it’s handy to add in half or quarter measures. I’ll admit to having a bit of a haphazard method for setting type down the page — in most cases I eventually end up just adding or removing some space here and there. But it helps to do it in increments so I know if I “fall off the grid” somewhere I’ll eventually fall back on down the page.
Thanks for the excellent addition, I am actually ‘studying’ the principles you, Richard and Khoi have put forward for what I will hope to be a design master piece, well, not quite. However, regardless of the outcome, I have gained vast amounts of knowledge in terms of web typography and layout that I know will help me in the future.
I also purchased Robert Bringhurst’s book as well as Jan Tschichold.
Oh how much we weren’t taught at uni. Shame on you lecturers.
Mark : Ok, I looked into it a bit further, and, in the case of Firefox at least, text seems to be aligned on the ascender. The descender seems to have no effect.
The question therefor seems to be : how is the first ascender positioned, relatively to the top of the containing element, and depending on the line-height.
Hah.
Hm, looks pretty nice.
Friend of mine trying to make something like that… and nothing :)
I will send him a link ;)
I read the transcriptof your presentation on Joe Clark’s website. Sounded like an interesting presentation. This accompanying article is very clarifying as well.
One question though, is the above just common sense, “do-what-works”, or does it have some solid ground as well? (I.e. a certain proportion between the two different line heights is optimal?)
I love this in theory, but doesn’t all that work just go out the windowif the someone doesn’t have the typeface you specified, and it defaults to another? Or are the relative values equal across typefaces?
oh my — i started freelance web design about a month ago (with a background in arts admin and theatre). before i read that post i thought i had a lot to learn…i can see now it might just be easier to head back to school (except that life really gets in the way of that sort of plan)
Excellent post. I’ve been playing around with the whole type/CSS thing since I saw the slides of your SXSW presentation.
One thing that I’m unsure of (and I wonder if this is something I’ve picked up on from Wilson’s comment above) but what happens in the case where you change the rhythm to something like 5:4 or 4:3 for lists in the body but the number of items in the list pushes elements further down the page out of rhythm?
Don’t why I notice earlier but I have just read Richard Rutters comment.
“One of the other recommendations I gave in the SxSW talk was to use plenty of decimal places in your CSS rules.”
Richard: After being inspired by you and marks typography sucks presentation, and your Compose to a Vertical Rhythm article, I have decided to redo my website, with both layout and typography in ems (and even vectors too).
I just wanted to ask a question on the safari ems issue because I seem to be have a very slight mis-placement of divs. With the plenty of decimals that you mention, how far should we go with this? I notice from the 24ways article that you go up to 4 decimals, this is something I have done but still seem to be getting problems, should I be using as many as the calculator dishes out for my calculations?
Thanks
Lee
I always find aligning the two to be tricky myself, if all else fails I simply resort to the ‘Line Guides’ available in the Web Developer Toolbar extension for Firefox. It’s time consuming (as each time you refresh you have to reset the guides to the baseline), but it does the trick quite well.
hmm. You say you are taking influence from print design but you aren’t actually aligning at all with the baseline grid. Your type should be sitting ON the gridline. Not centered between baselines. That’s why it’s called a baseline grid ;)
David, this is a common practice in editorial design, as Mark mentions.
It fits with the overall layout and baseline because it snaps to the grid using a 5:4 ratio.
You may be missing the point of the article.
Kilian Valkhof: The theory of this is sound, the implimentation however is a bit shaky at present. With regards to best practice with finding the right ratio, then it really is a suck it and see situation.
Adam: That’s a really valid point. This is based on the sidenote and main copy being the same typeface. If they were different, then you’re right, the x-heights would be different.
John Sutherland: Wilson’s point is a good one. If you were setting this type in a print document, you would add extra leading at the bottom of the list to ensure the type following would then align to the grid. You can do this on the web of course, but would have to be on a case by case basis, which doesn’t always work with dynamically created content.
david: I’m well aware of that. If you’d read the last part of this post, you’d see that I mention about the x-height value and issues with aligning baselines. This method is about as close as we can get on the web to a Baseline grid.
Does no one else find that leading differently in safari and firefox? (haven’t tested on a PC and IE)
I tested in Safari with a 18px guide grid as background. All ok. But in Firefox there’s a vertical shift. Any ideas why this is?
Ignore me, I see what David meant now. Thought he was asking why the sidenote text wasn’t the same line-height as the regular… sorry buddy.
Lee
I still think the red lines you use as traditional baseline grid is confusing. The type should be sitting on the baseline.
For example if you were aligning graphic elements with the baseline grid — like a 1px line rule or a photo you would be aligning it with the baseline, sitting it on the line, not it’s center.
Are there differences between firefox and other browsers as regards leading? — I do find that a problem. Perhaps you could next do a comparison test to get a consistent leading between them. Which browser should you start to use as your base tester?
David: I get the feeling you’re a print designer right?
I never said this was a Baseline Grid. It’s type aligning to a Vertical Rhythm. That rhythm is set to 18px and the type is aligned to it using line-height, not the baseline (as you can’t do that!).
I see where you’re coming from, but there is not way to replicate a print-based baseline grid on the web. Yet. So, we have to stretch that idea — which is what Richard did last year, and I’m adding to here.
With regards to browsers, there are differences in how they render line-height if it’s an em-based measurement. Richard suggested using lots of decimal places in your values and leave it up to the browser to work it out. Apparently, Safari rounds down to the nearest pixel which is why this may look a little ropey in Safari.
yep — print designer ;)
So with the ‘Vertical Rhythm®’ you are trying to get roughly between the lines is that right?
Why is a baseline grid not possible, if for example you were aligning type to a backround grid gif ? — 18px grid lines –18px line-height. etc.,
Thats what I have been doing.
I’ve found slight differences between safari and firefox even using px in line-height. down to using px ? is using px a no-no ?
Well, you can align it to a background image sure. I’ve done that in the past too. However, these techniques allow you to set the type to the Rhythm without having to do that.
Using pixels isn’t a no-no. I find that using ems (as it’s a relational typographic measurement) is better as when the type is resized, the typographic relationship is retained
So how do non typographic (pics, rules etc., ) elements align with the vertical rhythm if you don’t have a visual guide?
(If vertical rhythm = vertical line space height
as opposed to baseline grid which = baselines of type )
- or would you still use a background guide gif.
“Adam: That’s a really valid point. This is based on the sidenote and main copy being the same typeface. If they were different, then you’re right, the x-heights would be different.”
That’s actually a different valid point. I meant what if you line everything up with one of the new Windows fonts specified. Then someone on a Mac views the site and it defaults to, say, Georgia. Wouldn’t all your effort be wasted?
Very useful information, thank you for post.
WOW, remember reading the article on A list Apart but feeling empty afterwards, this definitely helps and has helped filled me up :)
So thank you
I sometimes get a feeling that firefox does quite a bad job at rounding some em units to pixels. Which leads to lines being aligned only within 1 or 2 pixel range. Is it just me, or has anyone else experienced the problem?
What I usually do about it is just horizontally align over the baseline the first lines of text between main content column and sidenote column. Then align every first lines of text of the next paragraphs or nav in the sidenote column with any horizontally matching baseline of text from the main content column.
If the next content in the sidenote column is an ad box, poll box, or an image, etc., then I try to align it with any horizontally corresponding x-height line of text from the main content column —instead of its baseline. That way I think can get, at least optically, vertical rhythm without missing some critical deadline —or my sanity, considering how obsessive one may get with stuff like that.
It’s always a trade-off, and I personally prefer this solution to end up with a disturbing sidenote with too much leading, except, obviously, in those cases where you deliberately want that much line-height as part of the design to, lets say, give a sense of lightness, or accentuate a particular text area. Sometimes I’ve managed to use incremental leading though, but with little consistency between browsers.
Given the visual rendering inconsistencies between browsers / platforms / versions + user settings / preferences, I think we are pretty much screwed.
I do agree that sidenotes look much better in a smaller font and with a narrower line-height; but I think this is way too ‘fragile’ to maintain throughtout a website!
if you just scale the font-size and the line-height of the sidenote according to your ‘Typographic Hierarchy — size’ article; then the sidenote will match the main body lines every few lines anyhow !
then we can talk about ‘emergent behaviour’ & ‘self-organization’ stemming from a general principle !
thanks Mark, you’re like Joseph Muller-Brockmann for the web!
Mark,
I’d like to thank you for this and all your other articles. If you’re working on a site design would you actually follow these rules in your photoshop layouts or do you only focus on such things when build time comes around?
J
Irving said:
Wouldn’t you want to align it with the ascender or cap-height of the main content? I believe that’s what Müller-Brockmann recommends in Grid Systems
i’m lerning CSS, whit my homepage and read all wat i kann find. thanks !
is very interessting Infomation!
not bad article! And look how many people are interested in it! But honesty… Where are some new topics?!
Nice article. Thanks!
[…] Read Mark’s article here. […]