About fluid and fixed width layouts
Just in the last few days the old debate about fixed vs. fluid width in website layouts has surfaced again for some reason. I don’t think we will ever come to a consensus on the issue, so there isn’t much use in sharing my point of view. But a bit of debating can be fun, so I’ll do it anyway.
Regular visitors will know that I recently redesigned this site. Before the redesign the site had a fixed width layout. Now the layout is neither fixed nor fluid, but elastic. I always wanted to use a flexible width of some kind, but never took the time to implement it until now. But why did I leave the fixed width format?
First, if you haven’t read the posts I was referring to, here they are: Fixed fashion (Jeremy Keith), Internet as the medium (Rob Mientjes), and Fixed Versus Liquid: The Beat(ing) Goes On (Molly Holzschlag). Done? Good. Welcome back.
I finally took the time to redesign, that’s the major reason. Another reason is that I know much more about CSS now than when i created the first version of the old design over two years ago. Back then I couldn’t get a fluid width to work the way I wanted, so fixed width it was. After all, a fluid width layout is more difficult to get right than a fixed width one. Especially when you take Internet Explorer into account. Nothing new about that.
A common argument against fluid layouts is that lines can become so long that readability is decreased. Yeah, well that depends on how wide you make your browser window, doesn’t it? I just don’t get why some people are so hell-bent on letting their browser window fill the entire screen. I think that “maximise me”-button thing in every Windows app is to blame for that. It’s just a little bit too convenient. Would you still push it if you had a 30”Apple Cinema Display with a resolution of 2560 by 1600 pixels? Really? Of course not. You’d probably be using that monitor with a Mac, and extremely few Mac users have the maximise bug.
Ok, so the next argument is that many people using the web are computer illiterate and won’t know how, or even that it’s possible, to change the size of their Windows windows. Let’s assume that’s true; now, how many of said computer illiterates are using monitors large enough for that to actually become a problem? Would you say that it’s common for people who do not know that they can resize their browser window to be using a screen resolution of 1600 by 1200 pixels or larger?
Ok then, I’m often willing to compromise, so the current 456 Berea Street layout is fluid and has a maximum width to prevent lines from becoming too long. But setting a maximum width in pixels can cause the opposite problem of having no maximum width: when you increase text size a lot, lines can become too short to read comfortably. I got around that by specifying max-width in ems, which lets it increase and decrease with text size.
Oh, and then there is Internet Explorer. A reasonable guess is that nearly all of the inexperienced users for whom not having a maximum width would be a real problem they cannot deal with are using some version of Internet Explorer for Windows. And that browser does not support max-width.
Fortunately it does have the proprietary expressions extension to CSS. Using expressions it’s possible to give the layout a maximum width even in Internet Explorer. But in pixels, not ems. I don’t know if a width expression can be made to work with ems, and I’m not spending the time to find out.
Internet Explorer for the Mac, then, does not support expressions either. I was close to dropping CSS support for it, but decided to let it come along for a final ride. Without a maximum width. At first I used an ugly CSS hack to feed it a fixed width. That has since been removed. One less hack in my CSS file. And very, very few will notice.
So there you have it. Elastic width for modern browsers, fluid width with a max-width for IE/Win, and fully fluid width for IE/Mac and everyone else.
Looks like I need to add a little bit of clarification here, since I’ve exaggerated some points a bit in this post.
Subscribe / follow
- iOS Architect at Mutual Mobile (Austin, TX, Te, US)
- Front End Developer/Website Manager at Chapelboro.com / WCHL (Chapel Hill, NC, No, US)
- UI/UX Engineer at Skyscraper (San Francisco, CA, Ca, US)
- Publication and Textbook Designer at The Church of Jesus Christ of Latter-day Saints (Salt Lake City, UT, Ut, US)
DreamHost web hosting
Use the promo code 456BEREASTREET3 to save USD 20 when you sign up for DreamHost