CSS Baseline: The Good, The Bad And The Ugly

Advertisement

Vertical rhythm is clearly an important part of Web design, yet on the subject of baseline, our community seems divided and there is no consensus as to how it fits in — if at all — with our growing and evolving toolkit for designing online.

This may be due to a lack of understanding and appreciation of the benefits that follow from a baseline grid, but it is more likely because baseline is notoriously difficult to get right, and no one yet holds the blueprint to its successful implementation.

Some even argue baseline is redundant online, as typographic terminology and behavior on the Web follow different rules than those used in print, the frustrating discrepancy between line-height and leading being the most obvious example.

For now, however, let’s assume baseline is, to some degree at least, a useful tool for Web designers. What exactly is it, what tools do we have at our disposal in order to execute it, and, crucially, is it worth the hassle?

Baseline.

Vertical Rhythm And Pattern Recognition

Before tackling the mathematical, potentially pixel-nudging implementation of baseline alignment, it’s a good idea to get an understanding of its parent principle: vertical rhythm. By understanding the why of the baseline, we’ll be better equipped and more motivated to come to grips with the sometimes tedious and obsessive how.

Vertical rhythm, in simplest terms, concerns the structural height and spacing of vertically stacked elements, perhaps most commonly the padding, margins and line height. Just like a horizontal grid achieves harmony by restricting the layout to a set of predefined unit sizes, the vertical rhythm (or grid, if you like) solidifies the structure by offering consistent, predictable measures as the user scrolls down the content.

Grids are not only helpful on the horizontal axis, but also on the vertical axis.
Grids are not only helpful on the horizontal axis, but also on the vertical axis.

Why is vertical rhythm important? Well, it has to do with how our mind works and how we use pattern recognition to decipher the world around us. Without going into the subject at length (other people1 much smarter than me would be more suited to that task), one can say that pattern recognition allows the human brain to store similar or identical impressions (such as primary shapes or colors) in a pattern library and retrieve them for quick analysis of new stimuli. This is the reason why we don’t look at individual letters when reading, but instead recognize whole words at a time (by pulling previous instances of the same pattern from our memory bank). It’s also the reason why we instantly recognize the letters themselves (“A,” “B,” “C,” etc.), even if the font, size and color vary — the basic shapes are stored in our pattern library.

Now it follows that any stimuli that doesn’t match any of your existing pattern records will prompt a new entry in the memory bank, which, in turn, requires more brain processing power — and that’s where the importance of design structure and grids, whether horizontal or vertical, comes in. Imagine a simple layout with a consistent paragraph spacing of X. Having analyzed the first space, your brain will instantly recognize all other identical spaces as part of the same pattern. If, on the other hand, the same layout uses different spacing between each element, the reader’s brain would have to analyze all individual spaces in order to understand their meaning. In other words: the more different shapes there are for the brain to analyze, the longer it’s going to take.

Irregular shapes (left) require more processing power than regular shapes (right).
Irregular shapes (left) require more processing power than regular shapes (right).

As any irregularity in a structure will break the automatic flow of pattern recognition (thus wasting brain activity that could otherwise have been used on good content), a regular, consistent and predictable structure will, naturally, aid the legibility and cognitive interpretation of your design. Establishing a solid baseline grid is a great method to achieve just that.

Furthermore, utilizing a consistent system in which every vertical (and horizontal) space or element derives from a predetermined unit size not only eliminates arbitrary inconsistencies, but also makes the designer’s job easier by basing structural decisions on an overarching framework. Establishing a standard where, for example, headers always have two baselines of white space below them, and the padding of every box always equals three baselines, adds logic to our layouts and makes them easier not only to design, but also to build and, most importantly, digest.

Now, if vertical rhythm seem like an abstract concept, the second benefit of baseline — horizontal alignment across multiple columns — should be easier to grasp. Most commonly seen in print design, particularly magazines and newspapers that frequently use multi-column layouts, the baseline alignment of adjacent paragraphs (or headers) is delightfully calm when done right, and annoyingly disruptive when implemented badly or not at all. The quiet order arriving from horizontal alignment exhibits a visual confidence, an invisible scaffolding that holds everything in place and reassures the readers at a subconscious level. A book with every line on a left hand page aligning with their counterparts on the right simply feels trustworthy; a book where the lines don’t match up at all somewhat less so.

Horizontal baseline alignment across multiple columns.
Horizontal baseline alignment across multiple columns.

The Trouble With line-height

Traditionally, the baseline is the invisible line upon which most letters “sit,” and the distance between each baseline forms the basis of the baseline grid, which, as we just discussed, aids not only the vertical rhythm but also the horizontal alignment of elements in adjacent columns. Having defined a baseline grid, what follows is the forced alignment of all other elements, ensuring that any line of text, any border, any image or boxed element will always match up and adhere to the same vertical structure.

The trouble is that where tools like InDesign let you do this by clicking a button (literally switching the grid on and off) and allow you to easily resize shapes to fit, when it comes to CSS, there’s no other way to do it than meticulous restriction and monitoring of line height, padding, margin, size — anything that may affect the total height of an object.

The traditional baseline is the line upon which most letters sit and from which the total height of elements should derive.
The traditional baseline is the line upon which most letters sit and from which the total height of elements should derive.

To make matters worse, the CSS line-height property doesn’t have an inherent concept of baseline, and each line of text is placed roughly in the middle of the element’s total height. This means that perfectly aligning the actual base of your text (which is to say the baseline) across different styles and fonts requires further manual, time-consuming tweaking and pixel nudging.

So how does one go about implementing CSS baseline? Well, due to the lack of a native baseline syntax, snap-in-place or browser functionality to force vertical alignment, we’re left to experiment. But let’s start with the basics.

The Good: Basic CSS Baseline

To date, at least as far as I’m aware, no consensus on a right way to do CSS baseline has formed. Some people are happy as long as the line height and spacing follow a set of guiding rules, others are more obsessed and meticulous — for better or for worse — and are not satisfied until every line of text sits beautifully on the baseline, and images, borders, boxes and other elements perfectly align to the same grid. The good news for all of us, however, is that basic CSS baseline really isn’t that hard at all. By making a few design decisions up front (and sticking to them), all it takes is a bit of elementary math.

To define your baseline, it’s a good idea to start with the smallest text size you’ll be using, in most cases your body text, and work upwards from there. In my examples below, I’m using 14 pixel font-size on a 22 pixel line-height, which means 22 pixels is my baseline. This definition has the consequence that all line-heights and the total height (including borders, padding and margin) of all elements must be a multiple of 22 pixels, like so:

h1 {
   font-size: 40px;
   line-height: 44px;
   margin-bottom: 22px;
}
p {
   font-size: 14px;
   line-height: 22px;
   margin-bottom: 22px;
}

Now defining our line-height and font-size in pixels is contentious at best, so in the name of scalability let’s convert them both to ems. Doing so makes the code a little harder to scan, but the math is fairly simple — just remember to recalculate the line-height if you change the font-size!

h1 {
   font-size: 2.5em; /* = 40px/16px */
   line-height: 1.1em; /* = 44px/40px */
   margin-bottom: 22px;
}
p {
   font-size: 0.875em; /* 16px is the default em size */
   line-height: 1.5714285714285714em; /* = 22px/14px */
   margin-bottom: 22px;
}

Note that I will invariably be referring to font-size and line-height in pixels throughout this article, as this will indicate more clearly the “physical” sizes and proportions in the examples given. All code, however, will stick to ems.

Utilizing a visible grid (many people use a background PNG or GIF, others use tools like Baseliner2), we can put this to the test and monitor the alignment of all our styles as we go along. At this point, we may find that the lines of text don’t “sit” on the baseline, but rather float in between the gridlines. That’s nothing to worry about at this stage — we can simply offset our background image or add some arbitrary padding to the top of our body to fix it.

A visible grid can be very helpful during the design process.
A visible grid can be very helpful during the design process.

So far so good, but our code is still extremely basic. What happens when we include more pizzazz — for example a top border — to our elements? Naturally, the numbers have to be adjusted to incorporate the height of the border to ensure that the total height of the object adds up to a multiple of the baseline.

h1 {
   border-top: 3px;
   padding-top: 22px;
   margin-bottom: 19px; /* 22px-3px */
}

Note how the 3 pixel border-top and the 19 pixel margin-bottom adds up to our baseline of 22 pixels.3
Note how the 3 pixel border-top and the 19 pixel margin-bottom adds up to our baseline of 22 pixels.

Using Sass or REM

Although it’s not exactly rocket science, getting the numbers to add up when working on complex websites can be a challenge, especially when using relative units. If you’re in a position to sacrifice the scalability of ems and stick to pixels, however, frameworks like Sass can take a some of the sting out of it. With Sass we can define the baseline as a variable ($baseline, in my example) and use simple equations to define multiples of this, making the whole process a lot simpler and the CSS much easier to scan. Should you want to change your baseline halfway through the process, you only have to do it one place. Although my example below concerns Sass, the same principle would apply when using rems — defining the baseline in one place makes it easier to implement across your code.

$baseline: 22px;

.box {
   padding-top: 3px;
   height: $baseline*15;
}
h1 {
   font-size: 40px;
   line-height: $baseline*2;
   margin-bottom: $baseline;
}
p {
   font-size: 16px;
   line-height: $baseline;
   margin-bottom: $baseline;
}

Using JavaScript for Images and Complex Layouts

Applying a baseline to a simple typographic layout is, well, rather simple. But we must also ensure other elements, including images, align to the grid. For containers, buttons, dividers, etc., this is a matter of restricting, by means of CSS, any unit to a multiple of the baseline. Images, on the other hand, rarely adhere to this restriction and are often served at a range of arbitrary heights, and in such cases a little bit of JavaScript can make our lives easier. I won’t go into the detail here, but both the jQuery plugin Baseline.js4 and this article on vertical rhythm5 by Matthew Wilcox are worth looking into. If you work on more complex layouts, you might want to check out FtColumnflow6 — a polyfill that “fixes the inadequacies of CSS column layouts.” It’s extensively used on the Financial Times Web app and may well be of use if you’re looking for something a bit more robust.

And that’s it for the basics. By making sure our line heights, paddings, margins, heights — everything — always add up to a multiple of our baseline, we can rest assured the integrity of our vertical rhythm remains unscathed. Simple, right?

Of course, you wouldn’t be reading this article if there wasn’t more to it…

The Bad: Improvising For Variety

The bad news is this. As much as designers thrive in restricted environments, sometimes a 22 pixel baseline can feel more like a frustrating barrier than a helpful constraint. For example, following the golden ratio, a paragraph body size of 16 pixels infers a paragraph header at around 26 pixels (though the below may apply to anything above 20 pixels, depending on the font). Keeping our baseline of 22 pixels, you may find that a single baseline is too tight a line height for comfortable reading, yet a double baseline (44 pixels) is too wide. Of course, arguably this only becomes a problem if the h2 runs onto two lines, and in theory one could get away with assuming the column width was big enough for that never to happen. Ahem. In theory.

h2 at an awkwardly small or large line-height.
h2 at an awkwardly small or large line-height.

If there was such a thing as snap-in-place, this wouldn’t be an issue, as we could simply choose not to apply our baseline to our h2 and watch in wonder as the the following paragraphs magically slotted back into place. But alas, no such sorcery is currently available and we’re forced to think pragmatically to come up with a solution.

At the start of this article I recommended defining your baseline from the line-height of your smallest text element, like the body text. As we’ve just seen, however, a fixed, minimum unit of 22 pixels (or whatever your body line-height may be) can make for awkward line heights for certain font sizes. But what if we were to halve our original baseline? Our body text would now technically have a line-height of two baselines, but that’s only semantics. In most cases, the resulting possibilities of variation and typographical freedom are worth it. Using the golden ratio to quickly define a few header sizes (rounded up or down to make our ems neater), we can easily see that a comfortable line-height is available at every increment: 16px/22px, 28px/33px, 40px/44px, etc.

h1 {
   font-size: 2.5em;
   line-height: 1.1em;
   margin-bottom: 22px;
}
h2 {
   font-size: 1.625em; /* 26px/16px */
   line-height: 1.2692307692307692em; /* 33px/26px */
   margin-bottom: 11px;
}

h1, h2, and p all aligning to the baseline grid.
h1, h2, and p all aligning to the baseline grid.

The Ugly: Offsetting Type

Before I go any further, let me be the first to acknowledge that the following is completely experimental and some of you may even call it bad practice. If you’re willing to humor me, however, keep reading even as it gets ugly. Well, ugly from a “clean code” point of view. From a design point of view, it might get very pretty indeed.

Between the basics and a bit of pragmatic (but optional) improvisation to increase variety, we now have the knowledge and tools to improve the vertical rhythm of most layouts. But the baseline? Not quite. As mentioned before, the way CSS line-height is calculated means the characters are positioned roughly at the vertical center of the line height, rather than sitting neatly on the baseline of it with descenders protruding (like in InDesign or Quark). Many of you will rightly point out that this is what’s supposed to happen. This is how CSS line-height works, and there’s nothing we can do about it. That’s true. But our eyes don’t know CSS semantics. Our eyes are not trained to follow the x-axis center of characters when scanning lines of text — they’re trained to follow the baseline, the bottom of the characters, and when two adjacent lines are misaligned the readability suffers.

Take a look at the following example:

h1 {
   font-size: 2.5em;
   line-height: 1.1em;
   margin-bottom: 22px;
}
h2 {
   font-size: 1.625em; /* 26px/16px */
   line-height: 1.2692307692307692em; /* 33px/26px */
   margin-bottom: 11px;
}
p {
   font-size: 0.875em;
   line-height: 1.5714285714285714em;
   margin-bottom: 11px;
}
p.intro {
   font-size: 1.125em; /* 18px/16px */
   line-height: 1.22222222em; /* 22px/16px */
   margin-bottom: 22px;
}

Placed in adjacent columns, even thought the baseline has been applied correctly to the intro paragraph, the base of the letters won’t line up to those of the main paragraph because of the font’s calculated line-height position.

CSS line-height makes alignment across adjacent columns inaccurate.
CSS line-height makes alignment across adjacent columns inaccurate.

Now this is where it gets ugly. In order to accurately align the base of all lines of text across all columns (which, of course, is one of the main points of having a baseline grid to start with), we have to offset the type manually. A simple way to do this is to add padding-top until the characters rest on the baseline and adjust the margin-bottom to reflect the offset.

h1 {
   font-size: 2.5em;
   line-height: 1.1em;
   padding-top: Xpx; /* This requires trial and error, as X depends on your font and line-height */
   margin-bottom: 22px-Xpx;
}
h2 {
   font-size: 1.625em; /* 26px/16px */
   line-height: 1.2692307692307692em; /* 33px/26px */
   padding-top: Xpx;
   margin-bottom: 11px-Xpx;
}
p {
   font-size: 0.875em;
   line-height: 1.5714285714285714em;
   padding-top: Xpx;
   margin-bottom: 11px-Xpx;
}
p.intro {
   font-size: 1.125em; /* 18px */
   line-height: 1.22222222em; /* 22px */
   padding-top: Xpx;
   margin-bottom: 11px-Xpx;
}

Messy? Perhaps. Tedious? Indeed. But very gratifying and wonderful at the same time. There’s nothing quite like turning on the baseline overlay on a complex layout to reveal the magic that is perfectly aligned typography.

All elements align across multiple columns.
All elements align across multiple columns.

Phew. If you’re still with me you’re probably either a masochist7 or have an unhealthy obsession with detail — either way I congratulate you, as your baseline is no doubt as solid as a brick outhouse.

Is It Worth It?

So there we have it. Basic CSS baseline is relatively easy and requires no more than a little math and organization to improve your layout. At the other end of the scale, we can manually adjust padding and margins to mimic the more sophisticated baseline of print design, a notion that will no doubt bring scowls to the faces of CSS purists. The real question, of course, is whether the visual benefits from manually offsetting type are worth it. In some cases, for example design-led campaigns and microsites, it could well be.

In others, particularly larger, more complex websites (your project managers will be scratching their heads wondering why it takes you so long to build the initial template) or collaborative projects with several developers working on the same code, well, it probably isn’t. Let’s face it — what we’re talking about in the most extreme examples not only adds manual labor, but also makes the code more intricate and harder to maintain. It will even affect the load time of your website if applied on a large enough project.

But consider this: just a few years ago, less-than-favorable techniques like “sliding doors” were advocated by industry leaders to hack attributes that CSS3 has now made commonplace. Were rounded corners really worth using two divs instead of one? Well, obviously, to some people they were — yet others may have considered them a waste of time, resulting in bad practice and semantically flawed code. But the point to take away is this: if no one experimented with such labor- and code-intensive techniques, we probably wouldn’t have native syntax for this technique today.

Experimentation, bad practice, hacks, ugly code — whatever we call it — has pushed, and continues to push, our syntax forward, reinventing the tools we will use to create and publish the next generation of online content. To echo Mark Boulton8, “How cool would it be for CSS to be able to give you pain-free baseline grid?” Whatever your level of obsessiveness — whether your characters sit neatly upon their baselines or float in between them — vertical rhythm is always an important consideration, and following any of the approaches outlined in this article should result in a satisfactory baseline grid.

There will, of course, still be cases where the restrictions feel too impeding, and sometimes elements like captions, navigation or list items don’t seem to sit right in your predefined structure. In those cases, it’s worth remembering that a few compromises are not the end of the world. Some designers, including the eminent Khoi Vinh, argue that baseline is most important in the context of the main body of your content, and peripheral elements may break the baseline without breaking the layout.

Hopefully the understanding that there’s no right or wrong way of approaching baseline will incite further experimentation on your part, and I encourage anyone with a typographical affection to contribute to the ongoing process of making vertical rhythm an equal priority to horizontal grids in the future of Web design.

Good luck!

Resources

(cp)

Footnotes

  1. 1 http://edwdebono.com/
  2. 2 https://github.com/jkeyes/baseline
  3. 3 http://www.smashingmagazine.com/wp-content/uploads/2012/10/border-top.jpg
  4. 4 http://daneden.me/baseline/
  5. 5 http://www.netmagazine.com/tutorials/preserving-vertical-rhythm-css-and-jquery
  6. 6 https://github.com/ftlabs/ftcolumnflow
  7. 7 http://8gramgorilla.com/the-masochism-of-implementing-css-baseline/
  8. 8 http://www.markboulton.co.uk/journal/rethinking-css-grids
  9. 9 http://grids.subtraction.com/
  10. 10 http://www.alistapart.com/articles/settingtypeontheweb/
  11. 11 http://elliotjaystocks.com/blog/the-relevance-of-the-baseline-grid/
  12. 12 http://baselinecss.com/
  13. 13 http://www.smashingmagazine.com/2011/03/14/technical-web-typography-guidelines-and-techniques/#tt-rhythm
  14. 14 http://vimeo.com/17079380

↑ Back to topShare on Twitter

Espen Brunborg is Head of Design at Primate, a web agency driven by an overwhelming passion for the web industry and a slightly unsettling love for monkeys, and is an advocate of content-led design, simplicity and typographic principles. He writes about his design convictions at 8 Gram Gorilla and his tweets are occasionally worth reading.

Advertising
  1. 1

    Great article. I have created a grid system that has all that included for free until the “ugly” part, maybe you could help with that, it is an open source project. :-)
    Check it and tell me what you think:
    http://unit.gs

    0
  2. 3
  3. 5

    Maybe you can answer this to me (as I honestly want to understand): Why not use the “line-height: 1.5″ (or whatever) and let that trickle down*? It’s the recommended standard from a “no unexpected results” POV, does anything make it less suited for the baseline from a typographer’s POV?

    * At font sizes 16px, 20px, 24px, we’d have line-heights 24px, 30px, 36px.

    0
    • 6

      @Melindrea, there’s nothing wrong with a “trickle down” system, in fact many would argue it is the best way to go. The problem, from a baseline POV, is that the resulting line-heights won’t necessarily align to the same vertical rhythm. As it happens, though, in your example a baseline of 6px would work just fine as all your line-heights would be multiples of the 6 (24px/30px/36px). Hope that helps.

      0
      • 7

        It does, thank you!

        So, then what I should think about is a common denominator to use in line-heights/font-sizes? (Well, base ones – I tend to try to do things in rems, using Sass)? Since as much as I did enjoy the visual prettiness of offsetting things… it feels like it would be near-impossible to achieve that with “any given text”.

        0
        • 8

          Yes, the “ugly” method of pixel offsetting we find is best used for small, bespoke work. For most projects we’re started to experiment with a REM baseline and use multiples of that to define heights of elements.

          0
          • 9

            I’m not quite sure I follow you there. How does it work, more technically?

            0
          • 10

            We’re using REM in a similar method to using Sass as described in the article, by defining our baseline once and then use that base unit to define height of other elements (eg. line-height = $baseline * 3)

            0
          • 11

            Ah, okay. Just a matter of using language in different ways, threw me for a loop. If I understand correctly, you set the font-size of the html-element to… let’s for simplicity call it 16px (yes, I know that’s generally base browser font size), and then you declare all other things in rems, so a 16px padding would be 1rem?

            And out of curiosity, what’s your thoughts on using a modular scale (as from http://modularscale.com/ )? Does that work with building a nice baseline? (If my questions sound odd it’s because I feel like I’m trying to solve a puzzle where I only have jagged edges to go from, and it might be two or three puzzles in one box… =)

            0
  4. 12

    You just raised a good argument as to why one SHOULD NOT use grid. Requiring more brain power to discern what is going on, also known as disruption, is a good thing. Why must all designers design in the same basic structure, and then complain when their content is not being consumed? You can’t have both. And frankly you just summed up why late night infomercials work so well. As to the subject of baseline, I’m just wondering whether or not this is even a valid subject of design. Where in the real world do we even see baseline used?

    -1
    • 13

      The designer should utilize his/her skills to present information in a more understandable, succinct manner. This is the job of a designer. A baseline grid aids tremendously in the presentation of information; whether it is on print, or on the web.

      “Where in the real world do we even see baseline used?”

      Any decent book, magazine, document, brochure, business card etc makes use of a baseline grid. Keep your eyes open next time you think a page layout looks comfortable and easy to look at/read. It’s most likely using one.

      1
      • 14

        What exactly is the definition of baseline anyways?

        0
        • 15

          The baseline is the line upon which most letters sit, and below which descenders extend. The point of the baseline grid is to create vertical rhythm and present information in a harmonious fashion, as to not create noise or disruption for the viewer.

          0
        • 16

          Tim, how do you judge the validity of the author’s arguments if you’re not even sure what baseline is?

          To have a disruption requires that you have some order first. Intentionally disrupting a good grid is a valid technique. Not having a grid just for the sake of it and calling that a disruption is just wrong.

          0
    • 17

      Thanks for you comment, Tim.

      As Ivelin points out, sometimes disturbing the natural flow can be effective in drawing attention to important elements of your layout. However, when readability is a priority the typography should be as “silent” as possible, detracting nothing from the reading experience itself. As for the validity and application of baseline I second Kelly’s reply – in virtually any decent print material you will see baseline applied. Why should we not aim for the same online?

      0
  5. 18

    Great Article!

    I will probably for my next project fight with a baseline first before building the pages :D

    0
  6. 19

    Great final point that vertical rhythm should be considered of equal importance to horizontal grids, I’ve been lazy regarding this topic in the past but this article gets the point across clearly and concisely so I will endeavour to allow time for this consideration in future. Thank you Espen!

    0
  7. 20

    What about baseline framework?

    http://baselinecss.com/

    JD

    0
  8. 21

    Great Article Espen,

    Just felt like I should post a quick link to Typecast – http://typecast.com/

    I find in invaluable when get started setting up typographic elements like baselines.

    Thanks, Stewart

    0
  9. 22

    Great article, do you think that line-height should be rewritten? I believe the end result of code should be semantic but also make sense on the user-end.

    Also, one request…can you dull down the color of your format graphics? The dark black boxes continuously draw your attention away from the content as you’re trying to read.

    0
    • 23

      Thanks Matt, glad you like the article. I’m in no position to suggest a rewrite of the line-height attribute, but as a general point I think that some traditional design practices have been lost in translation, so to speak, when digitized. Line-height is one example where the typographic behaviour is completely different to that of off-line counterpart – it makes little sense and creates an unnecessary divide between print and web.

      Mark Boulton also have some interesting arguments against the suggested CSS grid syntax: http://markboulton.co.uk/journal/open-letter-to-w3c-css-working-group-re-css-grids

      PS. Interesting point on the graphics, will tone down for the next one :)

      0
  10. 24

    Compass / Sass has some mixins for vertical rhythm that do all the em math for you. I used it on my last project – but even still – found it pretty challenging to keep the discipline up using it sitewide. Situations like the h2 scenario you painted kept haunting me – and I found myself constantly making up new rules when dealing with “boxed” text next to “unboxed” text.

    0
  11. 25

    One quick thing… I believe in “The Ugly” section, first code piece, you may have mislabeled the p.intro calculations. They should probably be 22px/18px, rather than 22px/16px, is that correct?

    0
  12. 26

    ResponsableCSS (just released from Abban Dunne and myself) tries to solve this by taking advantage of Less and Sass mixins and leaving the grid out of your classes. The one place it breaks is when images resize to their container while retaining their aspect ratio. Libraries like baseline.js can fix this bit and combined with Responsable get you really close to the “perfect” grid.

    0
  13. 27

    good article
    it certainly gives some food for the thoughts.

    0
  14. 28

    One problem I tend to find with working to a baseline grid is how to bring images into the fold in an eye-pleasing yet practical manner.

    There is, of course, no problem if you have one instance of an image which will only ever be displayed at a fixed size in a highly designed website – but it is fairly common for images to be recropped and used in a variety of instances, particularly on larger content managed sites, when coupling a baseline grid with a horizontal grid, there is no consistency with image proportions.

    0
    • 29

      Not exactly a solution for most of it but… Assuming one has more control over the images, perhaps work all the resizing/cropping into multiples of the baseline?

      So, assuming you have a baseline of 6px and no spacing around the picture, you (generic you) aim to make the original picture, oh… 600px high. Your miniature avatars are 60px high, etc. At least maybe a way to start thinking about it? (I’m still on the fence myself)

      0
  15. 30

    Great Article. Having a solid foundation or “baseline” is a fundamental of design. You can still have structured chaos, but the key word is structured. If the viewer cannot read text in a magazine or on a website quickly, the information will get lost. As a designer it is our duty to make sure this information flows with least resistance as possible. Twitter: cory_ley

    0
  16. 31

    Good read and some interesting musings. I myself use half of the standard text’s line height as the base unit of my vertical grid (usually that base is 10px or 12px) and almost without exceptions it works great!

    As for baseline offsetting, it’s good and not too messy if used sparingly e.g. only to put the main article heading on the same baseline with the first line of a sidebar.

    0
  17. 32

    I have been working on a guide that you can put directly on your site. It resizes images based on the line-height so they always maintain vertical rhythm and a calculator generates CSS based on the font-size you want to use for various elements.

    https://github.com/adjohnston/RubberBand

    0
  18. 33

    What is the font used for the examples?

    0
  19. 35

    Remember to use unitless line-heights if you’re setting line-height on elements that will have descendant block level elements.

    0
  20. 36

    Gunnar Bittersmann

    January 1, 2013 9:38 am

    That “the CSS line-height property doesn’t have an inherent concept of baseline” is a feature, not a bug. Web technologies have to deal with various scripts, not just Latin. Devanagari characters (used for Hindi and other Indian languages) don’t stand on a baseline, but hang down from it. When Latin and Devanagari characters like देवनागरी are mixed in a line they cannot share the same baseline. From an i18n POV is makes perfect sense that “the characters are positioned roughly at the vertical center of the line height.”

    0
  21. 37

    Dimitris Papageorgiou

    January 2, 2013 11:10 am

    Ι Did not understand the below phrase:
    But what if we were to halve our original baseline? Our body text would now technically have a line-height of two baselines,

    The original baseline was 22px., halving it will give us 11px;
    How is it that we end up with a line -height of two baselines?

    I miss something here-obviously

    And something else
    In this section:
    The Bad: Improvising For Variety

    I noticed that h2 line-height is calculated by dividing a multiple of the baseline which is 33 with 26. Is 26 derived by multiplying 16 with 1,618, the golden ration in other words?

    0
  22. 38

    This is very helpful, thank you. I’m working on a new site at the moment and trying to implement a baseline, but the text is off slightly across the columns, and now I understand why!

    0
  23. 39

    Why can’t I pin this?! Great article would like to be able to keep it pinned.

    0
  24. 40

    Great article, I’trying to look a little closer at typography in my websites lately and this is definitely a good baseline to go off (no pun intended).

    0
  25. 41

    I started a project with real baseline using vertical-align:baseline
    http://b4d455.fr/basel/

    0
  26. 42

    Valery Sibikovsky

    May 23, 2013 3:27 pm

    Why bother with ems at all if you are adjusting padding in pixels later? If you’ll change the root type size everything will fall apart anyway.

    0
  27. 43

    Nice article!

    However, I too do not understand why margin and padding are set in px instead of em, when font-size and line-height are given in em.

    Unless I’m mistaken, if the font-size would change, the margin and padding would not change with it, and the vertical rhythm would be disturbed/break.

    As an extreme example, say that we have a 160px font size, the margin and padding heights would be super small and not have much effect at all in maintaining the vertical rhythm.

    What am I missing here?

    PS: Super big thanks for not requiring registration/login to post comments. There’s too much of such crap on the Internet today, one can hardly post anywhere without having Facebook or some other ID. This is much better, thanks!

    0
    • 44

      Hi Leo,

      You’re not missing anything – your concerns are completely valid. Please see my response to Carolyn below.

      0
  28. 45

    In the ugle, you determine font size and line height in ems. You then via trial and error determine the padding and margins in pixels to adjust the lineheight to match the baseline. However, as soon as somone uses a different sized font, eg their browser sets a 12 pixel or a 18 pixel as the default font size, will that not screw up all the tweaking? Would it not also screw up on a zoom in or zoom out eg: ctrl+ ctrl-?

    Thanks, Carolyn

    0
    • 46

      The short answer is yes – using pixels in this way is dangerous when considering browser settings and manual zoom levels. That’s why we only experiment with this kind of obsession on small, confined projects. If the site is big, or the content is out of our control we generally don’t obsess over baseline and use ems to achieve a proportionate vertical rhythm as opposed to a pixel perfect one. Hope this helps.

      0
  29. 47

    First of all thanks a lot for this brilliant post. I’m messing around with type and vertical rhythm for quite a while now and I love it. But there is this one point in an actual project where I’m not 100% sure if that’s the way to go. I have the problem you’ve described in the ‘The Bad’ with my two lined h3. I’ve cut the line height in half (15px instead of 30px) to get an appropriate line-height. But now I have an offset of 15px if I have a two column layout like so: https://dl.dropboxusercontent.com/u/24391334/Screenshots/screenshot_20131120-232958.png
    I dont get the point how to fix that. Any idea?

    0
  30. 48

    Great article. I read this awhile back and am revisiting again to build modular scales for font-sizing using SASS. Dividing the baseline into half or quarters to offer more flexibility dealing with comfortable leading on wrapping headings is a great tip. Thanks!

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top