Those are all physical measurements, meant for the surface of the screen. If you design with them, it means you're designing with the screen size in mind. It's often wrong to design with those measurements.
There are relative sizes too.
%, em (current size of font), and measurements relative to viewports. That's what designers use very often.
I have been designing and building interfaces for a couple decades and I have been down the "relative size" path and learned not to do that the hard way. There lies nothing but tears. Sizing to pixels, for some reason, results in the most predictable and consistent appearances.
Pixels are being scaled all over the place these days, up to 300-400%.
The only reason pixels appear to "work" is that everyone uses pixels, so the software has to be written to lie about pixels. And so they continue to seem to work and people continue to use them to size things.
They might as well just call them "screen fractions" or something, because they sure aren't pixels.
MacOS/iOS uses screen units. Each such unit is of N physical pixels. Where N is a number obtained by [ nsscreen backingScaleFactor] function for particular screen (monitor).
That's a point. 12pt font means 12 points.
a: Relative sizes (to bounding boxes/etc)
b: Exact physical sizes (E.G. points which are 1/72nd inch)
c: Precise device sizes (REAL pixels, not compatibility pixels)
It's a special case, sure. But those special cases suddenly enable what was previously impossible.
Mostly these cases revolve around implementing something in program instead of with basic standard features. Some standards even recognize that more complex decisions need to be made and allow for 'shaders' that determine the outcome instead of basic operations.
Providing low level primitives in a responsible interface allows for the corner cases to be approached with nuance and care instead of glaring presence of omission.
If they're not the same, then they're not inches.
The current system of pts or inches varying by context would be like if an oven manufacturer said "Well, 60°F is pretty warm, and 90°F is downright hot, so we'll just recontextualize those numbers for our oven gauge. Bake cookies for 10 minutes at 80 degrees.
Unless you're using some other oven that scaled temperatures differently, in which case bake them at some other temperature instead ¯\_(ツ)_/¯
One could argue that you really are using inches, it's just that everything ever displayed on a screen has an implied "not to scale" note with it, but I don't think that's a particularly useful argument.
Heck, if you're editing something in MS Office it'll show you an 8.5x11 page with a scale meter. Set it to 100% and surely that's to scale.
Nope, 100% of some other totally arbitrary scale. That's what you wanted, yeah?
But I'm designing when I'm in Word, it's not necessary or convenient to do all of my work at 1:1 scaling, that's what the ruler is for.
Compounding the problem is that the operating system relies on the monitor reporting its physical size correctly via EDID and for a lot of vendors (most notoriously Dell) this isn't guaranteed either.
They already exist (vw and vh are percents of the viewport width and height respectively). Renderers "relativised" supposedly absolute units because 1. they already were not correctly handled (as output devices often don't correctly report their densities and renderers would then just fallback to 72dpi or whatever) and 2. they were ubiquitous.
Consider it this way. When you had a A4/A3 size paper it it natural to talk in point, inches because your A4/A3 sheet of paper doesn't suddenly change to A5/A6, so you're all-ways designing for a fixed size.
I'm typing this on a 27″ iMac 5K with 218 dpi resolution. My smartphone (an iPhone 6) has 325 dpi; my 9.7″ iPad has 264 dpi. And you don't even have to use "retina" high-DPI displays to beat 96 dpi. The older 27″ displays, with 2560×1440 resolution, have 109 dpi when you work out the math; the MacBook Air 11″ has 135 dpi.
I think it's fair to say the world ran, past tense, on screens that were 96 dpi and under. But that's just not a very good assumption to make anymore.
https://www.w3.org/TR/css3-values/#px
1px = 1/96th of 1in
There is a A LOT of content being built, have been build by designers for 96dpi. The reason why it isn't a concern for you is because that standard exists, and your webkit knows you're on a 218 dpi monitor and scales to the px unit.
Sizing to pixels is vital when using low-resolution displays, since any scaling will be unacceptably blurry.
Apple's approach with their Retina displays was brilliant - make the high-res screens an integer multiple of the low-res ones. That made the scaling issues much easier to deal with.
The tragedy is with Windows. Microsoft has long emphasized font hinting, which results in sharper display fonts. But it means that the font metrics don't scale linearly with the resolution. Apps that weren't tested at anything but the default resolution would invariably have rendering issues, so nobody used oddball resolutions. Because nobody used high resolutions, the app makers didn't feel the need to test them. Chicken/egg problem. It has taken far too long to overcome this.
Brilliant? Rather "lazy". They jeopardized the entire screen resolution spectrum introducing non-standard resolutions just to fit their vision, producing a new set of problems on its own.
HiDPI screens just get a multiplication factor, where a 1px by 1px <div> shows up as 2x2 or even 3x3 physical pixels.
So the CSS px unit is a bit of a hack, but ultimately works well.
Stuff sized in px stays readable across a super retina iPhone X, an older screen, a projector, or a stadium Jumbotron.
That's more than can be said of physical pixel or distance units.
No, it doesn't. That "innovation" breaks programmatic graphics big time. Imaging you are drawing something on the screen, and you have no way to prevent things to alias at those 3x3 CSS pixels
Fine grained control belongs to the users. The browser is a User Agent, after all.
Users may have their computer configured to display text bigger or smaller than normal. They may have blocked ads. They may have disabled autoplaying video. They might be using Flux or Reader Mode. They might be sitting on a couch, projecting a 6ft image onto a wall.
Just size your stuff in px. How many millimeters that works out to is up to the user.
Note that an inch (or more likely cm) is rarely what I want. Most of my use case is text where physical measurements are not important. When I'm writing code I want text to scale to be readable. This means web browsers and many other editors should not have any concept of points/inches/cm.
But most devices relate them to screen pixels. And therefore scale coded pixels to the screen density.
High density devices can do this in multiple ways: every screen pixel is a coded pixel, or scale the coded pixels so the user can 'see' them.
That's why using pixels in code work because the device is scaling them to a screen size that is nice for the user.
Sometimes pixels are not even 2d locations. I've seen experimental hardware running hexagonal and other unusual pixel configurations. Vector images look absolutely amazing, even at low resolution, however certain font types (formats, not typefaces) look better than others and some look downright terrible.
We had that in Win95. You could scale the display for 1:1 dimensional matching with an on screen ruler. Then Microsoft found out how broken everything became if you scaled the display to a non-default value because invariably some GUI elements were built around hard coded pixel dimensions that couldn't adapt when the fonts weren't rendered the same as the developer's machine. So they hid all of that machinery in '98.
Guess what? People are still designing web apps today with px units and the same scaling breakage persists with browsers jumping through all sorts of hoops to hide it.
The problem, rather was that the OS didn't really do much to implement it. That ruler was basically just surfaced to the apps as an API to query, and then they were supposed to apply their own calculations as needed. One exception was the API used to create dialogs (but not other types of windows) from Win32 resoures - CreateDialog etc - these measure widget sizes in "dialog units", which is "an average width and height of characters in a system font"; the idea being that this way, the size of the widgets would naturally scale to the size of the text labels, according to DPI. However, many (arguably, most) Win32 don't use CreateDialog even for actual dialogs, and many frameworks in the past didn't respect the DPI setting at all.
Although points are formally defined as a physical size, they really only make sense in their historical context - the printed page.
I think the W3C definitions make the most sense when relating measurements to displays. You are encouraged to use definitions that are flexible but consistent with the context of your display. https://www.w3.org/TR/css-values-3/#absolute-lengths
A size specification that can be correctly converted into any amount of meters at all is most definitely not a physical measurement. A unit that has a conversion factor to the corresponding SI unit for the respective dimenion that can be chosen completely arbitrarily is certainly not a phyiscal unit of measurement.
The definition of physical units is precisely that they are relative to only one unambiguous standard which relates it to all other dimensions of the universe. Distances, for example, are related to time. As such, one meter, as a unit of distance, is the distance that light in a vacuum travels in 1/299792458th of a second. A unit that does not have such a fixed relation to time is not a unit of distance by definition. So, unless increasing the font size in your browser also slows down time, the em is not a unit of physical size.
There are many more perfectly fine ways to specify how to derive a physical size relative to a given situation, but that does not make that specification a physical size itself.