Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry


October 07, 2008

Somehow over the last year or two we’ve landed in a situation where most browsers now default to full page zoom instead of traditional text-resizing.

Opera has long used zoom instead of text scaling; as of IE7 Internet Explorer uses zoom to replace the older resizing method; Firefox 3 now defaults to zoom as well. Safari is really the only holdout at this point (and I suppose Chrome by extension, since they both run the same WebKit rendering engine) but, oh look, it’s coming soon to a future release.

Now it’s true that Firefox and Internet Explorer still offer the ability to scale text as they always have, but a user has to look for it; if there’s anything we’ve learned from that latter browser it’s that users aren’t inclined to change default choices on their computers, so I think it’s safe to assume most users will employ the newer method, if at all.

The implications on a designer are fairly dramatic; page zoom is an attempt to continue accurately rendering the page as it was designed, whereas text scaling simply reflows the text, often causing serious layout problems. With full page zoom, the responsibility for ensuring page integrity and legibility is moved out of the designer’s hands, and placed fully on the browser. With text resizing, the designer needs to be conscientious of the ways their layout will break at different text sizes, and compensate accordingly.

So, personal preference aside, I wonder whether designing around scaling text is still a skill we need to hold on to, and for how long. I’d be interested in hearing about reasons for and against, as I’m sure there will be both.

October 08, 09h

This is a good observation. I recently starting designing completely with ems using the 62.5% method. Now it looks like that might be in vain and I might as well start using pixels.

Either way, I still plan on using ems because I know how to use them and if nothing else, it will still apply to older browsers. But for newer designers learning CSS, I’m not sure *which* I would recommend now =/

October 08, 09h

Like anything, I suppose it’s a benefit versus time issue. As all the major browsers line up behind zoom, scaling text layout breaks become less and less of a potential mishap.

I would personally prefer to avoid having to worry about text-resizing layout breaks, as that’s always been (for me at least) a headache to deal with.

Despite that, it’s probably something that you’d want to be more careful with when working on sites more likely to be viewed by seniors who will make use of text-resizing.

For example, some sites I’m regularly working on include one for expatriate retirees and one for senior citizen health care. I’m going to guess that at least a portion of that user base will have font-resizing active.

So although I’d like to say “Yes, let’s not worry about it anymore,” a better response is probably “Let’s worry about it in select cases only.” Which is at least an improvement over earlier years.

Steve says:
October 08, 09h

One of the things to be careful of, with zoom becoming the default is that as default layouts get wider (960px) they need to remeber to take zooming into account to avoid horizontal scrolling, especially for low vision users.

Josh B. says:
October 08, 09h

Browsers still allow users to set a default font-size though, yeah? I haven’t explored this, but I wonder if the low-vision users who have increased this default font size will see a page that is “broken” from the very start, rather than the user who breaks the page manually using ctrl+ ? So page-zoom works around those designers who insist on fonts much smaller than the mean, but may not serve those users who are trying to adjust all websites for their less-than-perfect vision.

Dave S. says:
October 08, 09h

@Steve - “layout […] need to remeber to take zooming into account”

I guess the question is, how? With text sizing you could test and correct positioning and adjust font sizes; with page zoom being so firmly controlled by the browser, I’m don’t know if there are many things that can be done to compensate at a CSS level.

Steve says:
October 08, 09h

Dave, I think it comes down to what it all comes down to balancing conflicting requirements. Just because you can make the layout that wide etc. doesn’t mean you should.

October 08, 10h

I think that, as of today, designing with text-only scaling in mind is still the best way to create a web page, as it forces the author to make more rational choices, despite being, perhaps, less creative (or creative other ways).

But, if this page-zoom thing will be adopted by all the major browsers, as it seems, this simply won’t be valid anymore, because theoretically we should be safe all the time.

As far as horizontal scrolling bars are concerned, it will depend on how browsers actually implement that feature.

One way could be having horizontal scrolling bars, that means no controls at all on the layout’s width; another option would be continuing with text-only resizing, once the window’s width limit has been reached by the layout container. Ok this would be a little too imaginative, hehe.

October 08, 10h

As a user I’m still not sure whether I prefer the zoom option or the text-only option in FF3. I find myself going back and forth between the 2 settings.
Of course, as you state in your article, if the page zoom becomes de facto standard browser behaviour maybe it’s time to just start designing in pixels and stop worrying about ems.

David says:
October 08, 10h

Personally, I hate page zoom. I often resize text on web pages because my fellow web designers often seem to think that 10 px Arial looks pretty. In fact, I have my multi-button mouse setup with text resize shortcuts… and they get used daily. I’m not old, I just don’t like reading tiny 10 or 11 px text on my 24” monitor. In 13 years of web development, I’ve never built a site that couldn’t resize. However, many websites fail to take resize into account. So as a result of poor coding and amateur developers, we now seem to be stuck with zooming. Ugh.

So… should we still code for resizing? Yes. Of course. Because it’s the right thing to do and it doesn’t take any more effort (if you know what you’re doing).

Dave S. says:
October 08, 10h

@David - I did say personal preference aside. I don’t disagree with your opinion (I do the same) but it doesn’t provide concrete reasons to do one or the other.

cam c. says:
October 08, 10h

I’m with the pro-font-resizing crowd on this one; other than the extra time, there doesn’t seem to be any downside of designing a page to work with font-only resizing; full-page zoom will work regardless.

Dave S. says:
October 08, 10h

@cam c - I think the extra time is the main reason to argue against. I know I’ve spent my fair share of hours fixing or re-thinking layout problems caused by font resizing over the years.

I’m wondering if that’s now time that’s better spent elsewhere. Especially if the functionality is so hidden from the user.

Colin says:
October 08, 10h

I, too, have been thinking on this front recently. Creating designs that gracefully scale with the text size (to a certain degree) has always been one of those things I strive for because I think it’s too often ignored. Em-based thinking is a way of life (at least whilst staring at CSS code).

But if you consider why we use ems, it is because this is the best unit treated relatively by all browsers. The specs, however, define the pixel as relative to the screen resolution. So switching to pixel-based dimensioning (which is easier even if you are an experienced em ninja), equally adheres to the specification. It’s good to see the browsers coming around to the standards.

For the time being, I think we still need to consider our layout with text-resizing and not zooming, but we can be much more relaxed about it and shoot for plain legibility and not the integrity of the design.

October 08, 10h

Absolutely (pun intended) on the side of letting go of text resizing as the browser makers move to page zoom over text zoom.

I’ve long decried the complicated maths involved in getting things the way you want them using relatively-sized text, and touted the wondrous simplicity of sizing text absolutely. Of course, historically, it’s been a bit of a pipe dream, because using absolutely-sized text introduced serious accessibility issues. Today, I think those accessibility issues are mostly gone. IE6 usage is on the decline, and I think it’s fair to suggest that most low-vision users who need to resize text probably realized long ago that IE6 didn’t allow them to do so on all websites. I would love to see stats on exactly how many users who NEED to re-size text still use IE6 or lower. I’d bet it’s remarkably low – most of them have moved on to better browsers. Given that, I think it’s fairly safe to assume that virtually everyone who needs to resize text will be able to (whether through page zoom or text resize), and this will become even more safe to assume as we go forward.

Give me page zoom, and give me absolute units in CSS.

October 08, 11h

Well, there is a huge field where we still have to care about scaling text, and it’s called “fluid layouts”.

If you design your page with percentages, the page zoom function of modern browsers (IE 7 is an exception here) will scale the text, but not the column width. Thus it is not that much different to traditional text scaling, right?

October 08, 11h

Zooming can’t (yet) be considered perfect. I’ve noticed in FF3 that at some zoom levels, lines break differently than they do at 100%. There’s potential there for overflow onto an additional line, and anyone who hasn’t planned for that may not be pleased with the result.

October 08, 11h

Jeff Croft said:

“Today, I think those accessibility issues are mostly gone. IE6 usage is on the decline, and I think it’s fair to suggest that most low-vision users who need to resize text probably realized long ago that IE6 didn’t allow them to do so on all websites.”

But unfortunately text sizing continues to fail in both IE7 and even the IE8 beta. Remarkably, this is a glitch that Microsoft kept sticking to for some reason, even when the majority feel as though it’s a bug.

So, we can’t forget to factor that into our decisions on how we size text. IE users (any version) won’t be able to resize text set in pixels.

Yet another plus for page zoom I suppose.

Personally, one of the reasons I like sizing with ems, is that it forces you to be flexible – not only for resizing _text_, but for allowing varying amounts of content as well. Blowing up the text was always an easy way to test for the integrity of various design components, answering the question: what will happen if there’s more “stuff” here? Relative units allow for future expansion, last-minute edits, or ham-fisted modifications.

That said, sure it’s more work, not necessary for every project, etc.

October 08, 11h

It’s probably a good idea to leave a little buffer for the people that use text scaling. For now I’ll give them one bump up and still look good. I think anyone expecting to bump it up two or more times and for it not to effect the layout is asking for too much. I like the new zoom function of most browsers but I agree with others that it could cause problems with wider sites.

October 08, 11h

I tend to agree with what Jeff is saying. Absolute pixel values make things a lot clearer than having to divide em’s to create a proper baseline rhythm -

I also somewhat agree with what Dan is saying:

“Relative units allow for future expansion, last-minute edits, or ham-fisted modifications.”

However, I think this mostly applies to using em’s for containers and especially height values when you look at it from the page-zoom perspective.

At the end of the day, we should be promoting page zoom, and trying to get the bugs in the various implementations squashed.

October 08, 11h


When I suggested that IE7+ users could “resize” text set in pixels, I meant they could make the type bigger by doing page zoom. The point is: every browser in wide use today and not named IE6 has some kind of provision for letting users resize text. In some it’s page zoom and in others it’s text resize, but the bottom line is that people can make their fonts bigger.

Sorry I wasn’t more clear. :)

Chris Vincent says:
October 08, 12h

I’ve personally always used page zoom in Safari (on Mac OS X, control-scroll wheel zooms the whole screen).

I’d be surprised if this newfangled Safari-specific zoom wasn’t based partially on their work on Safari for the iPhone.

Oh, and I’m all for dropping support for text zoom. It saves me lots of time, lets me use absolute units for typesetting, and I think it’s a more forward-thinking approach to the issue anyways. Any time browser technology takes the brunt of solving accessibility issues before they become the designer’s responsibility is a good thing. Of course, there’s much more to accessibility than just legibility, some of which will always be the designer’s problem to solve, but the more time we have to spend on those issues, the better.

October 08, 12h


Roger, that. I just wanted to make sure people know the bug is still there (for text sizing) in all versions of IE. And it makes me cry at night.

Rock on :)

October 08, 12h

The days of designing for scaling are gone. Unless, of course, you need to support ancient browsers. For most, though, this type of design is simply not worth the effort.

October 08, 13h

I think there may still be room for the liquid layout techniques and percentage based font sizing considering a user experience for mobile web browsing that needs to translate to the conventional desktop browser.

Wow that was a really fucking long sentence.

Anyhow, check out Radiohead remix site in a conventional browser and then the iPhone Safari:

Aesthetic and color choice aside: it works rather well in both a mobile and desk context. While not using percentages I think such an effect could be achieved with more utility/awareness of said context to better effect. The experience is a little overwhelming in the standard browser.

voyou says:
October 08, 13h

“I recently starting designing completely with ems using the 62.5% method.”

The 62.5% method is fundamentally broken, so you should certainly stop doing that.

On the original question - the default font size still varies across individuals, browsers, and OSs, so I think it’s still important to use units that are relative to the text size. This is especially important for people who specify a minimum font size, because for them page zoom still won’t mean unit sizes scaling equally with text sizes.

October 08, 14h

Why does Jeff Croft hate web standards so much?

October 08, 14h

I wonder if it’s worth deliberately designing and working with the highest-resolution, smallest screens around??

Designing in pixels is a real killer for people viewing sites on mobile phones (where physical pixel size is so much smaller.) And working with a low resolution inevitably leads to small font-sizes as you usually want to fit more on-screen (words, lines… columns.)

Matt May says:
October 08, 15h

We’re suggesting the same thing in our book. Full-page zoom is going to obsolete the current best practice pretty rapidly. And as far as mobile applications go, they’ve been doing their own thing for layout for some time now, so it’s going to do more good than harm overall.

There’s a good design reason for this move, and it’s the same reason the OS vendors went to device-independent display drivers: the pixels-per-inch ratio is much more variable, with some displays topping out at 200ppi now, and getting higher. None of the numbers necessarily correspond to anything in the physical world anymore. It’s going to be the user’s prerogative to display their browser window in whatever proportion and magnification they see fit. And hey, anything that mainstreams what used to be strictly an accessibility feature is aces in my book.

Jon Tan says:
October 08, 16h

Dave, this seems like a similar question to the issue of designing for 1024px or larger viewports. The tipping point is hard to determine without good data. Use of ≤IE6 may still be relatively high in some non-first world, public sector, or corporate environments. Designers of sites other than those being narrowcast to the technical elite may have to consider that.

As Dan also pointed out, IE7+ zoom is buggy. It would seem that as ≤IE6 usage declines, there exists a window of opportunity for the IE team to refine the bugs out of their zoom. Then the question might be, why mix absolute and relative values? Thats always seemed to me like a useful but problematic hack to workaround the lack of SVG or scalable background images but still enable text resizing. Relative lengths for all elements may have a small overhead in development but inheritance makes them much easier to maintain afterwards.

Kat B says:
October 08, 16h

More important than eva!!!

I am very anti this zoom direction that the browsers are taking.

1. Content is king, and the main content on the web is text. Most of the time I do not care about images at all, I am interested in the text. Bitmap images don’t necessarily zoom well either. A badly zoomed image isn’t always helpful.

2. The zoom feature in Firefox 3 is interesting: if you have a layout that allows text re-sizing: no horizontal scrolling. Don’t believe me? Test it!

3. The zoom feature in IE8 is even worse than the zoom feature in IE7, which was pretty bad. It does indeed, stuff up your layout.

4. Horizontal scrolling is harmful to the user; they may not know there is anything on the right hand side of the page, continually scrolling back and forth disturbs the reading and comprehension processes.

5. To up text sizes, you need to into options and set the default text larger. That works well for one site, but that cascades over to the next you are looking at, which allows you to set decent sized text, and now you have to go back into tools > Options >Advanced Fonts and Colors in order to get the text size on that one site back to normal. This is annoying to do for every site. WHich is what happens. It is a really bad user experience with the browser.

6. Just because MIE does it, doesn’t mean it is a good thing. Nor does anyone else have to do it. If MIE jumped off a cliff, would Firefox follow?

October 08, 16h

Ok.. zooming has arrived for standard browsing..

But what about mobile browsers?

Do not stop supports em and fluid desings

October 08, 17h

I’ve long been upset by the state of browser text-size shifting, simply because it makes marking up pages semantically essentially impossible. So many extra containers are required to manage fluid-sized text, especially in situations where user-generated content is common and uncontrollable.

I like the idea of a full-page zoom, especially as pixel density seems to increase a little every year, and widescreens become the norm in desktop environments.

I’m not sure the horizonal scrollbar confusion argument holds water: if it’s something you’re really worried about, you can discover if the browser window is smaller than your document size with some basic scripting and notify users of the content hidden offscreen or, reflow your layout to accomodate the smaller viewport.

As others have said, not everyone pays attention to the potential for reflowing larger (or smaller!) text in the browser window, and so often this breaks the layout. Usually these developers are the very same ones who set their font size to criminally-unreadable sizes. Resizing the text makes the page both more and less legible, in that case. I’d rather have a visually-coherent, horizontally-scrolling document than a broken, non-horizontally one.

October 08, 17h

I’m annoyed that in such a massive (now) industry (web), we still need to allow for software that was developed so long ago (in internet years!).
However, it stands to reason that we should opt for developing in ways that allow for expansion and modularity. Is hardcoding font sizes is not an example of this.
We’ve all known this. I just can’t believe we’re still here talking about it.

The problem though, even now, is the pork-barrel and special-interest-laden browser-smiths.
Is it not?

Ming Zhu says:
October 08, 21h

I am very glad to see major browsers begin to support zooming, considering the current trend of fixed layout compared to fluid/elastic design.

However, as long as IE 6 has not phased out of the market, we still need to cope with that.

Sander says:
October 09, 01h

Josh made a very important observation back in comment 4: Users still have the ability to set a different _default_ (and minimum!) font-size. It’s basically as if they always use text-zoom. The percentage of users who’ll do this will be small, but it’s likely to be exactly the same percentage of users for which we were setting up em-based designs in the first place. We really shouldn’t break their world just because our emulation method has changed away from text-zoom-by-default.

October 09, 02h

I adopt a very simple approach for this issue (and all web development issues for that matter)… cover all bases!

Even though users have to look for the facility to resize just the text in Internet Explorer 7+ or Firefox 3, it’s still there and I’m sure a number of users (no matter how few) will make use of it.

I want my websites to remain functional / readable for these users, and I don’t think creative designs or layouts have to be sacrificed in order to meet this requirement.

Until text resizing in browsers disappears from the face of the planet, I think it’s still a skill we need to hold on to.

Tom H says:
October 09, 05h

To all those thinking about dropping support for traditional text resizing in favor of zoom, please consider using flexible widths/fluid layouts.

This website beautifully fits into a 1024x768 window, however when I zoom the navigation disappears off the the right. Zooming further chops off part of the article, causing me to scroll horizontally to read each line; this isn’t a great user experience.

If this website were to scale to the with of my window, zooming would actually work great (try zooming my website for an example).

For those in doubt of the accessibility problem, this video demonstrates some of the issues (see 3:15 and 5:40 in particular):

October 09, 07h

I worry about people like my father who jack up the OS font size from 96 to 120 so he can keep the resolution and still read the text easily.

Cat Chen says:
October 09, 07h

Chrome doesn’t use the same rendering engine as Safari.

Safari/Mac uses Cocoa, and Apple has ported some Cocoa-like API to Windows so that Safari/Win can use the same API. I don’t think Google can use this Cocoa-like API on Windows. In fact, Chrome uses Skia instead.

Adrian says:
October 09, 07h

Personally, I find zooming to be a step backward. In theory, it sounds nice to have the entire design scale but I dislike how zooming almost always results in horizontal scrolling. From a user’s perspective, I find it easier to scale the text while retaining my browser width. In short: zooming looks better because the design remains intact but I still believe text scaling to be better as far as usability.

October 09, 08h

In my humble opinion, until browsers that don’t support text zoom properly on absolute values have fallen into obscurity, the practice of using ems over pixels is the best choice. It takes a more inclusive approach. Sure, most browsers are using or will soon be using page zoom, but there will still be the user group who prefers text zoom to page zoom or the person with low-vision who found text zoom is a better option for them – a group that, at least in the U.S., is increasing every year. The approach of being inclusive was most basic principle of the standards movement, so why not continue with that. It shouldn’t affect how page zoom works, but will give those people who have found that text zoom works best for them, what they need and deserve.

One of the core problems I found with page zoom is very long lines that could become difficult to read, especially for low vision users or those with narrow-angle vision. I have also found that in development I also get the same benefits that Dan Cederholm mentioned earlier. In regards to the time required I found that if you are taught or learn using em based layouts – as I was – it becomes second nature with little impact time on time lines. Yes, there might be little more math involved, but its become second nature. Also if you keep a personal library of your code, over time you have to do less and less math, because you have already done it.

So I put a in a vote for continuing to use ems over pixels.

I will say that this is a very important discussion to have. We air the facts, the opinions, and all our options. That way, all of us who thinking about this issue – now or in the future – can see it all and make their own decisions. As I said mine will still be ems for the foreseeable future

October 09, 08h

@Cat Chen

Cocoa and Skia are actually the interface frameworks that contain the rendering engine, which is Webkit in both cases. Cocoa and Skia are not the rendering engine. They are things like the buttons you see in the browser bar, or the menu bar items. The rendering engine is what generates what you see based on the HTML, CSS, JavaScript, etc. in the viewport. That is Webkit and is separate from Cocoa or Skia. They just talk back and forth.

October 09, 10h

Hmmm, interesting topic. I’ve always designed and built out sites in such a way that text resizing will not break the design. Recently, I also had the chance to implement a layout with em based widths, which allows the entire site to expand (height and width) with the browser’s text size setting. In a way, it simulates “zooming” functions of newer browsers. If the default functionality of browsers should continue in this zooming direction, then I would imagine that designing for text resizing would definitely be less of a priority.

There is also the possibility of low vision users, who are much more likely to change their text size settings, or turn on accessibility settings.

Dave S. says:
October 09, 10h

It seems as if a few different, separate issues have popped up in the comments here. Let’s see if I can untangle them:

1) Ems vs. Pixels

This is a re-hashing of the very old IE6 discussion. But I think it needs to be said that it’s entirely possible to set all your type in ems and still end up with a design that causes problems when text is scaled up even 10%. So, this is a related issue, but I don’t think it’s the core issue.

2) Fixed vs. Fluid layouts

Admittedly I haven’t dug very deep into full page zoom, but it’s clear enough that different browsers have different ways of handling fixed layouts. Horizontal scrollbars are the main issue here; fluid layouts seem to adapt better.

3) User defaults

The argument seems to be if a user has their font size set to a size they prefer using the older browser controls, then not supporting text resizing means they suffer. I just checked: FF3 and Opera persist the zoom setting (though FF does it on a site-by-site basis), whereas IE7 is the only one that forgets the zoom level on restart.

4) Time constraints

So far the only concrete reason I’ve been hearing against continuing to support text resizing is that it saves development time.

October 09, 11h

The thing is, it’s not just text reflow problems that we are designing for, it’s flexibility in general.

So an area that would have broken before when the text was resized doesn’t break anymore because of page zoom… Well that area will still break when a few extra sentences of text are added to that area.

October 09, 11h

I’d like bring up something related that I mentioned on Jeff Croft’s blog [ ]

There I talked about how NS4 and IE5 users aren’t really worth perfecting your site for because most websites has got to be screwed up for them already.

Text resizing is very similar. Outside of body text, I feel comfortable saying that most websites look screwed up when you start changing the base font size.

Sure, it’d be great if we could provide every user on every platform with every conceivable setting a perfect experience. But most people who use fringe software and unusual settings have already decided that the benefits of their custom settings are worth the web looking a little wonky to them.

In short, everyone’s a snowflake.

Dave S. says:
October 09, 12h

@Chris Coyier - that’s a good general point, but not always applicable. Consider simple UI elements that need a few words at most; say a button, or a navigation item, or a login link, or… and so on. They’ll likely never change, or at least never grow dramatically so your starting point is fairly fixed. Text resizing has always been a huge thorn in the side in those cases, but full page zoom magically makes the problem go away.

October 09, 12h

> So far the only concrete reason I’ve been hearing against continuing to support text resizing is that it saves development time.

Clearly this is the only reason. No one would argue that using relative sizes gives your site more flexibility. But let’s not brush off saving development time as insignificant. I don’t know about you, but I’m always working on a tight deadline.

To me, using relative sizes is going to end up one of those things you *can* do to impress your web geek friends, but not something that actually gains you much in the real world. We’re not quite there yet, but I think it’s obvious we’re heading that direction.

Also, I think people are confusing the topics of text resizing and layout flexibility. Daves article is all about *text* – he didn’t make mention of how you size divs and other layout containers.

There will probably always be some need for layout flexibility, as Dan alluded to. However, you don’t need to set your *type* in ems or percentages to get it. You can certainly size your layout containers relatively to maximize flexibility and your type absolutely to save development time – these things aren’t mutually exclusive.

October 09, 14h

@Dave S: Absolutely. In those cases page zoom is a blessing.

I think page zooming is here to stay and that we can start weening ourselves off some of the old habits that text-resizing brought on (e.g. using EM’s for elastic sites)

October 09, 14h

I’ll be glad to let go of some of the trickier bits associated with text resizing (like keeping navigation legible) but many of the tricks we’ve learned to accommodate text-resizing are still useful for cases where the content might end up longer than it was in the design phase. At least our skills won’t be totally useless. :-)

Dan says:
October 09, 15h

I really like full page zoom and it’s clearly the future, but I try to make sure stuff works at +1/+2 text sizes, or at least, that nothing breaks when text is re-sized.

October 09, 15h

@Jeff Croft:

I want to clarify that in my comment above it is text resizing I am referring to. Almost everything I have built up until this point has been ems based for the reasons I have stated above. It’s about the user – their needs and desires – not about showing off. I am sorry if that was unclear.

October 09, 15h

I’ve dropped optimizing the projects I’ve been working on for text-resize. I definitely think that, full page zoom is going to stay, and exactly as mentioned, must of the internet/computer users don’t change their standard settings, and with MS’ pushing of updates they make sure, that those users will get the full page zoom also.

Georg says:
October 09, 20h

Browsers will always be ably to change text-size - in addition to or instead of page zoom.

For instance: Opera has had page-zoom for longest, but it also has an option for overriding text-size. Similar options can be found in all browsers that have page-zoom now, and I don’t think that will change anytime soon.

I always take the browsers’ options into account while designing, as someone out here may need to use some of those options. For us to not account for what browsers can do, will cause problems for some users.

Megan says:
October 10, 08h

I wrote about this topic months ago on my blog but unfortunately can’t link to it because we’re having major server problems. Grrrr…..

I too question the need to build em-based layouts when most browsers no longer scale text that way. It’s a lot of work for a small minority of users. It would useful to see some stats on how low vision users resize text and which method they prefer. It could be that most users with severe vision problems use screen zooming software instead of the web browser’s text scaling (if they can’t read text at a few sizes above default they probably can’t read the program interface either).

So, I generally think that we don’t need to design in em’s anymore. It’s not worth the trouble. I would do it for a very simple layout but otherwise it’s too much of a pain to get layout precision with ems.

Lee says:
October 11, 14h

How is the 62.5% technique fundamentally flawed?

October 11, 21h

I like Zoom, don’t get me wrong…but…it would be nice to have a consistent specification on how the function is implemented across browsers.

Granted this is a hot debate that really isn’t going to go away until the zoom bugs are fixed and IE6 disappears from view.

Now I don’t know what type of clients and environments that all you guys work in.

But for me personally IE6 is still a major part of the equation. To the point that for the IE6 corporate audience alone I build sites with em in mind.

Yes in that corporate audience is the humble mid level manager with their laptop that they have to crank the browser font size up on to be able to read the text. Being a corporate environment the SOE is stuck on IE6. Sad but true. Often this manager has the guiding say on their website’s direction.

When this changes I will consider moving away.

BTW @JCroft I also don’t design in em’s to impress my webby mates. I doubt they even visit the sites I design.

Reality also bites in that not all of the people with extreme accessibility issues can afford or know how to upgrade their browser. So until they replace that computer it is stuck on IE6.

Now that’s not to say that moving away from a fluid layout is going to happen either. We must remember the iPhone is only a small percentage of the mobile web devices.

Now what would be good, and it’s just pie in the sky dreamin’, but why not have the zoom function that allows for fluid boundary divs and restricts the zooming to the fluid layout. Hence no horizontal scrolling. Okay it’s years away, granted.

Lee says:
October 12, 01h

Have people also forgotten about graceful degradation?

Sure, future browsers may not make full use of going the ‘em’ route with page zoom, but older, legacy browsers will still be able to benefit from it, who can only employ text resizing.

October 12, 10h

As very much an amateur in the web-site building arena I feel that it is important to check the pages work at various zoom levels. You would think that they would, after all, with the zoom you’d think that all block elements would grow in proportion to each other. However I have found problems with IE 7 zoom where things which work at 100% start to go wrong at higher levels of zoom.

So my feeling is that now we have two things to be aware of. The effects of the older text resizing and those of the newer zoom.

Mike Palmer says:
October 13, 05h

I have to maintain a website which is used across 13 languages, so text-resizing is extremely important. Though the thrust of the post is aimed at people resizing text of a single language, it is also important to recognize the importance of designing for multiple languages (for international sites which reuse the same look and feel). It’s a basic L10n concept which will never go away, regardless of the browser.

Marty says:
October 14, 04h

You’ve talked about zoom and text scaling, but there’s another purpose of having Ems as opposed to pixels - relative sizes for ease of maintenance! You haven’t mentioned this strong point.

If I want to increase/decrease font size of the main content section of a webpage (because Marketing said so, or for some other reason) then I can simply change the one property in CSS and every other element held inside the main content section will fall into line in terms of font sizes (using Ems, of course!)

Using pixels is just too ideal and impractical in both from the maintenance and practical sense of the web browser technology today.

Montoya says:
October 14, 06h

I still support the use of liquid-width layout design (with min- & max-width) for the sake of being able to support both large and small window sizes. I do all my work on a Macbook with a 13” screen, and when I can’t plug into a larger monitor, I appreciate sites that fit within 800 pixels, especially since I rarely view any application at full-screen width. But it’s nice to know that with a larger screen, I get more screen real estate too. So a site that’s flexible still has good use.

October 14, 06h

I’m all for the “we have no idea in what way, how or why someone uses the internet, or with what tool, so make it work properly anyway” school of thought. Think mobile browsers, internet goggles and Amazon Kindles, for all we know.

Timewise, on a big project like the one I work on, we’ve done a lot of the foundation work getting this sort of thing working, so time spent on it diminishes over time anyway.

Chris says:
October 14, 10h

Full-page zoom is completely annoying and useless (for me)!

I really don’t understand why it’s considered such a big deal. I enlarge the text so that I can read long articles better. This allows me to simply scroll down the page and read. But if I use full-page zooming to make the text larger, it doesn’t reflow within the visible window. Instead it spills over the edges and I’m forced to scroll and left and right as well as up and down.


J. Lester Novros II says:
October 14, 13h

Um, quite conceivably I’m completely missing the point here but px are relative to screen resolution whereas ems are relative to the default font the user has set.

What this means is that when I visit a site that defines fonts in pixels and the designer chose to use a 10px font, I am confronted with excruciatingly small text on my 2048x1536 21” monitor. When I use the Fox’s DOM Inspector to change that value to 1em, the text is easily readable.

So, using px instead of ems means that I [and conceivably quite a lot of other people] have to hit the zoom key at almost every site they visit. Not nice. Moreover, a webdesigner should *never* force the visitors of his page to dance to his tune.

Looks like we’re back where we were 10 years ago where graphic designers insisted on approaching web design as they did designing for dead tree media. But a computer monitor != a sheet of paper.

So count me firmly in the camp advocating the use of ems over px.

David Hucklesby says:
October 14, 16h

Matt May brings up the matter of screen resolution - the “normal” 96 DPI is by no means universal. IE and Opera display “medium” text at 20 pixels on my laptop, not 16 – it has a factory setting of 120 DPI.

So zooming is only a partial solution. I think we still need to test layouts at different text sizes, regardless.

October 16, 03h

But from my experience with IE 7+8, they don’t fully zoom in on the page - somehow the rendering engine also scales the text but at a different rate to the rest of the page causing the text to ‘jump’ around when zooming in.

Ems over pixels any day!

Stevie D says:
October 16, 04h

I’m reassured to see that I strongly disagree with Jeff Croft on this one :-)

20% of visitors to my site are using IE6. I suspect that for most websites that are not focused on web development, and so attract a representative slice of all users, have a similar proportion of such visitors.

I’m not going to screw up the potential working of my site for 20% of visitors when it is not difficult to do it properly and get it right. There’s NO good reason to deliberately do it wrong.

Jeff, you say that it’s too difficult to do the maths. That’s pathetic. First, you shouldn’t be so worried about pixel precision, because it WON’T hold for everyone. Second, you’re using a computer, even if you aren’t capable of multiplying 0.9 by 1.2, your computer certainly is.

Adrian, some browsers have better zooming than others. Opera’s zoom rarely results in horizontal scrollbars.

October 16, 06h

One thing I don’t like about page zooming is that I like to control the line length. Sometimes the measure/columns are too wide and lines are too long. Increasing text size makes it easier to read.

Jon Zuck says:
October 16, 07h

When IE6 still accounts for 25% of market share, allowing for text-resizing seems essential to me.

Zoom at modest levels is usually workable, but let’s face it: Zoom’s advantages are aethestic… no breaking, but horizontal scrolling possible in wide fixed-width sites.

Text-resizing is about functionality… being legible, even if a container is overflowed or displaced in an inexpert application. It sometimes gets ugly, but it’s usable, and avoid the nightmare that Zoom can cause with vital page elements shifted off the screen.

I’m a fan of liquid layouts and the Switchy McLayout. Yes, they require more thought, more patience, but they result in greater usability for more people.

Furthermore, I fully believe that cellphones will be used much more frequently for the Web in coming years. We need to be able to accomodate very small screen sizes. Zoom goes in only one direction–larger.

October 16, 19h

> There’s NO good reason to deliberately do it wrong.

Do it *wrong*? Please don’t tell me the “size your text in ems” mantra is has been driven home so hard over the past few years that people now think that it is somehow *wrong* to size text absolutely? Absolute units are every bit as valid as relative ones. The only thing that is *wrong* is IE6. CSS doesn’t give a damn what type of units you use.

October 19, 09h

I still feel that em based design of layout and text is here to stay for a while longer. For example the releaseof Google Chrome… no zoom feature.

It is up to web designers to ensure that the websites they build are always available to the widest possibble audience, browser, mobile, speech reader.

Finally em based design is required for a true accessible website design that is true cross browser compatable.

October 20, 16h

The problem that I have with page zoom is minimum width causing horizontal scrollbars. I just checked a page that I’m working on (in FF3 and Opera on the mac) that has a fluid layout with a minimum width specified to prevent the page getting /too/ squished, and that minimum width gets scaled along with the page. So, at 200% zoom, my minimum width (about 600 px) suddenly produces scrollbars in any viewport smaller than 1200px, which according to my Mint statistics means that 87% of my visitors would get scrollbars at that zoom level.

Text-only zoom, on the other hand, will let the columns retain their width and although the line lengths can get a bit short after two or three text-size increases, the viewer with an average screen (or smaller) at least only has to scroll in one direction to read the text.

So I think that, as currently implemented, page zoom actually constitutes an extra gotcha that we need to watch out for; a css parameter that assists the layout generally under the text-zoom regime causes problems in the page-zoom milieu.

Matt K says:
November 02, 12h

I find these discussions very interesting, but not comparable to my job as a front-end developer/designer - 99% CMS stuff.

There is no such thing as even considering using ems here (for font sizes). Each page is tailored as a compromise. Bespoke images cannot be resized in ems (especially if they are bumped by a resizing plugin from a CMS). Yes, I wish I could etc, but nope.

Besides, each site is aimed sharply at a niche of visitors, and both design, layout and implementation is plastered around a big heap of project work. What we sell these days is not design, it’s not usability, it’s not a portfolio site, it’s not black art - it’s the road leading to the site that our clients need. It’s a project method - and it works very well.

Besides - I consider a web site a work in progress - something which is renewed every 1,5-3 years, or at least gets a major overhaul. By that time, so much has changed in both CMS, the Web, the client & technology etcetera we scrap much of the front-end anyhoo.

CSS is a blessing, and continuing development in our field of work is too. I just wish the clients really got the Big Picture about how you cannot possibly control the user experience like you can a printed object. So In a way, zoom is a gift to this Way of Work.

November 04, 09h

I recently publish one CSS Framework completely based on ems. I know that designing with ems can be nightmare for lot of you, but in the end is not all about page resizing.It’s static v.s dynamic. I’ts is about writing better and more maintainable CSS code.

@Colin: I agree! Em-based thinking is a way of life!
@Jeff: 62,5% = 10px = 1em Then 1.2em = 12 px. Is this so hard?! Write your next css layout in ems! You will learn to love them!

voyou says:
November 05, 19h

“62,5% = 10px = 1em Then 1.2em = 12 px”

I wish people would stop propogating this little bit of cargo-cult CSS. It’s true that, if you want a font size that is likely to be around about 10px on many browsers, you can set the text size to 62.5%. But you can’t simply treat 1 em at 62.5% as equivalent to 10px. I’ve seen, for instance, websites that specify a width of 100em at 62.5%, on the grounds that that’s 1000px and should fit on most screens. Except, of course, for a lot of users it _isn’t_ 1000px, so they end up with horizontal scrolling.

Designing as if you were using pixels, and then converting all your pixel measurements to ems using the 62.5% rule, fundamentally misunderstands the reason for using ems in the first place.

Myarka says:
November 21, 12h

Hey, Dave

Why this blog simply doesn’t use em-based design? Instead, it’s a 12px font-size set in body element?

John says:
February 18, 12h

I say that the text scaling process has been placed there just for that websites that don’t follow the basic rules for design. We should not worry about them. So my approach on “designing around scaling text” is obvious: ignore it. Focus on the most important things. And focus very hard on them.

In my 10 years experience on the web I used the scaling only 2-3 times, and it was on really bad designed web pages.

Oliver says:
February 23, 09h

We have started using ems for our websites because if people need to enlarge text because of bad eyesight, then the text and graphics will enlarge proportionally instead of the text pushing the images out.