[brainwad]

Maybe it's better to say that browsers just take what the OS tells them, rather than actually deriving a device pixel ratio from first principles according to the CSS spec. Because, yeah, there's some weird devices with DPRs like 2.625, though _most_ are multiples of 0.25: https://yesviz.com/viewport/. But note how the same DPR can give a varying CSS PPI, which makes using it useless for this purpose.

[chrismorgan]

“Taking whatever the OS tells them” is rather different!

It also gets multiplied by the browser’s zoom, which in both Firefox and Chrome include values like 80%, 90% and 110%.

So for me on HN at 120% on my 1.5× laptop display, devicePixelRatio is… 1.8181818181818181. Huh. Wonder why it’s not 1.8. ¯\_(ツ)_/¯

[brainwad]

1.8 probably would produce a non-integer number of CSS pixels. The browser needs (wants?) to pick a number that divides both the width and height without remainders. For 1920x1080, 1.8 doesn't (works for the height, but not the width) but 1.8̅1̅ does.

[chrismorgan]

Although that has a plausible sound, I don’t think it’s it: the window size is what matters, not the screen size, and you can’t guarantee any sort of divisibility for either anyway. For example, my screen is actually 2560×1440, which is 1706⅔×960 in CSS pixels given the real devicePixelRatio of 1.5. The established rule when you need an integer is, at least on Wayland, to round things down to the nearest integer; I’m not certain about other platforms. Certainly everything that deals in integer pixels sees 1706×960.

Chromium doesn’t exhibit this behaviour; it’s just Firefox on some of its zoom levels. And when I saw 90% being 0.9090909090909091 (90⁄99 instead of 90⁄100) it triggered a memory of observing this five or seven years ago on my Surface Book (3000×2000 @ 2×). I think it is just that they’ve chosen to display different, slightly inaccurate percentage labels.