Jeff made a good point at the typography panel at SXSW, which I missed, but he conveniently summarized (and clarified) what he said in a recent post on his site.
It has become somewhat of a sacred cow to say, “pixels are bad for text sizing—don’t use them.” But the reality is that there is nothing inherently wrong with sizing text using pixels. There is only something inherently wrong with Internet Explorer 6’s implementation of CSS, which doesn’t allow for text resizing when the fonts are sized in pixels. I think it’s important to understand—especially now that IE7 is out and text resizing is no longer an issue—that this is not a problem with CSS. Shout it from the rooftops: It’s okay to size text in pixels!
This is something Jeff and I have talked about before, and I wholeheartedly agree with his point. It also illuminates two related points that have been bouncing around in my head lately.
So long and thanks for all the glitches
First, IE6 is effectively deprecated. Its maker has acknowledged its flaws (some of them, at least) and addressed them in a new official version. IE6 is still out there, and the numbers are still significant enough that we still have an obligation to support it, but it’s on its way out.
The nice thing about something being deprecated (you know, like font tags) is that it’s a known quantity. There will be no new updates to IE6 (other than critical security patches, I imagine). All the bugs, quirks and inconsistencies we’ve come to know and love are going to stay exactly the same, from now until IE6’s user share dwindles. It happened with Netscape 4, and for most of the Internet, it’s happened for IE5. We still need to keep it in mind (for now), but I think we can start to (carefully) move past its limitations.
Design for the ideal, build for flexibility
The second point is less concrete—more of a loose operating principle. Lately I’ve been thinking a lot about the balance between control and flexibility in design. On the web, we tend to favor flexibility over control. I think this is partly a capitulation to the constraints of the medium (we avoid relying on 100% pixel-perfect layouts because they’re harder, and often to a degree not worth the results) and partly an acknowledgment of accessibility concerns (we create more flexible designs because they scale better to the myriad environments and alternative devices we need to support).
The principle I’ve been operating from recently boils down to this: design for the first page load in an ideal environment, while allowing for flexibility in non-ideal, unintended and user-modified environments.
One example of this in practice would be line-lengths. We can’t predict how lines will break in different browsers on different platforms with different font substitutions. But there are some cases where we can’t get away with just ignoring line-lengths altogether and letting things fall as they may. What I do in practice—and I think this is pretty common—is to optimize the way lines break (and widows and orphans) for the typeface and browser where I’m doing my primary testing and make sure it doesn’t completely fall apart in other browsers or when the text scales up or down. So the design ends up looking pretty much exactly how I intended in Safari and Firefox on a Mac, and reasonably close in the other browsers that matter. Which in my opinion is better than looking not quite how I intended in every browser.
Complex relativity
This only really works when I can at least control the text size at the initial page load. The reason I keep coming back to pixels is the same reason I’ve avoided them in the past: they’re fixed. They’re a known constant. I’m a big fan of reducing complexity, especially when you’re designing systems for larger sites or teams. The more variables you introduce, the more complex things get—it’s unavoidable.
Even when you’re using relative font sizing, you still need a reasonably constant base value to start from. A lot of people (notably, Richard Rutter) have done a lot of work to come up with a way to emulate that constant using percentages. And it works really well. I’ve built entire sites based on ems for sizing everything, even down to images.
In the simple case, with minimal nesting and complexity, the math is actually pretty simple. Say you’ve got a base text size of, say 10px (1em) and you want your header to be 18px. Easy, 1.8em. But what happens when you add a span with class=“quiet” within that header and you want it to be 15px. That’s tougher, since 1em now equals 18px, so you end up with something like 0.8333em. And what if there’s something inside that? One em now equals 15px, so you have to divide by that. It’s a slightly exaggerated example, but you can see how it can get messy very quickly.
So you end up either adding complexity to your sizing math and rules to handle the special cases—which makes your CSS that much more complicated for you or anyone else to figure out later—or you limit what you can do with your design up front. I’m all for embracing constraints, but I also don’t think the design should be dictated by the technology. So either outcome is less than optimal.
I think anybody who’s ever built out a relatively complex design using ems will agree that at some point they wondered if the benefit was really worth the effort. It all comes back to that same balance between control and flexibility. It’s an important balance, and the debate between pixels and ems for sizing text on the web hits right at the heart of it.
Two steps forward, one step back
There’s really not a good precedent for this outside of web design. If you read a magazine, book or newspaper and you need larger text, the best case scenario is that they offer a large print version. This requires a non-negligible effort and expense for you and a big expense for the publisher and is therefore pretty rare. On the web, the worst case scenario is that you need to download a new (free) browser because the one you’re using doesn’t support scalable text and the designer has chosen to use pixel sizing. There’s no way to paint this as anything but a giant leap forward.
When 90% of your users were using a deficient browser that didn’t support scaling of pixel-sized text, the decision was clear. Even if 5% of that 90% needed larger text, that was still significant. It was simply irresponsible to choose to use pixels for text-sizing as long as there was a workable alternative.
But the numbers are changing. IE/Win is no longer synonymous with IE6. And IE7 supports text zoom – the deficiency inherent in IE6 has been corrected by the browser maker. As IE7 takes over more and more of the IE/Win browser share, the decision to avoid pixel sizing becomes less and less of a sealed tomb. If there is a potential value in using pixel sizes (and I believe there is), eventually in some cases that value will exceed the value of catering to a diminishing percentage of the audience (and fraction of that audience at that). As that happens, it’s worthwhile to reevaluate some of our assumptions.
Pixel measures for font sizes, just like min and max-width, are part of the CSS spec. They’re both equally valid techniques from a standards point of view. The only reason we’ve avoided using either one is because the overwhelming majority of our audience aren’t using a browser that supports them properly.
In either case, the lack of support isn’t disastrous, just undesirable. If we use pixel font sizes, our sites are still accessible, just not as accessible in a particular environment as we would like. And if we rely on min and max-width, our layout is still usable, just not as usable in a particular environment as we would like.
When that environment accounts for 90% of our users, it’s not really realistic to deliver an undesirable result to that entire group. But what happens when the number is 50%? Or 5%? If we were willing to hide all CSS whatsoever from Netscape 4 when it was hovering below a 5% share, when are we willing to let one or two relatively minor features degrade? If the worst case scenario is really just a matter of degrees, when is it OK to just let it go?
Something to talk about
I haven’t settled on a definitive answer in my own head, and I don’t have meaningful browser share numbers to back it up if I did. Internet Explorer only counts for 19% of the total traffic to this site (12% IE6, 8% IE7, 1% IE5.5), so that audience is hardly representative. Even with broader numbers, it might still be too early to accurately pinpoint the rate of adoption for IE7 in a meaningful way.
Even in advance of the numbers, I think it’s a worthwhile conversation for us to have as a community to keep things moving forward. In the case of pixel units, I think there are pros and cons to relative and fixed methods, but I do think it’s worth having all the tools in our belt that we can, and know how to use them responsibly.
Agree? Think I’m off base? As always, respond in the comments or on your own site and lets get the conversation started.
Comments / Add yours…
Post a comment