Why Percentage-Based Designs Don’t Work in Every Browser

By Scott Gilbertson

Here’s a rule any web designer can live by: Your designs don’t need to look exactly the same in every browser, they just need to look good in every browser.

It’s a maxim that will spare you many a hair-pulling hour. That said, there some things you would expect to be the same across browsers that aren’t. One such problem that’s likely to crop up more often as designers jump on the responsive, flexible-width bandwagon is percentage-width CSS rules.

According to the spec, browsers, given a percentage width, would simply render the width of the page based on the size of the container element. And, in fact, that’s what browsers do, but how they do it varies quite a bit. As a result, percentage-based widths are often displayed quite differently across web browsers.

Developer Steffan Williams recently ran into this problem when trying to create a percentage-based version of his Gridinator CSS framework. Williams created a container <div> with a width of 940 pixels and then wanted to create a 12 column grid within that container. Do the math and you end up with columns set to a width of 6.38298 percent.

Pull that up in Firefox or Internet Explorer 6/7 and you’ll see what you expect to see. In Safari, Chrome and Opera, however, you’ll see something different. IE 8 and 9 are also slightly off.

The problem is not a new one; developer John Resig pointed this out years ago. But as Williams notes, it’s odd that browser behavior when rendering percentage-width grids is still so inconsistent across vendors, especially given how much today’s browsers tout their CSS 3 support.

The problem isn’t necessarily a simple case of Firefox and IE being right and the others wrong. As Opera CTO and CSS creator Håkon Wium Lie tells Webmonkey, the problem is “the CSS specification does not require a certain level of precision for floating point numbers.”

This means browsers are free to round your carefully computed percentages up or down as they see fit. According to Lie, Opera considers the result of Williams’ experiment to be a bug. Same with the WebKit project, the engine that handles rendering in both Safari and Chrome, though in Webkit’s case the bug has been unassigned since 2006. But really, there is no right or wrong here, just different ways of rounding.

Fortunately, for most of your stylesheets, the differences in each browsers’ floating point precision will not result in visible differences on the screens of various devices. However, as Williams’ experiment shows, it’s easy to write a page where those very small differences in rounding become visible when compounded — like a grid-based layout.

What irks Williams and others is that these problems are old and well-known, and yet most browser vendors have still made no move to fix them. Instead, they focus on supporting the shiny new features in CSS 3.

We certainly wouldn’t want to suggest that browsers should stop innovating and supporting the latest and greatest standards-based tools, but sometimes it’s worth postponing playtime with the newest toys to make sure the foundations are solid. In this case, Opera, Safari and Chrome have some cracks showing, and it’s high time they fix them.

Until they do, we suggest you learn to live with the slightly different rendering behaviors in those browsers. After all, pixel-perfect cross-browser support is never going to happen. Given that the web of the future will have even more mobile phones, tablets, and small screen laptops, responsive designs and fluid grids are a trend we expect to grow.

There are also some workarounds. For example, you can use ems instead of percentages, which render much more consistently across browsers. Opera’s Lie also points out that the CSS Working Group has several specifications in draft to address the need for grid-based design, including multi-column text and theCSS Template Layout Module, though neither are widely supported at the moment.

iPad photo by Jim Merithew/Wired