- From: Nick Sherman via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Oct 2016 16:59:01 +0000
- To: public-css-archive@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 [explains](https://www.w3.org/TR/CSS21/syndata.html#length-units): “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 property](https://msdn.microsoft.com/en-us/library/windows/apps/windows.graphics.display.displayinformation.rawdpiy.aspx). 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 https://github.com/w3c/csswg-drafts/issues/614#issuecomment-254571480 using your GitHub account
Received on Tuesday, 18 October 2016 16:59:09 UTC