Last week I read an open-ended post from Robert Nyman asking his readers if we should continue to use relative units on the Web. I’ve had this question on my mind for at least a while, and I’m glad Robert’s post rekindled my thought process on the issue.
Robert questions whether we should be using relative units because browser manufacturers are now defaulting to page zoom when invoking size alterations. He notes that while relative units can be exponentially helpful for readers when the developer has used them properly, but more often than not, documents are destroyed with a single size adjustment made by a reader. Page zooming helps with the issue of a degraded experience when relative units are misused (or not used at all). Robert has a general opinion on the matter as a whole:
I think most users would appreciate full page zooming, where everything in the web page is resized in perfect relation to each other. It will be easier to read while at the same time giving the end user a more consistent use experience.
There are some interesting comments that follow Robert’s post, with both positive and negative reaction to both relative unit use as well as page zooming. I think it’s an issue that’s got many developers on both sides of the fence.
How do I feel about relative units and page zoom?
I’ve written before about the benefits of using relative units in Web design, and I’ve become quite comfortable with using relative units for type in the majority of my production work.
There are a number of ways to take advantage of relative units when designing on the Web. I’ve opted to use relative units for (mostly) type as opposed to layout structure. Having precise control over element position is a true benefit of using pixels for layout elements.
I’ve come to enjoy working with relative units for type a bit more simply because the parent-child relationship has given me an opportunity to scale the type of a document with a single unit adjustment. This can be both beneficial as well as troublesome, which is why I think many developers are partial to pixel units for type. There are times when you’d like to adjust the type size for a parent, but not the children. If you’re working with relative units, you’re in a situation requiring subsequent edits to unit measurements of child elements. On the same token, you’re faced with the opposite speed bump when looking to adjust the type size of many elements at once. I think it partially comes down to personal preference and workflow in one regard; but should a personal preference of a developer effect the end product? In this case, I’m not so sure.
At the end of the day, what’s important is to produce documents which are most beneficial to readers. Unfortunately, there’s an elephant in the room making fixed units for type a (partially) poor choice for designers. Internet Explorer, as we all know, refuses to scale type sized in pixels. Although I haven’t confirmed it for myself, it’s been said that even IE8 will not make this adjustment. This bug is one of the more common long-standing bugs rooted in IE, and will continue to haunt designers for years to come. Many designers & developers have taken a stance stating that they prefer sizing type in pixels, and Internet Explorer can simply take a back seat, end of story. I haven’t reached that level of frustration, and I’ve embraced relative units for type, so I’ll continue to use em to size my type.
The issue at hand: page zoom
As with nearly everything, page zoom has both pros and cons. While one part of me views text-resizing as unexpected to the average reader, page zooming (and the resulting horizontal scrollbars) can be equally frustrating. I’ve tried to take a step back and view the issue from the standpoint of a reader as opposed to a designer, and I still find it difficult to come to a decision regarding page zoom. While I think it’s great that page zoom can help retain a document as a whole, and resolution-independent imagery could open the door to endless possibilities, I’m not sure if it’s the best possible solution.
Which brings up an entirely different issue; with browser makers beginning to default to page zoom, is it out of our hands anyway? At this point, I’m not sure how to answer that question, and I’d like to hear other opinions. I will continue to work with relative units for type, as I don’t see any harm in doing such, and it’s a personal preference of mine. Additionally, we’ve got Internet Explorer to contend with for some time, and using pixels for type degrades reader experience in that regard.
Do you think page zoom is the way of the future? Given the circumstances, how do you feel it compares to type resizing? With an arguably small percentage of readers making use of this browser feature, do you think page zoom will for some reason take prominence in a feature list, where text sizing has taken more of a back seat?
Comments
I’m likely to continue to use relative values. Been using them for a couple years now, and they jut make sense to me. I’m not a fan of page zooming as I find horizontal scrolling deplorable. I do regularly increase text size on pages, like this site for instance. And doing so keeps everything in the page rather than expanding horizontally and keeps it readable.
I’m no IE fan, but their not changing px-valued size fonts on a text increase/decrease isn’t necessarily a bug. HTML standard doesn’t really address the issue of how a browser should handle this event, it’s a browser decision. If people used the different measurements appropriately then there wouldn’t be a need for page zooming in most cases. Unfortunately it seems over half of sites are created by novices who don’t really understand their decisions to use px measurements. Px are the easiest so that’s what a lot of people use. Unfortunate but true.
Then again, most people don’t know that they can increase text size, so why would they know of a page zoom? I’d be happy if people would just stop using font sizes smaller than 13/14px so I don’t have to increase text sizes.
a smarter solution than the naive “zoom everything” approach of, say, IE, is what Opera does – zooming text and images etc, but trying to avoid generating a horizontal scrollbar. personally, i hope that this slightly more considered zoom functionality will prevail in the long run. but at the same time i think zoom should live alongside, rather than replace, pure text sizing. ho hum…
I agree with Patrick that they should live alongside one another. Page zooming for someone with poor eyesight makes the text readable, but does it take away when concerned with the imagery? If I need big text to read, I don’t want to deal with blown up images.
But, boy do I hate em’s.
@Kendall: I’m on the same page with (many) current implementations of page zoom — horizontal scroll bars don’t help anybody. You bring up a great point about IE and text-sizing, technically it’s not a bug, the browser simply does things a bit different. Unfortunately it’s been outed a number of times for doing so, but you’re correct in your statement. The trouble truly does stem from many documents which have been styled using type sizes in pixels ‘by default’. You’re spot on. Reader education is another (large) issue when it comes to this subject. As you said, only a small number of people know about text resizing, page zoom, or changing the default font size in their browser preferences, so what are designers to do? Your solution of simply using larger type sizes would be very effective indeed, and recent design styles on the Web have lead to relatively bigger font sizes as compared to the pixel fonts of the late 1990’s which is a benefit to everyone. Page zoom (if used properly) may be a really effective solution to the problem as a whole, we just need to determine the best case scenario. Thanks so much for leaving your thoughts, I think we’re on the same page when it comes to this subject, except perhaps my choice in type size 🙂
@patrick h. lauke: I’m disappointed that I neglected to mention Opera in the article above, but I’m very thankful you’ve brought it up. Time and time again Opera has been referred to as ‘getting page zoom right’ and I do think they’ve got the best implementation indeed. I absolutely agree with hoping that functionality like that of Opera is referenced by other browser makers when establishing their implementation. Thanks so much for leaving your thoughts!
@Adam Butterworth: We’re on the same page as well. It’s important to take into consideration, however, that imagery can convey meaning as well. Page zoom not only effects the document design, but the meaningful images incorporated as well. Readers with poor eyesight may need images enlarged as well to get a better view. How can anybody hate ems?
Author: “I think we’re on the same page when it comes to this subject, except perhaps my choice in type size :)”
Yeah, that seems to happen when I tell people I think their font size is small. It comes from me using a 13″ MacBook at home and a 15″ MBP at work. A lot of designers work with 17″/19″ LCD monitors so everything is big to them in comparison, and when I use a larger monitor I don’t need to adjust font sizes s often, but laptops are becoming increasing popular so designers should take that into consideration. And it’s not that I can’t read your page at the default size, but it’s easier with a bump up in size.
Oh, and yes, Opera’s page zoom is the best of them, though other parts of Opera keep me from using it.
I believe that IE has got it right by not resizing text in pixels (it’s about the only thing it has got right…). It’s a shame that the page zoom in IE7 isn’t particularly good.
If page zoom was implemented in all browsers as well as it is in Opera, that would solve the problem for MOST users. Most, but not all. Users with more severe visual difficulties may add their own user stylesheet that enlarges the size of text – if your own stylesheets are in ems and %ages, they will scale better than if they are in px.
But don’t forget that a hefty proportion of users are NOT using browsers with (satisfactory) page zoom capability. The 25% of people still on IE6, and some of the 50% of people on IE7, still rely on text resizing instead of zoom when they need to change the size of text.