W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2019

Re: [csswg-drafts] [css-values] Ability to address actual physical size (#614)

From: Patrick H. Lauke via GitHub <sysbot+gh@w3.org>
Date: Sat, 12 Oct 2019 08:34:06 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-541301682-1570869245-sysbot+gh@w3.org>
> For the use case of touch targets, what is wrong with using something like

Probably the fact that `cm`, `mm` etc are anchored on the ideal CSS pixel, rather than on an actual physical size. But this has always been a problem from the start, since user agents don't necessarily have all the correct information about the actual device's physical screen dimensions to the make an accurate translation of what a `cm` etc would actually be, in device pixels. And, even if they could, this would then lead to weird problems for devices that have a nominally large screen, but are generally viewed/operated at a distance - imagine something like a TV or digital billboard, and an authors (naively perhaps) sets something to be at a particular size in `cm` ... IF the device respected that as meaning actual physical size as measured on the screen, you'd end up with something impossibly small to see.

Beyond web content, native app development also doesn't have any concept of actual physical sizes 
 - e.g. in iOS development, you'd define things in "points" which are not, in fact, typographic "points" as measured on the screen, but Apple's own concept of a density-independent pixel; same for Android `dp` and Windows' "[effective pixel]{https://docs.microsoft.com/en-us/windows/uwp/design/basics/design-and-ui-intro}". 

> Has any other use-case been brought up?

One use case I could imagine - though quite niche - may be creating some sort of accurate digital ruler?

-- 
GitHub Notification of comment by patrickhlauke
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/614#issuecomment-541301682 using your GitHub account
Received on Saturday, 12 October 2019 08:34:08 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:54 UTC