- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Oct 2016 00:44:28 +0000
- To: public-css-archive@w3.org
> > the current definitions are not merely an accident of history, they are intentional. > The current definitions were not the original intention of the spec. and > 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. Ok, sure, there is of course some part of the current definition that can be explained by history. The fact that we use an angular measurement called pixel rather than degrees or arcminutes is certainly due to the fact that we started with a pixel unit. You are right, it initially did not have that behavior, and was simply a physical pixel. But as time went by, that definition was found to be problematic, and the newer system was used to redefine it. What is particularly useful about the angular definition of the pixel and other length units is that they enable robust designs. By that I mean that it enables authors to write a web page that works in environments they know about, **and be confident that it will do the right thing even in environments they haven't tested in or are not even aware of**. For instance, when then first iphone came out, it had small physical pixels, but since they were to be viewed from a close distance, it was still OK to have 1px to be 1 physical pixel. That meant that inches on the iphone were small, since they kept the 96 to 1 ratio. This in turn meant that sites that had not anticipated the iphone ended up working just fine. Further down, when retina iphones came out, pixels were now “too” small, so we got multiple device pixel per css pixel, inches stayed the same size, and again everything worked fine. And not everybody thinks of a projector or a nintendo wii when they design their site, but again, it just works. I am not claiming that there is no possible use for physical measurements. Authors are infinitely creative, so I am sure something could be made of them. On the other hand, I *am* sure that valid uses of physical measurements are many orders of magnitude more rare than the ones we have now. This gives a double challenge to people asking for physical measurements: 1. Make sure you design this ability to access physical measurements in such a way that it could not possibly confuse authors, and cause even a small fraction of them to use physical measurements when they should be using the system we have now. Otherwise, such confused authors will write sites that don't work well across devices, and make the overall web experience worse for end users. If one author in a million makes the mistake, it is probably fine, but if one in a hundred does and writes sites that don't adapt well to different environments due to this, we will have done more harm than good. 2. Since the use cases, even if real, are rare, convince web browser vendors that this is worth their while. They already have a long list of things they mean to get to, and currently none of them recognize this need as something relevant, this is going to be an uphill battle. With regards to (1), I would say that introducing new units that give access to physical distances would not be acceptable. There's just too much a chance that authors who haven't thought deeply about this would pick the physical ones instead of the angle based ones, and make brittle designs because of that. So if this is to be exposed, it has to be some other way. As for (2), I suggest trying to build a corpus of concrete examples. Not abstract declarations of reasons why it should be useful, actual specific examples of designs that you cannot do today, but could if you had the feature. Down to the actual code, with mock ups of the rendering (ascii art will do, but the point is to be concrete), reasons why you cannot achieve this without the feature you're asking for, and (if it is not painfuly obvious) reasons why there is merit to this design. > 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. >From the spec: > For print media [...] the anchor unit should be one of the standard physical units (inches, centimeters, etc) So that's solved already. Using CSS for print is not theoretical, and I am not just talking about pressing the print button in your browser. Commercial books are made with CSS all the time (I just typeset [this one](https://www.amazon.co.jp/CSS%E3%82%B7%E3%83%BC%E3%82%AF%E3%83%AC%E3%83%83%E3%83%88-_47%E3%81%AE%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E3%81%A7CSS%E3%82%92%E8%87%AA%E5%9C%A8%E3%81%AB%E6%93%8D%E3%82%8B-Lea-Verou/dp/4873117666/)). -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/614#issuecomment-254679777 using your GitHub account
Received on Wednesday, 19 October 2016 00:44:37 UTC