Rounding Off
Published 15 years, 7 months pastIn the course of digging into the guts of a much more complicated problem, I stumbled into an interesting philosophical question posed by web inspection tools.
Consider the following CSS and HTML:
p {font-size: 10px;}
b {font-size: 1.04em;}
<p>This is text <b>with some boldfacing</b>.</p>
Simple enough. Now, what is the computed font-size for the b element?
There are two valid answers. Most likely one of them is intuitively obvious to you, but take a moment to contemplate the rationale for the answer you didn’t pick.
Now, consider the ramifications of both choices on a situation where there are b elements nested ten layers deep.
If you hold that the answer is 10px, then the computed font-size of the tenth level of nesting should still be 10px, because at every level of nesting the mathematical answer will be rounded down to 10. That is: for every b element, its computed font-size will be round(10*1.04), which will always yield 10.
If, on the other hand, you hold that the answer is 10.4px, then the computed font-size of the tenth level of nesting should be 14.802442849px. That might get rounded to some smaller number of decimal places, but even so, the number should be pretty close to 14.8.
The simplest test, of course, is to set up a ten-level-deep nesting of b elements with the previously-shown CSS and find out what happens. If the whole line of text is the same size, then browsers round their computed font-size values before passing them on. If the text swells in size as the nesting gets deeper, then they don’t.
As it happens, in all the browsers I’ve tested, the text swells, so browsers are passing along fractional pixel values from level to level. That’s not the interesting philosophical question. Instead, it is this: do web inspectors that show integer font-size values in their ‘computed style’ windows lie to us?
To see what I mean, load up the font size rounding test page in Firefox and use Firebug to inspect the “1(“, which is the first of the b elements, in the first (1.04em) test case. Make sure you’re looking at the “Computed Styles” pane in Firebug, and you’ll get a computed font-size of 10.4px. That makes sense: it’s 10 × 1.04.
Now try the inspecting that same “1(” in Safari or Opera. Both browsers will tell you that the computed font-size of that b element is 10px. But we already know that it’s actually 10.4px, because the more deeply-nested layers of b elements increase in size. These inspectors are rounding off the internal number before showing it to us. Arguably, they are lying to us.
But are they really? The reason to doubt this conclusion is that the values shown in those inspectors accurately reflect the value being used to render the characters on-screen. To see what I mean, look at the last example on the test page, where there’s sub-pixel size testing. The “O” characters run from a flat 10 pixels to a flat 11 pixels in tenths (or less) of a pixel, all of their font-sizes assigned with inline style elements to pin the characters down as much as possible. In Safari, you can see the size jump up one pixel right around the text’s midpoint, where I wrote font-size: 10.5px. So everything from 10px to 10.49px gets drawn at 10 pixels tall; everything from 10.5px to 11px is 11 pixels tall. Safari’s inspector reflects this accurately. It’s telling you the size used to draw the text.
In Opera 10.10, you get the same thing except that the jump from 10 to 11 pixels happens on the very last “O”, both visually and in the inspector (Dragonfly). That means that when it comes to font sizes, Opera always rounds down. Everything from 10px to 10.9px — and, presumably, 10.99999px for as many nines as you’d care to add — will be drawn 10 pixels tall. Brilliant.
In Firefox for OS X, there’s no size jump. The “O” characters look like they form a smooth line of same-size text. In fact, they’re all being drawn subtly differently, thanks to their subtly different font-size values. If you use OS X’s Universal Access screen zooming to zoom way, way in, you can see the differences in pixel shading from one “O” to the next. Even if you don’t, though, the fact that it’s hard to tell that there is an increase in size from one end of the line to the other is evidence enough.
In Firefox for XP, on the other hand, the size jump occurs just as it does in Safari, going from 10 pixels to 11 pixels of text size at the 10.5 mark. But Firebug still reports the correct computed font-size values. Thus, its reported value doesn’t match the size of the text that’s been output to the screen. Arguably, it’s lying just as much as Safari and Opera, in a different way.
But, again: is it really? The computed values are being accurately reported. That there is a small variance between that fractional number and the display of the text is arguably irrelevant, and can lead to its own confusion. Situations will arise where apparent rounding errors have occurred — I see people complain about them from time to time — when the apparent error is really an artifact of how information is delivered.
I have my own thoughts about all this, but I’m much more interested in the thoughts of others. What do you think? Should web inspectors report the CSS computed values accurately, without regard to the actual rendering effects; or should the inspectors modify the reported values to more accurately reflect the visual rendering, thus obscuring the raw computed values?
Addendum 10 Feb 10: I’ve updated the test page with a JS link that will dynamically insert the results of getComputedStyle(el,null).getPropertyValue("font-size") into the test cases. The results are completely consistent with what the inspectors report in each browser. This tells us something about the inspectors that most of us probably don’t consciously realize: that what they show us rests directly on the same JS/DOM calls we could write ourselves. In other words, inspectors are not privileged in what they can “see”; they have no special view into the browser’s guts. Thus another way to look at this topic is that inspectors simply repeat the lies that browsers tell the world.
