JavaScript is evolving fast, recently, but it's not like the other web development language companions are set to stone either.
CSS is evolving too, and even though Houdini is probably going to set a new breakthrough in CSS development, it's unfortunately far beyond wide adoption. So we have the usual drill of expert meetings, that produce new specifications and so on... Not like TC39's fast-paced progression, but still.
Talking about CSS that you might - but more probably might not! - have heard, and even less used, about the units described in this article. And no, not like the "old" vw and vh (which I happen to still have to explain to those less proficient in CSS).
The ones listed below are the new CSS units that are going to be specified in the upcoming CSS Values and Units Module Level 4.
lh and rlh
Things get interesting right from the start. lh is equal to the current line height, and that could become a very neat ally when computing the height of text content. Unfortunately, no browser supports it.
rlh is, on the other hand, the equivalent of what rem is to em: the line height on the root element.
vi and vb
Another interesting addition, and similar to vw and vh, they're percentages relative to the viewport. Specifically:
-
viis 1% of the size of the viewport in the inline direction; -
vbis 1% of the size of the viewport in the block direction.
What are these "inline" and "block" axes? For those languages that are written horizontally, like English or Arabic (as a right-to-left example), they're respectively the horizontal and the vertical direction, making these two units the equivalent of vw and vh.
But for those languages that are written vertically (Japanese comes to mind), those directions are switched.
We've used this distinction in CSS since the beginning (as in the display property, for example), so now they're used coherently as more language-aware CSS specifications are created.
Too bad no browser, again, support these units so far š.
ic
Talking about internationalization, ic is the Eastern equivalent of ch, which represents the size of the character 0. ic is, instead, the size of the CJK (Chinese/Japanese/Korean) ideograph ę°“ ("water", U+6C34), so it can be roughly interpreted as "ideograph count".
But what's this "size"? It's the so-called "advance measure": if the text is laid out horizontally, it's the width; otherwise it's the height. Notice that the same concept applies to ch too!
Aaand still no support from browser vendors.
cap
It's the measure of the so called cap-height. The spec defines cap-height as "approximately equal to the height of a capital Latin letter". There's an algorithm to compute that, even for fonts that do not include Latin letters, but I won't report the details.
Also because, again, we can't still use them in any browser.
Now something more anecdotal...
Let's have a look at the older spec (Level 3), because even if it should be widely supported and used, it still has some less known parts...
turn and brothers
This is for warming you up, as it should be a little more known than the others.
We've used deg to rotate things with transform, right? Well, one turn is equivalent to 360 deg. It's as simple as that. Quite useful for animations (especially for 360-rotations) and progression values computed in JavaScript.
But wait, there's more! Also grad and rad are specified, and yes, you guessed it: they're gradians and radians, respectively.
And they're all supported by every browser (IE since version 9), although I don't see a real place for gradians, whereas radians can be used for a direct usage from JavaScript's trigonometric functions.
Q
This one should be supported by every browser, as it's part of Level 3. As a matter of fact, only Firefox supports it, since the relatively recent version 49 (September 2016). Edit: apparently, Chrome supports too it since version 63.
So, what's a Q? It's simply 0.25mm, a quarter of millimeter.
And why did we feel the need for this? Apparently, it's used in printing typography. In Japan. Where, apparently, they don't use points or any other imperial unit whatsoever (and that's a š for me).
Aspect ratio
Not really a unit as it should be a pure value, but a measure anyway. It's specifically expressed as two positive integers separated by a / (a slash, or "solidus" in Unicode terms).
Where can we use it? Why, in media queries of course! Example:
@media screen and (min-aspect-ratio: 16/10) {
/* something for wide screens */
}
And the good news is: it's supported by every browser! Hooray! š
Hz and kHz
... Wait, what? As we've learnt in high school, aren't those units of frequency? What do they have to do with CSS?
To answer the questions: yes, they are; and nothing, as no CSS property, as I'm writing, requires a frequency. And yet, frequency units have been defined: why?
Probably for future usage in case of a specification of a module targetting speech synthesis or some other aural output. At that time, there actually was a CSS Aural style sheets module in the works, which does define properties that make use of a frequency, but that module has never seen the light.
That module has been superseded by a new one, compatible with the Speech Synthesis Markup Language (SSML), which responds to the name of CSS Speech. It's still in the works and again defines properties (like voice-pitch) that require frequencies, but it's not ready yet.
So it's pretty understandable if no browser supports frequency units: we wouldn't be able to use them anyway!
Future plans?
In conclusion, dear reader, have you ever used or planned to use one of the above units? Or maybe, you're planning it right now?
Top comments (13)
Love this lad. Absolute unit.
In awe at the wit of this comment.
You win this:
I've used vh/vw a bit, and the new fr unit (which is useful when working with CSS Grid).
I've also come across the new (I assume that they're new) units vmin and vmax, which works pretty much the same as vh and vw. But represents the bigger/smaller side of the viewport instead of the height and width.
It'd be quite interesting to see a use case for all of these units.
Great post!
vminandvmaxare actually as old asvwandvh, both on Level 3. Not many use cases, but there are some! They're especially useful for responsive layouts and font sizing.Some trivia about them:
vmax, and Edge started to support it only recently; a way to emulate it was usingcalc. E.g. if you wanted15vmax, you could docalc(15vw + 15vh - 15vmin)- not really handy, though.vminstead ofvmin, together with a completely wonky implementation of all these viewport units.They're great units, unfortunately they lose a lot of value due to inconsistencies among mobile browsers (I'm looking at you, Safari).
I used to like vh/vw. Until I discovered that Safari scaled them with zoom. So if you are zoomed at 85%, 100vw becomes 85% of the width of the page which is now equal to 72.2% of its original size.
I don't know who thought that made any sense and it seems to be the only browser that behaves that way :\
Oh, I see.
It's a shame that it's not implemented consistently, which often seems to be the case with CSS.
All these typography units and still no way to control the baseline position...
Ah, tell me about it š
It should be coming, though. Alas, not very soon.
lhunits can be simulated when using a scalar line height (likeline-height: 1.2) with:Likewise
rlhwithrem.How does the min-aspect-ratio works?
In the example, 16/10 or wider?
Exactly.
16/10 is, after all, equal to 1.6 š
I feel really dumb right now.
Thanks.
Awesome article, thank you for sharing the knowledge.