a rubik's cube
Web Development |

A guide to CSS units — pt. 4: angles, time, dpi and values without units

Moritz Jacobs

February 12, 2021

tl;dr quick summary
Welcome to our four part series on units in CSS, where we dive into each available unit, explain the relationship between them and try to find out when to use which. We will talk about accessibility, best practices for developer teams and the history of sizing elements on screens. In this part we will talk about expressing angles, time intervals, revisit the dpi dillemma and inspect values without a unit attached to them.

Did you miss the first, second or third part of this series? They exclusively dealt with what the CSS spec calls "lengths" — descriptors of dimension. Or in other words: any value that would fit properties like padding, margin, width, height, font-size etc.

There are a few units in CSS that do not describe dimensions though:


Something that I only learned when researching this article series: there is more than one way to describe angles in CSS!

Do you want to load external content from codesandbox?

  • deg: good, old degree — 1/360th of a circle — this is the one I have used all my life
  • rad: radians, I remember this from high school… a bit. It describes an angle as a fraction of 2π and is a useful unit if you're really doing some math in your transforms. Since CSS does not have π as a constant you can only use decimal notation for rad, which leads to many decimal places (or you calc() something together with a variable var(--pi)). I knew this existed, but I never needed it before.
  • grad: this is a weird one — it's equal to 1/400th of a circle. The idea is that a right angle can be divided into 100 parts. I can see that it might be handy, but I have never even heard of it until today.
  • turn: represents an angle in number of turns, so if you want to rotate something twice, you would do transform: turn(2);. I can see myself using this, now that I know about it!
comparison of css angle units
The more you know!


This one is quick: There is seconds — s — and then there's milliseconds: ms. You need this to time your animations and transitions.

Keeping in mind all that we talked about in this series, is it just me or does it feel weird that the spec stopped there? Why not mins, hours or even days?

dpi? Again!?

Yes! If you read part 1 of this series, I told you not to worry about dpi (dots per inch) in your designs and also claimed:

The web doesn't have a resolution.

me, a few posts ago

Alas, I kind of lied to you. The CSS standard assumes a baseline density for webbrowsers of 96dpi and there even is one aspect of CSS where this is used: responsive images and media queries.

Ideally, your site would serve different images for different devices to save bandwidth using srcset. If you have never used it, learn all about it over at CSS-Tricks! Essentially, you offer the browser multiple images/sizes and it choses the one that fits the current viewport and display density best, without you having to do any magic in CSS.

Yet, additionally you can media query display density/resolution in CSS. This is only needed if you want to make images responsive and, for some reason, absolutely can not use an <img srcset="…"> but must use a CSS background image. The way you do this is by querying min-resolution in dpi:

@media (min-resolution: 192dpi) { 
    background-image: url(…)

Alternatively, you could also use dpcm (dots per centimeter) but while I technically agree that metric is always the better option, browser support is poor and this is one of those areas where the metric system never really prevailed. There's one more unit that you can use here: dppx — dots per px. As a unit I find it the least confusing and the values are also less "magic": 2dppx means 2 actual, physical pixels per 1px of rendering, so HiDPI/retina. Unfortunately browser support is still bad, so we're stuck with dpi for now. 192dpi (2 × 96dpi) is the HiDPI/retina value, probably the only one you need.

Another caveat is browser support for the min-resolution query itself, that's why — as of early 2021 — you have to add this fallback for Safari:

(-webkit-min-device-pixel-ratio: 2), /* fallback for Safari */
(min-resolution: 192dpi) { 
    background-image: url(…)

In the future, min-resolution will prevail, but for now we need the fallback.

Another use case for such a media query would be borders with half pixel widths. border-width: 0.5px would render kind of blurry on non-retina screens. But with this media query you could fall back on 1px for lower densities! If your designer really, really insists on such thin borders, do yourself the favor and put it in a media queried CSS variable:

:root {
	--half-pixel: 1px;

	(-webkit-min-device-pixel-ratio: 2), /* fallback for Safari */
	(min-resolution: 192dpi) { 
		:root {
			--half-pixel: 0.5px;

.foobar {
	border-width: var(--half-pixel);

See this in action in this pen.

Unitless values

There are two notable cases in CSS where omitting units has specific implications. The first is when setting a length of 0. Since there's no difference if something is 0px or 0rem, you can omit the unit. So width: 0 is the only valid use of a unitless number as a width.

The more important one is the line-height property: you should always use unitless line heights so it will correctly adapt to different font-sizes. See this pen for example:

4 examples of different methods to denote line height in CSS

The content of these boxes is double spaced, so its line height is defined as twice the font size. Each box uses a different unit, but watch what happens when you add another paragraph that uses a smaller font size: in the first three boxes the line height of the smaller paragraph is inherited from the container as an absolute value and thus too big! Only the one that uses unitless line-height looks correct, because only unitless is truly font-size relative.

Selina Meyer from the TV show Veep making a "wrap it up" gesture

Phew, I think that's the end of the series! We looked at all the commonly used (and then some not so common) units in CSS as of now. CSS is ever evolving and a few years from now, we could probably amend this article series with more parts. Just look at the proposals developers have for new CSS features! Some people (myself included) are super opinionated on CSS units but there is not always a definitive right choice. Understanding your options and reaching a team-wide decision is sometimes the best you can do.

Header Photo by Daniele Franchi on Unsplash

CSS units

CSS angles

CSS time



Peerigon logo