search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.46k stars 658 forks source link

[css-env] Device Pixel Ratio #5986

Open Crissov opened 3 years ago

Crissov commented 3 years ago

As a result of #614, please add environment variables:

This is a <number> constant, which can be used verbatim as a multiplier or divisor with a <length>, e.g. calc(1mm * env(device-pixel-ratio, 1)), to get from nominal, CSS millimeters to actual, SI millimeters etc.

On media and devices where px depends on physical units and not the other way around (as on screens), this should always be set to 1.0. Elsewhere, it should not deviate a lot from this.

I included horizontal and vertical variants, because not all pixels are square.

tabatkins commented 3 years ago

d-p-r, as the term is currently used, is not about the ratio of px to physical sizes, but rather the ratio of CSS px to device pixels.

As I just laid out in a new FAQ entry, having user agents provide real-world lengths is a failed experiment that we're not interested in trying again.

As a side note, pixels are always square enough on the web that lengths are identical in both dimensions; a 100px by 100px square is always square.

Crissov commented 3 years ago

The Workaround section in that FAQ entry uses a custom --unit-scale property. This issue is asking to provide the same thing with some standardized name and a sound default value where available. Browsers or OSs could offer a system-wide calibration to their users, so authors would not have to provide a site-specific one.

Authors, who believe they could increase reliability with calibration done by their users, could still do it, but with better fallback: var(--unit-scale, env(unit-scale, 1)).

The separate horizontal and vertical values are less important, perhaps unnecessary indeed.

tabatkins commented 3 years ago

As I explain in the FAQ, getting accurate values for this out of arbitrary display devices is, as far as I know, a failed experiment.

This is one of those cases where worse is better - giving authors a way to sometimes get a value that is correct (but othertimes is still slightly or extremely wrong) is worse than just telling them to calibrate when they need accurate answers, because it suggests that the scale value is something worthwhile when actually it's sole use is as a hopefully better fallback value than 1.

Crissov commented 3 years ago

For arbitrary display devices, this may well be a failed experiment. However, for mobile devices that integrate a touchscreen, i.e. phones, watches and tablets, the system usually knows such physical dimensions and may expose them to native apps, e.g. rulers. I believe that PWAs should be able to do something equivalent, and not just in JS.

Crissov commented 3 years ago

JFTR, env(unit-scale-physical) has been suggested in the original issue.