Csswg-drafts: [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.

[nicksherman]

@tabatkins I strongly disagree …

"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

This is not “impossible”. There are many hardware/software chains already in existence that do this properly (e.g. native Windows apps have been able to report/address physical display properties for some time now). And the places where it doesn't currently happen aren’t because it is impossible, only because it hasn’t been done yet – not surprising if there is no standard for it yet. It is a chicken/egg situation. The “impossible” excuse is like saying something like the new font variation features should be abandoned because some environments don't support them yet.

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.

So you are ignoring the entire world of print design? Accepting your statement is accepting the concept that no CSS for printed documents will ever be accurate or dependable. And accepting that is betraying the original idea of CSS.

[jonjohnjohnson]

@nicksherman I'm guessing what's most "impossible" would be getting implementor interest. We still haven't found a way to land position: device-fixed, which has similar non-scaling/zooming issues with what I imagine absolute/physical sizing out in the wild. I mean, we even lost the ability to disable "pinch-to-zoom" in iOS safari over a year ago https://webkit.org/blog/7367/new-interaction-behaviors-in-ios-10/ and I sadly don't think they would entertain this in any form. Even if there is a real use case on the print side of things, when we can't even reel in the violation of screen implementations of viewport.

[patrickhlauke]

So you are ignoring the entire world of print design? Accepting your statement is accepting the concept that no CSS for printed documents will ever be accurate or dependable. And accepting that is betraying the original idea of CSS.

print media is already supposed to anchor on physical sizes. the spec has been saying that for ages.

[BevansDesign]

This issue needs to be reopened. Physical units are essential to the future of CSS design. It's not going to be effortless, and it probably can't be done without "cracking a few eggs", but it needs to be done anyway.

Uncoupling physical units from pixels is the most obvious solution, of course. I really don't think we should worry about breaking any sites that use in or cm right now, because they shouldn't be doing that in the first place, and they can easily change to px. I'm not sure what the effect would be for print, but that can be adjusted too.

And if uncoupling is impossible or too undesirable, then just create new units, like rin (real inches) and rcm (real centimeters).

Obviously a big issue is knowing the device's screen's physical dimensions in the first place. Here are some solutions for that, in order of usefulness:

Long term: Devices would report their screen's _usable_ physical dimensions to the OS, which would pass that along to the browser. This would be specified by the manufacturers in the same way that the device's name is right now.

Medium term: Browsers already have access to things like device names, OS versions, pixel dimensions, etc., and that can be matched against a database to infer the physical size of the device. For example, a "Samsung SM-G960U" is this big, an "Apple iPhone" with these pixel dimensions is this big, and so on. (This could probably also be done with a Javascript library, if anyone wants to tackle that.) Obviously, this solution leaves out many desktop devices.

Short term: Ask the user! Have the browser ask them to get out a ruler and measure their screen. They could probably just insert the diagonal size, and have the device figure out the rest based on the pixel dimensions.

Shortest term: Use what we have now, or fall back to default sizes for devices. A smartphone could be assumed to be 5in, a tablet 10in, a desktop 16in - or whatever makes sense.

I know these ideas aren't perfect, but I hope they at least demonstrate that we _can_ implement physical units in CSS - but it's not going to fall into our lap.

[tabatkins]

What do you want to do that requires true physical sizes? Information about use-cases will be far more valuable than possible implementation strategies.

[Crissov]

Touch target sizes have been accepted as a valid use case by almost everyone, yet we still have no respective unit in CSS. (I might have overreached with the set of anthropometric units proposed in #837.)

As for the argument that software can never trust hardware to tell its true dimensions accurately, there have long been several apps that display a ruler onscreen which is apparently accurate enough in many cases. CSS Values and Units could also specify that UAs _must ignore_ physical units if they cannot guarantee their correctness, i. e. treat them as unsupported, whereas one would intuitively assume that they fell back to their px-based counterparts.

Regarding the names (or abbreviations or symbols) of physically accurate variants of existing units in CSS, Iʼm surprised that some people would be contempt with abominations like realmm or truecm when we could simply use their actual full names like millimeter and centimeter. (CSS prefers US spelling as color clearly demonstrates.) It may be counter-intuitive that 1cm would usually differ slightly from 1centimeter, but the clumsiness yet familiarity of the full names would ensure that they are chosen consciously and deliberately. (Metric base units without a prefix, as in 0.01meter, could actually be more convenient in many cases, while English unit names like inch are always short anyway.)

[frivoal]

• The use case of print is would not be addressed by adding new units, because the current units are already supposed to be physical-size-accurate when printing, by spec. If they are not, this is due to bugs in implementations. Go file bugs on browsers, and printer driver developers, and printer manufacturers…

• For the use case of touch targets, what is wrong with using something like

  @media (pointer:coarse) {
      .touch-target {
          min-width: 1cm;
          min-height: 1cm;
      }
  }
  

  That won't be exactly the same size on all devices, but it'll be smaller on devices which are operated at small ranges like phones, and bigger on devices operated further away (like a touch sensitive desktop screen), which seems to actually be useful.

• Has any other use-case been brought up?

[patrickhlauke]

For the use case of touch targets, what is wrong with using something like

Probably the fact that cm, mm etc are anchored on the ideal CSS pixel, rather than on an actual physical size. But this has always been a problem from the start, since user agents don't necessarily have all the correct information about the actual device's physical screen dimensions to the make an accurate translation of what a cm etc would actually be, in device pixels. And, even if they could, this would then lead to weird problems for devices that have a nominally large screen, but are generally viewed/operated at a distance - imagine something like a TV or digital billboard, and an authors (naively perhaps) sets something to be at a particular size in cm ... IF the device respected that as meaning actual physical size as measured on the screen, you'd end up with something impossibly small to see.

Beyond web content, native app development also doesn't have any concept of actual physical sizes - e.g. in iOS development, you'd define things in "points" which are not, in fact, typographic "points" as measured on the screen, but Apple's own concept of a density-independent pixel; same for Android dp and Windows' "effective pixel".

Has any other use-case been brought up?

One use case I could imagine - though quite niche - may be creating some sort of accurate digital ruler? (and i see now that the previous comment actually mentioned a ruler, oops)

[Crissov]

Another use case: a web shop or documentation site wants to scale an image of a physical object to show its actual or accurately scaled size, e. g. PNG has a pHYs chunk type to help with that.

[frivoal]

For the use case of touch targets, what is wrong with using something like

Probably the fact that cm, mm etc are anchored on the ideal CSS pixel, rather than on an actual physical size

I know the styles I provided wouldn't actually result in accurate physical centimeters. That wasn't the point of it. However, for the purpose of providing touch targets, would they actually fail to work? Within the range of devices you actually want to use touch for, it seems to me that the variation would fall within the acceptable range (possibly starting from something else than 1cm, if you think that's overall too small), and even be correlated with slightly smaller targets hand hand-held devices vs slightly larger targets on arms-length devices, which seems like a good thing, since arms-length manipulation is less precise.

Sure, 1cm would actually look like 15 actual centimeters on a wall projector, and like 1 actual millimeter on VR-glasses, but you're not using touch on these, so for the purpose of this use case, that's irrelevant.

[frivoal]

As for the use case of the ruler or of the physical object replica at scale, do people actually want to do that for the whole range of devices CSS can be used on, from a direct-to-retina VR screen to an cinema-screen sized projection?

[Crissov]

Matching actual size of physical objects might mostly apply to images, so could be handled by a dedicated image-… property similar to image-resolution, but authors would probably also want to adjust captions (indicating the scale factor) and descriptions with MQs. I find it reasonable to display an object like, say, a Lego figurine at 1:1 on a phone as well as on a TV, whereas smaller and larger canvases would get an automatically scaled version.

[nicksherman]

Matching actual size of physical objects might mostly apply to images

I'd have to disagree about this. Physical size can be just as important with text as with images. Two examples:

1. I've consulted with multiple law firms who are worried about following certain laws about how legal documents must be formatted, including very specific rules about the minimum physical size and proportions of type. These laws apply to both printed and digital web presentations of legal documents, but – as you might imagine – the web presentation is hard to guarantee without being able to address actual physical size.

2. There has recently been a discussion taking place about how to handle the “optical size” (opsz) axis for variable fonts on the web. The official OpenType specification explains that an optical size value of 12 should correspond to 12 points. This has caused some confusion though, because some people are equating the values to pixels instead of points, which aren't the same, even in the context of software “points” and “pixels”: 12pt equals 16px by default. The situation gets even more confusing when you consider that 12pt also does not equal 12 physical points. I'm not promoting the idea that 12pt should now change to actually equal 12 physical points, but as a typeface designer there are indeed times where I want my design variations to address issues related to physical size as well as relative/perceived size. For example, compensating for the effects of light halation is much different when the type is physically smaller, even if the perceived size might be the same.

[patrickhlauke]

i would love to see the laws that regulate minimum physical size of text as rendered on screen. for both 1 and 2 it sounds like cases where the actual nature of digital presentation, how it differs from physical presentation, and how devices and monitors come in all sorts of different sizes and dimensions (and often even the OS has no idea what the actual physical size of a monitor/display is), has not been properly taken into consideration.

[nigelmegitt]

tl;dr: there's a trade-off between functionality and privacy here, and it's likely that we have "good enough" functionality already, for the majority of use cases, not to diminish the importance of those possibly minority use cases where better functionality is needed.

---

In case this helps, here's a real world story where the lack of physical units has made implementation more difficult and the user experience less than ideal:

I helped design some user research about how big subtitle text should be on different devices, with varying distance from eye to screen, and varying screen sizes (given that subtitle text size is generally proportional to video height), and presented it at CSUN (slides).

I hypothesised that there would be a typical preferred size measured by angle subtended from the eye, and while that was broadly the case, there were some exceptions for which we still have no explanation (see slide 3.5.

In order to do that we measured typical distance between eye and screen by the participants in the research (see slide 3.6).

One of the problems we had when implementing a text size customisation tool was lack of knowledge of the physical screen size; instead we had to use a heuristic/proxy measure based on the number of available pixels (which can be checked with a media query) and then, to restrict the number of code paths, divided that into "break points" and set the font size by break point.

In the end we had gone from a table of (several) best choice values for each of 6 different devices to a total of 5 compromise values that sort-of meet user needs but are very likely not quite as good as they could be. If we could set physical sizes, we would have less need to compromise the user experience.

However another thing we could likely do, which might not be so desirable for the world at large, is fingerprint the device to discover its actual screen size. At this point I feel the trade-off between functionality and privacy is more of an _ethical_ question than anything else - the heuristic solution we found is not ideal, but it is certainly good enough for the vast majority of cases, and nobody has ever complained that the text should be a couple of pixels bigger or smaller on their particular screen.

[patrickhlauke]

the scenario around subtitle text size is an interesting one, but i'm wondering: how would being able to define things in CSS using real-world, as measured on screen, dimensions help you here? you still wouldn't know what the dimensions of the actual device's display are (unless you could query THAT as well, and you mean media queries could be written against that), and what kind of device it is (is it a small screen, but held close to the user's face, or a giant screen, but seen from many metres away?). so being able to define "this text should be at least Xcm tall", even combined with a media query that lets you query the actual physical dimensions of the display (if the browser and OS even know this, which is not necessarily the case), will still not give you information about the viewing distance, so you're still then left to guessing?

also wondering if it would make more sense to use units like vh/vw here, and use the initial value you set as the starting size, then allow users to scale the text size up/down based on THAT initial value, rather than defining a set of sizes first, and then trying to determine what the best size that should be preselected is? seems, to an extent, to put the cart before the horse...

[nigelmegitt]

We can get data to broadly categorise the device type, so we know if we have a mobile phone, a tablet, a laptop or a TV for example, and the viewing distances for each are broadly consistent, discovered by user research rather than a direct measurement at playback time. Obviously there are outliers in terms of people holding devices at different distances, but then that's why we have size customisation options.

Using something like vh/vw units is essentially what we already do: that's how the subtitle text height is proportional to the video height. The point here is that it's not necessarily the best way to do it, and that actual sizes could be better.

We might be able to mediate between authoring constraints and display constraints to avoid text being too big by doing something like font-size: min(12.5vh, 1cm); for example.

[patrickhlauke]

The point here is that it's not necessarily the best way to do it, and that actual sizes could be better

but only if you can reliably know the viewing distance, which you can't, so it's still up for guessing/guesstimating?

[nicksherman]

@patrickhlauke I would much rather guesstimate the viewing distance based on the physical size of a screen than on the number of virtual pixels it uses.

[tabatkins]

If we could set physical sizes, we would have less need to compromise the user experience.

When screens use the hardware pixel as their reference, they have to choose their px size to approximate that of the "physical" px, 1/96 of an inch. As such, they'll only be off from true by at worst 1/3. (If the screen is 144dpi, you either use 1 pixel = 1px and are 2/3 the size you should be, or use 2 pixel = 1px and are 3/2 larger than you should be. This is the absolute worst dpi possible for this purpose; everything else gives you a closer match.)

Assuming screens could reliably get their true physical size, how much would doing an exact physical size help you vs an approximate physical size that has this as its maximum error?

[nigelmegitt]

they'll only be off from true by at worst 1/3

I'm not sure if I understand this correctly: I consider a range of 0.67x to 1.5x the desired size to be a very large range: certainly it would make a huge difference to the size of subtitle text, and is the same order of magnitude as the variation that the text size customisation allows for.

[faceless2]

Bit late to this. I can't speak for screen output at all, but if you specify units of 1in, 96px or 72pt in the CSS, that is absolutely the length that can - and should - be written to any product creating PDF or PostScript output from CSS.

That is exactly what happens with all CSS to PDF products. It's not always the case when printing from browsers, but that's an implementation - not a spec - issue, as is any scaling introduced by the print dialog that means an inch in PDF is not an inch on the page.

But I do need to take issue with this:

print media is already supposed to anchor on physical sizes. the spec has been saying that for ages.

We initially anchored our CSS-to-PDF engine on points, which worked fine until we came to implement css-transforms. The matrix() transform is unitless, but the translate components have to be treated as pixels. So even as a print-based implementation, we found it simpler to work from pixels. They are defined to be 96 pixels per inch, so are as much as of a physical size as points or cm.

[patrickhlauke]

would we agree that the only way in which this could be implemented and actually bring any benefits is if we could guarantee that the browser knows for sure what the actual physical dimensions of the display are? and if so, is that information reliably available at the browser/OS level?

[trusktr]

Qt is awesome, they give native developers as much info as they can about the screen in the QScreen class.

Why are we so hesitant to make the web as awesome?

Is it that hard to expose EDID information (whether by CSS units or in JS APIs), or similar, to end devs, when that info is available?

[patrickhlauke]

Until browsers DO know and expose that information (about the actual physical size of the current display), if it's even available everywhere, it's all quite theoretical...

[trusktr]

I removed part of my above comment and re-worded it below to be less particular about certain people, which wasn't my intention:

imagine something like a TV or digital billboard, and an authors (naively perhaps) sets something to be at a particular size in cm ... IF the device respected that as meaning actual physical size as measured on the screen, you'd end up with something impossibly small to see.

Let's avoid downplaying web developers' abilities to use physical screen size properly (not naively). Let's rather provide tools that people can use well for great purposes.

At the moment units like cm are confusing and useless in my humble opinion.

[k3a]

I think it is actually the only proper way to design layouts - using physical units (also see this blog post). What we currently have is a total mess - websites display differently on screens with different densities and sizes and it doesn't make sense at all. Sometimes header fonts are so big that they fill more than half of device screen height on smartphones! Hard-coded density of 96dpi is ridiculous, having now smartphones with 760 ppi on the market. Then some people do @2x and @3x srcset image versions as cheap workarounds.

I think website layouts should be designed for various physical sizes (not pixels, not relative vw or 96pixel inches). For example: small smartphones (<5"), medium (7" small tablet), large (10" tablet), desktop (20"), x-large (40" large monitor, TV etc).

Then browser would choose the one fitting fully into the physical display size, leaving space around or stretching layout to fit. Image assets should be selected so that they match or exceed pixel density of the display. Nowadays I often see that if the magic "retina" scaling factor is not integer (1.5, 1.6), the browser picks the lower-resolution images (e.g. 1.0x "non-retina" scale) and just make them blurry by stretching them. It doesn't make sense.

Additionally, there should be one more "variable" and that is user scale. If someone wanted to display a website on a big 8000 inch movie canvas located 100 yards from the viewer, user could apply 200x "scale" which would simply act as a magnifying glass in the real world. This is all what that magical OS-level or browser-level "scaling" should do.

Display technologies are so great nowadays, yet websites sometimes look awful due to lack of physical units and bad management of raster images, which is sad. :(

Someone has to start that. After there is a spec for physical units, browsers will demand DPI info from the OS, vendors sill start putting proper EDID records to monitors, etc.

[patrickhlauke]

What we currently have is a total mess - websites display differently on screens with different densities and sizes

the whole aspect of densities seems...incorrect to me? for screen media, everything is anchored on the CSS pixel, and CSS pixels are density-independent.

laters parts of this comment seem to focus on the handling of raster images, which is a completely separate discussion to this one.

[KMNTJ]

I want true physical device dimensions because I do not want these. https://en.wikipedia.org/wiki/Imperial_units#/media/File:English_Length_Units_Graph.svg

I will let the device manufacturing engineers come up with as many combinations of pixels on width and height or dots per inch. But when I am designing for human interaction, be it either visual inspection or physical interaction I would _absolutely prefer_ to know the actual physical size of the device screen so that I can design the proportions of the elements I intend to have displayed.

I read through most of this and very much agreed with what @nicksherman was saying.

[tabatkins]

Hard-coded density of 96dpi is ridiculous, having now smartphones with 760 ppi on the market.

The first and second parts of this sentence aren't connected.

Yes, 96px == 1in. But 1px is not necessarily related to the hardware pixels on the screen. 1px is defined as a particular visual angle at a particular distance; this definition matched "96 hardware pixels per physical inch" on some historical screens, but as you say, these days screens can have a wide range of vastly higher pixel densities, and so 1px can map to any reasonable number of hardware pixels, even fractional numbers of them (which is true on most mobile devices these days).

This means that 1in will be approximately 1 inch, but it can vary by a fair % based on exactly how the UA maps to its hardware pixels.

[spawnia]

We currently have a use-case for this. Our web app is used in a laboratory working environment. One of our workflows requires pipetting small amounts of a reagent onto a glass slide. The exact placement is paramount, so we show a template that indicates the points where the reagent has to be pipetted upon. In order for that to work, we need to have the template on the screen match the physical slide 1:1.

I do realize the difficulties in achieving a generalized solution. There are acceptable workarounds for our specific use case, we have a limited range of devices to support. However, those might not work for every user.

[tabatkins]

For cases like that, the correct solution is to have a locally-stored scaling factor that you then use when computing lengths for display on that machine, calibrated from actually holding up the template to the screen.

Adding "true physical" units doesn't help here, because there's still no guarantee that the data we get from the OS about the screen's size is physically accurate; even if it's close that doesn't help your use-case that needs exactness.

[nicksherman]

Adding "true physical" units doesn't help here, because there's still no guarantee that the data we get from the OS about the screen's size is physically accurate

This is a defeatist attitude toward a chicken and egg situation. Hardware and software makers will have much lower motivation to provide accurate data if there is no standard around which to utilize that data.

I agree that it will require time for support to build (perhaps even more time than most features), but that doesn’t mean the idea should just be abandoned. If any new feature was dismissed because it wouldn’t have proper support right away, we would never have any new features.

As I mentioned in an earlier comment:

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?

[frivoal]

We currently have a use-case for this. Our web app is used in a laboratory working environment. One of our workflows requires pipetting small amounts of a reagent onto a glass slide. The exact placement is paramount, so we show a template that indicates the points where the reagent has to be pipetted upon. In order for that to work, we need to have the template on the screen match the physical slide 1:1.

I don't see how this use case would be helped by introducing units that are guaranteed to be the same size as physical measurements regardless of the device it's being run on. You show the template on a particular screen, and for that screen, it needs to be right. You don't need the same website to have the exact same physical measurements if it is displayed on a watch, a phone, a wall projector, or virtual reality goggles, all while ensuring that the px unit does scale according to those environment. That's what a physical unit independent of the device would give you: a responsive px unit that changes based on viewing distance AND physical measurements that stay the same in any environments.

CSS already has a cm unit (and other physical units), and it is ratio is fixed with the px unit. But User Agents have leeway in terms of what they anchor these units to. Given your use case, your setup should anchor the absolute length units on the physical ones, and let everything fall from there. And if it is displayed on a watch the template will be scaled down, on a wall projector it will be scaled up, and that's ok: you're not doing your lab work on a watch or on the wall.

[spawnia]

You don't need the same website to have the exact same physical measurements if it is displayed on a watch, a phone, a wall projector, or virtual reality goggles [...]

The examples you give are extreme cases, in our case we are dealing with varying sizes of tablets. We need some elements that are part of the website to be consistently sized across those tablets. If that makes the site unusable on a smart watch or a wall projector, that is totally fine. It does not have to work there.

That's what a physical unit independent of the device would give you: a responsive px unit that changes based on viewing distance AND physical measurements that stay the same in any environments.

I am not sure i quite follow what you are saying here, maybe we are talking about different things here. For what we are trying to do, we do not care about viewing distance, consistent layout or being compatible with every device there is. We just need an element to line up 1-1 with a physical object on any screen it is viewed.

The way the current "physical" units are anchored to pixels is exactly the culprit of this issue. We are not going to write our own rendering engine to set a different anchor.

[faceless2]

It does not have to work there.

It may not have to work there for you, but if you're going to add a universal concept to CSS then it has to work _everywhere_, otherwise you've made the situation worse: a "physical pixel unit" that claims to be correct, but isn't on some media. Measuring a pipette against a scale claiming a false sense of accuracy is a good illustration of why this matters.

For anyone that considers this "defeatist", please detail a solution for when:

• you've mirrored your screen onto two different size monitors
• you're using a projector
• you've used the buttons on your LCD monitor to stretch the image to fit (adjustments which are not relayed to the OS)

No solution exists in these cases.

That said, there is a solution for a limited number of cases - specifically, tablets or phones where the hardware is fixed and the screen is not being mirrored. I could see a case for env(device-pixel-resolution) here, which resolves to 0 if unknown or indeterminate, but (for example) "326dpi" on an iPhone 11. This could be used in both media queries and calc() expressions - for example something like width: calc(1px * (1dppx / env(device-pixel-resolution))) would give you a hairline of 1 device pixel. If the resolution was indeterminate it would give you an infinite width, which would - I imagine - encourage authors to wrap their declarations in a suitable media query!

That's not a general "physical pixel unit", but it covers a lot of the same cases while shifting the responsibility of ensuring it's valid to the author - where it needs to be.

[spawnia]

It may not have to work there for you, but if you're going to add a universal concept to CSS then it has to work everywhere

Agree that the concept should be universal. The physical size for a smart watch could be reported correctly and the content can scale accordingly. It would work in that sense.

What i meant is that it would not be usable, since the screen of the smart watch is physically too small. I think the fact that using physical sizes will not produce sensible results on every possible device should not prohibit the introduction or use of such a feature, where it makes sense.

using a projector

I guess the projector could report some kind of default to the OS, possibly adapting dynamically to some value measured during auto-focus?

Sure, CSS can not magically solve cases where the display is modified in ways that are not detectable in the OS. Some OS's might not relay that kind of information at all. I like your suggestion of introducing an API that forces handling the case were the physical pixel size can not be determined.

[patrickhlauke]

this discussion seems to go around in circles at various points, but i think the most salient one is:

• IF operating systems could correctly identify, in all situations, the physical dimensions of their displays/the exact actual DPI (and this still assumes that users themselves haven't messed around in the monitor settings with things like setting their own stretching/geometry etc, which isn't a given)
• THEN browsers could access this information and use it to calculate/apply real-world physical measurements

I believe the biggest blocker is the first step, and not necessarily browsers being unwilling to do it. And the thing is: unless there's a guarantee that for the first step the OS will always report the absolutely exact measurement/real-world DPI it has (down to the highest possible level of accuracy, not just rounded/guesstimated), this will be utterly pointless to implement.

but even assuming that this does work out, the best way to implement this may well be that on those correct platforms that do provide rock-solid monitor/display metrics for the browser to use, the UA could decide to anchor to the physical size, rather than the CSS px size? this way, the various measures like cm, mm etc already in CSS can still be used exactly the same way. on browsers/platforms where the right physical measures are conveyed, browsers would render 1cm as an exact centimetre as measured on screen. on other platforms, they would do the same as they currently do. it would then be up to users who have use cases where they want to use their screen as an accurate template/measure to make sure they're using a correctly calibrated and supported environment/display.

[patrickhlauke]

and additionally i'll note that that first step (about OS being able to accurately know the precise physical dimensions/real dpi - maybe even taking into account user settings for stretch etc on the display itself) will be down to OS developers and most crucially display manufacturers. even if in this WG here it's decided that yes, that's what OSs and displays should do...it's then the job to convince those entities to play along...that'll be the harder sell to achieve some form of support.

[patrickhlauke]

last thought: if you are making a web-based application that is then intended to be used as a real-world measuring reference, you should probably consider (in future, IF all the above actually miraculously went through, still as a fallback) also adding an extra calibration screen/setting in the app, so users can adjust a web-app-specific scaling factor by comparing their actual display against a known good real-world measure/object/ruler. and, depending on how critical the accuracy is, that calibration should be done frequently (similar to color calibration of monitors)

[Crissov]

On screens, authors always want and expect 1px to be an integer¹ number of device pixels. Even if the device, OS and browser know the screenʼs exact dimensions and thus its resolution (or rather _granularity_), we could still not anchor mm, in etc. on this physical-world measure, because the 4:3 pixel to point ratio has been made sacrosanct years ago (decades by now, actually), i.e. they must not be decoupled.

Anyway, an environment variable might solve most use cases indeed.
Alas, calc(1px * (1dppx / env(device-pixel-resolution))) does not seem very elegant. Iʼd want it to be a <number>, which can be used verbatim as a multiplier or divisor with a <length>, e.g. calc(5mm * env(foo-ratio, 1)). It might also need to come in horizontal and vertical variants, because not all pixels are square.

¹ This should have been ''integer or simple fractional number of device pixels''. As of mid-2020, popular integer factors are 4, 3, 2 and 1, while fractions like 3½, 2⅗, 2½, 2⅖ and 1½ also occur, rarely 2¾, 1⅘, 1⅖ and 1⅜ as well. The most common viewport sizes are:

| Minor | > 1.8 | 16:9 | 5:3 | 8:5 | 3:2 | 4:3 | Type |
| ----- | ----- | ---- | --- | --- | --- | --- | ---- |
| 320px | | 568px | 533px | | 480px | | phone |
| 360px | 740px, 718px | 640px | 600px, 598px | | | 480px | phone |
| 375px | 812px | 667px | | | | | phone |
| 384px | | | 640px | | | | phone |
| 400px | | | | 640px | | | phone |
| 411px, 412px, 414px | | 731px, 736px | 690px | | | | phone |
| 432px | | 768px | | | | | phone |
| 480px | | | 800px | | | | tablet |
| 600px, 604px | | | (1024px) | 960px, 966px | | | tablet |
| 720px | | 1280px | | | | | tablet |
| 768px | | 1366px | | | | 1024px | tablet |
| 800px | | | | 1280px | | | tablet |
| 1024px | | | | 1280px | | 1366px | tablet |

[tabatkins]

On screens, authors always want and expect 1px to be an integer number of device pixels.

Well, they don't get that today on a lot of phones, which conform to a small set of unofficial standard "mobile viewport" sizes (320px, 360px, 375px, 412px, 414px, 480px), but with a wide variety of actual pixel sizes which are often not an integer multiple of those numbers. ^_^

but even assuming that this does work out, the best way to implement this may well be that on those correct platforms that do provide rock-solid monitor/display metrics for the browser to use, the UA could decide to anchor to the physical size, rather than the CSS px size?

This is allowed by the spec currently, yes. The only requirement is that 96px must equal exactly 1in (and the other physical units have their standard ratios with the inch), and that either 1px has approximately the specified size as an arc measurement (aka a length that varies based on expected viewing distance) or that the other physical units have their correct value, as accurately as you can achieve.

[patrickhlauke]

On screens, authors always want and expect 1px to be an integer number of device pixels

adding to this that it may be true on low-dpi devices, but that on modern (loathe to use the word "retina", "hyperretina", or whatever the latest marketing word is) displays, the concept of the device pixel is more or less irrelevant (as you don't get the horridly obvious sub-pixel rendering issues prevalent on low-dpi displays when the ratio of CSS pixel to actual device pixel wasn't an integer)

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