All in the <head>

– Ponderings & code by Drew McLellan –

– Live from The Internets since 2003 –


The Fallacy of Page Zooming

18 June 2009

A couple of weeks ago, Cameron Moll posted an article entitled Coding like it’s 1999 in which he put forward his case for switching back to using HTML4 and sizing his text in pixels. I’m not going to cover the HTML issue today (although I happen to disagree with Cameron’s choice), but I did want to put some thoughts down on the issue of sizing text in pixels.

The argument that many designers put forward is that working in relative sizes (such as percentages or ems) is hard work because you have to take inheritance into account. In fact, Cameron refers to it as the “burden of calculating relative units throughout a CSS document” in contrast to “the convenience of absolute units”. I can absolutely see his point on a surface level.

However, I see no reason to use pixel-sized text, and in fact I think it’s shooting yourself in the foot to do so.

The approach I take is to size the body element in ems, and then use percentages from that point down, so everything is relative.

When you think about what makes good design, a lot of it is about proportion – the sizes of elements relative to each other. What’s important is not that the H1 is 36px, but that it is three times the height of the body copy. It’s the sizes of items relative to each other that really counts – that’s what gives us proportion and visual hierarchy.

A lot of what makes a good technical implementation on the web comes down to flexibility. Building with pixels takes away your flexibility to make intelligent changes to text size.

Take that H1 as an example. If the design dictates that the H1 is three times the height of the body text, you might specify the body text as 12px and therefore set the H1 to 36px. If, six months down the line, user feedback tells you the the text size is too small, you might come along and tweak the body text to 13px. In doing so, you’ve compromised the design, as the H1 is now not three times the height of the body text, so you have to adjust that up to 39px. And the H2s are no longer twice the height, so you adjust those to 26px, and the sidebar and footer text is no longer… and so on. A nightmare of changes and recalculations for an extra pixel on the text size.

Compare that to working proportionally, as described above with setting everything in percentages off a base text size. I might set my body size to 0.8em, which is around 12px in most desktop browsers. I’d set my H1 to 300%, the H2 to 200% and so on. When I want to tweak the body text, the integrity of the design is maintained, as the CSS is expressing the rules behind the design, not just the execution of the design.

Text scaling is a red herring

There are obviously other arguments against pixel-based text sizes, such as being polite to IE6 users, and not having inheritance crippled by fixed values. One argument that Cameron puts forward particularly worries me, however.

For example, if a div contained text set atop a background image, we would have to either repeat the image as the div grew larger with text scaling or create the image larger than necessary to compensate for growth.

Whoa, Nelly. That’s a seriously dangerous line of thought. As I’ve said, a lot of what makes a good technical implementation on the web is its flexibility. The rest comes down to robustness – how far what you’ve built can be pushed and pulled and strained before it breaks. Regardless of the way you choose to scale text, the most dangerous assumption you can make is that what you’re looking at will never change.

To understand by page zooming is a complete red herring you have to understand this: the property of being able to cope with resized text is more important than the size of the text. There are many reasons why a design may need to be able to cope with change, from content being longer than you thought (e.g. forcing a heading to wrap onto two lines), or translation of the text into a different language, to future evolutions of the design or the design being used in ways that were never anticipated. Not to mention the fact that some browsers out there that you may never worry about enough to test in will just get your layout wrong. You have to build to be robust. It is the nature of the web to be robust.

Changing text size is a handy way to test for that robustness, but is it not itself the sole reason for it. Page zooming is a distraction, and you know what? Users can turn that feature off.

The only reason I can think of for using pixel-based text sizes is a perception that it’s less work. That’s a very short-term view, as the loss in flexibility and robustness is so damaging that you’re creating much more work than putting the effort in to do a good job in the first place.

- Drew McLellan


  1. § Dave Kirk:

    It’s interesting to hear an argument against reverting back to pixel based sizes with all the recent articles advocating it now that page zoom is more common.

    I have yet to make up my mind on whether to move back to pixel based sizing, having used relative sizes for the last few years. However, I am not convinced there is a ‘correct’ answer to the question. There are so many variables within web design and for me the key is making it an informed choice and articles like this are great for helping us to make that choice.

  2. § Peter:

    I can’t understand this massive shift toward pixel-based text size either. Thank you for voicing your opinions in a clear, linkable manner. I can recommend this article too: Why browser zoom shouldn’t kill flexible layouts. A little bit different approach, but valid anyway.

  3. § Amy:

    Very well said. It’s good to see someone come down on the other side of this argument. I’ve never really found it to be that much of a burden to implement relative font sizing in the first place.

  4. § James Lindeman:

    Good argument Drew. I still think it really depends on the job and the priorities/requirements of the design. I’m not sure I would agree that either way is ‘correct’.

  5. § Matt Bee:

    Absolutely. If anything, I’ve found setting font sizes throughout a document easier with relative sizing. My opinion may be wrong, but using pixel sizes is done by purely designers with little CSS experience or, to put it bluntly, lazy coders .

    If I had time and designers with the same mindset I’d make every site that realistically allowed it to be fluid, regardless of page zoom.

  6. § Justin:

    Perhaps using relatively-sized text won’t be such a perceived burden when browsers support the CSS3 rem unit.

  7. § Marco Jardim:

    I try to use EM as much as possible, but in certain conditions, like certain types of menus, or other visual elements of the site, I sometimes have to resort to using pixels.

    There are some visual elements that sometimes scale badly, not in Firefox, Safari, or other standards-compliant browsers, but in Internet Explorer, which sometimes needs a little nudge to keep things in shape.

    Though the tendency of which I use pixels as a font size has reduced greatly, there are some cases in which I can’t imagine doing things without it. A short example: a button with a background image.

    Sure, you can make the background symmetrical and there are dozens of little tricks you can use to make them scale well, but you can only use them when the person who does design is aware of the restrictions browsers have. When they don’t, I have no choice but to resort to a fixed measure.

  8. § Divya:

    >> Page zooming is a distraction, and you know what? Users can turn that feature off.

    I think users very rarely know about this feature. There are short cuts which are easy to remember for page zooms but not for increasing/decreasing text sizes in Firefox. I highly doubt if more than a handful of users who really need text resizing will know how to use text resizing rather than page zoom.

    I do agree with your point of the design being robust. But how do we convince the graphic designers who design for the web (and managers/clients) to not look for pixel perfection?

  9. § Andy Ford:

    I agree in most cases. But if your only target browser is WebKit (or to put it another way: does not include IE), then it’s probably fine to just use pixels. I still find myself using relative units and created a px to em lookup table called EmChart to help keep the math straight.

    One nit to pick: assuming a browser default of 16px, setting the body size to .8em is indeed ‘around’ 12px, but .75em is exactly 12px.

  10. § Peter:

    I’m also wondering about resolution independence – Apple’s Cocoa tries to tackle the problem even though we don’t really need to prepare desktop apps to work well in higher dpi environment. How we can “port” pixels to higher display res? Isn’t that futile by definition?

  11. § Chris Wallace:

    I agree that this is the proper approach. Cameron’s article definitely felt a bit off to me, he is usually spot on in all his work. I think the problem is, sure, it’s ok for Cameron Moll to use the font size approach he is comfortable with, but when you’re in a position to teach others, I think it is important to explain the benefit of percentage-based text sizing first so beginners understand both methods. Once you understand the reasoning behind it, only then can you make an informed decision one way or the other. Cameron did include a list of resources on the topic as well, which is good.

  12. § Travis Gertz:

    So, you see no reason to use pixel sizing… fair enough, but I’m seeing any compelling reason to use relative sizing other than a so-called loss in flexibility.

    Don’t the “reasons” you listed for using relative units ultimately come down to the design of the site? Shouldn’t it be designed to allow for longer headlines and longer content? Shouldn’t visual hierarchy and headlines be determined in the design phase?

    What kinds of unanticipated future evolutions can be solved solely by relative units? In what situations would a site need to be pulled and pushed in a way that pixel sizing would be any more of a burden?

    Maybe I’m being short-sighted, but I don’t see how relative units can fix any of this more than absolute units.

  13. § Billee D.:

    Very interesting article, Drew. I’m always looking to try something different to help with relative text sizing. My current trick is to set the body in percentages, typically 75% for roughly 12px text, and then set my font sizes throughout the document in ems; 3em equals 300%, etc. Dan Cederholm uses something akin to this method, but sets the base size at 62.5% which roughly equates to 10px.

    Setting the base font size in ems on the body certainly makes sense. Much more sense than setting things in pixels. I’m not quite sure what the current trend with pixels is all about, but as one commenter pointed out, it just seems to be plain laziness.

    I think you will start to see a shift towards this kind of relative text sizing once fluid grids become the new hotness. It makes perfect sense in this context.

    Thanks for the read!

  14. § Brian Drum:

    I would be interested to hear your reasoning for using XTHML over HTML. I quit using XHTML years ago, since:

    …the vast majority of supposedly XHTML documents on the internet are served as text/html. Which means they are not XHTML at all, but actually invalid HTML that’s getting by on the error handling of HTML parsers. All those “Valid XHTML 1.0!” links on the web are really saying “Invalid HTML 4.01!”. (Understanding HTML, XML and XHTML)

  15. § Pete:

    don’t always agree:

    I used to use a base font size and then use percentages, but they do not compute to the same size on screen on different browsers, so I returned to pixels and am much happier with the results.

    Having used the different approaches, it seems to me that there aren’t really many advantages to ems and percentages (beyond the ideological niceness of it) just more display inconsistencies, and more work in maintaining a site

  16. § Gail Dedrick:

    “That’s a seriously dangerous line of thought.” Plu-leeeze. Web designers and their hyperbole … really now. There is nothing – absolutely nothing dangerous about anything web designers argue about. Now the content out there, that’s another story, but pixels vs. ems could not be less important in even the small picture.

  17. § Drew McLellan:

    Travis – those issues you describe are more to do with thinking that because page zooming exists, text is not resized independently of layout and therefore designs do not need to be built robustly.

  18. § Christopher Meeks:

    Hi Drew,

    While I don’t always agree with Cameron, I think he has a fair point, as do you.

    I believe it comes down to how we work, individually. There are so many differences between design processes. I, for example, mock up everything in Photoshop – where I fine-tune the proportions and render most of the text.

    Here is the thing: Photoshop’s sizes are absolute. If you make a three column layout in Photoshop, the right two columns have no idea what the left one is doing.

    So when it comes time to create the living website, I’ve got a simple 1 to 1 pattern to follow in order to get it completed. I don’t have to rethink relativity, I don’t have to recalculate anything. I measure the pixels and type it in my CSS.

    I think you are correct in identifying the problem if you are accustomed to making small design changes on your site quite often. If you keep changing one element, relativity is a gorgeous thing. But the amount of time it takes for me to make my entire layout relative is often much more than the amount of time I’m going to tweak the CSS once it is complete.

    So it’s simple, there is no right answer. It depends on how you design and how much maintenance you anticipate.

    -Christopher Meeks

  19. § Jeff Croft:

    > What’s important is not that the H1 is 36px, but that it is three times the height of the body copy. It’s the sizes of items relative to each other that really counts – that’s what gives us proportion and visual hierarchy.

    Although I agree with this in principle, the real-world, practical workflow problem here is this: most of us designer create comps in Photoshop before we move on to CSS. In Photoshop, we’re setting that H1 as 36px, not at 300%. Then, when we move to CSS, if we use relative methods, we have to calculate: “Okay, if the body is 12px, what percentage do I need to make 36px?” That’s not that hard. But what about when you start nesting elements? “Okay, so the body is 12px, and then this div is 250% of that. And then this navigation UL is 75% of that. And now I need to make the links in it 18px.” Now I have to do complicated math in order to figure out how to get my links to be 18px like they are in my comp.

    So there are kind of two issues are play, here:

    One is that we use Photoshop, which doesn’t let us do relative sizes. You can certainly make the argument that we shouldn’t be using Photoshop, but my designers will punch you in the throat if you suggest that. :)

    Two is the fact that as a design’s complexity increases, so does the number of containing elements, which makes the math more difficult. If you have a very simple design with few containing elements, your method works fine, because the math stays simple. As soon as your design increases in complexity, though, it gets complicated.

    Personally, I think either method is just fine, and you should simply use what you’re comfortable with. I’m not necessarily saying pixels are better — I’m just trying to help people understand why many of us designers feel like using relative sizes is more complicated.

  20. § Olly Hodgson:

    @Peter – A CSS pixel is not necessarily the same size as a device pixel, so resolution independence is possible with pixel-driven designs.

  21. § Doug S.:

    Well reasoned, to a point, but still inevitably flawed.

    First, the only browser this decision effects anymore is IE6 and, to be quite frank, I could not care less about IE6 users. They make up a very small percentage of the kinds of sites I work on and as such I’m able to give them a basic level of support.

    As for your argument that developing in PX will cause you more work down the road, I don’t agree. I went through and changed a site I was working on from EMs to PX entirely and it took me about 30 minutes. It was a very large site with lots of CSS to fix.

    The “more work down the road…” argument is highly flawed because it took me hours to get the EMs working perfectly but didn’t even take me a full hour to move back to PX.

    So that’s argument two out the window…

    Then there’s the flexible vs. static layout argument. I’m going to bypass this argument all together as it’s one as old as the web and no one has come up with a conclusion either way. Many THINK they have, but they really haven’t. If they had we’d all be doing one or the other.

    But even after this the entire argument is a moot point. Why, you ask? Because we’re talking about text scaling! Either way it’s browser-controlled, yes? Funny thing is all the latest research (think Jakob Nielsen) has pointed that the vast majority of users don’t know how to zoom a page in a browser, let alone that they can. So PXs or EMs is a useless argument because most users would never, ever know there was a difference.

    Instead what we SHOULD be arguing is about better usability and control of things like text size in our websites. Instead of programming in EMs so that the browser can scale the text (which only IE6 would do) we should program in easy to use controls on our websites. Wouldn’t that be the more user-friendly option? Wouldn’t that solve the issue under debate here?

    We’re debating how to better leverage the browser without considering if the user even knows how to use their browser!

  22. § Drew McLellan:

    @Jeff Croft:

    Now I have to do complicated math in order to figure out how to get my links to be 18px like they are in my comp.

    As someone who is clearly not a designer and so doesn’t create the comps myself, I don’t build like that at all. I do almost zero maths. I figure out the base size, and then estimate the differences as I go. So I’ll see a large heading that I think is about 300%, try 300% and then just tweak. I usually get it within a couple of adjustments and it’s much, much faster than stopping to think.

    It sounds like a clumsy way to work (even to me as I write it now), but it’s actually not clumsy at all. It involves no maths and no thinking so it’s extremely efficient.

  23. § Amy:

    “As someone who is clearly not a designer and so doesn’t create the comps myself, I don’t build like that at all. I do almost zero maths. I figure out the base size, and then estimate the differences as I go. So I’ll see a large heading that I think is about 300%, try 300% and then just tweak. I usually get it within a couple of adjustments and it’s much, much faster than stopping to think.”

    This is precisely my workflow as well. I’m definitely not a designer so I study the mockups I’m given, determine the base font size, and make a ballpark guess for headings.

    The thing is, once you do a couple projects this way, it gets very efficient. Base font sizes for sites don’t usually vary a ton, so after a couple projects you just know what percent will probably work. No math is really needed.

  24. § Vladimir Carrer:

    It’s my third comment on this subject in two days.

    First I think we all are giving to much importance to this “not so important subject”, do you know someone why is using zooming or text resizing?

    It is a little contradictory that I’m saying this (I made CSS framework based on ems Emastic ) . I relay prefer ems, and for making em based system you need to plan everything, because is connected with everything else. Em are not so forgiving like px. But that is the beauty of ems you start with the main text size and on that base you build everything else. And that is one of the most important thing in typography and the design, first the text than the layout.

    Only when I want something quick I use px. Because they work and you don’t need so much planing.

    I think that px or em should be personal designer decision based on how they approach the CSS design process and design philosophy.

  25. § Sarven Capadisli:

    It is true that it takes a little bit more fiddling around with relative values than putting absolutes in. Whether one does “math” or no math, this is fairly trivial IMO. We might use any method whether it be our eyes, calculator, ruler, Firebug, or simply use the exact values provided to get the design right, however, I think the difference is a moot point in the grand scheme of things.

    I just hope that pixel-perfect designs are not what people are concerned with in these debates. I, for one, embrace the device-agnostic Web.

  26. § Peter:

    Maybe it’s not a place for a shameless plug – but if you’re having troubles with calculating ems (like I did), this will probably save you a lot of time.

  27. § Jeff Croft:

    Drew, I think your workflow is very common for non-designers, and it definitely is efficient and works well. No arguments from me! But, the fact remain that most designers prefer to work in Photoshop first, and Photoshop doesn’t offer relative sizes. I don’t think it’s a coincidence that it’s designers who are saying, “relative is complicated!” and developers who are saying “no it’s not!” It’s because designers and developers work quite differently, in general. :)

  28. § DN:

    Man, there are a couple snarky-pants commenters here. Bad form.


    Vladimir, I know someone with poor eyesight (not by way of disease; just aging) that uses text resizing (not page zoom). When I brought it up they had forgotten they’d done it at all. Even people who use it may not realize they’re using it (might be said something like ‘fixed the font size’ or something). Something to keep in mind.

  29. § Shira:

    I think some of the points you make here are valid and should be taken into consideration, but I disagree with the underlying assumptions behind the two arguments.

    1. I think that the premise that text size should always be determined in proportion to the body text is not always true. Going back to your H1 example, sometime a H1 header is set to a certain size because it’s the right size for it, taking into consideration its position, the font you’re using and the other non-text elements around it, and it would remain the right size for it whether the body text was 12px or 13px.

    2. Good design shouldn’t be sacrificed out of hand in the name of robustness. Not all websites would be pushed and pulled until they broke. It depends on the level of control / understanding the client has. Not all websites would eventually be translated (and those who would, wouldn’t necessarily be translated into German ;) ). There are quite a few instances where positioning text over an image would be a safe and valid design solution.
    You may think I’m nitpicking here, but the issue here isn’t this specific design choice, it’s the approach that indiscriminately puts robustness ahead of design even when there’s no call for it. We risk making the web a very boring place.

    3. Page zooming is a fact. Users aren’t likely to turn in off, they’re going to use it because it’s there and it helps them see the content better (those who even know it exists, that is). We have to take it as a given and work with it.

    So I absolutely agree with those who commented that each case should be looked at individually and addressed with the more suitable approach for it.
    Personally, I find that pixel based design quite often does the job for me. It also makes more sense to me when I go back to old designs as I can open up the CSS files and immediately see what’s what (whereas with ems/percentage I keep having to go back and calculate), but that’s just a personal preference.

  30. § Finn:

    Nice try, but what about the other side? What if the proportions should change? You specify body text to 12px and H1 to 36px. Body text is to small but H1 should stay as it is. Now with the relative way you would need to change all the definitions again. Same game, different trigger. As always, there is no “best solution”.

  31. § Emily H:

    I think I’m with Drew on this one, though I can see both sides.

    For those who do believe in sticking to ems but have difficultly with the maths (don’t we all) I wanted to share a couple really useful tools I use to calculate what my pixel text sizes should be in ems. It also calculates line-heights and margins to keep a vertical rhythm or baseline grid.

    On this webpage CSS with vertical rhythm you just put in your base pixel size and line-height and tell it what other target font sizes you want calculated and it will write out the CSS for you to copy and paste into your style sheet. I’ve created a couple templates using this tool, one for 10px/18px and one for 12px/18px, which I reuse all the time.

    But what about when you start nesting elements?

    You can also download a desktop widget from here CSS Typography Calculator Widget for OS X which again quickly calculates the font-size and line-height in ems from the pixels you put in. I use this one a lot for the situation Jeff mentioned with nested elements – you know when you have an element nested within another one that needs to be smaller so you’re going to have to make it like 0.8 or 0.9em? Well in this case I pop up this widget, enter the (computed) pixel size of the parent element, like 16px, enter the (computed) size I want the nested element, like 14px, hit go and out pops 0.875ems (and it is copied to the clipboard at the same time).

    So either you can do it Drew’s way of roughly calculating things in percentages, or you can use these tools (which help if you are like me and want the calculated pixel values to be whole numbers!) but either way – its easy and quick and means my dad will still be able to read the text on your web page.

  32. § Marco Jardim:

    @Pete from my experience it depends on the value of the base font size. If you’re dealing with a number that is hard to compute into a solid, or non-infinite, division the results will vary a lot. Specially on Windows machines where fonts sizes are adjusted “pixel by pixel”.

    If the font sizes on Windows are different from the Mac sizes you need to either find a better base value that will make it easier for you to divide, or be more specific with the value you put in (Example: 1.234em and 1.23456789em) otherwise the Mac browsers will think you mean a 1.234em meaning 14 pixels while Windows will think you mean 13.99px and will render it as 13px.

    I’m not 100% certain about this, but this is how I usually solve my cross-platform differences with relative sizes.

  33. § jamie Knight:


    This is an interesting discussion for sure, and i fall in the middle of it. Generally speaking sites font sizings are done in EMs for client websites, however web applications i tend to do with PX.

    I tend to look at this debate on two sides:

    1: The User

    So, often the user and browser stats etc are used to defend or attack various view points. I don’t quite understand this, the argument about page zooming (as a whole) or content zooming (just the text) is a valid one, and some users prefer it different ways. From what i can summarize, the browsers which allow the user to page zoom, or text zoom will do so whether a site is using PXs, EMs, or % (with the notable exception of IE6, but more on that later). So from the user perspective there is not a huge difference, I use text zooming a lot (i am zoomed as is type ;) ) and i personally prefer different behaviors on different sites, but then i am not exactly the typical user! So, as a user, to an extent (yes, IE6 will be covered in mo ) the EM and PX debate is not that relevant, the preference as to which style is used (page or text) is more important.

    2: The technical and theory

    As Drew lays out in this post there are a number of future facing technical reasons for using EMs. Like with validation (which becomes something you just do) i think Drew makes a strong case for using EMs from a technical view point. From my perspective the time aspect (for myself) has budget constraints, however following this debate i think i will spend a few hours revising my methods.

    As noted i think it depends on how you think as well, it has been raised above about the difference between developers and designers. From my perspective the clear technical advantage to EMs make them the number one in my mind, however if budget, time, or (in some cases) complexity issues means that in the interest of the user i end up using something different, to an extent i don’t think it is a huge issue.

    My final thought (which in some ways is my opinion ;) ) is about how i do things different depending on use, often for web apps (where IE6 is not in use) i use Px sizing, the same way that i use progressive enhancement. The system is still as usable as either way. For clients sites in the wild i use EMs (though i may be using them differently soon), this is because the site is likely to be used on IE6 and this is how to ensure that it is usable.

    Hope that helps, brilliant debate :)


    Jamie & Lion

  34. § Christopher Meeks:

    Just in regards to the comment that: “I take a designer’s comp and I eyeball it…”

    There are few things more frustrating as a designer than handing a very well thought-out, pixel-perfect comp to a developer, and having them “eyeball it” to get it close. Many times, those developers don’t see that a few important elements are 2 or 3 pixels off. But I can assure you, your designer sees it.

    I’ve too often let a design go to production because the developer did this, and there wasn’t enough time late in the game to fix it.

    So you developers may think that “eyeballing” a size is a quick an efficient means of developing, but I would argue that the accurate-ness you lose by developing this way is far more detrimental than the time you save is helpful.


  35. § Drew McLellan:


    There are few things more frustrating as a designer than handing a very well thought-out, pixel-perfect comp to a developer, and having them “eyeball it” to get it close.

    Taking an initial estimate and then refining does not mean that a developer is doing a sloppy job. That’s a completely outrageous thing to suggest. A sloppy developer will do a bad job no matter what methods they use. A good developer will do a good job, no matter what methods they use.

    Seriously. I’m furious that you’d even suggest that.

  36. § Doug S.:

    Sorry Drew, but I have to agree with Chris. It is sloppy. Refining would be unnecessary if they grabbed the right measurements the first time around. And, for the record, I’ve sat on both side of the fence as a designer and a developer and as such I know how both sides feel. It’s why I make sure when I build someone else’s design I stay as close to their vision as I can.

    To do otherwise is sloppy and you’re correct it would make them a bad developer. To do otherwise is to completely disregard the designer’s intent and since I know how much thought goes into a good design it can really bring a site down if the developer starts making judgement calls like that.

  37. § Drew McLellan:

    Doug, that’s utter nonsense.

    We’re discussing two ways to arrive at the exact same value. The first is to do some simple maths, which is easy and quick, but requires a little bit of thought. Gets you to the exact value. The second is to make an educated guess to get in the ballpark, and then tweak to the correct size, it’s less direct but requires zero thought (and no maths at all) and so is very efficient. Gets you to the exact value.

    So to be completely clear: both methods get you to the exact value. How you get there is a matter of personal preference.

    Neither method tells you anything about the quality of the developer, nor affects the outcome and quality of the work.

  38. § Rachel Andrew:

    When working with any scalable font size the first thing the designer has to realise is that it scales.

    So they can provide a Photoshop document with headings set to 16 pixels and the body set to 12 pixels, and we then have to convert that to ems and %. It will only be at the pixel font size specified if the user has their browser text set to the default. For anyone who has taken the text size up or down using their browser then everything – including leading etc. should remain in proportion.

    Whether I reach that point by calculating em sizes mathematically or eyeballing the design or picking a size out of a hat does not matter as long as the end result is correct. You can always do a quick test at the end using Firebug. Make sure your browser text size is at default, pick each bit of text and switch the em or % size to the pixel size you were given. Does it change? Yes – fix it. No – you’re set to go.

    If you are designing for the web it is in your interests to design in a robust manner. So that things don’t break if people resize their text or the client using their CMS puts twice as much text in an area as you expected. The developer can’t dig you out of a hole that you have created with an inflexible design – no matter how good they are.

  39. § Jeff Croft:

    As a designer, I don’t really care how a front-end developer gets to the final result, as long as they really do get to the final result. The problem with “eyeballing” is that many developers I’ve worked with stop there, and never actually get to the final result. I have no doubt that the talented, detail-oriented developers here wouldn’t be so lazy. But, I admit, as a designer, hearing someone say they’re going to “eyeball it” makes me cringe a bit, because I’ve been burned so many times by developers “eyeballing it” and it not actually turning out to be a precise representation of my design. If you can “eyeball it” and get it right, awesome. If not, please take measurements.

    This is really all about precision. If my Photoshop comp has a grid unit of 30 pixels, then dammit, I want the final web page to have a grid unit of 30px. Not 32. Not 29. 30, dammit. If you want to build it in ems, such that it’s 30px at the default text size, then please, be my guest. That’s just fine. But if you do it, and I get the final product, and it’s 29px instead of 30px, I’m going to hunt you down. If my comp has text set at 36px, then your web page better have text at 36px (at the default text size), too, or I’ll come after you. Precision matters. Yes, the web is a flexible medium. Yes, there is no guarantees of much of anything. But there’s no reason a developer can’t use the exact same sizes I’m using in my comp, so that’s what I’ll expect.

    Bottom line: if you’re lazy, please just use pixels to make sure you get the measurements right. If you’re very thorough, or just looooove doing math, feel free to use ems. But dammit, you better get it right, or you’ll hear from me. :)

  40. § Sarven Capadisli:

    Here is another issue that’s being overlooked: Most of the time the screen designs are given in static format. A single representation of a page given for desktop browsers. It is not how it may look on x-user-agent with y-resolution. For all those in favour of absolutism: you haven’t taken care of that in the past, how do you plan to do that now? IMHO, relativism is a (simple) realistic scenario.

  41. § Jason Grant:

    I work in ems everywhere pretty much.

    I think developers should do everything they can in order to provide as flexible a layout as possible.

    Sometimes pixel perfect requirements can drive you nuts and you might have to resolve to pixel widths on the structural containers, which isn’t so bad, but ems are preferable.

  42. § Zoe Gillenwater:

    I think one of the biggest problems with pixel-sized text is that you’re overriding the user’s chosen text size. Sure, you can do that with em and percentage based text sizes too. But at least those relative units are somewhat close to the user’s chosen size. Pixel sizes are arbitrary and could be incredibly far off from the size the user wants or needs to see. Sure, they can scale it, but why should they have to? This isn’t just about IE6 users.

    Here’s an analogy: You use some piece of web development software. You set all your panels in a specific arrangement. You want them to stay in that arrangement. But every time you open the program, the panels are reset back to the default that the software manufacturers thought was best. Sure, you can move them back to your preferred spots, and maybe you can do this in a matter of one or two seconds, but man, wouldn’t that be annoying to have to do that every time? Resetting the user’s text size to some pixel value with the attitude of “Their browser can zoom, so they can just fix it if they have a problem with it” is just as annoying and unfriendly and unnecessary.

  43. § Catherine Hodge:

    You are my hero! I’m working on building a website for a client and putting a little flash menu in seemed like a simple bonus feature … until I reached browser testing. I had to hunt, but I found your Satay method and both myself and my client are very happy with the remedy!!

    Thank you for making me look good. I’ll be following your blog going forward for all the juicy tips I’m finding here. :)

  44. § Michael Kozakewich:

    The biggest problem is that people say, “Oh, they can just resize it.” The problem with that is it doesn’t converge with fixed-width design. If I had one or the other, I can resize things. With both, I need to shrink the design but increase the text-size, which is just impossible.
    At least full-page zoom lets me shrink the design down; before that, I really couldn’t do anything but work with a horizontal scrollbar all day.

    Jeff makes the argument that most designers design in photoshop, which uses pixels. If I were to design in Photoshop (though perhaps my argument is weakened by the fact that I don’t), I would set things at a base of 12px or so and work, in my mind, with percentages, even though I drew everything with pixels. From there, I would turn it into code using the percentages I’d worked out.
    The problem, really, is communication from designer to developer. If I designed in percentages, I’d have to note it down somewhere for the developer. Frankly, the designer should make a list of all pixel values they use, and the developer could slice the page based on that. Pixels for margins, padding, heights, widths, and font sizes.

    Actually, once it became very common to be changing sizes to ems, I could see most developers even having a simple cheat-sheet with base pixel sizes and the ems that would go with that.
    I’ll have to make a webapp for that!

    Jeff, if you read this, I’d like to ask a question: When you design, do you give a list of text-sizes to the developer, or only the comp? Do they have to ask you specifically?

  45. § John:

    I agree with you. Using relative text sizes within a document improves usability, point blank. I also think the contrast between the size of h1 vs. body copy or headings vs. descriptions conveys much more than meets the eye, and relative units handle the task of evenly distributing sizes beautifully . Sizing elements of interest permanently traps the user in a box. Relativity adheres to a user’s needs and preferences and ultimately makes reading a pleasure. When done right, web documents become just as tangible books, catalogs and atm machines – and that’s the idea we’d like to implement, right?

  46. § Robin Massart:

    Regarding the discussion between Jeff and Drew on approaches to implement a Photoshop design:

    Surely the web is a fluid medium and thus expecting a web page to look identical a photoshop comp, whilst desirable, is not the most important issue. There are too many variations in browsers (especially with mobiles), settings, fonts, font-sizes and so on to guarantee a page will be identical to the comp in all situations. In fact this is impossible.

    The 30px grid might work in the Photoshop comp with Arial at font-size 12px. But won’t work if the user’s browser is set to use Times New Roman at 16px.

    My point is not that the developer should not aim to implement the design 100% accurately, just that in reality there will be slight variations across users and thus the ultimate aim should not be that the final web design equals the Photoshop comp, but that the look and feel of the design for most users (across numerous browsers) will match the Photoshop comp.

    Finally: shouldn’t the designer be implementing their own Photoshop comps in CSS/HTML and handing this over to the developer?

  47. § Rimu:

    All this thought put into whether to use px or em, and yet the font size on this web site is TINY (firefox 3 on linux)

    Wood…. trees….. Can’t see…..

  48. § Drew :

    All this thought put into whether to use px or em, and yet the font size on this web site is TINY (firefox 3 on linux)

    Sounds like you’ve got font issues with your window manager (it’s fine here). Good job the text is resizeable, isn’t it?

  49. § Jeremy Cook:

    I’d agree with Billee D here. I go with Dan Cederholm’s method and resize the text in the a CSS rule for the body to 62.5%. As all modern browsers set the default font size to 16px, this effectively knocks the text size back to 10px. This is obviously far too smal for normal use but it provides a good baseline. You can use ems to get pixel precision sizing by dividing the pixel size by 10. 12px is 1.2em, 30px is 3em, etc. This also works for sizing parts of the page (96em is 960px for example). I find this approach gives me the advantages of using ems but retains the precision of pixel based measurements.


Work With Me logo

At we build custom content management systems, ecommerce solutions and develop web apps.

Follow me


  • Web Standards Project
  • Britpack
  • 24 ways

Perch - a really little cms

About Drew McLellan

Photo of Drew McLellan

Drew McLellan (@drewm) has been hacking on the web since around 1996 following an unfortunate incident with a margarine tub. Since then he’s spread himself between both front- and back-end development projects, and now is Director and Senior Web Developer at in Maidenhead, UK (GEO: 51.5217, -0.7177). Prior to this, Drew was a Web Developer for Yahoo!, and before that primarily worked as a technical lead within design and branding agencies for clients such as Nissan, Goodyear Dunlop, Siemens/Bosch, Cadburys, ICI Dulux and Somewhere along the way, Drew managed to get himself embroiled with Dreamweaver and was made an early Macromedia Evangelist for that product. This lead to book deals, public appearances, fame, glory, and his eventual downfall.

Picking himself up again, Drew is now a strong advocate for best practises, and stood as Group Lead for The Web Standards Project 2006-08. He has had articles published by A List Apart, Adobe, and O’Reilly Media’s, mostly due to mistaken identity. Drew is a proponent of the lower-case semantic web, and is currently expending energies in the direction of the microformats movement, with particular interests in making parsers an off-the-shelf commodity and developing simple UI conventions. He writes here at all in the head and, with a little help from his friends, at 24 ways.