Setting Type on the Web to a Baseline Grid
Issue № 235

Setting Type on the Web to a Baseline Grid

by
Published in HTML, Layout & Grids, Typography & Web Fonts

We web designers get excited about the littlest things. Our friends in the print world must get a kick out of watching us talk about finally being able to achieve layouts on the web that they’ve taken for granted for years. Let’s face it: it’s easier these days to embed a video on the web than it is to set type consistently or align elements to a universal grid.

Article Continues Below
Article Continues Below

But we’re scrappy folks, web designers. We don’t give up easy. In the long slow battle with browser support and platform inconsistencies, we’ve been able to bring more and more sophisticated print techniques onto the web—sometimes kicking and screaming.

We have the technology#section2

Over the last year or so, there’s been a lot of talk about grid systems and using column grids for website layouts. Mark gave us a lesson plan, Khoi gave us a case study and Cameron gave us a toolkit. The message is clear: we have the browser support, the know-how, and the tools we need to create consistent multi-column grid layouts on the web.

We can apply the same principles of proportion and balance to the type within those columns by borrowing another technique from our print brethren: the baseline grid.

The main principle of the baseline grid is that the bottom of every line of text (the baseline) falls on a vertical grid set in even increments all the way down the page. Imagine those old Big Chief ruled writing pads they gave you in grade school to practice penmanship and you’ve got the basic idea. The magical end result is that all the text on your page lines up across all the columns, creating a harmonious vertical rhythm.

In print, it’s not that hard. Just enable the baseline grid in Quark or InDesign and set the increment based on the line-height you want. On the web of course, it’s another story. It’s hard enough to align things vertically with CSS because it’s tough to predict where every element will fall, and it only gets worse when we’re dealing with type, which is hard enough to size consistently on its own. But with a little math and a slightly obsessive attention to detail, we can make it work.

Firing up the grid#section3

Note: I’ve used pixel units for sizing text in the examples for this article. Recognizing that this may be a surprising recommendation for an article in this publication, I’ve addressed some of my reasons for doing so—as well as some alternate techniques that use relative units—further down.

The first thing we have to do is set a line-height for our grid. I’ve chosen a pretty standard base font size of 12 pixels, and set the line-height at 18 pixels, which gives us a nice open leading of about 150%. It’s important to think about your line-heights up front. You want a ratio of font size to line-height that’s a good balance for readability and that’s easily divisible into smaller units (more on this later).

I’ve also borrowed a trick from Khoi and created a tiling background image that I can use on the page while I’m working to make sure everything lines up where I want it to. You can see the end result with the grid turned on in this example.

You’ll notice in the previous example that the text doesn’t fall directly on the grid lines. Because of the way CSS renders line-height (by adding space above and below the letters) it’s a lot easier to line the text up within the grid lines rather than directly on them. It’s possible to adjust your background image to take this into account, or tweak the padding on certain elements so the text starts in a different place, but there’s no point making this more complicated than it needs to be.

Paragraphs and headers#section4

I’ll start by resetting the margin and padding on everything to zero so we don’t have to worry about default browser styles. In practice, you’ll probably want to use something a little more precise, but for the purposes of this example, a good old star selector will do just fine.

* { 
  margin: 0; 
  padding: 0;
}

We want space between paragraphs, but the default top and bottom margins of 1em (which works out in this case to 12 pixels) won’t work with our 18 pixel grid, so we’ll set the bottom margin on paragraphs to 18 pixels. 

p { 
  margin-bottom: 18px; 
}

As we set the font size for headers, we also need to set appropriate line-heights in multiples of 18, as well as adding the 18 pixel bottom margin.

h1 { 
  font-size: 24px; 
  line-height: 36px;
  margin-bottom: 18px; 
}
h2 { 
  font-size: 18px; 
  line-height: 18px; 
  margin-bottom: 18px;
}
h3 { 
  font-size: 12px; 
  line-height: 18px; 
}

The pattern is pretty simple. Any time you add vertical space with a margin or padding, you need to add it in units of 18 pixels to maintain the baseline grid. You don’t always have to add it in one place, but you need to add it in pairs that add up to 18 pixels. For instance, you could set a top margin of 12 pixels and a bottom margin of 6 pixels.

Lists#section5

Lists are a little bit tougher. We’re used to adding a little padding between each list item and before or after a nested list. Depending on your grid size, you may have to choose between adding a lot of extra space (adding a full grid line) or adding none at all and letting list items fall on the regular grid lines.

Since the 18-pixel line-height we started with is pretty generous, the “none at all” option works pretty well here. I’ll just add the bottom margin of 18 pixels.

ul, 
ol { 
  margin-bottom: 18px; 
}

As for nested lists, it’s possible to add half of your line-height (in this case, 9 pixels) of margin above and below nested lists. Adding half a line to the top and another half to the bottom means the contents of the list will be “off the grid,” but the grid will get back on track once the list ends. It’s a compromise, but sometimes worth it for designs in which you need to accommodate especially long or complicated nested lists.

Floats and sidebars#section6

Here’s where a little discipline comes in. Images and other elements floated within your text need to be sized vertically in multiples of your grid increment: in this case, multiples of 18. If they’re sized correctly, you can add margins around them that add up vertically to a multiple of 18, and the text will always break in the right place, directly under your image.

.left { 
  float: left; 
  margin: 0 18px 18px 0; 
}
.right { 
  float: right; 
  margin: 0 0 18px 18px; 
}

Other floated elements like callout boxes are a little bit more complicated, since it’s harder to predict their height based on the content inside. As long as all text and images inside the float follow the 18-pixel rules, and you always add vertical padding and margins in groups that add up to 18, everything should line up no matter what you put inside.

.callout {
  border: 1px solid #ddd;
  padding: 8px 10px;
  margin-bottom: 18px; 
}

Notice that I added 8 pixels of padding to the top and bottom of the floated element, since the border width already accounted for 2 pixels of added height (8 + 8 + 1 + 1 = 18).

I’m also going to suck out the bottom margin on the last element in the callout so we don’t end up with too much extra space inside. This isn’t a critical layout feature (the grid is still intact without it), so I’ll go ahead and use the :last-child pseudo class since it doesn’t require me to add any extra markup. IE6 won’t get it, but it won’t break the layout.

.callout :last-child { 
  margin-bottom: 0; 
}

The important thing to remember with callouts and sidebars is to keep the line-height the same even if you make the text smaller. You might be tempted to tighten it up, but even for 11- or 10-pixel font sizes, 18 pixels is still a very readable line-height.

All your baseline are belong to us#section7

You can see it all put together in this example. If you don’t believe me, put your rulers away and check it out with the background grid visible.

You can start to see why baseline grids aren’t used very often on the web. It’s pretty tough to keep up with it—especially as your layouts get more complicated—and we’ve only touched the surface of some of the relatively manageable challenges. Just as in print, baseline grids are not always the right choice for every layout, and sometimes you need to make exceptions or exclude certain elements from the grid to make a layout work.

But it’s definitely possible, and something that’s worth experimenting with, especially in combination with a horizontal or column grid. A nice balanced baseline grid—even just within the main content area—can add polish and readability as we move typesetting on the web to the next generation with CSS3 and beyond.

Don’t fear the pixel#section8

One final note on font sizing: I’m using pixels instead of ems in this example for one reason: it makes everything simpler. With pixels, I can set one base line-height for the entire document and I don’t have to recalculate it whenever I use a smaller font size. When designing a practical system like this, it’s important that it’s relatively easy (for yourself and others) to use and maintain.

You can use relative sizes, but it quickly becomes a lot more difficult to maintain as the math becomes more complicated. It’s easy to get 12 out of 18 (just set the line-height to 1.5em), but when you want to adjust the text size but keep the same line-height, the fractions start to get messy, and predicting how browsers are going to round your values makes it hard to be exact. It’s certainly possible however, and if you’re interested in trying something similar with relative text sizes, I’d recommend checking out Richard Rutter’s excellent 24 ways article, Compose to a Vertical Rhythm.

In the end, it’s a tradeoff. Most browsers will scale pixel-based line-heights proportionally along with the text. Of course, the margins don’t scale, and neither do the images. But is it worth making the system more complicated just to make the margins scale if the images don’t? It depends on the situation. In the end, it’s up to you.

At some point as designers we have to strike a balance between creating pixel-perfect layouts and infinitely flexible ones. When you get down to it, resizable text is primarily an accessibility feature, not a design feature. Ideally it’s something that should be provided by the browser, no matter how the page is built, and in modern browsers it is. As long as all your content is readable and accessible at all sizes, it’s not necessarily true that the design must maintain integrity as you scale.

52 Reader Comments

  1. Great article, Wilson. Love it.

    I will add one point: if you take the time to get all this working one, you should be able to reuse it over and over again. Yes, getting the baseline grid right on the web is a bit tricker than it should be, but once you’d done it, it’s pretty easy to maintain.

    Consider building a CSS typography framework that you can reuse from project to project. We’ve recently done this at my day job, and it’s been really, really handy. Every project overrides certain aspects of the framework, but having a great starting point that already establishes a nice baseline grid is a huge time saver.

    Great work, my friend.

  2. Thank you for another few reasons to use pixels instead of EMs or percents. It is very interesting question: should we use pixels or not.

    My opinion: using EM – it is not so complicated as it seems. You can compose vertical rythm with assimetric margins (real beaty!) and it will work even in IE6 (with JS of course). Calculating – it is not real problem for real typography fanatic 🙂
    Please check this test page:
    http://warmrobot.com/lab/vertical_rythm/test7.html
    But one BIG PROBLEM: round-up errors in… Opera. Even in the last version. Test pages for Opera:
    http://www.brunildo.org/test/emarg.pl
    http://steve.pugh.net/articles/opera-bug-compfntsize-rounding.html
    So, this is the only reason why I think about using pixels in the future works.

  3. I have used EMs on my site and it can get quite complicated; however, if you do most of the maths before hand it doesn’t have to be. I.e. know your base font size, margins and padding with borders and without, etc.

  4. On some project, it might a good thing not to clear out the grid. Meaning, keep—some of—it visible.

    Having a thin, barely visible but there, line under each line of a long and complex text help some people to read it, and to do so faster and more easily. It might even be an Accessibility improvement.

  6. Sidebars shouldn’t really be set on the same line height as body text. They should be set with the same ‘color’, that is their line height should be calculated using the same multiplier as body text. Then the first line of the sidebar should be aligned to the baseline grid with the rest hanging. How easy this is to do in html I’m not sure.

  9. Peter is totally right saying the sidebar does not have to be vertical aligned to the main text. If you do so you are implementing a connection that is not there. Things are different htough in a multi column layout with equal columns, e.g. the main text is in columns (not readable in the web, but it’s just an example). There between equals the alignment is good, as you will also have everything else the same (text height and so on). But a sidebar can have different text shapes and therefore should be unaligned.

  10. Peter and Handy Andy have a point, but it’s not always the case.

    If the copy in a sidebar is disconnected from the flow of text, then there is good reason, if the type was smaller, then you probably shouldn’t align it to the baseline grid. However, if the copy in the sidebar were a caption to an image which is in the main content area, then aligning to the baseline grid is probably the way to go in order for that copy to feel like it belongs to the main content. It depends on the implementation of columns within the grid.

    You both have a good point, but it’s not quite as cut and dry as you suggest.

  11. bq. One final note on font sizing: I’m using pixels instead of ems in this example for one reason: it makes everything simpler.

    True, but—you knew it was coming—where does that leave Internet Explorer?

  13. It leaves the miniscule percentage of IE6 users who really need to resezie their text to either upgrade to IE7 or turn on the “Ignore font sizes…” option in their browser so IE6 will resize text sized in pixels. That IE6 can’t resize text set in pixels is a myth. I can, it jus requires you to change a setting in the options. Personally, I think if you have this unique need to resize text, then it’s your responsibility to either use a browser that supports it by default or take the time to set your up to deal with it.

  14. Come on now, Jeff. That’s the idealist in you speaking 😀

    Unfortunately, most of web design needs to accommodate realists. We comprise not only people who use the web, but people who “get” the web. Screwing with our settings is easy and commonplace for us. The staunch majority of web users likely don’t know about settings like that, or can’t find them (due to awesome MS UI design). The plain fact remains that we are designing for realistic scenarios and not always ideal ones. We can’t always take the stance of withholding information or capabilities until users meet our requirements. Remember the days of separate site versions for IE and Netscape? We now have many capabilities to make these decisions seamless, or completely agnostic, for our visitors. Let’s make a kinder, gentler web! Wanna hold hands?

  15. Let’s talk about the real world for a second.

    I have neck and back problems, myself. Because of that, I have to buy a decent chair and take the time to configure it for the optimal support. If I don’t, I’ll end up in pain when I’m reading a book at my desk. If I choose to sit in a crappy chair, or I choose not to configure my chair the way that is best for me, or I simply don’t learn how my chair works — whose fault is that?

    I’d say it’s my fault. You can maybe make an argument that it’s the chair manufacturer’s fault, because they didn’t make it easy enough for me to use my chair properly. But I don’t see any way in hell you can blame it on the book I’m reading. Do you?

    But anyone who says the web designer is at fault for a user not being able to resize text set in pixels in Internet Explorer is basically blaming the book, rather than the chair or the person sitting in it.

    The web designer has some degree of responsibility to ensure their site is accessible to the greatest amount of people possible. But, so does the browser maker and the hardware maker. And, most importantly, so does the user bear some responsibility for understanding how to use their tools.

    I’m sort of playing devil’s advocate here, and not necessarily saying I believe all of this explicitly — but it’s worth talking about. Doesn’t the user, especially one with unique needs, bear some responsibility for knowing how to use their tools?

  16. Sorry man, still not sold. We aren’t necessarily even talking about dire needs here, like pain. There is something still inherently technical for people about the internet, or computers, that they will not or choose not to overcome. I often think of some of my professors at school in this position; crazy smart people that are just set in their ways. There are tons of people, not even among the disabled or special needs areas, that use the internet we thrust upon them. It’s just not a fair comparison to make (chair-to-internet) because the barrier to entry is considerably more technical.

  17. “It’s just not a fair comparison to make (chair-to-internet) because the barrier to entry is considerably more technical.”

    Apparently you haven’t seen all the levers and dials on my Aeron chair. 🙂

  18. Great article,

    encouraged by reading this and some other sources related to web typography in the last few weeks I created a little tool to calculate ems, px and the margins.

    http://dev.jan-quickels.de/temp/typography/

    It isn´t finally ready, but it works well if you already selected your set of font sizes–just give it a try.

  20. Having worked with Wilson for the better part of a year, and as someone who has to maintain a lot of the CSS he wrote, I can assure you he knows about unitless line lengths.

  22. Dan, you’re right, using pixels again does beg the question: what about Internet Explorer? Obviously that question is out of the scope of the article, but certainly not the discussion. I’ve recorded some of my thoughts on it “here”:http://www.wilsonminer.com/posts/2007/mar/16/problem-pixels/, but I don’t think those that relate to IE are fleshed-out enough to warrant a practical recommendation. The practical outcome is that we can’t ignore IE6 yet, and IE7 hasn’t fully solved the problem yet.

    I do think it’s important to frame the discussion around this as an accessibility problem with a browser, and what we as designers have a responsibility to do to work around that problem so our users don’t have to.

    A lot of the response I’ve seen to weighing the merits of using pixels again boils down to something along the lines of _Didn’t we solve this problem already? Use ems._ I see the point, but I’m not sure I buy it. The problem is solved the same way the problem with IE5’s box model was solved with Tantek’s hack. Which is to say it wasn’t really a permanent solution. Richard’s “62.5% technique”:http://clagnut.com/blog/348/, like Tantek’s box model hack, is a clever workaround for a broken browser–it’s a (very good) hack.

    There’s nothing wrong with a hack, but it’s not ideal and it’s not permanent. It’s what we can do with the resources at hand. With the perfect concoction of unusual percentages and fractions, we can almost achieve something as simple and basic as sizing body text at 12 point, headers at 18 point and sidebars at 11 point.

    You might say I’m overstating the complexity. It’s not that bad, really. Just keep a calculator handy, or use one of the tools available and deal with it. But this is baby games. We’re not even out of the gates and already it’s this complicated. We’re not even doing anything advanced here. We’re sizing text. Think what we could be devoting all this ingenuity and clever hackery to accomplishing if IE just worked right.

    So you can say that it’s not really that complicated, and that you don’t see any real benefit to using pixels and I’m not going to argue with you. Every project has different requirements and different constraints. Ems are a great tool for dealing with relative sizing, but I honestly don’t think it’s sustainable to use them as a universal measure.

    The hacks work for now, and it’s our responsibility as designers to do whatever we can to build accessibility into our sites. But the root problem is in one browser, and the browser maker also has a responsibility to build accessibility into the browser. Microsoft says they want to build a better browser, and we’ve seen them follow through somewhat by clearing up some of the most glaring rendering problems and deficiencies. But there’s a lot left to fix.

    Incidentally Dan, I like your technique of using pixels for browsers that can handle them responsibly, and giving IE a relative font size so users can still resize the text. I just wish it didn’t have to come to maintaining two separate type scales, especially when the main benefit I get out of using pixels in the first place is simplicity.

  23. I am familiar with unitless line-heights and use them a lot. But since they adapt relative to the size of the text they don’t really solve the problem of maintaining a consistent line-height as the text size changes. For example, a line-height value of 1.5 with no unit will calculate to an 18px line-height for 12px text, and a 15px line-height for 10px text.

  24. Mandy, the history of the “origin of the baseline”:http://www.alistapart.com/comments/settingtypeontheweb?page=1#10 is interesting but it does not account for its importance in modern graphic design. Just like the convention of paragraph indentation survives the practice of hand-painting initials (or printing red pilcrows, depending who you ask), the baseline grid found a use as a structuring device, even for cases when paper transparency is not an issue.

  25. Nothing to add except to comment that I really loved the article (and many of the comments. Loved the history of the baseline). Got me thinking about typography in a new way, which I always appreciate. Thanks.

  26. I do not know if it is just me(Firefox2@Ubuntu), but the lines in the callout does not line up with the basegrid. Should there not be the following in the embedded CSS:

    .callout img {
    padding-bottom:10px;
    }

    Nice article though!

  27. When speaking of “average users”? using IE as is, IE’s inability to scale pixels is not akin to our sites being the book and the browser an uncomfortable chair that the user deliberately chose and choses to leave as is. Metaphorically, I think it’s more like we’re building drive-through windows that can only accommodate the shortest, most-eco-friendly cars, even though most of the public drives gas-guzzling SUVs that cannot match up to the drive-through window. Sure, they’re not responsible in their actions; but they don’t care (or more-likely aren’t aware) and will pass right by our (to them) ugly, inaccessible window.

    If we want to make a difference or a paycheck or otherwise be heard, we should make things pleasant to that majority as well. This includes drawing them in and telling them to trade in their “SUVs.”?

  28. So you’re saying that “most of the public” needs to resize their text in IE6 and can’t? I disagree. Yes, a lot of people still use IE6 (about 35%, according to the stats of our newspaper sites), but very, very few of those actually need to resize text.

  29. First of all, I apologize for turning this into a “how should I size text?” thread. While it’s related to the article, it’s not really the main premise. That being said, I think there is definitely a great discussion happening.

    “Wilson”:http://alistapart.com/comments/settingtypeontheweb?page=3#23:

    bq. Every project has different requirements and different constraints. Ems are a great tool for dealing with relative sizing, but I honestly don’t think it’s sustainable to use them as a universal measure.

    Right on. I agree that sizing text in pixels _should_ be the way to go. However, the web is about the people that use it. Although it _is_ the responsibility of the browser makers, the fact is that we should accomodate the browsers’ shortcomings for the greater good of making web sites as usable as they can be to people of various capacities.

    All that isn’t to say that I disagree with you; I totally support your point and think that it can’t be emphasized enough.

    bq. Incidentally Dan, I like your technique of using pixels for browsers that can handle them responsibly, and giving IE a relative font size so users can still resize the text.

    Aw, shucks.

    bq. I just wish it didn’t have to come to maintaining two separate type scales, especially when the main benefit I get out of using pixels in the first place is simplicity.

    Too true. However, until a version of IE supports scaling pixels (and not this wannabe page zoom thing), it’s a fallback method that will have to stay.

    “Jeff”:http://alistapart.com/comments/settingtypeontheweb?page=3#29:

    bq. Yes, a lot of people still use IE6″¦ but very, very few of those actually need to resize text.

    Really? I’d love to see some stats on that”¦ 🙂

  30. I certainly don’t have the luxury of IE<7 users representing anything less than the majority of users for my employer's site. Even if it was only 35%, that could be an awful lot of users to turn away just because they are unable to easily customize the display.

    I hear what you're saying though when it comes to most of them not wanting or needing to change the font-size. You're absolutely right there. To back you up even further: for those that do want to scale using IE 6 or below, odds say that the majority of them have no clue how to do that. Even when the font is scalable (with ems and the like), many aren't aware that changing "View > Text Size” will have any effect (especially if they’ve tried it on the average site that uses pixels).

    So you’re right in that there’s less need than usually stated to support text scalability in IE<7—but I still find it lazy (personally) to not put forth a little effort that could benefit those users and earn their undying affection and loyalty.

    Disclaimer: My views are for commercial or public-need sites. For personal sites, I'm getting more and more of the view that I want to be deliberately exclusive of IE including 7. I agree that browser-makers own some of the responsibility and IE 7 with it's hasLayout component is still doing things that are holding back the status quo of the Web.

  31. bq. Really? I’d love to see some stats on that”¦ 🙂

    Heh. I wish. I admit that I’m just making an edcated guess. We have no way of now how many of those IE6 users actually need to resize their text. But, it’s safe to assume it’s a pretty small number, isn’t it? If we, as good designers, are choosing reasonable font sizes to begin with, then it ought to only be people with low vision and no glasses to accomodate for it that really *need* to resize text, right?

    I have no supporting stats, but I can’t see how this could possibly be a very big number.

  32. John, I basically agree with everything yo’ve said. The bototm line on text resizing is that it boils down to the same thing every design decision does: know your audience, know your product, and know it’s goals. Not every site *needs* perfect text resizing. Not every site has only about 35% of it’s users on IE6 (although, our newspaper sites serve a very general audience, so I’d expect that’s a typical-ish number). And so forth.

    To prove that I believe that it depends on the siuation, i’d point to BoomerGirl.com, a site I recently designed using all ems (both for type and layout) to ensure great text resizability. Why? Because that site is aimed at an older user, who is more likely to have low vision.

    “Lazy” is a pretty touchy word to use, though. It’s not about personal work eithic, it’s about business decisions. If I decide that text resizability it’s a priority, it’s because the extra time put into making it happen doesn’t warrant the benefit. There are only so many resources to go around, and if it’s determined by the project manager than there’s a minimal need for text resizing, and a very large need for some whizzy flash widget that is going to directly bring in dollars, then the flash widget will oten win. This is pure business. It’s not personal, it’s not lazy, it’s not insensitive. It’s just about business. For that reason, I’d avoid calling any web designer “lazy” when you don’t know what the limitations and demands they were working under was.

    But, overall, I agree with you. 🙂

  34. I sort of hate to admit it, but I like the way IE handles text sizing. Since IE will resize text set in EMs and not in PX, it allows the savvy designer to make some text on the page resizable by the user, and force other text to remain fixed.

    This allows you to let the user scale up the body copy to a more readable size without blowing out your navigation or causing fragile UI elements to look broken. If a user absolutely has to resize all the text on the screen they can do that (as mentioned in comment #14).

    Because it is much easier to set fonts in pixels, it would be ideal if IE would allow fonts set in pixels to be resized AND there were also a CSS property that would dis-allow font resizing when and where the designer desires it.

  35. Great article. It helped me a lot. Designing in pixels helps maintain the baseline grid. As a matter of which measuring unit to use for font-size, it is what works well for the design. Accessibility can be achieved in many ways. Every project does not have to be px the same goes for ems. I agree with Jeff Croft. Good lesson Wilson, Thanks.

  36. I think giving the text sizes in pixels is just OK. Anyway when designing a layout for the web i design in pixels (photoshop, fireworks), i set up rules in pixels.

    Unless i design something really basic that does not get messed up when scaling, i think using pixels for text sizing is just better (and easier) to get closer to that layout i designed in photoshop. If you don’t use stylsheets you don’t use font sizes, so it doesn’t matter if you gave them in ems or pxs.

    I think in some way a layout is about pixelperfection, when designing you have to make decisions, it is all about decisions. You put down exact sizes, spaces etc. and you design to see exactly the same – as much as possible – result in the browser. So why not use pixels?

    But maybe i am not right.

  37. Hey, thanks for the great article. It inspired me to write “TypoGridder”, it’s a little javascript you can use on your sites to display a grid overlay.

    Have a look on: http://milianw.de/projects/typogridder

    Also note that I wrote a bookmarklet version (see link above).

    Hope it helps the one or the other of you.

    Greatings

  38. Is it fair to suggest that for some sites its reasonable that anything less than modern will not have the same quality of typographical rhythms as those that are modern? At what point does settiing our type to the grid become a point of usability (readability) that might appeal to accessability (I’m going bility bility bility crazy!). Progressive enhancement right? I’m still working out where to draw the line on these things – which of course is always dependent on a myriad of other factors, but nonetheless, what thinks you folks?

  39. Matthew, I think your question is a good one. For those that are in IE-mac or IE-5.5 or lower, I think they are used to a less than stellar experience online (not that they are necessarily even aware of it). The extra mile of adjusting the baseline can be appreciated by those with more modern browsers, and for the time-being also for the 800-pound (but shrinking) gorilla, IE6. For older browser users, I think they’re happy if a site doesn’t have a broken layout; but they’re certainly used to many visual quirks and shortcoming in their browsers. A baseline grid is probably the last thing to worry about in those browsers to get perfect.

  40. I find that typographers look at me with a certain kind of hatred.

    I annoy them be telling them they can’t use the Font they want to and that because of flexible font sizes the can’t position every word exactly where they want it. I now _finally_ have something I can offer them as a token of peace 🙂

    Thanks for a good read Wilson, and an eminently useful technique. Good stuff.

  41. I’ve been out of the web design loop for a while, having been mired in programming work, but I’m surprised how much debate can flare up over the simple use of @px@ units. Wilson predicted it and took measures to head it off right in the article, but still people obsess over it.

    I’ll be honest here. I use px quite a bit. I’m lazy, I admit it. There are a lot of CSS techniques I want to develop and work with, but in the world of client work most of these ideas go on the extremely long list of nice-to-haves. Even clueful clients are not likely to be impressed by immaculate code. They would rather have their project done a week sooner and $1000 cheaper.

    So even though @em@ over a bit clearer advantage than other types of pedantry (think @b@ vs @strong@), I’m not interested in using it as some kind of litmus test. This article was interesting to me because it’s a novel idea (on the web anyway). I welcome discussion of the merits of the article, but I could do without the endless debates over a tangential issue.

  42. I’m a very occasional css user (thank God) and tried to use this design for a banal little site I’m working on. I have a list that wraps round a callout box and it won’t align in IE. If anybody’s got a solution to this I’d be pleased to hear it, but meanwhile can someone tell my why CSS has to be so hard? Every time I come back to it I seem to waste a day trying to do something that any reasonable person would consider trivial…

  43. 1. That person you’re shutting out of your site is one of the biggest taggers on del.icio.us, and their personal blog has a high Google page rank. Wouldn’t you like a link from them?
    2. Your competition doesn’t use px on their site.

    Actually, I note the example page in this article with the grid showing doesn’t line up on the grid once you get a certain part of the way down the page. Firefox 2.0.0.3, default font Verdana 16, minimum font Verdana 14.

  45. I have been working with a baseline grid ever since I read this article. I have found a few things I don’t care about, and have had some problems finding a work-a-round, but all that aside, I like the way it looks on a page, and have kept it.

    I’m still new to the EM world, so I have been using pixels for a long time now.

    One question… why can’t font sizes in px be resized? And why can’t the line-height be adjusted upon resizing on of the text?

    I don’t have IE6 installed these days, so I have no idea of the problems px fonts cause. I guess I should up my reading knowledge!

    Anyways, great work. It was a good read!

  46. Nice article, but thought I’d mention that there’s a small but almost humorous spelling error in the title tag for the link to “Compose to a Vertical Rhythm”. The title tag says “Compost to a Vertical Rhythm”. I hope the author of that article is not offended. :o)

  47. i am trying to set up a baseline grid for myself. i have to say it’s pretty easy if you take only block elements like headings and paragraphs into account, and if you don’t care if at some font-size/font-family combinations you won’t get a pixel-precise baseline grid. what really gives me headaches are forms and tables. is there any example of anybody doing this pixel-perfect?

  48. I do agree with Mandy, the sidebar type should be set to a leading that is appropriate to it’s size and face and this can vary on each page, not the size and face of the paragraph it sits next to. This is a common mistake I have seen.

  51. Thanks for bringing a favorite print topic of mine to the web design table!

    To help with the calculation of baselines, and picture heights, I use InDesign to do my early mockups. It might seem unheard of in the web world, but I have found that it helps me test the look and feel of my grids in advance before committing to a single grid, and the time and investment needed to calculate each individual piece of the site.

    And once I’m in the implementation phase, I always keep a post-it note full of grid multiples (18, 36, 54, … and way up) on my screen for resizing pictures, and setting CSS info on the fly.

  52. Pingback: How to Use Tailwind CSS for Perfect Letter Spacing - Tecnologia

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

I am a creative.

by
A List Apart founder and web design OG Zeldman ponders the moments of inspiration, the hours of plodding, and the ultimate mystery at the heart of a creative career.
Career