① Its display dimension and screen diagonal figures are just a figment, due to a fundamental error in understanding of CSS units. It works by measuring how many pixels a div that’s been given style `width:1em;height:1em` takes—trouble is, that has always given you and will always give you the answer 96, because CSS units don’t correspond to physical units. (Firefox tried doing that long ago with the mozmm unit, but it became apparent that there’s almost no legitimate use for it, and it can’t actually be known on most devices anyway, so browser makers gave up on the idea.) So in practice, it’s just assuming 96dpi times the device pixel ratio.

② If your device pixel ratio is anything but one (e.g. high-DPI, or if you zoom in or out and then reload the page), the display dimension and screen diagonal figures are even more wrong, because it divides screen dimensions (which are in CSS pixels) by DPI (which it has calculated in device pixels).

③ It makes an assumption about the device pixel ratio that simply isn’t valid: it may not actually correspond to the number of physical pixels. The example I’m most familiar with is how Firefox under Wayland doesn’t implement fractional scaling¹, but instead renders at the next integer up and downsamples. My laptop is 2560×1440 run at 1.5× scaling; it detects it as 3412×1920 at 2×. The browser simply doesn’t expose what you need to be certain about these sorts of things. And Chromium under XWayland is saying 1706×960 with device pixel ratio 1, because Chromium itself isn’t even aware of the proper size. (XWayland is running at 1× scaling and upsampling to 1.5×; I used to run the sway/wlroots/xwayland hidpi patches and run it at 3× and downsample to 1.5×, but stopped at some point because it was too much bother and there had been some change in the software.)

④ It assumes screen.colorDepth is telling the truth (which it may well not be; on my device it’s 32 when I believe it should be 24). (It also shows both colour depth and pixel depth, even though they’re the same thing, only both present for “compatibility reasons” per the spec.)

—⁂—

¹ There’s actually been an experimental implementation for almost three years <https://bugzilla.mozilla.org/show_bug.cgi?id=1707209>, but when I tried it back then I decided regretfully (the text rendering was beautifully crisp!) that it was unusable for a couple of reasons. Gonna switch back to sway-git and try it out again now, and they should actually care about bug reports now since the fractional-scale-v1 Wayland protocol has happened, whereas last time it was deemed too early for bug reports.

I know it’s because Safari lies for the sake of compatibility, but I thought there was an escape-hatch API or CSS trick to get real details?

Device inner Resolution: 1080 x 2105

DPR(Device Pixel Ratio): 1.7647058823529411

Display Dimensions: (width x height): 3.6" (9.2 cm) x 8.0" (20.4 cm)

Screen Diagonal: 8.8" (22.4 cm)

Color Depth (bits per pixel): 24

Pixel Depth: 24

Display Aspect Ratio: 0.45:1

Your Resolution Is: not a widescreen

Browser Viewport: 612 x 1193

Not very impressive, considering I'm portrait fullscreen on a Pixel 6. (Firefox for Android 121.0.1)

   <script>
      document.write('<b>Screen: </b>'+screen.width+' x '+screen.height);
   </script>

> Your Screen Resolution is 1440 x 810

> Device Resolution: 1920 x 1080

Oooh, wait, I get it, it's because I have my default zoom set to ~130% for my shitty eyes.

I very much doubt that.