I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

New CSS tests - units and values

Just now I uploaded the Units and Values desktop and mobile tables. They contain tests for many useful units, such as em, mm, vh, calc() and much more.

Oh boy, units and values.

Most compatibility patterns are actually quite simple: a browser does or does not support a given unit. There are a few exceptions, though.

But let’s start with some easy stuff.

“Absolute” units

The so-called “absolute” units are px, in, cm, mm, pt, and pc. Of course they’re not absolute at all: they’re all defined in terms of pixels.

Thus a 1cm wide element is not one real centimer wide; instead it’s 37.795 pixels wide. By definition. That’s not what many web developers want, but, as I said before, I think it’s inevitable. Making sure a 1cm element is really 1 centimeter wide under all circumstances (zoom!) would require far too many reflows of the page and will become prohibitively expensive on mobile.

Anyway, these are the definitions:

• 1in = 96px
• 1in = 2.54cm
• 10mm = 1cm
• 1in = 72pt
• 1pc = 12pt

The good news is that absolutely every single browser I tested supports all these units correctly and completely.

Font-related units

Then the font-related units: em, ex, ch, and rem. I must admit I do not really understand ex and ch; that is, I cannot write a useful test for them because I lack the necessary typographic knowledge. I accepted any value that seems roughly correct. Fortunately ch is not supported by any WebKit-based browser.

em and rem are a different case. 1em is defined as the amount of pixels in the font definition. So if your elements have font-size: 16px 1em is 16px, if they have font-size: 12px 1em is 12px, etc. This is exact, not rough.

rem works the same, except that it takes the document’s root font-size, i.e. the font-size of the HTML element. Under normal circumstances this is 16px, and if you change the font-size of the HTML element, rems should change with it.

All desktop browsers and most mobile browsers get it right.

Most mobile browsers. Android doesn’t. Worse, it depends on the device vendor, and not the Android version. Quick, say “fragmentation” five times without breathing in!

• My LG (2.2) and Samsung (4.0.3) Android phones get it right.
• My Sony (2.3.7) initially uses a root font-size of 14px, but otherwise gets it right, too.
• My HTCs (2.2 and 4.1.3) and tablet (3.2.1) see this test as an excellent opportunity to fire up their random number generator. Except that an em is never larger than a rem. Obviously.
• The One browser (by Chinese company TenCent) does the same. (It’s not a skin over Android WebKit, though. The numbers are different. As they should be.)

The rule here is clear: the farther you are from Korea, the wronger you implement em and rem.

Viewport units

That was fun, wasn’t it? But wait, there’s more!

The vw and vh units denote percents of the viewport width and height; i.e. 50vw means 50% of the viewport width. That’s extremely useful for responsive design, you will agree.

All desktop browsers but Opera support it, although WebKit supports them only statically; that is, the test elements do not change their dimensions when the viewport changes.

Mobile support is less, but most modern browsers support these new units. There’s a problem, however. vw and vh may take their cue from the viewport, but from which viewport? The visual or the layout? See this article for an explanation of the difference.

If you think the choice of viewport depends on the browser, bravo! You’ve just earned a badge of merit in comparative browser sciences.

It turns out that Safari (from iOS6 on) and IE use the layout viewport as their reference, while Chrome, Dolphin, and Tizen use the visual viewport. Judging by the results the Opera 14 engineers were drunk when they implemented these units, and the other browsers do not support them at all.

Even worse, every single browser except for IE10 and Dolphin implement the units statically: they do not change when you change the viewport dimensions, for instance by changing the device’s orientation.

The spec says that “the viewport-percentage lengths are relative to the size of the initial containing block,” so it would seem Safari and IE are right with their layout viewport, and the rest is wrong. Since Safari and IE9 don’t react to the changing of the viewport, that means there’s only one single mobile browser to implement these exciting units correctly, and that’s IE10.

Congratulations to the MSIE team for reading the spec correctly and for not being drunk while creating a mobile browser.

That concludes this exciting new episode of “How mobile browser prevent me from having a life.” Still, I would like to take this opportunity to thank the browser vendors for supporting my business model.