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!

Designing CSS Layouts for the Flexible Web (PDF, 5.5 mb)

Yes, it’s a big file—there are a lot of graphics in the PowerPoint. But I didn’t want to compress it very much and have all those graphics look distorted, since examining the graphics is the main point of the presentation.

There’s a little CSS in the presentation, but if you want more in-depth tutorials on the techniques alluded to in the presentation, I’ve written up many of them on this blog:

• Foreground images that scale with the layout
• Hiding and revealing portions of images
• Creating sliding composite images
• Space images out to match text height

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.

Designing CSS Layouts for the Flexible Web (PDF, 5 mb)

Yes, it’s a big file—there are a lot of graphics in the PowerPoint. But I didn’t want to compress it very much and have all those graphics look distorted, since examining the graphics is the main point of the presentation.

If you’re ready to get beyond the graphics and start working on the actual CSS techniques alluded to in the presentation, I’ve written up many of them on this blog:

• Foreground images that scale with the layout
• Hiding and revealing portions of images
• Creating sliding composite images
  

Since the area available for an image to display within a flexible layout changes on the fly, your images may need to as well. While fixed-width images can work within flexible layouts—as long as they’re not too large, or you have matching minimum widths in place—there are lots of ways you can dynamically change the screen area that an image takes up.

I’ve already written about how to make images literally scale, but another way to change the amount of screen area an image takes up is to dynamically change how much of the image is shown at any given time. The image itself doesn’t change in size—the amount of space in which it’s allowed to show does, and the rest of the image just remains hidden outside of that space. I call this “variable cropping.”

You can create a variable cropping effect with either background or foreground images. Both look the same, but each is specially suited to different situations.

Variable cropping with background images

Putting the image that you want to dynamically crop in the background is ideal when the image is purely decorative. This technique lets you keep the image in the CSS with the other decorative images, so if you later change the look of the site, all the decorative images can be changed in a single style sheet instead of having to replace multiple img elements across multiple pages of the site. By keeping the decorative image as a CSS background, you’re also making it likely that the image won’t print when the user prints the page—background printing is turned off by default in all major browsers—so the user can save ink by printing only content.

To use a CSS background image, you’ll fi rst need an element on which to place the background. This example will use a div:

<div id="background"></div>

The div is completely empty; it contains no content, but exists simply to hold a background image. If you have a more semantic element you can hang the background on instead, use it. For instance, perhaps the image you want to dynamically crop sits above an h3 element and matches it in width. You could add the image as a background to the h3 element and give the h3 enough top padding to make sure its text sits below the image, not on top of it.

Next, create a rule for this div that sets the image as its non-tiling background:

div#background {
	background: url(styx.jpg) no-repeat;
	border: 2px solid #000;
	}

I’ve added a border on to this div as well so you can easily see where its edges lie. Right now, with no content within the div, it will collapse to zero height. Add dimensions to the div to prop it open:

div#background {
	width: 50%; 
	height: 330px;
	background: url(styx.jpg) no-repeat;
	border: 2px solid #000;
	}

Tip: To dynamically change the height of the image as well as or instead of the width, use a flexible value for the height property.

The width is set to some flexible dimension—either a percentage, as I’ve done here, or an em value to make it elastic—so that the div can change in width to show more or less of the image. The height is set to the pixel height of the image so that the entire height of the image will show at all times.

The div will now always be 50 percent as wide as the viewport; its background image doesn’t change in size, but gets cropped to a varying degree from the right side.

However, this particular image would look better cropped from the left side, as the cat’s face is on the right side of the photo. To specify from where the image gets cropped, use the background-position property, or its shorthand in the background property, to change the alignment of the image within the div:

div#background {
	width: 50%;
	height: 330px;
	background: url(styx.jpg) no-repeat right;
	border: 2px solid #000;
	}

The image is now anchored to the right side of the div, so more or less of its left side shows as the div changes in size.

This is all the CSS necessary to get the basic variable cropping technique working, but you can add a few other enhancements if you like. For instance, right now, once the div exceeds the width of the image, empty white space shows within the div. There are a few ways you could handle this. You could add a background color to the div as well that would fill up whatever space the image cannot; if you blend the edge of the image into this background color, the effect can look seamless. Or, you could add a maximum width to the div so it can never grow larger than the image. You could also add minimum widths, as well as maximum and minimum heights, to ensure that the div can never grow or shrink past particular
points in the image.

Variable cropping with foreground images

If the image that you want to dynamically crop is functional content, you’ll want to keep it as a foreground image by placing it in the (X)HTML using the img element. You can ask yourself these questions to determine if the image is content, not decoration:

• Does the image convey information that I ought to put as text in an alt attribute?
• Do I want to make sure the image always prints because without it the
  printout wouldn’t make sense or be complete?
• Do I want to link the image?

If the answer to any of these questions is yes, the image is content and should be kept in the (X)HTML. CSS background images can’t achieve any of these goals—at least not without some complicated workarounds and hacks, all of which are quite silly, considering how easily a simple img element can achieve all this.

As with the background-image version of the variable cropping technique, you’ll need some block element in the (X)HTML to hold the image. We’ll use a div again; this time it won’t be empty, but will instead contain the img element:

<div id="foreground">
	<img src="styx.jpg" alt="my cat Styx" width="500" height="330">
</div>

Note: The img element has an alt attribute providing the text equivalent of the image. You can’t do this with a CSS background image.

Just as before, the div needs to have a flexible width and a height set to the pixel height of the image:

div#foreground {
	width: 50%;
	height: 330px;
	border: 2px solid #000;
	}

So far, all we have is a regular div holding a regular image—there’s nothing yet that makes this a variable cropping technique. If the image is bigger than the div, it doesn’t get cropped, but simply overflows.

To get the cropping effect, add overflow: hidden; to the CSS rule:

div#foreground {
	overflow: hidden; 
	width: 50%;
	height: 330px;
	border: 2px solid #000;
	}

Now whatever portion of the image would overflow out of the div is hidden from view.

Once again, though, it would be better for this image to be cropped from the left side, not the right. We can’t use the background-position property this time because it’s not a background image. To change how a foreground image is anchored within its parent, you can float the image:

div#foreground img {
	float: right;
	}

This anchors the image to the right side of the div, so more or less of its left side shows as the div changes in size. Using a foreground image results in an effect that looks exactly like using a background image, but the foreground image has alternative text, and you could also easily add a link to it.

Since the area available for an image to display within a flexible layout changes on the fly, your images may need to as well. While fixed-width images can work within flexible layouts—as long as they’re not too large, or you have matching minimum widths in place—there are lots of ways you can dynamically change the screen area that an image takes up.

One way to dynamically alter the footprint of an image is to make it literally scale, based on either the text size or the changing dimensions of its parent element. Both are elegant effects that are deceptively simple to create.

Both liquid and elastic scaling images start out with a regular img element in the (X)HTML:

<img src="styx.jpg" alt="my cat Styx">

Notice that this img element has no width or height attributes, as it normally would. You control the dimensions with CSS instead.

For a liquid image, create a CSS rule to set the image’s width to a percentage value:

img {
  	width: 50%;
  	}

Note: This rule will make all images 50 percent as wide as their parents. In a real page, you would probably add an id or class to the specific image you wanted to scale and use that id or class as the selector in the CSS.

No height value is necessary; the browser determines the height that will proportionately constrain the image’s dimensions. If you were more concerned about making the height of your image stay proportional to its parent’s height than you were with width, you could use the height property in the CSS and leave off the width property. Just make sure not to use the two together.

As with all percentage dimensions, the percentage width value you choose is relative to the width of the parent element. As you change the width of the parent element, the image scales to match.

If you want the image to scale with the text size instead of the width of the parent element, simply change the width value in the CSS to an em value:

img {
  	width: 20em;
  	}

Any time a browser scales an image, there’s going to be some distortion, but you can keep it minimal by starting out with a very large image so the browser will usually be scaling it down.

To assure that the browser always scales the image down, not up, you can set a maximum width on the image that matches its set pixel width:

img {
  	width: 20em;
  	max-width: 500px;
  	}

Tip: If the image must stay above a certain size to remain “readable,” add a pixel min-width value too.

Now the image will scale only until it grows to 500 pixels wide; thereafter it will act as any other fixed-width image.

Simulate image scaling with JavaScript

If you don’t want the browser to scale your images at all, yet you want them to change in size based on the amount of space available, you can use JavaScript to swap in differently sized versions of the same image. The JavaScript detects the user’s viewport size and chooses the appropriate version of the image to show. This works in the same way that resolution-dependent layouts swap in different CSS files based on viewport size.

A live site that uses image-swapping to simulate scaling is Art & Logic. There are four illustrations under the banner on the home page. Try narrowing or widening your browser window; the images don’t scale in real time in most browsers, but as soon as you stop moving the window, they jump to a different size to match the available new space.

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.

The slides PDF has quite a large file size, due to all the graphics in the PowerPoint, but I didn’t want to compress it very much and have all those graphics look distorted.

Designing CSS Layouts for the Flexible Web (PDF, 6.9 mb)

Designing CSS Layouts for the Flexible Web (PDF, 4.8 mb)