This comes up fairly often, gets pushed back every time. Let me try to give you a little gist of why.

As you said, it is two late to change the definitions of what in cm and px are without breaking everything, so compatibility alone is a sufficient argument for not changing them. You are right that we could introduce separate units with a different behavior, but the general consensus is that we should not, because the current definitions are not merely an accident of history, they are intentional.

in, px, cm etc are defined in a fixed proportion of eachother. Depending on the media, we might use one or another to anchor the whole thing, and the rest falls out of that. If you are printing, there is no clear concept of what a px is, but it is easy to define an inch to be an inch, and the px just falls out as 1/96th of that.

On screens though, the px is defined to be (an approximation of) an angular measurement. The article you linked to is brushing that aside, but that does it a great disservice: if the pixel you're claiming is insufficient isn't the one defined in CSS, then it is difficult to make sense of the criticism.

As you say, it matters to typography whether something is small or large. You want different font design and different typography based on that. But small or large is mostly not a question of physical size, but rather a question of the percentage of the field of vision, which combines physical size and viewing distance.

The CSS pixel is often (but not always) rounded to a integer number of physical pixels by implementations, but it is fundamentally designed so that if you know the size of something in pixels, you know how big it looks. You mention low sighted readers as an example of why you need to know how large something physically is, but that wouldn't not work. Making each letter 2cm tall, which would seem gigantic if you're thinking of text on a phone, would result in small and unreadable text when seen on the projector of a large conference room. The CSS pixel already accounts for that.

So your pizza slice analogy doesn't work. To turn it around, 1 “CSS pizza slice“ is defined so that it is always equally filling, regardless what kind of topping it has, whether it has a thin Italian crust or is an inch thick deep-dish Chicago style one. Knowing the diameter of the pizza alone wouldn't give you a better results, and if you had all the parameters, you'd need to boil them down to the same result a we already gave you.

Sometimes, you also want to know about the resolution in order to know if you can use a font with fine serifs or other small features, or if they are going to be all mashed up due to a lack of physical pixels. But what's relevant here is the density of pixels with regards to the size of the font. And since that is not in physical units, but in CSS units, the resolution media query does the right thing.

Another argument against absolute physical measurements is that they would mess with zooming. With the way things are currently defined, when the user zooms in, everything gets larger. If we respect that, the absolute physical units would no longer by absolute and physical, and we're back to square 1. If we don't, we're preventing users from zooming, which is a terrible disservice to do. We could distinguish between page zoom and pinch zoom, but that wouldn't really solve the problem.

Yet another argument is that the browsers are not typically aware of the physical measurements of the display. Sometimes they may be, but in the general case they are not. And without that information, they cannot know how to correctly display something at 3 physical inches. This is not merely a temporary limitation of current software: if you move a projector closer to or further away from the wall it is projecting on, you would need to change the relative size of things on the web page to preserve the absolute measurements. But even the OS or the graphical drivers have no idea how far the wall is.

Interestingly, MDN mentions the experimental mozmm unit intended to "render at exactly one millimeter regardless of the size or resolution of the display".

Not entirely clear how that works though. On my mac, it seems to be the right size as long as you don't zoom (because then its size changes, just like any other unit).

On my phone, if I use the meta viewport, it is larger than the requested size and larger than the same size in standard css mm, this works out to a different proportion between mm and mozmm compared to my mac. If I do not use the meta viewport, it is smaller than the requested size (no doubt due to the initial state being zoomed out).

So the result is not reliably matching the physical measurement nor not reliably proportional to other css units. Doesn't sound terribly useful to me.

@frivoal See responses to specific comments below …

the current definitions are not merely an accident of history, they are intentional.

The current definitions were not the original intention of the spec. As the spec itself explains: “Note that this definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)”

If you are printing, there is no clear concept of what a px is

Like screens, printers also have physical resolution and an equivalent of a physical pixel unit (they are just much smaller than most screen pixels, and unrelated to the current concept of a CSS “pixel”).

On screens though, the px is defined to be (an approximation of) an angular measurement. The article you linked to is brushing that aside, but that does it a great disservice

The angular measurement ascribed to px in the spec (0.0213 degrees) is fairly arbitrary, a backwards-justification from the previous definition of px in order to maintain some kind of logic and support older designs. If the original plan was to include angular measurements in the spec, they would have chosen a more logical unit like degrees or arcminutes.

I am a huge proponent of the ability to address size in relation to perception and angle of vision, but the concept is not mutually exclusive to the ability to address physical size either.

small or large is mostly not a question of physical size, but rather a question of the percentage of the field of vision, which combines physical size and viewing distance.

I am very aware of this. See my Size Calculator project which is intended for calculating these relationships.

You mention low sighted readers as an example of why you need to know how large something physically is, but that wouldn't not work. Making each letter 2cm tall, which would seem gigantic if you're thinking of text on a phone, would result in small and unreadable text when seen on the projector of a large conference room.

One of the biggest values of addressing physical size is not in specifying how large something is rendered but in knowing the size of a display on which it is rendered. If I know the physical size of a display, I have a MUCH better idea of how far away the viewer will be from it than I would from a relatively arbitrary pixel count.

Another argument against absolute physical measurements is that they would mess with zooming. With the way things are currently defined, when the user zooms in, everything gets larger. If we respect that, the absolute physical units would no longer by absolute and physical, and we're back to square 1.

Zooming for physical units could easily work the same as any other units. Zooming a 1-inch element to 200% would make it 2 inches.

But you're also incorrectly assuming that I'm only talking about screen-based media, and that I think the size of most elements should be spec'd in physical units. In fact, I'd say fixed physical sizes wouldn’t make sense for many things. But that doesn't mean they shouldn't be an option for the times when they do make sense.

Yet another argument is that the browsers are not typically aware of the physical measurements of the display.

Again, you are assuming I'm only talking about screen-based media. And even if some software environments don't currently access physical display info from the device, that isn’t a reason that none of them ever should. Windows 10 is already providing access to physical measurements for native apps via the RawDpi property. Why shouldn’t websites be able to leverage the same info?

Perhaps these comments are all beside the point though. If nothing else, the ability to address physical size is fundamental to using CSS for any fixed media like print. If designers can’t render an element at a specific physical size on a piece of paper, the whole notion of CSS being a truly universal language for presenting a document in a variety of media (including print) is moot.

the current definitions are not merely an accident of history, they are intentional.
The current definitions were not the original intention of the spec.

and

The angular measurement ascribed to px in the spec (0.0213 degrees) is fairly arbitrary, a backwards-justification from the previous definition of px in order to maintain some kind of logic and support older designs. If the original plan was to include angular measurements in the spec, they would have chosen a more logical unit like degrees or arcminutes.

Ok, sure, there is of course some part of the current definition that can be explained by history. The fact that we use an angular measurement called pixel rather than degrees or arcminutes is certainly due to the fact that we started with a pixel unit. You are right, it initially did not have that behavior, and was simply a physical pixel. But as time went by, that definition was found to be problematic, and the newer system was used to redefine it.

What is particularly useful about the angular definition of the pixel and other length units is that they enable robust designs. By that I mean that it enables authors to write a web page that works in environments they know about, and be confident that it will do the right thing even in environments they haven't tested in or are not even aware of.

For instance, when then first iphone came out, it had small physical pixels, but since they were to be viewed from a close distance, it was still OK to have 1px to be 1 physical pixel. That meant that inches on the iphone were small, since they kept the 96 to 1 ratio. This in turn meant that sites that had not anticipated the iphone ended up working just fine. Further down, when retina iphones came out, pixels were now “too” small, so we got multiple device pixel per css pixel, inches stayed the same size, and again everything worked fine. And not everybody thinks of a projector or a nintendo wii when they design their site, but again, it just works.

I am not claiming that there is no possible use for physical measurements. Authors are infinitely creative, so I am sure something could be made of them. On the other hand, I am sure that valid uses of physical measurements are many orders of magnitude more rare than the ones we have now.

This gives a double challenge to people asking for physical measurements:

1. Make sure you design this ability to access physical measurements in such a way that it could not possibly confuse authors, and cause even a small fraction of them to use physical measurements when they should be using the system we have now. Otherwise, such confused authors will write sites that don't work well across devices, and make the overall web experience worse for end users. If one author in a million makes the mistake, it is probably fine, but if one in a hundred does and writes sites that don't adapt well to different environments due to this, we will have done more harm than good.
2. Since the use cases, even if real, are rare, convince web browser vendors that this is worth their while. They already have a long list of things they mean to get to, and currently none of them recognize this need as something relevant, this is going to be an uphill battle.

With regards to (1), I would say that introducing new units that give access to physical distances would not be acceptable. There's just too much a chance that authors who haven't thought deeply about this would pick the physical ones instead of the angle based ones, and make brittle designs because of that. So if this is to be exposed, it has to be some other way.

As for (2), I suggest trying to build a corpus of concrete examples. Not abstract declarations of reasons why it should be useful, actual specific examples of designs that you cannot do today, but could if you had the feature. Down to the actual code, with mock ups of the rendering (ascii art will do, but the point is to be concrete), reasons why you cannot achieve this without the feature you're asking for, and (if it is not painfuly obvious) reasons why there is merit to this design.

If nothing else, the ability to address physical size is fundamental to using CSS for any fixed media like print. If designers can’t render an element at a specific physical size on a piece of paper, the whole notion of CSS being a truly universal language for presenting a document in a variety of media (including print) is moot.

From the spec:

For print media [...] the anchor unit should be one of the standard physical units (inches, centimeters, etc)

So that's solved already. Using CSS for print is not theoretical, and I am not just talking about pressing the print button in your browser. Commercial books are made with CSS all the time (I just typeset this one).

Interestingly, MDN mentions the experimental mozmm unit intended to "render at exactly one millimeter regardless of the size or resolution of the display".

For what it's worth, I think this was added primarily because it was needed to make things that are touch targets an appropriate size. (See Jonathan Kew's original proposal and roc's later post on use cases and the bug in which the unit refactoring was done.)

Touch screens are the reason why I still think that tip (≈ centimeter) would be a useful physical unit in CSS.

Right. Matching the size of a physical object seems valid in theory if there are relevant use cases, and correctly sizing touch targets seems like one.

As such, a tip unit might be reasonable, especially if we let the UA define how big that should be. A stylus touch device could for instance have a smaller tip than a finger touch device.

On the other hand, the difference between finger and stylus may be something we leave up to media queries (pointer:coarse vs pointer:fine), and for the rest maybe we can just deal with this with existing units: the distance range in which touch UIs can be used is necessarily limited by human anatomy, and something like 60px = 0.625in ≈ 1.6cm seems to me like it would be appropriate for a finger touch target both on arm's length devices (touch-screen laptops), where it would have approximately that size in terms of physical measurements, as well as for folded-arm's length devices (phone/tablet), where it would be about half that in physical terms. And since arms length manipulation tend to be a little less precise (arm movement vs finger movement), the difference in scale might actually be a good thing.

Coming in late here, but: @nicksherman

If I know the physical size of a display, I have a MUCH better idea of how far away the viewer will be from it than I would from a relatively arbitrary pixel count.

You'd still end up inferring things. What if you find out that a display is physically large. It doesn't tell you if it's a TV type device (with a viewing distance of 10' ~ 3m) or a large touchscreen device meant to be stood in front and manipulated.

I've long argued that the problem is potentially already solved if devices chose a sensible ideal viewport size https://patrickhlauke.github.io/web-tv/ideal-viewport/index.html

I agree with @patrickhlauke, and believe at least a large part, and probably all, of the CSSWG does agree as well.

@patrickhlauke I like some of your thinking with the viewport tool, but it also seems to put a lot of faith in how closely CSS pixels on most devices tend to match the spec’s reverse-justified definition of 0.0213 degrees. In most cases, devices do not render CSS pixels at the spec-accurate size when their displays are viewed from the intended viewing distance. But this is a bit of a digression.

There will always be some amount of inferring unless there is a specific viewing distance that can be detected/reported. In the mean time, regardless of if physical size is used for inferring viewing distance, there are still all the other previously-mentioned situations where physical size would still be just as useful/necessary.

One very basic example that @frivoal brushed aside is the issue of what happens when you hit the print button in your browser. Currently, even if you have a print-specific stylesheet with sizes set in “absolute” units like inches, almost all print output that is initiated in a browser will send something off to the printer that doesn’t match the specified sizing, instead utilizing CSS pixel sizing logic, usually in unpredictable ways. Unless there is a way to explicitly address physical units, there will likely not be any support for accurate print formatting within the output flow that most of the general public will ever use to print a web document (i.e. hitting the print button in a browser).

Solve the use cases with media queries then?

@media physical {…}

@Crissov All media formatting is physical, even when it’s screen-based :)

But I understand what you’re getting at. I think that is making it more complicated than it needs to be though. The simplest way to solve this issue would be to just introduce a new set of bona fide physical units that correspond to actual physical size, and specify very clearly in the spec that they must be interpreted as such.