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

Re: [csswg-drafts] [css-values] Ability to address actual physical size

From: Nick Sherman via GitHub <sysbot+gh@w3.org>
Date: Tue, 18 Oct 2016 16:59:01 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-254571480-1476809939-sysbot+gh@w3.org>
@frivoal See responses to specific comments below …

> the current definitions are not merely an accident of history, they 
are intentional.

The current definitions are not the original intention of the spec. As
 the spec itself 
“Note that this definition of the pixel unit and the physical units 
differs from previous versions of CSS. In particular, in previous 
versions of CSS the pixel unit and the physical units were not related
 by a fixed ratio: the physical units were always tied to their 
physical measurements while the pixel unit would vary to most closely 
match the reference pixel. (This change was made because too much 
existing content relies on the assumption of 96dpi, and breaking that 
assumption breaks the content.)”

> If you are printing, there is no clear concept of what a px is

Like screens, printers also have physical resolution and an equivalent
 of a physical pixel unit (they are just much smaller than most screen
 pixels, and unrelated to the current concept of a CSS pixel).

> On screens though, the px is defined to be (an approximation of) an 
angular measurement. The article you linked to is brushing that aside,
 but that does it a great disservice

The angular measurement ascribed to `px` in the spec (0.0213 degrees) 
is fairly arbitrary, a backwards-justification from the previous 
definition of `px` in order to maintain some kind of logic and support
 older designs. If the original plan was to include angular 
measurements in the spec, they would have chosen a more logical unit 
like degrees or arcminutes.

I am a huge proponent of the ability to address size in relation to 
perception and angle of vision, but the concept is not mutually 
exclusive to the ability to address physical size either.

> small or large is mostly not a question of physical size, but rather
 a question of the percentage of the field of vision, which combines 
physical size and viewing distance.

I am very aware of this. See my [Size 
Calculator](https://sizecalc.com) project which is intended for 
calculating these relationships.

> You mention low sighted readers as an example of why you need to 
know how large something physically is, but that wouldn't not work. 
Making each letter 2cm tall, which would seem gigantic if you're 
thinking of text on a phone, would result in small and unreadable text
 when seen on the projector of a large conference room.

One of the biggest values of addressing physical size is not in 
specifying how large something is rendered but in **knowing the size 
of a display** on which it is rendered. If I know the physical size of
 a display, I have a MUCH better idea of how far away the viewer will 
be from it than I would from a relatively arbitrary pixel count.

> Another argument against absolute physical measurements is that they
 would mess with zooming. With the way things are currently defined, 
when the user zooms in, everything gets larger. If we respect that, 
the absolute physical units would no longer by absolute and physical, 
and we're back to square 1.

Zooming for physical units could easily work the same as any other 
units. Zooming a 1-inch element to 200% would make it 2 inches.

But you're also incorrectly assuming that I'm only talking about 
screen-based media, and that I think the size of most elements should 
be spec'd in physical units. In fact, I'd say fixed physical sizes 
wouldn’t make sense for many things. But that doesn't mean they 
shouldn't be an option for the times when they do make sense.

> Yet another argument is that the browsers are not typically aware of
 the physical measurements of the display.

Again, you are assuming I'm only talking about screen-based media. And
 even if some software environments don't currently access physical 
display info from the device, that isn’t a reason that none of them 
ever should. Windows 10 is already providing access to physical 
measurements for native apps via the [RawDpi 
 Why shouldn’t websites be able to leverage the same info?

Perhaps these comments are all beside the point though. If nothing 
else, **the ability to address physical size is fundamental to using 
CSS for any fixed media** like print. If designers can’t render an 
element at a specific physical size on a piece of paper, the whole 
notion of CSS being a truly universal language for presenting a 
document in a variety of media (including print) is moot.

GitHub Notification of comment by nicksherman
Please view or discuss this issue at 
using your GitHub account
Received on Tuesday, 18 October 2016 16:59:09 UTC

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