- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Oct 2016 04:20:51 +0000
- To: public-css-archive@w3.org
This comes up fairly often, gets pushed back every time. Let me try to give you a little gist of why. As you said, it is two late to change the definitions of what `in` `cm` and `px` are without breaking everything, so compatibility alone is a sufficient argument for not changing them. You are right that we could introduce separate units with a different behavior, but the general consensus is that we should not, because the current definitions are not merely an accident of history, they are intentional. `in`, `px`, `cm` etc are defined in a fixed proportion of eachother. Depending on the media, we might use one or another to anchor the whole thing, and the rest falls out of that. If you are printing, there is no clear concept of what a `px` is, but it is easy to define an inch to be an inch, and the `px` just falls out as 1/96th of that. 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: if the pixel you're claiming is insufficient isn't the one defined in CSS, then it is difficult to make sense of the criticism. As you say, it matters to typography whether something is small or large. You want different font design and different typography based on that. But 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. The CSS pixel is often (but not always) rounded to a integer number of physical pixels by implementations, but it is fundamentally designed so that if you know the size of something in pixels, you know how big it looks. 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. The CSS pixel already accounts for that. So your pizza slice analogy doesn't work. To turn it around, 1 “CSS pizza slice“ is defined so that it is always equally filling, regardless what kind of topping it has, whether it has a thin Italian crust or is an inch thick deep-dish Chicago style one. Knowing the diameter of the pizza alone wouldn't give you a better results, and if you had all the parameters, you'd need to boil them down to the same result a we already gave you. Sometimes, you also want to know about the resolution in order to know if you can use a font with fine serifs or other small features, or if they are going to be all mashed up due to a lack of physical pixels. But what's relevant here is the density of pixels with regards to the size of the font. And since that is not in physical units, but in CSS units, the resolution media query does the right thing. 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. If we don't, we're preventing users from zooming, which is a terrible disservice to do. We could distinguish between page zoom and pinch zoom, but that wouldn't really solve the problem. Yet another argument is that the browsers are not typically aware of the physical measurements of the display. Sometimes they may be, but in the general case they are not. And without that information, they cannot know how to correctly display something at 3 physical inches. This is not merely a temporary limitation of current software: if you move a projector closer to or further away from the wall it is projecting on, you would need to change the relative size of things on the web page to preserve the absolute measurements. But even the OS or the graphical drivers have no idea how far the wall is. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/614#issuecomment-254403012 using your GitHub account
Received on Tuesday, 18 October 2016 04:21:00 UTC