[Webkit-unassigned] [Bug 247980] WebKitGTK seems confused about size of 1px on 283 dpi display
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed May 15 12:10:25 PDT 2024
https://bugs.webkit.org/show_bug.cgi?id=247980
--- Comment #29 from Glen Whitney <gwhitneycom5 at pobox.com> ---
OK, after looking Philippe Normand's setup and Michael Catanzaro's comments, I am going to try to implement the other recommended standards-compliant definition of the "1px" unit: "the pixel unit refer to the whole number of device pixels that best approximates the reference pixel", where the reference pixel subtends .0213 degrees at the typical viewing distance. I will assume that mobile viewing distance is half that of desktop/laptop viewing distance, and I will assume the latter viewing distances are the same and are equivalent to the "standard" viewing distance at which the reference pixel is 1/96th of an inch. But there are still three unspecified aspects of implementing this standard that I would really appreciate input/guidance on:
1) How to decide what integer multiple "best approximates"? In Philippe's setup, 1.497 pixels would match the reference pixel, and based on his comments, a choice of a multiplier of 1 would match his expectations and apparent Chrome behavior. So I could try straight rounding to the nearest integer, 1.497 is just small enough to round to 1. Or if people think that actually we want a bias toward rounding the multiplier down to match historic behavior in more cases, I could map 0-1.6 to 1 (say), 1.6+ to 2.6 to 2, 2.6+ to 3.6 to 3, etc. Thoughts?
2) How to decide mobile? Michael recommends basing it on screen size, which makes sense. But what width cutoff should I use? 200 mm (a little under 8 inches, to get cellphones in landscape orientation)?
3) Finally, what about tablets? Should there be a size range considered "tablet" between "mobile" and "ordinary screen", and if so, what should be used as the expected viewing distance for a screen in this tablet range?
Thanks for your input; I will be happy to open a new PR for this issue, which should have far less in the way of side effects, once reasonable answers to these three items are settled on.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240515/20218040/attachment.htm>
More information about the webkit-unassigned
mailing list