I'm with you, John. (Open to changing my mind, too.)
I'm with you, John. (Open to changing my mind, too.)
Tim Brown
is talking with
This is particularly important if you have a meaningful portion of your audience browsing on Windows, where type rendering is still extremely inconsistent if a font is not well-hinted.
[...] Making sure the type looks good in general is far more important than adhering to an invisible grid dogmatically."
Tim Brown
Hi Tim, thanks for taking the time to talk! My first proper project using a scale and the question that keeps looping in my head is have I made a mistake in understanding? Aware that I need to have a fallback baseline but I have abandoned the notion of lots of equally spaced lines running down my page that dictate the spacing and am letting the modular numbers do the talking. Results have been surprisingly good (even in these early days and with much work to do) but stumbling upon gridlover.net today made we wonder if I'd gone off course.
I use both of them. Here's how.
1. I pick a base font-size and line-height.
2. I create a baseline grid based on the line-height.
3. I create a modular scale based on the font-size.
4. I round (or "snap") the results from the modular scale to fit the baseline grid, much like Gridlover does.
Two special things I do with the baseline grid:
1. I rarely use just line-height as the unit. Instead, I split it: (line-height/2), (line-height/3) or (line-height/4). I think of this as changing the "resolution" of the baseline grid. Here's an example of Aen Tan applying this method to iOS: aentan.com
2. I use this split baseline grid horizontally too. It's great for determining things like paddings for buttons and widths for columns.
Chris Coyier for Smashing Magazine:
coding.smashingmagazine.com
"I think it’s a bit of a fool’s errand to enforce perfection on it up and down every page of a website. One image inside the content will most likely throw the whole thing out of whack. [...] Making sure the type looks good in general is far more important than adhering to an invisible grid dogmatically."
This is why I don't use a baseline grid. It's too easy to mess up, and worrying about lining everything up does not seem to be worth the aesthetic rewards on today's web.
Although one might argue the same about a modular scale, in this case I have found the aesthetic rewards to be worth the cost of extra attention to measurement.
My reply ran a bit long, so I posted it to my site instead:
jasonsantamaria.com
The one time I used a grid, it was only slightly helpful in setting up the rhythm of the page; by contrast, I've been using a scale for about a year, and I find that's consistently helpful in setting the rhythms of text and elements to each other on a page. It seems to me that the web is perfectly amenable to sensible use of rhythm; but on the other hand it is not terribly amenable to the exacting demands of a grid.
A grid may make a certain amount of sense on a 960px fixed layout, but if you're fluid, responsive, or both, the grid has to flex in ways that just aren't very gridlike—tools like goldengridsystem.com notwithstanding.
Per Jason's post, the point is rhythm—and we can get that other ways on the web.
So I spent a day with Compass' vertical rhythm mixins adding a configurable baseline grid to Zurb's Foundation which already has a modular scale. There was some initial friction but once I got comfortable I found it easy to get everything aligned. The grid overlay tool helps and it's a great way to see the impact of the aligned typography has. My opinion is the result was well worth it.
I think for talented visual designers who have an innate feel for layout and typography these constraints are unnecessary, but for many of us it provides a sensible scaffold for our typography. I prefer breaking from rhythm to be the exception not the rule.
Pull Req: github.com
Blog: lucisferre.net
Just wanted to quote this line from Jason's post for emphasis: "Type is such a finicky beast that it needs to be judged optically first, not by the numbers."
This is particularly important if you have a meaningful portion of your audience browsing on Windows, where type rendering is still extremely inconsistent if a font is not well-hinted.
Many typefaces available on webfont services require you to use whole pixel values (or math that calculates out to such), and often you must test sizes + or - 2 pixels from your "optimal" size in order to find the one that renders well on Windows browsers.
I see this problem constantly, because we web designer/developers tend to live in our Mac/iOS-centric bubble and don't test enough on Windows.
Yes! Also worth adding: as retina screens become more common for lots of us, we should also look at what typefaces look like on normal screens; fonts that are just fine on a retina-density screen may look poor or be downright unreadable on lower resolution screens (too-thin ascenders, for example, can make for a very poor reading experience).
Totally agree with Jason's post, and that rhythm is the ultimate goal. However I think baseline grids serve another useful purpose: as a good starting point/training wheels.
Type does need to be judged optically, but it takes time to develop an ‘eye’ for this, and in the meantime I think a baseline grid can be a useful guide when choosing line heights and margins. Fair enough it's probably not worth spending several hours making sure everything lines up to a baseline (since it probably won't anyway), but it can still be useful to *aim* for it.
Regardless of whether or not a baseline grid is a good thing to aim for on the web, it's nearly impossible to do precisely with the current state of text rendering in browsers. The main problem lies with how the CSS line-height property affects text layout: text is vertically centered in its line-height.
Say I have a 12px font with a 24px line-height. The text will be vertically centered in the line-height, so that there are 6px above and 6px below the characters. This is fine if we only use this one font size. However, ideally, we want the extra 12px to be above the text. Why? Well, imagine we have another font that is 16px with the same 24px line-height. That means there will be 4px above and 4px below the characters (i.e., there are 4px between our text's real baseline and the baseline implied by the line-height). This means our 16px font's baseline will be 2px lower than the 12px font's baseline. This inconsistency is at odds with the appeal of the baseline grid, particular with pages with multiple columns using different font sizes.
I've tried some techniques that attempt to more strictly adhere to a baseline grid, but haven't found anything good enough yet. I tried using top-margin to simulate line-height, but this technique requires the use of Javascript to split up the lines of text and becomes very dependent on the particular metrics of a given typeface on whatever system you happen to be on.
It seems like the majority of actual criticism is around the work involved in setting up and maintaining a baseline grid. I've found the Compass Vertical Rhythm module to make this process a walk in the park. Define a base font size and a line height and you're good to go, just use +adjust-font-size-to() and +trailer() / +rhythm() and it just works. @jetviper21 wrote a great article on using it: scottdavis.github.com
I agree with what seems to be the general theme here - these are tools, not commandments, but straying from them should be the exception, not the norm. To extend the music analogy: Drummers can take a fill out an extra measure for effect, but if they don't land on the down beat, people will notice that he's off time.
I've never even tried to use a baseline grid on the web like in print (making the actual baselines align up). For me it's all about the rhythm and system-building.
Having every margin, padding and line-height in a design stem from the same measurements creates a certain kind of rhythm that makes a layout easy to follow. It's very much like what happens in music. Simple as that.
As for the system-building part, it simply saves time and energy. Instead of trying to figure out the perfect width, height, margin or padding for each case, I just try out (line-height/4), (line-height/2), (line-height*2) and so on. 95% of the time one of those produces a perfect result.
Joni Korpi is right. But actually we use the scale, the ratio, to scale font-sizes, not the leading/line height. That's why we need a baseline grid as a reference for vertical rhythm. It's a rhetoric question to ask if we have to align everything in that grid. Chris Armstrong described it perfect, the result is judged optically.
However, I think that using grids correctly leads to eye appealing results. I have developed my own "maths" to apply baseline grids. The trick is to calculate the bottom margins for any scaled size. (I can explain it further if needed). If someone spent some time to setup correct sizes-lineheights-bottom margin, then he can achieve a perfect "map" to position everything (even not standardized images).
I don't feel like there's any effort at all in maintaining them. More like they decrease the total effort of the design by quite a lot. o_O
"When deciding the dimensions, margins or paddings of any element, try lines(1), lines(x) or lines(1/x) first. If none of them work — which rarely happens — try something else."
It doesn't have to be any more complicated than that.
Again, on the web these grids are all about the rhythm, not the baselines. It doesn't even matter if you break the rhythm at some point, as long as you pick it up again.
P.S. We really should start calling these things something other than "baseline grids".
@Chris, I'd love it if browser tools had a built in grid overlay which you could use to quickly check if things are lined up and easily fix the CSS in the browser.
Failing that, the overlay that Compass has works fine for me. Generally speaking I've found setting up a reasonable set of defaults that will work *almost* everywhere and then doing a spot check with the grid is fairly quick. I'm not a perfectionist though, good enough is enough for me.
Thanks for your feedback! Team Branch
Please refresh the page and try again.