zomigi.com » layout

Examples of flexible layouts with CSS3 media queries

Zoe Gillenwater — Wed, 15 Dec 2010 11:22:17 +0000

In my CSS3 presentation that I’ve given several times over the past year, the part that seems to impress the audience the most is my demonstrations of media queries. I’m with them. I think media queries are perhaps the most useful and exciting piece of all the great new stuff that’s new to CSS3.

While creating effective, attractive, flexible layouts that adapt to the user’s screen size has always been possible, media queries add another layer on top of flexible layouts to make them even more adaptable to an even wider range of sizes, allowing you to really fine-tune the experience for even more users. Media queries allow you to selectively feed styles based on the characteristics of the user’s display or device, such as how much width is available in the viewport, whether it’s in portrait or landscape mode, or whether it can display color.

My demonstration of media queries is the fictional Little Pea Bakery site, created for my book Stunning CSS3: A Project-based Guide to the Latest in CSS. Here’s how it looks for most users (shown here at 990 pixels wide):

The "default" layout seen by most users.

It’s a liquid (also known as fluid) layout so it can adapt to the user’s screen size, but the design doesn’t look as good and isn’t as readable when the viewport width is very narrow or very wide. I used media queries to solve this problem. Here’s how the page looks over 1200 pixels wide:

The layout for wide screens (over 1200 pixels) adds a third column.

Using a media query and just a few lines of CSS, I was able to easily turn the horizontal navigation bar into a vertical menu in a new third column. This kept the text line lengths from getting too long and making the overall design look too stretched out.

Going in the opposite direction, here’s what happens to the design under 760 pixels wide:

The layout for narrow screens.

We’re back to two columns, as in the “base” layout, but I’ve made changes to keep the content from appearing too squished and the line lengths getting too short. First, I got rid of the two columns in the introductory text. I also moved the three featured product boxes from sitting side-by-side to stacking on top of each other, moving the icon for each one from the top of the product box to the left side.

A third media query improves the design on small mobile screens, seen here at 480 pixels and 320 pixels:

The layout for very small mobile screens uses only one column.

The design is now a single column. The main page heading and introductory text are smaller, as are the product icons.

To see all these changes in action, view the page yourself and resize the browser window. To see how it was done, check out the CSS embedded in the head of the page. You can learn the full details, of course, by reading Chapter 6 of Stunning CSS3.

For more examples of flexible layouts that use media queries to further enhance the site’s adaptability, dubbed “responsive web design” by Ethan Marcotte, see the following sites. Small screenshots don’t do them justice, so be sure to click through to the sites and resize your browser window back and forth to get the full effect.

All of these sites use liquid layouts, but that’s not a requirement for using media queries. It’s also possible to use media queries to essentially create multiple fixed-width layouts that can be switched between on the fly. A few sites that do this are:

Know of any other great uses of media queries in the wild? Please share them in the comments!

Update 1/25/11:

I’ve learned about a few other resources for media queries/responsive layout inspiration:

Also, I’m bookmarking sites that I find to be nice examples of media queries on Delicious.

Deal-breaker problems with CSS3 multi-columns

Zoe Gillenwater — Fri, 02 Apr 2010 15:36:48 +0000

I’ve been playing around with the new multi-column properties of CSS3 (column-count, column-width, and so forth), and I’ve come to the conclusion that they’re sadly not ready to really use. Sure, use them in experimental sites, and maybe even in mainstream sites in small doses with very particular types of content. But for most content, I found that there’s not enough control over how the content is distributed between columns to make them reliable. I’m not sure if the browser behavior I’ve been seeing is correct or not; the spec is unfortunately not well defined enough to make it clear—at least to me—of how browsers ought to be handling some of the problems I ran across.

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!

The liquid web site motherload

Zoe Gillenwater — Thu, 16 Jul 2009 20:03:13 +0000

I feel like a kid in a candy store. A nerdy kid. Because I’ve hit the liquid web site motherload: Nomensa’s portfolio.

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.

Why browser zoom shouldn’t kill flexible layouts

Zoe Gillenwater — Tue, 16 Jun 2009 14:24:38 +0000

Now that all the major browsers include the ability to zoom the entire page layout, rather than just increase text size, are liquid and elastic layouts obsolete? Can’t we just use fixed-width layouts and let the user zoom them if needed? The answer to that question depends on whether browser zoom solves all of the same problems than liquid and elastic layouts solve, and I don’t think it does.

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.

Voices That Matter: Web Design Conference 2009

Zoe Gillenwater — Tue, 28 Apr 2009 20:00:23 +0000

I just gave my talk Designing CSS Layouts for the Flexible Web here in San Francisco for the Voices That Matter: Web Design Conference. I was asked to give the same presentation I gave last year, but of course I had to do a little bit of updating and improving. So, here are the new and improved slides for your downloading pleasure:

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:

Updated flexible design inspiration

Zoe Gillenwater — Thu, 23 Apr 2009 02:48:54 +0000

I just updated my post on sites to explore for liquid and elastic web design inspiration. Web sites are constantly being redesigned and added to, of course, so I intend to keep updating the original post periodically. Please check it out, and post in the comments there if you have other resources you think we should all know about.

Living, breathing design comps

Zoe Gillenwater — Wed, 01 Oct 2008 19:51:31 +0000

In my book Flexible Web Design, I give lots of reasons why liquid/elastic layouts make sense. While this will hopefully convince you, the designer, to give them a try, it’s not necessarily going to convince your client that a flexible layout is acceptable for his or her own site—especially if you present comps to your client as static images created in Fireworks or Photoshop. Andy Clarke makes a great argument against presenting clients static design comp images because they set up expectations in the client’s mind that the design is always going to look exactly that way, instead of varying based on the user’s browser, text size, installed fonts, monitor colors, etc.

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.

Revised presentation slides available

Zoe Gillenwater — Thu, 25 Sep 2008 17:54:10 +0000

On September 10, I presented Designing CSS Layouts for the Flexible Web at the National Association of Government Webmasters 2008 Annual Conference. This was a slightly revised and lengthened version of my presentation from the Voices That Matter conference.

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)

Voices That Matter slides available

Zoe Gillenwater — Tue, 17 Jun 2008 23:21:52 +0000

The slides from my presentation Designing CSS Layouts for the Flexible Web at the Voices That Matter Web Design Conference are now available to download. It’s a pretty big file, 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, 4.8 mb)

Inspiration for flexible web design

Zoe Gillenwater — Wed, 11 Jun 2008 13:48:35 +0000

This post was last updated April 2009

Flexible web sites—sites that are liquid or elastic—have the unfair reputation of being ugly and plain. There are certainly lots of flexible sites that fit this stereotype, just as there are tons of ugly fixed-width sites. But flexible design doesn’t have to be unattractive. There are lots of really beautiful, graphically rich liquid and elastic web sites, which are all the more impressive to me because of the extra skill it often takes to pull off these graphic techniques in a flexible environment.

Here are some web design galleries that showcase flexible design:

No Resolution: This is an entire site devoted to showcasing liquid and elastic designs. Unfortunately, you have to register to submit entries, so things have been slow lately. Still, lots of great stuff in the archives, and new additions from time to time.
CSSGlance, liquid layout category: CSSGlance categorizes all entries as fixed-width, liquid, or elastic, which is really nice. They have a pretty good collection of liquid layouts.
CSSGlance, elastic layout category: Only a few things here, but elastic layouts are pretty rare in general, as well as hard to recognize with only a glance.
CSS Drive, liquid layout category: This category seems to have been mostly forgotten about recently, but it does have a good collection of liquid layouts from 2007 and earlier, and new entries do show up occasionally.
Unmatched Style, entries tagged as liquid layout: A very small collection of liquid layouts that is very rarely updated, but I include it here in case it takes off one day. Let’s hope so!

I keep my own collection of designs I find attractive and inspiring in del.icio.us. I have a number of liquid layouts saved as inspiration, as well as a few inspiring elastic ones. I’ll point out a few of my favorites:

~~SimpleBits~~ (sadly, no longer elastic)
Dizzain (liquid)
Castello di Bolgheri (liquid)
Sozidatel (liquid)
Simon Wiffen (liquid)
Clearleft (liquid)
Biola Undergrad (liquid)
RateMyArea (liquid and elastic)
iA (elastic)

zomigi.com » layout

Examples of flexible layouts with CSS3 media queries

Update 1/25/11:

Related Posts:

Deal-breaker problems with CSS3 multi-columns

Balancing column heights

Flowing margin and padding across columns

Breaking content across columns

Next steps? Workarounds?

Related Posts:

The liquid web site motherload

Related Posts:

Why browser zoom shouldn’t kill flexible layouts

Prevent horizontal scrolling

Take advantage of screen real estate

Allow users to choose their own line lengths

Set an optimal line length

Preserve design proportions

Make text more readable

Conclusion

Related Posts:

Voices That Matter: Web Design Conference 2009

Related Posts:

Updated flexible design inspiration

Related Posts:

Living, breathing design comps

Related Posts:

Revised presentation slides available

Related Posts:

Voices That Matter slides available

Related Posts:

Inspiration for flexible web design

Related Posts: