[css-values] Ability to address actual physical size

[nicksherman]

The lack of ability to address physical size in any meaningful way is one of the most glaring issues with CSS today. I wrote an article a few years ago explaining why:
http://alistapart.com/column/responsive-typography-is-a-physical-discipline

Especially if there is any expectation that CSS will ever be used beyond the world of web design, the ability to specify and query physical size is crucial.

I realize it may now be too late to change the definition of what in, cm, px, etc refer to in CSS without breaking a lot of things. But that doesn’t mean there can’t be new units introduced to refer specifically to real physical values.

[frivoal]

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.

[SelenIT]

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

[frivoal]

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.

[nicksherman]

@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.

[frivoal]

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).

[dbaron]

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.)

[Crissov]

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

[frivoal]

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.

[patrickhlauke]

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

[frivoal]

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

[nicksherman]

@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).

[Crissov]

Solve the use cases with media queries then?

@media physical {…}

[nicksherman]

@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.

[patrickhlauke]

There are extra complications to take into account, mind. For instance, what if a user has set their OS resolution to something other than factory settings? Should physical units ignore that (e.g. 1cm always means 1cm, regardless of however the user set up their environment)? What about zoom factors? What about set-top boxes which may have no direct way of knowing physical size of the TV/screen they're connected to?

[patrickhlauke]

@nicksherman

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.

of course they don't. but they strive to come close (with exception of TVs which stubbornly seem to refuse to implement anything close to a sane ideal viewport, and instead insist on desktop-like 1080p type resolutions with pixel density of 1 plus lots of fudging/upscaling, which is my personal bugbear). there's no guarantee of absolute accuracy, and the spec https://drafts.csswg.org/css-values/#absolute-lengths aknowledges that

[...] it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel.

[patrickhlauke]

@nicksherman

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.

related, i admittedly didn't do extensive testing, but when i last looked at this, the combination of browser/printer driver/printer seem to try to get it right to an extent (there's probably further fudging caused by printer settings involved here). using http://codepen.io/patrickhlauke/full/zqabMR/ and printing it out (I believe I tried only in Chrome at the time, admittedly) I get the below (where 72pt in CSS come...close-ish to a physical 1in on paper)

[nicksherman]

@patrickhlauke Yes there are several interesting questions related to this. Some of them are more complex than others, and while I personally have opinions in many cases (perhaps better elaborated elsewhere if we want to keep this thread on topic), I can’t claim to be an authority on all of them. Nevertheless, I don’t think questions like these should be the reason that physical units are entirely ignored.

I’ve done a few rounds of tests using the existing “absolute” units with typical consumer-level software and hardware, and every time I’ve had inaccurate results like the ones you showed. What’s worse is that the results vary widely depending on factors that are very hard if not impossible to pin down with certainty.

The sizing error you showed seems small at the target size of 1 inch, but that’s already enough to be unusable for many production purposes. And if you multiply that scaling error up to a target size of 10+ inches, it literally becomes a big problem.

Most of this conversation has been focused around the idea of sizing elements with physical units, which is great, but I feel inclined to also point out the less-obvious benefit of being able to query again physical sizes. For example, I'd love to be able to specify separate layouts for 8.5×11″ and 11×17″ paper formats, etc.

[patrickhlauke]

every time I’ve had inaccurate results like the ones you showed

my contention is that this level of inaccuracy won't be solved by simply decreeing in the spec that the whole pipeline of browser/OS/printer driver/printer/etc must be accurate. but happy to be proven wrong :)

[nicksherman]

@patrickhlauke If not start in the spec, then where else? Can we at least agree that dependable and accurate physical units are a good thing that should ultimately exist?

[patrickhlauke]

random idea: similar to box-sizing, create a new value-anchor-unit or similar (open to bikeshedding), with values physical|pixel (where pixel would be the default)

[nicksherman]

That’s an interesting thought … Would that allow for a fixed physical unit to be specified for one dimension of an element and a relative/reference unit for the other? Or – maybe more importantly – would that be less complicated than simply introducing entirely new units?

[frivoal]

my contention is that this level of inaccuracy won't be solved by simply decreeing in the spec that the whole pipeline of browser/OS/printer driver/printer/etc must be accurate. but happy to be proven wrong :)

I agree. Current mis-sizing is not due to trying to do some different kind of sizing, but to failing at making 1in be 1in on paper, due to a bunch of intermediates, some (or many) of which may be sloppy.

TV are refusing to do what the spec says they should do, and I don't really look favorably upon defining "You must do XYZ. If you'd rather not pay attention and keep on violating this spec, here's another one you could have a look at."

Until TV vendors come back with an explanation for why doing the viewport the way the spec says cannot work for them, my assumption is that not that they have found such a reason and remain silent about it, but that they haven't bothered to try. I may very well be wrong about this, but I did spend two years as porting browsers to TVs, and two other years working for a TV vendor, so my guess is not a totally uninformed one.

[patrickhlauke]

Though it's an aside to the main conversation, my take on TV vendors' reluctance (having worked with the same browser/vendor as @frivoal on that) is a combination of:

• following specs like the HbbTV one (which mandates desktop-like resolution as standard)
• at least at the time, a fear that having a different viewport size (and the resulting calculations needed to then upscale the output) would strain the CPU on set-top boxes/TV sets with built-in web browsing capability (which often lack dedicated GPUs)
• a fear that customers will be confused if they don't see the same site as on their desktop computer when accessing it on their TV
• a fear that if a TV set the viewport to be small (mostly, tablet-sized) with high pixel density, sites would naively assume it's a mobile/tablet device and do things like rely on touch events, thus breaking navigation
• a belief that authors will simply design specifically for the "web on TV" scenario and compensate for the inappropriate resolution by "making things bigger" (which is ludicrous, as that would mean every site would potentially need to make a separate TV version, AND do something like UA sniffing to then redirect devices that smell like TVs to that version, since there's no other indicator that's reliable)

I am still hopeful that with the more current crop of devices (and particularly now in light of 4K / 8K displays, which absolutely demand some form of upscaling or at least reassessment on what resolution is being pushed out) the idea that TVs should behave more like a tablet/large phone with high-resolution display (as that gels with a viewing distance of 10' or so) will catch on (from memory, the FirefoxOS enabled LG models do at least run at desktop-like resolution, but advertise a device pixel density of 1.5 or 2).

[tabatkins]

As argued very ably by several people in this thread, "real physical units" are (a) impossible in general, due to needing every part of a hardware chain to reliably tell the truth about its scaling, which they don't do, and (b) very, very rarely, if ever, what you actually want. The one use-case that kinda makes sense (making sure touch targets are sufficiently large in real terms) is better served by addressing that directly with a 'touch' unit or similar.

As such, I'm going to go ahead and close this issue.

[frivoal]

In addition to the considerations above as to whether this is even possible, another point is that while there are some use cases for physical units, and it would be nice to measure the correct amount of chemicals in your pipette using a css-made scale, these are vastly outnumbered by the number of developers who use units rather interchangeably without thinking too much, and don't test on a very broad range of devices. And if anyone uses the physically-accurate-on-any-device physical units for anything other than making a physically accurate measuring instrument, they'll make sites which are badly broken and unusable on a wide variety of devices.

In general, the ability to use a feature wrong should not necessarily mean that we should ban that feature, but when a feature is overwhelmingly likely to be used wrong and to result in broken sites, then it's a bad feature. It be nice to be able to make accurate lab equipment in CSS, but that is of much lower importance than keeping the ability of the web to robustly work across devices, including those the author doesn't test on (which includes those that those that haven't been released yet).

The way the current "physical" units are anchored to pixels is exactly the culprit of this issue.

Fixing the ratio between px units and physical units was found to be necessary for cross device interoperability given existing content, and desirable to make it easy to author robust cross device content. Solving cross device interoperability is a core goal of the web. Making accurate measuring equipment is not.

We are not going to write our own rendering engine to set a different anchor.

You don't have to make your own rendering engine, you just need to set the default zoom level on your browser to make a 1cm in css be 1cm in real life, or to add a calibration step in your web app. If it works out for you, great. If not, this is unfortunate.

But the whole world is not going to write a rendering engine that sacrifices cross-device interoperability just so that a few people can make rulers more easily.

[tabatkins]

to add a calibration step in your web app.

Notably, this would basically be:

1. Have a calibration page, where you ask the user to measure the distance between two lines that are some CSS distance apart (say, 10cm), and input the value they get.
2. Use this to find the scaling factor necessary for that screen (CSS length divided by user-provided length), and store it locally (via localStorage, or a cookie, etc).
3. On the pages where you need the accurate length, fetch it from local storage, and set a --unit-scale: 1.07; (subbing in the real value) property on the html element.
4. Anywhere you use a length that needs to be accurate, instead of width: 5cm;, write width: calc(5cm * var(--unit-scale, 1));.

This is a robust and minimal calibration scheme that will "fail open" - if the user hasn't calibrated, or clears local data, or has JS turned off, it'll just use standard CSS units (due to the , 1 default arg for the unit scale), rather than breaking.

[davelab6]

This is a robust and minimal calibration scheme

It also requires zero spec changes, right?

And, if that non-spec-changing technique is really a solution, then isn't there a plain case for a unit-scale-adjust property that works similar to font-size-adjust so that you just that property and then 5cm becomes calc(5cm * var(--unit-scale, 1) automatically, everywhere?

[patrickhlauke]

but your unit-scale-adjust property you're suggesting would still be dependent on the browser being able to get the accurate adjustment from the OS, which then goes back to the original problem of this information not always being available at all...and we're back to the same problem again?

[BevansDesign]

If the info isn't available (which would often be true in the first few years of a physical-size feature being added) there would just need to be a fallback of some kind. Let the browser itself make its best guess, or even let the user manually enter their screen dimensions.

It's definitely not going to be an easy process, but a lot of the things that this project relies on won't get done until the project itself is actually implemented. For example, there's no reason for devices and OSes to report their physical size to the browser unless there are features in the browser that can take advantage of that info. In that case, we just need to forge ahead and get the CSS piece implemented, then pressure MS, Google, Apple, and device manufacturers to get on board.

[tabatkins]

It also requires zero spec changes, right?

Yes.

And, if that non-spec-changing technique is really a solution, then isn't there a plain case for a unit-scale-adjust property

Not really. The use-case here is not "scale every single length in the page to match physical dimensions", it's "scale these particular lengths to match physical dimensions, so users can measure real-world things against the screen". So it's absolutely a targeted operation, on particular lengths that only the page author can identify.

but your unit-scale-adjust property you're suggesting would still be dependent on the browser being able to get the accurate adjustment from the OS

No, they were talking about just adapting my variable-based suggestion into an official property; it would default to 1 and the user could set it as needed to scale the physical lengths up or down.

[minomikula]

Another use case:

We are creating web application, and we know the intended viewing distances. For example in our system, we created:

• Page for big screen in the hall, where we guessed viewing distance to be 10 meters
• Another page is build for operators, where screen is mounted on wall, and user do not interact with it, so we guessed distance to be 2 meters.
• Next page could be displayed on same display, but this time we expect that user is sitting on the chair, so distance will be 70cm.
• We have pages optimized for tablets, for in terrain work....

We want to create system, that will calculate best font size from expected viewing distance (known to author in our case) and ideal viewing angle (user configurable, based on sight quality). We can calculate optimal size in real centimeters, but we don't have methods to set size in css pixels.

[justingolden21]

I see little downside to adding something like mentioned above with the experimental mozmm unit suggested.

• It won't break any existing code
• It acknowledges and maintains all benefits of the normal mm, cm, and in units, and for people not even aware of the existence of mozmm and similar, they go about programming the same
• It provides the functionality people here are suggesting, and have good reason to suggest
• Adding it has virtually no downsides in terms of: complexity, processing time, code size, etc. I really see no downsides aside from the clutter of adding another (entirely optional) unit

Just my opinion here; I understand this isn't something fundamentally necessary, but it's definitely a useful building block that we couldn't have without making this change, and there really is no reason to not implement it.

[mrmazda]

Justin Golden composed on 2021-01-09 11:53 (UTC-0800):

I see little downside to adding something like mentioned above with the experimental `mozmm` unit suggested. * It won't break any existing code * It acknowledges and maintains all benefits of the normal `mm`, `cm`, and `in` units, and for people not even aware of the existence of `mozmm` and similar, they go about programming the same * It provides the functionality people here are suggesting, and have good reason to suggest * Adding it has virtually no downsides in terms of: complexity, processing time, code size, etc. I really see no downsides aside from the clutter of adding another (entirely optional) unit Just my opinion here; I understand this isn't something fundamentally necessary, but it's definitely a useful building block that we couldn't have without making this change, and there really is no reason to *not* implement it.

+++ A huge selection of my web pages irrecoverably broken when mozmm units were expunged from Mozilla browsers. Luckily, there's still Palemoon.

[frivoal]

I see little downside […]
really see no downsides […]

Saying this at the bottom of a thread where multiple people have went to quite some length to explain the what the downsides are seems unlikely to move the discussion forward.

[davelab6]

Unlikely to move the discussion forward

How can this move forwards?

[frivoal]

I do not have strong expectations that this can move forward. Numerous explanations have been provided as to why this won't happen, and the issue is closed, very deliberately so. It is far from the first time that this gets raised, and the conclusion is always the same, for the same reasons. So most likely, nothing will happen.

At the same time, those who believe that closing the issue is a mistake are welcome to try and convince others of that, but repeating arguments that have already been refuted, or acting as if the downsides that have been pointed out don't exist is unlikely to convince anyone.

It is possible that most members of the CSSWG and most browser engineers are wrong, that there's a big flaw in the collective reasoning, and that one way or another, this is actually a good idea. If you think so, start by understanding the arguments against, then build a strong case debunking them, and explain why you're right.

Merely stating that there's no downside isn't going to be convincing.

[davelab6]

adapting my variable-based suggestion into an official property; it would default to 1 and the user could set it as needed to scale the physical lengths up or down.

How can this move forwards?

I do not have strong expectations that this can move forward. Numerous explanations have been provided as to why this won't happen, and the issue is closed, very deliberately so.

I'm sorry I was too terse, I was talking about the thing @tabatkins and I had discussed which seems to have merit.

[tabatkins]

Note that, when asked if there was a use-case for the "adjust all length on the page by this factor" property, I replied "Not really". ^_^

As I said in the linked comment, the use-case is not "adjust every length on the page" - calibrating your ruler shouldn't also scale the UI. It's "adjust these particular lengths that I want to be physically accurate", and with variables there's an easy and robust way to do this by asking the user to calibrate the length, which is guaranteed to be correct in all cases rather than relying on a possibly-faulty browser-provided scaling factor.

[tabatkins]

I've gone ahead and added this to the FAQ, since it's come up multiple times.

[graphicore]

It is possible that most members of the CSSWG and most browser engineers are wrong, that there's a big flaw in the collective reasoning, and that one way or another, this is actually a good idea. If you think so, start by understanding the arguments against, then build a strong case debunking them, and explain why you're right.

Hey all, based on this discussion, I wrote an article about this topic: Calibrate CSS

• It implements a calibration widget as described by @tabatkins.
• Under Debate I take up the argument.
• It has an incomplete list of possible Use Cases.
• And it proposes a progressive Browser Support Roadmap in four milestones; suggesting the CSS property env(unit-scale-physical)—similar to [css-env] Device Pixel Ratio #5986—in Level 1.

I hope this is a constructive contribution to the debate and I'm looking forward to evolve this.

We need a community to further establish Level 0.

[trusktr]

What is EDID?

EDID is an industry standard (published by VESA) for AV Source and Display devices which automatically communicates manufacturer specification and data between devices. This allows your AV source to send the best compatible signal data to your screen, TV or projector to ensure the best possible picture results.

It is a well known standard. There may be others.

Exposing physical pixel APIs in the web will encourage hardware makers to follow along, considering the web browsers are the most stable and widely tested pieces of software humans may have ever made.

It seriously can not be more difficult than managing OpenGL compatibility behind WebGL. That must be many times more complex. Yet we still did it.

A simple fallback for certain cases when information is not available is totally a must.

Well known native frameworks like Qt have been giving developers physical pixel sizing for a long time. It is time for web to be as good.

_{It takes a visionary to be able to see this future.}

[gepardec-wf]

hi,

this is a very interesting, although seemingly hopeless conversation about this rather confusing topic (at least it is/was for me). i too came here originally because of the hit target problem, but generally i expect "physical units" to work as expected/promised/suggested by their name.

in my opinion and experience, it is extremely misleading and irritating to borrow the names of "real" units like inch or cm and use them for "fake" units that lead to different/unexpected results. i really cannot think of why they were introduced in the first place, if there was never a chance to achieve exact/expected results with them. i can only guess it has some historic reasons ("simpler times") and it can not be undone now without breaking some exotic code (which is i would do in a second), but wouldn't it be better to let them go or at least clearly warn developers/designers about these inconsistencies?

it probably would help people like me a lot to prominently warn of that mix-up, to expect inaccurate results and probably avoid these units at all. yes, in the specs there is a note, but is very subtle and most people don't find the time or interest to dig into such details. there should be a big red warning sign to avoid misuse.

i too would really like to use the real deal or avoid it at all, but it seems that has already been discussed in great lengths. the suggested alternative/compromise of being able to at least set a new property on specific elements or even the html element itself sounds great too! it reminds me of applications like acrobat that supports setting a global custom dpi in the preferences to manually adjust/calibrate the display of documents on one specific monitor. of course, it would even be better to automatically support reliable actual 1:1 physical view/scale like indesign or illustrator. if that is not possible (for whatever reason), why not give up on these otherwise unnecessary units... they seem to cause more harm than good.

i find it funny that the same discussions happened when desktop publishing software introduced the pixel unit to attract web designers and suggested it is an actual physical unit while the software works completely independent of density/resolution until export... to me it seems like the same issue, just the other way around.

anyway, the concept of css pixel as an angle is really fascinating! sadly, i cannot find out when this concept was introduced first and how well it is adopted across current devices and browsers. can designers already rely on it? is it at least a good enough approximation of consistent size across devices with different densities/sizes/distances?

[trusktr]

I don't see why this can't be added. In many cases, the API will be useful (most apps run on a single display, with EDID information readily available).

It seems like real unit (rin, rmm, and rcm, etc) would be a simple solution for it. In the case some odd device has missing information, those units can simply fallback to the same values as the current units (in, mm, cm, etc).

Additionally, a capability for @supports/CSS.supports() can be included so that users can make (media/container) queries based on whether a device has the information available or not.

On multi-monitor setups, unless the pixel sizes match, either

• provide values based on the monitor on which the web app has most of its pixels,
• or just fallback to the fake units like the current behavior

For mobile phones and tables, this isn't even an issue. These devices have a single display the vast majority of the time. The vast majority of people with multi-monitor setups I've seen tend to have windows on one monitor or another, not spread across multiple.

Seems rather simple from an implementation perspective. I've used (actually valid) physical units in Qt since many many years ago...

[trusktr]

There are some really good use cases for this too. No everyone is designing standard apps.

For example, if someone is designing a physical experience inside a physical space, decorating that space by wrapping flexible monitors around a tube (etc), then being able to code the design that is supposed to wrap around that physical object simply using the units as designed, is a very simple dev experience.

Or someone makes a ruler app.

Or someone makes a huge wall out of multiple monitors, to display human-sized objects. They just use the actual size of humans (in inches for example) and it simply works.

Etc.