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!

I’ve heard a lot of complaining about how SXSW Interactive isn’t what it used to be, it’s too big, you can’t run into your friends, you can’t get into parties, etc. Since this was my first time, I have nothing to compare it to, but I can say that I was still able to meet a lot of the people I wanted to and make some really great connections with smart, talented people in the web design industry. My situation is a little bit different than most people who attend SXSW, however; I’m an author and speaker in addition to being a working web designer, so I think I do stand to get work in the writing and speaking areas of my career as a result of networking at SXSW. If I wasn’t an author and speaker, though, I don’t think SXSW would have been as beneficial in building my professional network. I do see how it’s both too insular and big for being as effective at that as other conferences or events could be.

The first couple days, I had a hard time getting into any sessions—or at least any I really cared about. I wasn’t terribly impressed with the quality of the presentations I did see and didn’t feel like I was learning much. But after the first couple days, I finally got into some really excellent sessions that gave me new ideas for things to try in my projects and career. I’ve felt like I’m in a bit of rut lately, since I haven’t had much client work to do, and have felt discouraged about my career. But after seeing some of these great sessions, I feel re-energized about what I do, the value it has, and where I can take it. That’s probably the most valuable takeaway from SXSW for me, so if you’re trying to decide whether to go to SXSW next year, that may be a good reason to decide yes.

My own workshop, “CSS3 Design with HTML5,” went pretty well, I think. I got many really nice compliments on it from people who were there, as well as some helpful feedback that I think will improve some of my upcoming speaking engagements. I assume that a podcast of it will be up on the SXSW site at some point, but I haven’t been able to find it yet. I’ll let you know! In the meantime, you can view the demo site for the workshop at www.sxswcss3.com.

I had a lot of fun going out to bars and parties and such, but I also managed to squeeze in a tiny bit of Austin tourism. On my last evening, I went down to Holy Cacao for some cake balls. The peanut butter ones were amazing. The chocolate ones were quite good too. The others I tried were rather unsweet for something that I expected would taste incredibly indulgent. But I’m definitely glad I went. I desperately wanted to try their s’mores, but didn’t have time. Next time… (Side note: The owner and her boyfriend were extremely nice—the boyfriend even gave me and my friend a ride back downtown when our cab never showed up!) After going to Holy Cacao, I went to the Congress Avenue bridge to watch the famous bats emerge at dusk. Very cool.

Here are a few tips I would give to SXSW newbies, just based on my own limited experience:

• Stay at a hotel really close to the convention center. Yes, you will pay more, but I think it’s worth it. I can’t imagine having to take a shuttle or other type of transit back to some distant hotel multiple times a day. It was nice being able to quickly go back to my hotel in the middle of the day to rest, grab a snack, or drop off my laptop.
• If cost is an issue for you, leave for home on Tuesday, not Wednesday. There really wasn’t much going on Tuesday, since so many people leave that day and everyone who is still there is exhausted from partying all weekend. It felt really anti-climatic being there on Tuesday. I should have saved myself that one extra night of hotel cost and left a day early.
• Wear comfy shoes.
• Pack a tiny flashlight so you can sneak into your room at 4am and get ready for bed without waking up your roommate.
• Buy some food (preferably healthy stuff) the first day you’re there so you don’t have to eat out every single meal. Bring a water bottle along with you.
• The sessions on the first two or three days can be really busy, and the popular ones have lines, with not everyone being able to get in to see them. Get to these 15 minutes early to ensure yourself a spot.
• If you want to go to the parties, plan to get there really early, and you may still have to wait in line. I went to almost no parties, but instead had a really fun time hanging out at bars and restaurants with my friends and new people I had met. We had some really great conversations, both geek and non-geek related, and I had a great time. Thanks, people who hung out with me! You know who you are.
• Talk to everyone. Try to limit your time sitting silently behind your screen. I’m an introvert, so it was a little hard for me to strike up conversations with random people standing around me, but I did it and I’m so glad I did. Again, I had some fantastic conversations, both ones that were just plain enjoyable and a couple that might actually help my career.
• You can’t go to everything, so try to prioritize the things that you won’t have an opportunity to do at any other time. For instance, a certain panel may sound really interesting, but if you have the chance to go to lunch with some new people and talk about interesting and career-benefiting stuff, do that instead. You can always watch or listen to the panel later.

Final fun fact: I thought North Carolina (where I live) was obsessed with pork. Turns out Texas is far more obsessed. There was bacon and/or sausage in everything and many signs gleefully celebrating this fact. I have finally eaten bacon chocolate chip cookies. I also ate this delicious, ridiculous monstrosity involving a bacon-laced waffle cone filled with guacamole, pico de gallo, beef taquitos, and tortilla chips. Texas, I salute you.

Of course, 140 characters couldn’t capture his whole opinion on the subject, so he wrote a blog post followup. I strongly recommend reading it. I really agree with it.

Also, he later tweeted: “My new opinion, based on insight from commenters: You DON’T need to know how to write HTML/CSS. But in many scenarios it can be useful.”

I agree with this too, for the reasons explained well by Mark Boulton. A web designer doesn’t necessarily need to know how to write actual HTML and CSS. But she does need to know about the limitations imposed by browsers, the strengths and weaknesses of the medium. Writing HTML/CSS can make understanding and designing around these limitations a lot easier. But you can come to this understanding without learning HTML/CSS first.

Basically, my opinion is still the same as it was when I wrote Should web designers build their own pages? back in June 2008. Check that article out for my full opinion—including my very own architect analogy! (Seemingly a must whenever debating this topic.)

Design inspiration

It’s always helpful to look at existing liquid and elastic sites to get inspiration for how to design your own. I’ve pulled together several sources of flexible design inspiration in a couple former blog posts on my site:

• Inspiration for flexible web design
• The liquid web site motherload

Templates

Even if you don’t read my book, you can download the example and exercise files from the book’s companion site. They essentially give you several liquid and elastic layout templates or starter pages that you can use to build your own liquid and elastic sites.

Here are some other layout templates:

• Matthew James Taylor’s liquid and elastic layouts
• Layout Gala liquid layouts
• IronMyers liquid layouts
• CSS-Tricks liquid layouts (see “Layout Packs” third on page)
• Dynamic Drive CSS liquid layouts
• ThemeForest’s liquid fully-designed templates
• WordPress flexible themes

Here are some frameworks and grid systems that allow you to make liquid and/or elastic layouts:

• Fluid Grid framework
• Fluid Grid System framework
• Fluid 960 Grid System
• aplus elastic grid
• Elastic framework (elastic and liquid)
• Emastic framework (elastic and liquid)
• YUI Grids CSS (liquid)
• YAML framework (elastic and liquid)
• The 1kb CSS Grid can be adapted for liquid layouts (see description halfway through this article)

Articles

Here are some general articles on the what and why of flexible layouts:

• Sample of Chapter 1: Understanding Flexible Layouts (PDF, from Flexible Web Design book)
• Fixed vs. Fluid vs. Elastic Layout: What’s The Right One For You? (Smashing Magazine)
• CSS Layouts: The Fixed. The Fluid. The Elastic. (Beast-Blog.com)
• Why browser zoom shouldn’t kill flexible layouts
• Elastic layout – wrong term? (AlastairC)
• Accessible layouts (AlastairC)
• Where Have All the Flexible Designs Gone? (Sitepoint)
• Flexible Layouts: Challenge For The Future (Smashing Magazine)
• Elastic Design (A List Apart)
• Fixtorati (Adactio)
• Liquid layouts using CSS – the joy, the pain, the tears (presentation at Web Essentials 05)

Understanding min-width and max-width is essential to working with flexible layouts:

• Sitepoint’s CSS reference on min-width and max-width
• Add min-width and max-width Support in Internet Explorer 6 (PDF, from Flexible Web Design book)

Understanding line lengths is also essential. Although popular belief is that there’s a narrow band of line lengths that are ideal for everyone’s reading comfort, the (limited) research that’s been done on on-screen reading suggests that there is a much larger range of effective line lengths, and that there is a difference between preference and efficacy. Age, disability, reading level, native language, leading, and other factors can all impact which line lengths are most effective for specific individuals in specific situations. See these articles for details:

• The Line Length Misconception (Viget Advance)
• Reading Onscreen: The Effects of Line Length on Performance (usability.gov)
• The Effects of Line Length on Reading Online News (SURL Usability News)
• The Effects of Line Length on Children and Adults’ Online Reading Performance (SURL Usability News)
• Optimal Line Length: Research Supporting How Line Length Affects Usability (webusability.com)
• Reading Text Online (UI Design Newsletter)
• Line-length is not different than any other user preference (CSSing)

Tutorials

Here are tutorials on creating multiple-column liquid and elastic layouts:

• Liquid layouts the easy way (Max Design)
• CSS Mastery: Fixed-Width, Liquid, and Elastic Layouts and Faux Columns (excerpt from CSS Mastery on webreference.com)
• Fixed or fluid width? Elastic! (456 Berea Street)
• Creating Elastic Layouts with the em Unit (Community MX)
• The Incredible Em & Elastic Layouts with CSS (Jon Tan)
• Fluid Grids (A List Apart)
• Five simple steps to designing grid systems — Part 5 (on liquid grids, by Mark Boulton)
• CSS Floats to Display Columns in Any Order (Christopher Schmitt)
• Changingman layout (updated) (also a template, from For a Beautiful Web)
• Intricate Fluid Layouts in Three Easy Steps (24 Ways)
• In Search of the Holy Grail (A List Apart)
• Creating Liquid Layouts with Negative Margins (A List Apart)
• The Definitive Guide to Using Negative Margins (Smashing Magazine)
• Get Refreshed: Liquid Layouts With Simpler CSS and Without A Semantic Mess (Mindfly)
• Multi-Column Layouts Climb Out of the Box (A List Apart)
• Fluid elastic design (Boagworld)
• Using the Liquid CSS Layouts in Dreamweaver CS4 (excerpt from Mastering CSS with Dreamweaver CS4 on peachpit.com)
• Flexible equal height columns (SocialGeek)
• Vertical Centering with CSS (Andrew Valums)

Creating successful flexible pages is about more than just the layout; you have to make sure the content inside the layout can be flexible too. Here are tutorials on making content, backgrounds, and other effects work with flexible layouts:

• Creating Liquid Faux Columns (Community MX)
• Elastic Faux Columns (Nick Cowie)
• Smart Columns w/ CSS & jQuery (Soh Tanaka)
• Equidistant Objects with CSS (CSS-Tricks)
• Sample of Chapter 9: Creating Flexible Images (PDF, from Flexible Web Design book)
• Foreground images that scale with the layout (pure CSS solution)
• Quick Tip – Resizing Images Based On Browser Window Size (JavaScript solution, from Build Internet!)
• Creating sliding composite images
• CSS effect: space images out to match text height
• Hiding and revealing portions of images
• Stretchy Images with HTML and CSS (Sitepoint)
• Fluid searchbox (outbreak)

This should keep you busy for a while, no? I hope this will be the start of some lovely liquid and elastic designs for you, folks! Drop me a line if you have one you want to show off; I love seeing other people’s great work.

Digg this article if you enjoyed it. Thanks!

Although @font-face, the CSS method for embedding and using any font in a web page, now enjoys rather good browser support, it still has some limitations that keep people from using it. Chief among these is the fact that the license of most fonts, even free ones, do not allow re-distribution over the web using @font-face. Because of this, a number of services and technologies are springing up that provide alternate ways to get non-standard fonts into your pages. I was unable to find any place that listed all of the major @font-face alternatives, so I decided to do my own roundup to provide the basic info on each.

This roundup of alternatives is not meant to discourage the use of @font-face. In the spirit of progressive enhancement, I wholeheartedly think it’s ready to use (with the right fonts, of course). But, in case you are unable or unwilling to use a pure @font-face solution, or you’re just curious what your other options are, here’s are the most popular services and techniques out there for you right now.

Note: This a rapidly evolving area of web design. These solutions are going to change and more are going to be added. I will try to keep this page updated as things change, but if any of the changes are so big that it makes the most sense to just create a new page, I’ll do that instead. Either way, I’ll post a note here indicating where the latest updates are.

Font Embedding Services

These services all make use of @font-face, but make implementation easier by helping you work around the browser differences. They also all get around the legal issue of font embedding by providing you with a set of fonts that are licensed for this type of use and impossible or difficult for end users to steal.

Typekit

Status

Open to all.

Method

Subscription to a font library from multiple foundries by month or year. JavaScript used to connect your site with remote font library. You customize CSS to work with the selectors and tags you need, as well as create a font stack to be used as a fallback if @font-face is not supported, but the CSS is in the JavaScript, not your own sheet. sIFR and Cufón will also be used as fallbacks.

Pricing

Freemium. Free “Trial” account gives access to smallest number of fonts and can be used on one web site. “Personal” account for $24.99/year, “Portfolio” account for $49.99/year, and “Corporate” account for $49.99/month increase limits on fonts, bandwidth, and number of sites.

More Info

• First impressions of Typekit
• Getting Started with Typekit
• First Ten Minutes with TypeKit
• A Few Thoughts on TypeKit

Fontdeck

Status

In development. Sign up on home page to get details when they become available.

Method

Supposedly similar to Typekit’s, but details unknown. Font library will be from multiple foundries.

Pricing

Unknown.

Kernest

Status

Open to all.

Method

A la carte font selection from multiple foundries. Select fonts you want to use and paste generated CSS into your style sheet. No JavaScript involved.

Pricing

Pay yearly subscription for each font individually, per domain. Many fonts free.

More Info

• Using new fonts from Kernest on Blogger
• The importance of knowing Kernest: Pretty high. Your move, TypeKit.
• An Interview With Kernest’s Garrick Van Buren

Typotheque

Status

Open to all.

Method

Fonts come only from the Typotheque foundry. Select fonts you want to use and paste generated CSS into your style sheet. No JavaScript involved.

Pricing

Pay one-time fee for each font individually. Buying installable print version of font for full-price (including access to web version) or web-only version for 20% of full font price. Extra charges for bandwidth over 500 MB.

More Info

• Testing Typotheque @font-face embedding
• Multi-Lingual Fonts with Typotheque and Font Face
• Beta-testing Typotheque’s Font Embedding Technology

Font Replacement Techniques

These techniques do not make use of @font-face, but instead use scripting and/or Flash to display fonts that are not on the user’s system. All of these techniques are free and open to all to use. None of them directly address the licensing issue, but none of them link directly to ready-to-use fonts, so copyright legality is not clear-cut.

sIFR (Scalable Inman Flash Replacement)

Embed your font in a Flash SWF file. JavaScript converts chosen text on the page to Flash text, which can be selected and resized. Some styling handled in CSS and some in JavaScript. Rather difficult to set up.

More Info

• sIFR Generator
• sIFRvault
• Implant sIFR3 – A Healthy Alternative to Browser Text
• How To Implement sIFR3 Into Your Website
• cufón and sIFR (A Visual Comparison)
• Cufon vs sIFR vs FLIR
• Text replacement comparison
• Text Replacement Roundup: The Pros and Cons of SIFR, Cufon, Typeface.js, and FLIR
• Rich Typography Options for the Web

Cufón

Convert your font to a proprietary JavaScript format and link to it and the main Cufón script. Specify CSS normally. Uses the HTML5 canvas element or VML to draw text. Contrary to popular belief, text selection is possible, you just can’t see the selection.

More Info

• The Easiest Way to Use Any Font You Wish
• Exploring Cufón, a sIFR alternative for font embedding
• Combining Cufón and @font-face
• cufón and sIFR (A Visual Comparison)
• Cufon vs sIFR vs FLIR
• Cufón vs. Typeface.js, which one is better?
• Text replacement comparison
• Text Replacement Roundup: The Pros and Cons of SIFR, Cufon, Typeface.js, and FLIR
• Rich Typography Options for the Web

typeface.js

Same idea as Cufón, but somewhat lower performance and quality. Convert your font to a proprietary JavaScript format and link to it and the main typeface.js JavaScript library. Specify CSS normally. Uses the HTML5 canvas element or VML to draw text.

TypeSelect is based on an older version of typeface.js, but now that typeface.js supports text selection, it seems to be redundant.

More Info

• Cufón vs. Typeface.js, which one is better?
• Text replacement comparison
• Text Replacement Roundup: The Pros and Cons of SIFR, Cufon, Typeface.js, and FLIR
• Rich Typography Options for the Web

FLIR (Facelift Image Replacement)

Uses PHP and JavaScript on a regular font file that you upload to your web server to dynamically generate images.

More Info

• Install FLIR – Typography Solution For The Web
• How To Use Any Font You Wish With FLIR
• Cufon vs sIFR vs FLIR
• Text Replacement Roundup: The Pros and Cons of SIFR, Cufon, Typeface.js, and FLIR
• Rich Typography Options for the Web

PIR (PHP Image Replacement)

Uses PHP and jQuery on a regular font file that you upload to your web server to dynamically generate images.

FontJazz

Convert your font to an image containing each character in a specific size and color. A generated JavaScript for the font displays the appropriate character for each word.

More Resources

There are a ton of general articles and web sites out there about @font-face, font embedding services, font replacement methods, the politics of web fonts, and more. Here are just a few that I think are particularly helpful.

• Webfonts.info wiki
• Beautiful fonts with @font-face
• The Font-as-Service
• Why webfont services are the future of fonts on the web
• The direction forward with web fonts
• Designing with @font-face delivery services
• Web Fonts Panorama – September, 2009
• WOFF, the web standard for type
• Typography for the Web—NY Web Standards Meetup
• Rich Typography On The Web: Techniques and Tools

Luckily, I ran into a large source of free handwriting fonts called Fonts for Peas, part of the kevin & amanda blog. These are fonts that are meant to be used for scrapbooking, family blogs, and the like, so most of them are pretty cutesy. But, with 333 to currently choose from, you’re bound to find a few that you could use. All of the handwriting fonts are based on actual handwriting samples that readers of the blog send in, so they’re pretty diverse. I downloaded a couple dozen myself and am excited to try them in my logo comps.

Jane Austen quotations set in Pea Bandit, Pea Mystie Caps, and Pea Anderson.

Mixed in with the handwriting fonts are a few hand-drawn symbol fonts that would make nice icons. There’s also another section of the site called Free Scrapbook Fonts that currently has over 100 decorative fonts to choose from.

Now, I know these aren’t very high quality fonts, in terms of kerning and metrics and ligatures and all those things that make a professional font a professional font. But, I think many of them will work in small doses, especially if you’re going to be manually kerning and tweaking them yourself.

These fonts are free for personal use, and you can use them for free commercially if you display a button linking back to the site. If you don’t want to do this, you can buy a single-font license for $10. (That’s what I’ll be doing if I end up using a font in the logo I’m working on.) Read all the details in the terms of use.

Nomensa is a web agency specializing in accessibility and usability. Their own site is a nice example of a liquid design, and I’ve had it bookmarked for a while, but I finally got a chance to check out the sites in their portfolio. There are dozens and dozens of them, and almost all of them are liquid. (They also have a few elastic ones, and a few fixed-width.) Unfortunately, Nomensa doesn’t provide links to all of their work, but only a select few as case studies. But, you can google the names of the non-case-study clients, and you’ll find that most of these sites are liquid as well.

Now, I grant you, many of the sites are not terribly stylish. But they still are really useful to look at to get ideas for how to handle content and layout in liquid layouts. You could easily use the same techniques they’re using with a bit more spit and polish added.

Here are a few of the most well done liquid sites from Nomensa’s portfolio:

Barcham Online

The header using seven images of tree foliage that expand and contract to fill the available space is very clever and attractive. Also check out the feature boxes on the home page and the thumbnail gallery under Our Trees. It’s notable that this is an e-commerce site, which you don’t often see liquid.

Broads Authority

I’m not in love with the overall look and feel of this site, but I appreciate the unique layout of the home page. The main image on the home page that has a text box below, which moves down as the text in the adjacent columns grows, revealing more of the image above, is very well done.

Preston City Council

Another unique home page layout and neat use of “variable cropping” on the main photo. Be sure to check out the Gallery under Get Involved, as well as all the little feature boxes and things on the inner pages.

Macmillan Cancer Support

This site is notable for the large amount of information that it organizes into liquid rounded corner boxes throughout the site, without everything becoming chaotic and unbalanced at different viewport widths.

Business Startup Community

Again, not a very attractive site, but I’m bookmarking it simply for the treatment of the three tabs on the inner sections of the site.

I’ll be sure to stop by Nomensa’s portfolio periodically to see what new work they are featuring and gather ideas for solving problems in my own work. I should have mentioned in my flexible web design inspiration post that a great place to find liquid and elastic sites is within the portfolios of agencies or designers who themselves have liquid or elastic sites. Nomensa is now on this list for me.

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.

The "See All Prizes" links below each grand prize package radio button.

I was happy to see this “See All Prizes” link, since I didn’t know what the difference between the BOB Revolution Stroller and Maclaren Stroller was. So I clicked on the link and got a popup window listing the prizes in each package. But that was it. I didn’t actually get to see any of the prizes. Nor did I get a description of each item. Nor did I get links to the pages on the Babies R Us site where I could view each item and learn more about it.

The popup listing the prizes.

I was left still not knowing what the difference between the two strollers was, and thus still didn’t know what choice I should make. Sure, I could go search for these strollers myself on the Babies R Us site. But I wish they hadn’t of gotten my hopes up by saying “See All Prizes,” when saying “See List of Prizes” would have been more accurate and left me less annoyed. (Plus, how hard would it have been to link each prize to its associated product page?)

The lesson here: language does matter. Mean what you say so your users get what they expect to from you.

Back on the form, I randomly picked the second prize package—or at least I tried to. When I clicked on its radio button, the prize lising popup window appeared again. The clickable area of the prize link was overlapping the clickable area of the radio button. I see why they did this—that prize link text is dang small. Expanding its clickable area (via padding in the CSS) helped me select it without having to be terribly precise. But when it came time to actually select a radio button, it made things worse.

The clickable area of the link overlaps the radio button, so clicking in the middle of the radio button selects the link, not the button.

I closed the popup and tried clicking on the label text “Maclaren Stroller & JJ Cole Package” right above the radio button. Alas, this did nothing, because this text was not actually marked up as a label element in the HTML. Finally, I was forced to very slowly and precisely move my cursor over the top half of the radio button, where I could finally click to select it.

Moving your cursor to the very top of the radio button finally lets you select it instead of the link below.

Radio buttons are small enough targets to hit as it is. Reducing their clickable area by half because you’ve overlapped them with the clickable area of an adjacent link makes using them ridiculously difficult. If the label text had been marked up as an actual label, I could have just clicked on this text to select its associated radio button. This helps people with mobility impairments, but as you can see from this example, it helps people without disabilities as well when space is tight and there are lots of little competing things to click on.

The lesson here: use label elements on form fields. Always. It really does matter.

While Andy’s proposal doesn’t just pertain to the design process for flexible sites—he seems to advocate it for all types of sites—Andy does ask:

Is the fact that so many web pages are fixed width and centered a direct result of clients signing off fixed width design visuals?

I’m willing to answer yes to that question. Not that this is the only reason fixed-width designs get created, but I’m sure it plays a role in many of them. As I talk a great deal about in my book, as well as the presentation I’ve made at a couple conferences lately, you can’t build a flexible page unless you’ve designed it to be flexible in the first place. You may design a page that must be fixed-width inadvertently, and won’t catch it until you go to build the page in (X)HTML and CSS. But if your client already signed off on the design when it was a static image, it’s now too late to change the design to make it liquid-compatible. Forcing yourself to build at least a rough version of the page before you present the design to the client is a great way of checking if your design is truly flexible-friendly. If you find that it isn’t, you can make design changes to avoid CSS headaches later.

A lot of the commentary surrounding Andy’s proposal has been that building pages for clients will take a lot more time that isn’t in the budget. I think this is a valid argument. But, I also agree with the arguments that this workflow method can actually be a time-saver—or at least that the extra time spent making the (X)HTML/CSS comp can be made up later. Andy says:

As I work almost as fast in markup and CSS as I do in Fireworks, I find that the overall time that I take designing and implementing that design is dramatically reduced as I am not duplicating work. It leaves me free to spend more time on fine tuning a design and I’m sure that my designs are all the better for that.

I’m right with Andy on this one. I’ll spend a lot of time futzing with the perfect border color or the perfect amount of spacing under a heading; when it comes time to build the page, I’ll have to do all that futzing over again in the CSS to find the perfect em measurement, for example, that matches the spacing I created in the Fireworks comp. It’s often faster for me to just leave all the work on these design details to my CSS development stage.

Another argument for time-saving comes from Kyle Weem’s response to Andy’s original post:

…you can absorb that extra time spent in the budget that would have been wasted on extravagant solutions generated to create identical rendering where it need not exist.

Another argument I totally agree with, especially if you are trying to create flexible designs. When you build the (X)HTML/CSS before showing to the client, you catch things in your design that are going to be tough and time-consuming to build—either because you’ve designed them in such a way that you can’t make things flexible, or it’s just going to take a lot of hacking to get it looking the same cross-browser.

All this said, this method of showing (X)HTML/CSS pages to clients instead of static design comps is not something I’ve actually done (though I do sometimes show wireframes before design comps). But as someone who primarily designs liquid layouts now, I can see it being really beneficial to the way I work, and I’m definitely going to give it a try soon.