- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Sun, 05 Mar 2023 20:20:35 +0000
- To: public-css-archive@w3.org
[The spec is very clear](https://w3c.github.io/csswg-drafts/css-values/#absolute-lengths) that all the absolute length units (`in`, `mm`, `px`, etc) are simple linear multiples of each other - `1in` is always `96px`, ~`25.4mm`, etc. The UA chooses what length one of them is, and the rest fall out by scaling. On browsers, it's common for the `px` unit to be tied to an integer number of device pixels, at least by default (this is noted in the spec) but UAs are allowed to do anything else they want, such as anchoring `1in` to an actual inch. A browser is thus *allowed*, but not *required*, to do things like correctly sizing the physical units at 100% zoom when printing. This used to not be the case - the real-world units were all coupled together, but the px unit wasn't necessarily so. This broke websites, because people used mixtures of px and other units (especially `pt`, which is 1/72 of an inch) and didn't anticipate the sizes scaling differently under zoom. So everyone converged on px just being a physical unit that was exactly 1/96 of an inch. Targets being larger or smaller under zoom is very much intentional - that's the entire point of zooming, after all. Some browsers used to have a "text only" zoom that scaled font sizes but didn't change the viewport size, but that's faded from mainstream browsers, again because it reliably breaks pages. This means there are some use-cases that can't be addressed without manual intervention from the page, but that's unfortunately the result of many years of compat pain. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8525#issuecomment-1455194296 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 5 March 2023 20:20:37 UTC