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.
Very nice read. No, you are not alone 🙂 I like fixed layouts and they make perfect sense in some cases but there is some beauty in elastic layouts. The balance and harmony of text and rest of environment.There is one strange thing when you build elastic layout it is “pixel perfect” job and everything should be in harmony with everything else.
I’m receiving similar comments for my project Emastic that ems are outdated.
But I think that everyone should try at least once to build em based layout. It’s something spacial about ems. I’m always exited that I can change the entire layout by chaining one parameter.
There is one more possibility of elastic layouts, theoretical we can serve different layouts for different monitor size by only changing text size in the body element. Example: if the users have 1280px monitor we will have text size(body) of 1.2em and for 1024px monitor we will have 1em text size. So we will have 2 layouts by only changing this “body {font-size:1em;}”, obviously we need some web programing for detecting the monitor size.
Vladimir, I’ve seen your CSS framework in the past and bookmarked it to look into further. Thanks for the reminder!
Be careful basing anything off monitor size, as not everyone maximizes their browsers. Detecting viewport size is a better way to go.
Nicely said, Zoe. I’ve been arguing similar points in response to fluid grids and fluid images articles, and couldn’t agree more: page zoom is an awesome feature, but it’s kinder to the higher end of the resolution spectrum than it is to the lower.
Thanks for the read.
I’ve caught this post at a funny time in my browsing evolution.
In order to fit things so that I can have TweetDeck open on one side while I also talk with someone in MSN while surfing the web and editing a site I have open in another window, I’ve basically split my 1920×1200 screen into a few different areas. Two thirds of the monitor contain four 640×550 windows, there’s a thin bit for my feed reader or my messenger windows, and then TweetDeck and a little box that keeps track of my internet usage have the leftovers.
Anyway, the main point is that I’m browsing on 640×550, minus chrome and toolbars. My exact viewport is 622×475, which means I get a scrollbar on pretty much every site I go to. Even if I don’t, there are usually broken floats or something.
To solve this, I basically just zoom out two or three clicks of the mouse wheel. That usually made the text too small, so I just set it back up again, to about 22pt (which looks about 10pt or so).
Actually, I think my biggest problems are those sites which force the text-size to some specific value. No matter what I set mine to, the text is so tiny that it becomes an anti-aliased grey, and I have to hunch down to the level where my LCD gets dark.
Oh, speaking of which, your sidebar on the right? It wraps down and then goes off the screen. I manage to see about five pixels of it.
Michael, thanks for sharing your experience. Glad to hear I’m not alone in dividing up a huge monitor into thin, side-by-side windows. Regarding the float drop — yep, I’m on it. It’s one of those “cobbler has no shoes” things. 😉
Safari 4 now zooms the entire page, not just the fonts. You do have also the option to make the fonts bigger “Zoom Text Only”; these are great features I think and the other browsers should implement them too.
“…no shoes…”
Oh, I know how it is. I haven’t touched the coding on icosidodecahedron.com in a couple months, I think.
Whenever I hear developers going on about it being “time to go past 960,” I cringe. 960 happens to be half of 1920, and I have a wonderful app (Zestant’s reSizer) that lets me easily set my windows to half my screen (or a third).
Anyway, I’m using Chrome 2.x.
It no longer wraps, though it does lay on top of the body text. I suppose you’ve got a minimum-width set? 26em or so? I should note that I only have the problem with a large font and a small window, so it’s great now.
It is so nice to see others who set their browsers to zoom text only. I have a high resolution tablet pc 1400×1050 in a 12″ form factor. I typically use this tablet in portrait orientation. That means 1050px is my max width but I use a custom dpi. When designers map sizes to pixels my custom dpi is ignored and I end up with text that is the equivilent of 4.5pt print type, ouch. Zooming the full page invariably gives me pixelated images and a horizontal scrollbar – yuck.
When my tablet is docked to the large flat panel my application windows are sectioned off like Michaels. So I too cringe when I hear people proclaiming wider web page sizes.
I’m personally not a fan of zoom. I don’t like having the entire page enlarged. It forces people with low resolution displays to scroll sideways and people with high resolution displays to resize their window (usually). Zoom has become a default behaviour because most website don’t account for text-resizing. Even very high profile sites often fall to pieces with just ONE ‘notch’ of text resize. It’s shameful. But that’s the web for you.
So zooming, overall, is good. It solves a lot of problems; sites that don’t resize at all (pixels in IE), site where the designer thought that 9px body copy would look ‘cool’, sites that fall apart and break when resized… etc.
In a perfect world… everyone would code properly in the first place… using relative units… liquid layout when it makes sense… graceful resizing… etc. That will never happen though. Another thing that will never happen is me, as a developer, abandoning what I consider to be best practices in web design (see above).
p.s. No need to go past 960… line lengths and all that. We don’t print books on poster size paper just because we can. There will be cases where it makes sense of course… but in general… for information based sites… 960 is fine. The old 640×480 days were painful tho’!!!!
Thanks for articulating these points. I hinted at this problem last December wen looking at a “CSS Angles” tutorial, and wondered at that time how I should teach this to my students (http://flexknowlogy.learningfield.org/2008/12/03/re-css-angles-and-the-future-of-em-based-scaling/). I think your article will become required reading for them now!
Jared, your comment about required reading is funny, because I expect to be pointing a lot of people towards this article myself in the future. I get the question about how page zoom affects flexible layout a lot, and now I can point people towards this article to sum up all my thoughts on it. I wrote this up for my own benefit as much as anyone else’s! 🙂
I definitely agree browser zoom doesn’t get rid of the need for websites to have resizable text. For starters there’s still a fair percentage (> 10% by most estimates) of IE6 users out there who don’t have page zoom. Ideally they would all upgrade, but some – especially those browsing the internet at work – don’t have a choice.
RE elastic layouts: It’s nice to be able to let users set their own line length, but I’d still advocate setting a max-width on any layout. Most users I know (on Windows machines at least) just tend to maximise their browser window out of habit. If they’re using a wide-screen monitor this can result in some unpleasantly long line lengths, many users wouldn’t necessarily realise this and would struggle on without re-sizing their browser window, giving them an unpleasant experience viewing your site – even though they may not know why.
Effective design should always take into account the ignorance of the masses!
Joel, I agree that you should set a max-width to protect people, and that’s why I always put max-width (and min-width) on my sites. True, there is not one yet in place on my own blog — this site is still in development, and I will have the max-width and min-width chosen soon and added. The max-width will be in ems, not pixels, to allow users who have really big font sizes the ability to have wide windows without only a couple words per line because they’ve been pinned to an arbitrary pixel max-width. All those who keep the default font size will still have a max-width that computes out to a reasonable pixel measurement.
Wolf, I won’t attempt to convince you that I’m not an edge-case, that flexible layouts can be beautiful, and all that good stuff, because it’s clear you’re not interested in this topic. That’s fine.
For all the others reading this, though, please know that my book has an entire chapter on limiting flexibility (through max and min width and hybrid layouts) and an entire chapter on making images flexible. You can actually download the flexible images chapter (sans the exercise at the end of the chapter) at the book web site. Also, I’ve posted before on this blog about attractive flexible layouts to use as inspiration, and there are some good examples in chapter 2 of the book as well.
Ow c’mon. You’re an edge case for browsing specifically at 900px.
The reading length of this site (I count 184 columns on the content area, using a 24″ monitor) is terrible.
You’re saying that luckily you’re not the only one… well, you’re part of a minority holding on to something that -was- a good practice when everyone was surfing the web on 800×600 and 1024×768 and few people had monitors bigger than 19″.
People that specifically want long line lengths should disable CSS with a bookmarklet or use a user stylesheet.
Also, you can’t design sites that are fully liquid AND look good since, well, you know, images are fixed size.
W.
It’s silly to say that liquid sites cannot be beautiful. Every site I have designed in the past 15 years was designed to allow the text to resize gracefully… and I happen to think I’ve created some very nice looking sites. They are not “fully” liquid. I rarely do “stretchy” websites. And yes… that would add some further design constraints… but you could still make beautiful sites that have a min/max width… and you can still use images.
So all this proves what. That as we all know people browse sites in ways we never knew they would? we already know that You say “..I usually keep my browser window at about 900 pixels wide….most sites designed for a 1024 resolution produce a horizontal scrollbar for me…” yet you hate horizontal scrollbars along with everyone else.
The solution for this is not for designers to allow for every eventuality but to make your window wider! YES I SAID IT. Sure the user is in controll but that controll often produces unwanted results.
It is NOT the designers job to try to think of every esoteric way people can browse a website and to attempt to allow for that in their design if they did nothing would ever get built)but to serve majority of useres who when they get a scroll bar will increase their browser width. I’m all for increased usability, accesibilty and great user experiences, I promote these causes daily, and i believe the results should be proved by audiences. But a designer is just that, some one who designs and as such has the right to execise some smidgeon of control over a websites experience.
maak, I agree that we cannot plan for every variation of ways people will browse our sites. That’s impossible, of course, so you have to draw the line somewhere. But it’s really quite easy to make a site that works well and looks good from, say, 700 pixels to 1000 pixels, and this could help thousands of people. So to me, it’s illogical to alienate users when I could easily make browsing the site a pleasant experience for them. As someone who wants to increase usability, I don’t understand why you disagree so strongly with this.
Hi Zoe
Lots of this is matter of opinion..and its up to us designers to do what we believe serves our users best. I like many others I dont like reading long lines of text..like on this blog. so I rarely see yhe need to make a site stretch. Most of my clients and their users actually prefere the fixed length text…and the detail in design that comes with fixed widths. It’s true some cool things can be done with floating panels and lots of time spent working out what they do when the browser window is resized, but usually that time can benefit more users in other areas.
I am half-way through your book, Zoe, and want all “designers” to read it !!! I assist with coding at a web design class, and the teacher wants all students to slice and dice Photoshop images to make web pages. Invariably these are fixed width.
Experimenting with @media queries on a liquid design, initially for the iPhone, I found it easy to make pages one, two, or three columns, depending on the window width (EMs again) using only a few lines of CSS. This looks like a way forward, as Opera 7+. Safari 3+, and Firefox 3.5 support @media queries. There are JS solutions for IE and older browsers.
The entire premise of this writing most certainly seems very strange to me. Page zoom makes flexible layouts far more necessary than text zoom ever did in my opinion. I’ve been using Opera for years and I have to say, fit to width is one of the best inventions of recent years. Or in other words, a browser-forced flexible layout on inflexible layouts. Of course when a website is usable without fit to width, that’s all the better.
I take issue with poster 19 (i.e., WOLF) who said:
That’s not true as seen here:
http://sperling.com/examples/zoom/
As for me, I like flexible min-width layouts based upon em’s, which includes basing graphic size on em’s.
There’s no argument that taking advantage of the real estate the user provides is something we should consider, but we should also consider what’s the optimum width (in characters) for reading. Clearly newspapers and magazines have realized this long ago. As such, that should lessen our rush to “use the maximum width possible” and consider there are more things at issue here.
As for the dreaded horizontal scroll-bar, nothing is prefect. Most people realize that when they use a magnifying glass then they can’t fit everything they see into it. So, I don’t think it’s the problem that some people make it out to be.
As I get older, I have more need for the zoom and we’re all getting older — it’s something every web developer should consider in their attempts to reach the largest audience possible, which is what this is all about anyway, right?
This is an interesting article. I used to make all my pages fluid but haven’t done so for a while. I fancy trying it again having seen http://www.webstyleguide.com/index.html, which I just like the look of.
I guess the all dominant grid has partly put pay to fluid designs – we seem to like complete control over layout dimensions, just as we get in print. (I know you could create a grid using % but you still couldn’t absolutely control the column widths. Are there any examples of % grids?)
Having said that, don’t most users surf with their browsers maximised? Which means you’re going to get some rather wide measures. Could do something with
max-width, I guess, but then you’re going to get some gaps on wider monitors).And thanks for the book samples – they’ve given me some ideas to try out.
Nope, that isn’t acceptable.
It is not up to you as a designer to tell me how to set up my computer and browser. I have it configured to the size and setups that I find most comfortable to work with. Your job is to make sure that your website is sufficiently flexible to adapt to a reasonable range of requirements. And a viewport down to 750px wide is definitely “reasonable”. If you aren’t going to make the effort to design a website that I can use comfortably at my default settings then I will use your site as little as I can.
I am a rank amateur with an interest in this topic, and I have found the article and the discussion very helpful. But I have one troubling thought.
Most modern browsers have both text enlarge and page zoom, I think. (Certainly Safari and Firefox do.) These two options allow the user to enlarge text without enlarging the page (but risk strange things happening to the layout) or enlarge the whole page (but risk the dreaded horizontal scroll bar). If I use an elastic design, I cater for those who don’t have a modern browser, but don’t I take away one of those options? For if they set a minimum text size, or use text enlarge, they effectively get page zoom, just as if they’d chosen page zoom in the first place.
Is this correct? If so, elastic design increases the options for those with older browsers but reduces them for those with newer browsers. If not so, can someone please explain why? (This is not an argument but a genuine question.)
Thanks.
These are good concerns unkleE. You’re right about elastic designs offering less user control/choice than liquid layouts. That’s why I usually go for liquid. The main reason for creating an elastic layout is to set an “optimum” line length. But, there’s no line length that’s best for everyone–some groups will prefer shorter and some longer. However, I think elastic layouts are still useful; for instance, if you are developing for a set group of people, or if there is not a lot of text to read. The web site for my book, Flexible Web Design, is elastic for this last reason.
There is someone telling about here : http://stackoverflow.com/questions/7403438/how-to-deal-with-zoom-in-responsive-layouts