Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-values] Ability to address actual physical size #614

Closed
nicksherman opened this issue Oct 17, 2016 · 52 comments
Labels

Comments

@nicksherman
Copy link

@nicksherman nicksherman commented Oct 17, 2016

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 comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented Oct 18, 2016

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

This comment has been minimized.

Copy link
Collaborator

@SelenIT SelenIT commented Oct 18, 2016

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

@frivoal

This comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented Oct 18, 2016

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

This comment has been minimized.

Copy link
Author

@nicksherman nicksherman commented Oct 18, 2016

@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

This comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented Oct 19, 2016

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

This comment has been minimized.

Copy link
Member

@dbaron dbaron commented Oct 19, 2016

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

This comment has been minimized.

Copy link
Contributor

@Crissov Crissov commented Oct 19, 2016

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

@frivoal

This comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented Oct 20, 2016

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.625in1.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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Nov 14, 2016

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

This comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented Nov 15, 2016

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

@nicksherman

This comment has been minimized.

Copy link
Author

@nicksherman nicksherman commented Nov 15, 2016

@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

This comment has been minimized.

Copy link
Contributor

@Crissov Crissov commented Nov 15, 2016

Solve the use cases with media queries then?

@media physical {…}
@nicksherman

This comment has been minimized.

Copy link
Author

@nicksherman nicksherman commented Nov 15, 2016

@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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Nov 15, 2016

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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Nov 15, 2016

@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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Nov 15, 2016

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

cxtoucpxgaeo1l2

@nicksherman

This comment has been minimized.

Copy link
Author

@nicksherman nicksherman commented Nov 15, 2016

@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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Nov 15, 2016

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

This comment has been minimized.

Copy link
Author

@nicksherman nicksherman commented Nov 15, 2016

@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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Nov 15, 2016

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

This comment has been minimized.

Copy link
Author

@nicksherman nicksherman commented Nov 15, 2016

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

This comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented Nov 16, 2016

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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Nov 16, 2016

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

This comment has been minimized.

Copy link
Member

@tabatkins tabatkins commented Jun 21, 2018

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.

@tabatkins tabatkins closed this Jun 21, 2018
@nicksherman

This comment has been minimized.

Copy link
Author

@nicksherman nicksherman commented Jun 21, 2018

@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

This comment has been minimized.

Copy link

@jonjohnjohnson jonjohnjohnson commented Jun 21, 2018

@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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Jun 21, 2018

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 comment has been minimized.

Copy link

@BevansDesign BevansDesign commented Oct 10, 2019

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

This comment has been minimized.

Copy link
Member

@tabatkins tabatkins commented Oct 10, 2019

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

This comment has been minimized.

Copy link
Contributor

@Crissov Crissov commented Oct 11, 2019

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

This comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented Oct 11, 2019

  • 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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Oct 12, 2019

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

This comment has been minimized.

Copy link
Contributor

@Crissov Crissov commented Oct 12, 2019

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

This comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented Oct 14, 2019

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

This comment has been minimized.

Copy link
Collaborator

@frivoal frivoal commented Oct 14, 2019

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

This comment has been minimized.

Copy link
Contributor

@Crissov Crissov commented Oct 14, 2019

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

This comment has been minimized.

Copy link
Author

@nicksherman nicksherman commented Oct 14, 2019

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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Oct 14, 2019

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

This comment has been minimized.

Copy link

@nigelmegitt nigelmegitt commented Oct 15, 2019

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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@nigelmegitt nigelmegitt commented Oct 15, 2019

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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Oct 15, 2019

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

This comment has been minimized.

Copy link
Author

@nicksherman nicksherman commented Oct 15, 2019

@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

This comment has been minimized.

Copy link
Member

@tabatkins tabatkins commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@nigelmegitt nigelmegitt commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@faceless2 faceless2 commented Oct 17, 2019

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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Oct 18, 2019

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

This comment has been minimized.

Copy link

@trusktr trusktr commented Oct 31, 2019

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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Oct 31, 2019

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

This comment has been minimized.

Copy link

@trusktr trusktr commented Oct 31, 2019

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

This comment has been minimized.

Copy link

@k3a k3a commented Nov 7, 2019

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

This comment has been minimized.

Copy link
Member

@patrickhlauke patrickhlauke commented Nov 7, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.