This article discusses font HEIGHT, but doesn’t touch on the side effect – font WIDTH.

If you want a piece of text to fill a horizontal space (like a banner for a title) as close as possible, then the fractions are very helpful.

Say you want to fill a space 700px wide. If your text is 650px wide at 10px high, then:

10.0px high = 650px wide
10.5px high = about 685px wide
10.7px high = about 695px wide (your ideal size)

Those fractional sizes can be handy.

The browser may be choosing (i.e. round before passing to the OS) because it knows the OS’s behavior – or simply out of bad programming, or because it can’t tell how the OS will render the font, not knowing if the system’s font file format and scaling options. Heck, on most OS’s you can replace the text drawing core – such as supporting a new format.

Add to that, the OS is written to try and allow for the fact the output might be on your screen OR your printer.

Firefox’s smooth size change may actually be a case of “fire and hope” where it passes it to the OS and happens to get lucky it renders well – try the test with a bitmapped font and you may get different results. Oh, like courier at 6px, which windows doesn’t like to do.

There SHOULD be a W3C rule that if a browser is going to round it should REALLY round (i.e. 0.5 split point) in order to get universal behavior where possible. (they can’t dictate OS font render engines but this would make them as “alike” as possible).

I strongly agree with others info should be shown as:
Size = rawsize (rendersize)
so you have as much info as possible.

But the headache this gives me makes me want to toss the em’s go back to the good old days of everything in px…
;)

But seriously – until all of our A-rated browsers support the sub-pixel rendering in the FF example, shouldn’t we be coding things so that they land at full integer values as much as possible? When a designer hands us a PSD doc with 11.5pt arial, shouldn’t we be asking “do you mean 11px or 12px?”

I guess my question is – what’s the practical application of
b {font-size: 1.04em;}
right now if it leads to unpredictable results?

Here is the test platform that I used:
http://mailmarkup.org/zen/

Please feel free to play with the css values and alter them to become more specific to see where the browser begins rounding values in conflict with the specifics you provide. The degree of precision is set pretty high and specific by default for many of the values, so it becomes very easy to see finite changes.

Cheers

I also get frustrated by em-value rounding, in which Safari uses a rounded value (plus compounding errors) whereas Firefox uses the specified value (if I remember correctly). This becomes really apparent when designing to a baseline grid, even with 4 or 5 decimal places.

Designing for the platform of Dao is 0.49999 finding the brilliant solutions (thank you for this one) and 1/2 letting go ^^

Obviously though, in an ideal world, I’d want both.

Still, the inspector inspects the end result as rendered on-screen, and should report the final values.

The inspectors inspects the element in the DOM. It shows you the CSS applied to that element. The inspector is showing you (and telling you that it’s showing you) the COMPUTED style. If an inspector is showing you a rendered style, it should say so.

As for the browsers that round to integer values, of course it would be better to report both values. Anyone who has filed a bug with Opera or Webkit?

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.

You can really see this if you inspect the inspector, which I learned you could do a while back while complaining about how the Webkit inspector doesn’t do something like Firebug. @xeenon told me it’s just built using HTML/CSS/Javascript. Webkit nightlies allow you to do this in the context menu – start webkit, start the inspector, hover over what appears to be ‘chrome’ of the inspector, right click/two finger click, and choose ‘Inspect Element’. Then you can see the markup of the inspector itself. However, you can’t write a user stylesheet that changes the inspector as Webkit doesn’t honor those. You can edit the one hiding deep inside the WebKit.app bundle, though.

See http://www.clagnut.com/blog/2228/