Balancing column heights

The first problem is how the browser should handle one or more extra lines of content if the amount of content cannot fill up each column equally. In my opinion, the extra content should come at the bottom of the first columns, so that columns further to the right are never longer than columns further to the left. This is pretty standard practice in print design, and having it any other way just looks really strange. At least to me. Take a look and you decide:

The last column has one extra list item and line than the previous columns.

Doesn't this look weird?

Another example of the last column being longest.

You can check out the first demo page yourself. Resize the window and see how each browser handles column number, placement, and height.

It seems like the column-fill property is supposed to address this problem, but I may be misunderstanding what it’s supposed to do. In any case, my testing has shown that no browser supports it, even with browser-specific prefixes. So, we’re left with these unbalanced, awkward looking columns.

In some cases, I understand why the browser is making later columns taller than earlier ones. For instance, there’s a bottom margin on one of paragraphs that happens to fall at the end of one of the columns, leaving a gap and making that column shorter than the following column. I know there are cases when this behavior is desirable and necessary given the content. But we ought to be able to control it, and we can’t right now, and the default browser decisions about how to fill look weird to me in many cases.

Flowing margin and padding across columns

The second problem is how the browser should handle margin and padding on elements inside the columns. Webkit will let margin and padding be split in between columns; even when it doesn’t split a bottom margin, it will often let the entire margin show up at the top of a column. This can result in some extremely ugly and bizarre stuff:

Safari and Chrome break margin and padding between columns.

Check out the second demo page with extra margin and padding added.

Firefox, on the other hand, expands the height of the column area to accommodate the padding, and let’s margin escape out the bottom (margin collapsing at work, I guess) rather than letting it show up at the top of a column.

Firefox makes the bottom margins on the last items in the columns just disappear, instead of splitting those margins across columns or allowing them to show at the top of a column.

Again, the spec doesn’t seem to say anything about which implementation is correct (does it?), but in my opinion, the way Webkit handles it just has to be wrong. Margin and padding are never ever split, are they? And even if they are split in other non-column CSS layout scenarios, it certainly doesn’t make sense to do it in columns. Again, it breaks with print design conventions; while I know web design does not have to emulate print, there are certain typographic conventions that we’ve preserved on the web for readability’s sake, and breaking them would make most people say it looked “wrong.” I think this is one of those cases, and in my opinion, it’s the biggest deal-breaker for using columns right now. Or at least, using them in Webkit-based browsers.

Again, if there are fringe cases where it makes the most sense to split the margin and/or padding, by all means let’s do it. But we need a CSS property to control that, and it doesn’t look like there is one in the spec now. So for now, I hope Webkit changes how they handle this to match up with Firefox’s more intuitive choice, and that the W3C clarifies this in the spec.

Breaking content across columns

Finally, the third problem is that neither Firefox nor Webkit seem to support the column break properties. For instance, adding break-inside: avoid-column; to the li elements should keep the content in each list item from breaking across columns. Unfortunately, it doesn’t work right now.

The text "Start sociis natoque end" is all one list item, but both Webkit and Firefox break content within the list items.

The third demo page is the same as the first one, but it has the break-inside properties added. As you can see, it behaves the same as the first demo.

Controlling breaking isn’t necessarily a big deal with a simple series of paragraphs, but it becomes more important on lists with brief list items, as shown in the image above, and when you have headings mixed in the text, as you definitely want to make sure that headings stay with their following text. Not having support for the breaking properties can really impede usability and limits the usefulness of multi-columns.

Next steps? Workarounds?

Given these problems, multi-column layout isn’t very useful to me right now. Honestly, it’s always been something that I’ve thought should be used only sparingly, in very particular cases. But with these problems, I’m not going to use it in any cases. I’m really hoping that the spec continues to evolve and that browsers continue to update their implementation of these features. (I’m mainly looking at you, Webkit.)

In the meantime, if anyone has any workarounds for these problems, I’d love to hear them!

Don’t get me wrong—it’s great that browsers have added this zoom ability. It’s yet another tool to give users more control to view web pages in a way that is most easy and enjoyable for them. But liquid and elastic layouts still offer a lot of benefits, as does plain old text resizing. Let’s go through the flexible layout benefits one by one and see if browser zooming on fixed-width layouts can deliver just as well.

Prevent horizontal scrolling

Liquid layouts get rid of the dreaded horizontal scrollbar (or crawlbar, as Jeremy Keith would have us say) for most users, since the layout adapts to whatever viewport size they’re currently using. This is a great boost to readability and overall usability. Browser zooming doesn’t do this automatically, and though it can be used to get rid of the horizontal scrollbar once it’s shown up, it produces unwanted side effects in the process.

Here’s an example from my own experience to illustrate what I mean. I usually keep my browser window at about 900 pixels wide, simply because that’s a width I find comfortable to read and visually pleasing, and because it fits well with the other windows I have open in my widescreen monitor. Browsing at 900 pixels means that most sites designed for a 1024 resolution produce a horizontal scrollbar for me. Now, I can zoom out of the page in order to make the whole layout smaller and make it fit in my window. But when I do this, the text size of the page gets smaller, since everything is smaller when you use browser zoom. Now I can’t read the page. All I wanted was the page to fit in my viewport, not for the text to change size. Liquid layouts are perfectly suited to this task, and browser zoom is not.

Take advantage of screen real estate

Liquid layouts allow you to make full use of the area available in the viewport, showing more or less content, depending on what will fit at any given moment. Browser zoom doesn’t do this. You can zoom in to fill up the viewport, but again, this just makes everything bigger, instead of showing more content to the user who has the space for it.

Allow users to choose their own line lengths

Liquid layouts essentially allow users to choose the line length, or number of text characters per line of text, that is most comfortable for them to read. Although most people will find the same, optimal line length easily readable (75 to 100 characters seems to be best for most people for on-screen reading), there are certain people who favor long or short lines of text, and those people who do make a conscious choice about their line lengths deserve to have this preference respected.

Browser zooming with fixed-width layouts doesn’t give users this ability to adjust the line length to fit their needs. Instead, the line length is fixed at a particular value that varies only based on the user’s text size. Users with large default text sizes may get much shorter line lengths than they prefer, for instance, and changing the zoom level will only preserve these un-ideal line lengths for them.

Set an optimal line length

Elastic layouts also don’t give users the ability to change the line length to suit their needs, but they do give the designer the ability to choose a line length that will be ideal for the majority of users. You might think you can do this with a fixed-width layout as well—and you could, if all your users had the same text size. If everyone kept the 16-pixel default text size, you could make your layout a fixed number of pixels and know exactly how many text characters would fit across each line. Then, if the users needed to zoom in to make the text bigger and easier for them to read, this same, optimal line length would be preserved, just with larger text characters.

But it doesn’t work this way in the real world. Not everyone uses the default text size. Some people make it bigger due to vision problems or other disabilities. Some people make it bigger because they have such a huge resolution on their huge monitor. Some people simply have the dpi on their machines set to 120 instead of 96, which makes all text throughout their system bigger. All of these users are going to have a different line length than the one you intended in your fixed-width layout. This won’t happen in an elastic layout, because its width will always be based on the user’s default or current text size, keeping line lengths constant.

But it doesn’t work this way in the real world. Not everyone uses the default text size, and those that don’t are going to have a different line length than the one you intended in your fixed-width layout. This won’t happen in an elastic layout, because its width will always be based on the user’s default or current text size, keeping line lengths constant.

Preserve design proportions

Elastic layouts give you more control over where text falls in relation to other design components on the page. No matter the text size, your design remains proportional and visually consistent (depending on if you choose to make the images scale too, of course). Again, you might think you can accomplish this with fixed-width layouts and browser zoom, but variable user text sizes make it impossible to know where a piece of text is going to fall on a fixed-width page.

Make text more readable

All of the benefits of liquid and elastic layouts that I’ve gone over have to do with respecting user preferences and making text easier to read. It seems to me that this is the goal of browser zoom as well, and in many cases it does make text easier for the user to read. But browser zoom also scales images. In some cases, this is probably desirable, as the user may want to get a better look at an image as well as the text. But, images scaled through zooming are going to be pixellated and blurry, so zooming may not help the user at all. And, I’m willing to bet that in most cases, users have no need or desire to view your logo or sidebar ad at three times its original size, and that the now-huge images are just getting in their way. (That’s why I reset Firefox, my default browser, to just scale text instead of zooming.)

If you have images that you think the user will want to get a closer look at, you can choose to scale only these images using easy CSS tricks. You can set up your images and CSS in such a way that the images will have little distortion or blurriness when scaled dynamically by the browser. The other images can all remain a constant size, so that they don’t get in the way of users with very large text and contribute to horizontal scrollbars, float drops, or other nasty things that can happen when you put huge images into web pages. And of couse, if a user does want to scale one of the non-scalable images, they can always use the browser zoom function as a backup method.

Conclusion

Again, I have to stress that zooming is a great function for browsers to include. Also, fixed-width layouts are not evil—they are ideal in certain situations. But liquid and elastic layouts have a lot of benefits that fixed-width layouts in combination with browser zoom can’t necessarily match. Luckily, I’m not the only one who recognizes this. Don’t use browser zooming as a reason to stop—or never start—making flexible layouts.

If you want more detail on all these benefits of flexible layouts, check out the free sample of Chapter 1 of my book, Flexible Web Design: Creating Liquid and Elastic Layouts with CSS.