Specify a maximum width for em-based layouts

As someone who likes to bump up text size a notch or even two on many sites, I often notice that this behaviour is not something that web designers in general anticipate. However, layouts do tend to be a little bit more robust now than a few years ago, at least at a moderate increase in text size. That’s good, though I think in many cases it is just a matter of luck that nothing gets obscured as text size is increased.

One technique that can easily make reading a site a lot more uncomfortable is using an elastic, or em-based, layout such as the one I use here (and talk about a bit more in detail in Fixed or fluid width? Elastic!) without specifying a maximum width in another unit. I’ve come across a few of those recently, which could perhaps be explained by the fact that the preset fixed width layouts created by YUI Grids CSS are of this kind.

Since the em unit is tied to the browser’s text size, increasing that size will have consequences. Let’s say you have specified that the total width of a layout is 60em. As text size is increased, so is the entire width of the layout. In the absence of a max-width CSS property that uses another unit, like pixels or percent, that will rather quickly lead to horizontal scrolling - and plenty of it - unless you’re browsing with a very wide window on a very wide screen.

And how is that a problem? Well, if you need larger text, you’re likely not going to appreciate that in order to get larger text you will have to put up with a lot of horizontal scrolling to find parts of the site. It doesn’t make the site completely inaccessible or impossible to use, but it does make things harder for anyone who likes larger text and does not use a very wide browser window. Alastair Campbell talks more about the issues this can cause (and why “elastic” may not be the ideal name for em-based layouts) in Elastic layout - wrong term?.

So just a heads-up: when creating an em-based layout, consider using max-width instead of width. As for IE 6, which does not understand max-width, I tend to either use a dynamic property to give it a maximum width in pixels or just give it a fixed width (again, in pixels). I think both options are better than setting a fixed width in ems since they are less likely to cause massive horizontal scrolling at large text sizes.

Posted on March 3, 2008 in Accessibility, CSS, Usability


  1. You’re absolutely right! I try and incorporate a max-width on the “elastic” websites I create, where I can.

    It would be interesting to see your take on max-width by the way, especially the way you work around IE6.

  2. I refuse to do em-based layouts - one reason I refuse to is because it’s too much of a hassle compared to pixel layouts. We are working in a competitive business where every hour we spend on details like this could be spent on more worthwhile items e.g. refining of the layout and optimizing file sizes.

    My other objection is that page zooming is the responsibility of the browser, not of the web designer. Firefox 3, IE7 and Opera 9 all have page zooming instead of text zooming. You can safely specify everything you want in pixels and the browser does the job for you. This is the way it’s supposed to be.

  3. Wolf, it is indeed a competetive business, let the games begin!

    As I’ve stated elsewhere before, creating fluid scalable websites isn’t really that much harder. It’s just a bit more to learn, and so much easier, once you get your head around it. Check out Tripoli CSS for easy entry into the scalable game.

    The argument about FF3, IE7 and Opera is flawed. You’re relying on specific browser behaviour to fix your work for you. What happens if those browsers combined market share never rises above their current levels?

    What happens if new useragents become more popular (iPhone)?

    What happens when new, higher DPI displays become the norm?

    I am guessing that for FF3 (beta), IE7 and Opera, their combined market share is 50%. So, you’re admitting that you’re willing to sacrifice the quality of your clients websites for 50% of the internet population, just to push it out the door a day or two earlier.

  4. Although I’m aware of the debate (and I don’t quite agree with your view), I think you forgot to mention one thing which is quite important.

    Specifying a max-width is important as long as you don’t specify it in ems too (which I usually do to get a liquid/elastic layout). If you do specify it in ems, it won’t hold back the scrollbars :)

    (oh, and em-based layouts aren’t much hassle as long as you know what you’re doing)

  5. Nice debate, the same topic was proposed for discussion on Digital Web recently.

    As for me, I generally specify a max width and give a fixed width to IE6.

  6. March 3, 2008 by Roger Johansson (Author comment)


    The IE 6 workaround I use is nothing special:

    1. width:expression(document.documentElement.clientWidth > 960? "960px" : "auto")

    It isn’t connected to ems at all, just a fluid width with a max-width.

    Niels: Good catch, I forgot to mention that the max-width needs to be specified in a different unit or it won’t make a difference. I updated the article.

  7. I haven’t thought about that, but I will admit that I’m a bit laxed about using em very often, I don’t like people changing the text size as I think web should have fixed designs usually, but it’s usually possible on my sites without it looking really ugly, except if you use IE of course.

    And for IE6 changes I always make another CSS File that has IE6 specific stuff with a conditional comment in the html to make it load. That way I won’t have to change any css later if a new IE version would not read hacks.

  8. @Morgan Roderick: it’s not that I can’t do it, it just takes an awful lot more time to get it right. It also imposes more design limitations (see http://ejohn.org/blog/sub-pixel-problems-in-css/ ) and is generally one of those things that is just not worth doing. Out of principle, but also because of the really bad effort vs. result ratio. How many people are out there that actually know how to resize text and use IE6 as their browser? I’m not going to throw around made-up statistics like you, but think about that for a second.

    I am not relying on specific browser behavior to fix my work. I am saying if [this] is a feature you need, you should consider switching browsers. For too long we have been the slaves of lazy people. Updating your software takes what, ten minutes?

    Yes, IE6 gets a worse treatment than every other browser out there. If I have rounded corners in my design, they are often disabled in IE6 because they cause rendering bugs. If something is transparent, it gets replaced by a gif or is just non-transparent (if it’s a background). Visitors using IE6 get a version of the website that is visually less pleasing, but one that is still entirely functional and usable.

    If zooming is an issue to you, get better software. You can’t rely on web designers to fix a software issue. If browser vendors fix this issue, which most of them have done in their latest version (Webkit is missing I believe), that’s a hundred times better than letting every web designer spend extra minutes on a detail like this.

    By the way, practice what you preach. The sites in your portfolio don’t comply with what you’re saying.

  9. March 3, 2008 by K. Ralho

    Well… fck CSS. There, I’ve said it. I wanted to do an 100% fluid website and couldn’t do it. Not because of the fonts (fck that, since all major websites zoom), but because there’s a lack of support for such implementations and it’s a fcking mess with percentages and sht! How hard is to set [20%][80%] and then [20%]\n[80%] on the [80%]?

    Fck this shit, we should go back to the old pure HTML (SGMLOL) days. Fck the presentation!

  10. If one has to base layout-width on ‘em’ and add an expression for IE6, why not give it an em base max-width solution?

    Mixing pixels, percentages and ‘em’ in the same layout without running into “horizontal scrolling” imposed by font-resizing, is not really a problem either, but few layouts are in need of the whole package for IE/win.

  11. March 3, 2008 by Stevie D

    Another situation where the continued use of IE6 causes a nightmare for the conscientious designer. Any browser that supports page zooming should work around horizontal scrolling, rendering this problem irrelevant.

    People who are still using IE6 can expect their browsing experience to be poorer than someone using a real browser. If we add weeks to every project to ensure pixel perfect rendering in IE6, where is the incentive for them to upgrade?

  12. I have been using elastic width layouts with max-widths (and expression hacks for IE6) for a while now, including on some high profile ones.

    Generally it has been no problem. I appreciate some very, very fine details at pixel level and rounding calculations can cause problems but usually can be worked around in some way.

    I have noticed, however, that sometimes the expression hack for IE6 will cause CPU to spike (it is not great for performance usually, anyway).

    With more browsers offering zoom, it will be interesting to see how general trends appear. In a way zoom is nice, but sometimes it is annoying when it distorts images. Especially if you have spent time making larger images that reveal themselves as you scale, so your design remains fluid and flexible…!

  13. Ahh yes. This is what I’ve been doing for a while now after investigating your site Roger a few years ago. Very few sites employ this flexibility and it is very annoying when I set different default font sizes (ie, not 16pt) on my different resolutions (TV, monitors) and the site become unreadable or even breaks the layout.

    So I would have to disagree with some of the commenters who say it is up to the browser vendors to fix this solution and provide better page zooming tools. No! It is very possible for the designer/developer to make their page scalable and takes no more time than using pixels. In fact once mastered I think it is even quicker. If you need to alter the percentage widths of the main and side columns for example, change these two numbers and the rest of the page automatically adapts. This offers so much flexibility for reusing modules you have designed to fit into different sized templates. I love it! I would never go back to building websites where its structure is determined by pixel widths (unless forced to by clients :( ). Websites should be flexible not pixel perfect. This isn’t a print environment.

    During @media 07, Jeremy Keith and his panel mentioned this article written in 2000 (still makes sense today):


    All web designers/developers who care about producing the best websites should read this. It might make fixed-width people consider things differently.

    Mmmmmmm, adaptability.

  14. I am using this technique successfully for some time now, and as of the problem with min-/max-width support for <= IE6 users, I don’t care anymore. I simply make the page work nicely enough to be readable.

  15. @Morgan Roderick

    Let’s pretend that your statistics are right for every website on the web and Firefox, IE7 and Opera have 50% of the market share.

    Then that’s 50% of people that can surf 100% of sites with the text size increased and experience scalable designs as though every website on the web uses em units. The other 50% of people can surf ~1% of sites that bother to use em units.. and maybe a generous portion of the rest of the web with the text size slightly increased while experiencing aesthetic glitches in most sites they frequent.

    OK, I don’t know what the stats are for the other 50%, so I made them up, but it’s pretty obvious that the burden should be on the browser instead of the website. Page zooming should be a standard in and of itself. em units should be abandoned. Page zooming gives em units to the whole web instead of only that tiny fraction of sites that bother to implement em unit based designs.

    The cold, hard truth is that most designers don’t know what they’re doing, and won’t ever bother with em units. Some designers do know what they’re doing and won’t bother with em units because of all the design hassles that introduces. On top of that, em unit design is well on the road to being just as obsolete as the <font> tag, because 50% of browser users don’t care if you use em units or not — they already have scalable design!

  16. @Richard York

    EM units should be abandoned? Then the browser vendors should take away the default font size setting too? And all browsers should be shipped with a fixed 16pt font size?

    Or are you saying that if the user has their default font size at 19pt, the browser should automatically increment its zoom by 3 for example? Yay, distorted/pixelated images for those users.

    Yes page zooming for some users/websites would be a nice feature in all browsers, but as an optional extra. Plain old text size increase should be the default. I don’t want distorted images when I want better readability. I worry for Firefox 3.

  17. March 3, 2008 by Ty (tzmedia)

    I haven’t ventured into an Em’s based layout yet, but it does have merit and possibilities. My favorite post on the subject is Jon Tangerine’s: http://jontangerine.com/log/2007/09/the-incredible-em-and-elastic-layouts-with-css Why did it never occur to me about setting a max-width? I guess because the whole point is ultimate expansion of the layout. I think you are absolutely right though Roger, setting the max-width to where the third bump up in text size invokes it, makes good sense. Where did you dig up that IE6 fix, I’ve never seen that one before, proprietary fixes for a proprietary world I guess. Thanks Roger.

  18. @Richard

    Yes. They should be abandoned. When you fire up your browser for the first time, set the zoom level instead of the font size. As SVG gets implemented and its use increases, I think we’ll start seeing vector graphics more and more. And maybe someday IE will do proper anti-aliasing of scaled bitmaps. Until then deal with pixelated images. It really isn’t a bad trade-off.

    What you’ve said doesn’t change the fact that em units aren’t implemented in most sites, never will be, and will never be a practical solution to the problem. Good luck getting the majority of websites to even consider implementing em units now that there is page zooming.

  19. @Richard York

    I think you’ll find most designers do know what they are doing! It’s just the small percentage of cowboys that either can’t be bothered or don’t know how to fix the problems em based layouts can produce.

    Many designers like myself put time and effort into there designs, to look the best and stand out from the crowd. Why would we want it to break when somebody increases the text size.

    If you take pride in your work it won’t be a hassle. It would be just part of the everyday coding norm.

    I agree with the previous Richard (#16), Firefox 3 needs to get its act together and fix its text zoom feature or at least make it an option. Not the default.

    As all ways Roger another great article. Keep it up!

  20. @Wolf: I see your points.

    Firstly, I am not making up statistics, I am guessing … there’s a subtle distinction.

    I do practice what I preach (to some extent), but haven’t gotten round to updating my own website, nor my list of sites.




    The above are examples of recent work … as you can see, some of them has nice scaling of text and layout (well, somewhat nice), and one does not.

    As you can probably also tell, is that I am also getting better at it, but haven’t given up on pixels entirely ;-)

    The argument about getting better software, is an interesting double edged sword, as it cut’s us both. I use time to get my scalable sites to work in IE6, since I don’t expect users to upgrade. You’re spending time making rounded corners and transparency not suck in IE6, because you know that part of your audience will be using IE6.

    I wasn’t trying to pick a fight, although recent posts across the web would suggest otherwise, but am just making a point. You’re competing on pixel perfection, I am competing on device independence and (slightly) improved usability.

    @Richard York: Don’t feel about about the percentages, I am guessing as much as you are :-)

    But, it doesn’t strike me as an entirely wrong assumption that firefox 3 (in beta), IE7 (why won’t IE6 users upgrade) and Opera (norwegian gold) cover about 50% of the market.

    If you feel like waiting on major browser vendors to implement solid zooming, when they can’t (or won’t) even implement the most basic of web standards (that they’ve championed themselves), then more power to you! I am certainly not holding my breath …

  21. @Morgan Roderick

    No worries man, “lies, damn lies, and statistics”, right? I should have said that I agree that 50% is a good and proper generalization of those browsers’ mainstream market-share.

    I wish Firefox 3’s implementation were more like IE7’s, but I don’t think it’s all that bad…

    In any case I think we can all agree that IE6 cannot die fast enough :-)

  22. Roger, the link in your article to MSDN’s Dynamic Property is broken.

  23. March 3, 2008 by Kendall

    I’m a fan of this technique and always increase text size on your site so noticed you use it to and appreciate it that there are some who know how to accommodate people increasing text sizes. It took me maybe a minute to switch from a pixel width to em width layout despite how hard some people make it sound. I even use em measures for border widths some times s the entire site gets larger, not just the layout and font sizes. Browsers with features to zoom were only created to accommodate lazy and unknowledgeable web designers.

  24. @Richard York: Agreed on IE6 … I was quite relieved when they finally buried 5.5, and am hoping for IE6 to die soon …. but I am a bit concerned with their plans for IE8 … but we’ll see how bad it’ll be, and manage just the same.

  25. @Georg, You’re right, you’re conditional elastic layout is just what I would want to use, except that as you note:

    This solution does not work in IE6, if there’s even the slightest hint of Author’s font-size choice declared on html, body or wrapper-div.

    That’s quite a difficult one to get around, and would mean re-doing the CSS for many sites.

    You were kind enough to email me that when I asked on the CSS-D list, but I found it difficult to use in practice. That’s pretty much what turned me off the use of elastic layouts.

    However, having just seen you page on ‘more min/max-width in IE6’ where you explain a bit more, I might give it another go.

    It’s worth noting, IE7 has not helped in this regard, I just hope that IE8’s new engine will include better zooming options.

  26. This is something I have been working on to solve the em based layout issue. Comments/ help would be appreciate

    wrapper {
    margin:.5em auto;


    Then use the following for IE6 using proprierary CSS comments

    #wrapper { width:expression(document.body.clientWidth < 810? “770px” : document.body.clientWidth > 811? “” : “auto”); }

    We now have: a minimum fixed with of 770px a width of 48.125em i.e. 770px/default font size of 16px (to ensure nice resizing and tight layout) a maximum with of 98.2% to constrain the layout within the window

    The for IE6 we use the proprietary comment to say:

    Well if the window is less than 810px fix the #wrapper at 770px. Then if the value is greater that 811px let the ems do their thing. The logic here is that theres no point in having an elastic layout for a small resolution however with a bigger resolution it should be big enough to allow some scaling without a horizontal tool bar kicking in.

    This is a hobby by the way for me so if I have made an error here or I am missing something completely on this go easy.

    Noel Kelly

  27. @Noel kelly,

    If you turn it backwards and declare ‘width’ in percentage and ‘max-width’ in ‘em’, and use a more complete expression for IE6 (and older), you’ll get a much more user-friendly layout. Enforcing “horizontal scrolling” just to keep the layout-proportions intact, is not user-friendly, and may be why some browsers already have a “defense” against that kind of layouts.


    It is true that IE7 works better with ‘em based’ layouts when we resize fonts instead of zooming the page, since IE7’ zoom takes the page at initial size and just scales it up - and does a bad job of it too.
    In Firefox 3(beta) and Opera it makes no difference, since they handle a “conditional elastic” page the same way with page-zoom as they handle it with font-resizing. Fx and Op have the same “conditions” built in.

    Letting IE6 set its own font-size on html/body so we can extract its value for use in an expression, should not be problematic in any layout. Where the font-size bases are makes no difference to any browser, as long as we keep track of where we declare subsequent font-sizes and what values we give them.

  28. @Morgan Roderick

    I surely wasn’t trying to pick a fight, but you can’t be kind and have a real discussion going on. In the end we all have a common goal, creating the best site we can.

    I agree with your points, but still feel the time spent versus the result is not worth it. Usability is an important factor of course, and the main question I ask myself all the time when I do anything is “Will this work?”. But as I said, the time spent on this is better spent elsewhere.

    Imagine you have 3 days; one to design, one to slice, one to integrate in a CMS. You have an alloted time of eight hours to do what you have to do for each part. In those 8 hours of slicing [and testing], there surely are better things to do than a tiny detail like this.

    If you feel this is important, by all means do it, but for me, this item is very low on my priority list.

  29. I like using a max-width in liquid/fluid sites too, at least on parts of the site if not the whole thing. This of course must be in pixels. The reason is simply to keep line lengths in check. With em-based layouts the proportions will stay right, but on fluid site, what with today’s Xtreme monitors, lines can stretch well beyond the desired 80 characters.

    As it concerns IE, if doing an elastic layout, I try to start narrow enough to allow reasonable page-width expansion. Fortunately, the saving grace with IE is its limited ability to enlarge text (two sizes up).

  30. Excellent idea - I’ve been implementing EM-based layouts for quite a while, and the horizontal scrolling issue has bugged me many a time. Thanks for the ingenious max-width application!

    Also, I wasn’t aware em-based layouts were controversial at all… but the comments seem to prove otherwise. Everyone’s entitled to their opinion, I suppose.

  31. @Wolf: I like a healthy discussion like the next man, but have (over time) learned, that sometimes my language offends others.

    Those are valid points. With practice, and a good css reset, doing em based layouts will take similar time as doing pixel based. So I am working on getting there, am not quite there yet.

    On each project, I try to evaluate the techniques that I know, and try to apply them to the best of my abilities. For some clients, that means, going pixelbased, heck, I’ve been know to throw in a table (oh noes!!!) or two, if that would fix the problem across platforms.

    So, I guess the conclusion to this rather lengthy, and slightly off-topic, discussion would be that learning new stuff is great, but you still have to do the best you can, with the techniques that produces reliable and predictable results?

  32. Why would you want a maximum width on your site if you are making it elastic? Isn’t the reason you are making it elastic so you can essentially zoom in on the text and other items on the page? I have designed my site to do basically do the same thing that IE7 does, it zooms in, even in Firefox. This happens to be so that if there is someone that needs a larger font size they can zoom in or if they have changed there base font size in the browser it will all be easy to see.

    Also to the point that em’s are harder to implement is a crock. I have done layouts using pixels and it is no harder especially if on the body you specify a font size using x-small then base the rest of your page em sizes off that. If you are looking for a good way to learn elastic layouts “”Bulletproof Web Design (2nd Ed.) by Dan Cederholm is a great way.

  33. March 12, 2008 by Roger Johansson (Author comment)


    Why would you want a maximum width on your site if you are making it elastic? Isn’t the reason you are making it elastic so you can essentially zoom in on the text and other items on the page?

    The problem, which I explained in this article, is that not setting a maximum width will cause a lot of horizontal scrolling, which is a usability and accessibility problem.

  34. March 12, 2008 by Roman

    Enraged (or just vocal enough :) ) users of Firefox 3 beta have changed the minds of its developers, and the text zoom is back (as an option selected via a menu)! It is again better than IE and Opera.

  35. March 12, 2008 by Roman

    To avoid horizontal scrolling, setting max-width as 100% works too, which I think is better in some situations that using px.

    Has somebody said that doing that (or the expression hack in IE 6) doesn’t work in font-size is specified in ems?

  36. March 12, 2008 by Roman

    I meant “thaN px”

  37. @Roman

    Why should text zoom be an option and not the default?

  38. March 22, 2008 by Cecil Ward

    @Matt @Roger

    Roger’s point about avoiding horizontal scrolling is a very good one. But there are times when horizontal scrolling is a necessary evil. One example is where a page includes a data table. I had an experience with a page design that contained a column in which was a data table with four or five columns and around twenty rows. The data table was used to represent a timetable, containing geographical locations, dates and times, and was pretty wide. I had implemented a max-width on the containing pane as Roger discusses, precisely in order to constrain the width of text in normal flowing paragraphs elsewhere in the content. But a max-width that effectively constrained the total width of the table as a whole caused all kinds of other usability difficulties, with some cells needing to line-wrap internally or becoming two “narrow” in terms of the number of characters they contained horizontally. The point is that max-width of containers is easy enough in say a simple article with paragraphs of text alone, but containers that themselves contain more complex sub-layouts can experience breakage.

    The second problem I have is “what max-width do we choose”? Do we make a choice based on unprincipled guesswork concerning the size of displays? Do we use some percentage, which will certainly prevent horizontal scrolling altogether, but could render layout unusable and so inaccessible on small displays.

    It would be good to build a layout playground website featuring different layout design strategies plus different kinds of content, then write up which design choices do or do not make sense when tested against various accessibility use-cases.

  39. March 23, 2008 by Roger Johansson (Author comment)


    Roger’s point about avoiding horizontal scrolling is a very good one. But there are times when horizontal scrolling is a necessary evil. One example is where a page includes a data table.

    Oh, absolutely. Wide data tables are a pain to work with. However unless you enforce the “no scrolling ever” principle by using overflow:hidden, won’t the browser always automatically introduce horizontal scrolling for over-wide content such as a wide data table? it might not look good, but the table should be intact and the data readable. Or perhaps I am missing something :-).

    The second problem I have is “what max-width do we choose”? Do we make a choice based on unprincipled guesswork concerning the size of displays? Do we use some percentage, which will certainly prevent horizontal scrolling altogether, but could render layout unusable and so inaccessible on small displays.

    One option that I’m not using here currently is setting it to 100%, making it adopt to the user’s window width. As long as you combine it with a min-width and a width the layout should remain fairly usable regardless of window or display size.

  40. March 26, 2008 by Giuliano

    I have to agree with Wolf. We are using too much time making our design work on multiple browsers. Do we really have to add even more headache to our selfs?

    If some company is developing new web browser, or new version of existing browser, they should make their product is showing our designs as we design them. We are waisting too much time just because internet browser developers are living and working in the Wild Wild West.

    There should be someone (Internet God) who has authority to stop publishing of the browser if he’s not working by the big book. We need strict rules here!

    At this moment we have Explorer and Firefox as a big players. Just imagine if some new browser appear and grab 20% of the market. Of course, new browser will work by his rules. Do we have to redesign all our websites so “new browser” can show them or they should redesign their product?

    I’m not ready for a 3rd player! I have enough headache with these two guys (and the rest of the gang). Just browse through this site for example. Probably 80% of articles is “How to make “this” working in multiple browsers”.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.