- From: Joshua Cranmer <Pidgeot18@verizon.net>
- Date: Sun, 19 Feb 2012 20:06:37 -0600
- To: www-style@w3.org
On 2/19/2012 11:03 AM, Matthew Wilcox wrote: > None of which mitigates the fact that physical measures are wrong in CSS. > > I know this isn't fixable whilst keeping backward compatibility. I > also think it's a pretty crazy position to be in. Given what I recall of the history of CSS dpi decision, the physical units were originally spec'd as being their actual physical lengths, or as near an approximation as could be made (see, e.g. <http://www.w3.org/TR/2008/REC-CSS2-20080411/syndata.html#length-units>, which appears to be more or less exactly the same as in CSS 1). I also seem to recall that UAs originally implemented the DPI value in such a way that it was modifiable, if not following the platform's estimation of DPI. However, given that too much content breaks when 96dpi is not what happens, the decision was made to redefine them, despite the fact the values were never originally specified in that way. So, strictly speaking, it's not backwards compatibility but web compatibility that forces the issue. > Oh to be able to declare a version of CSS to author against. We'd be > able to fix these inconsistencies. You may see versioning as a "press 1 to fix all these problems [in the implementation/model/etc.]" issue, but I suspect a lot of authors will see it as a "press 1 to break all my code" issue instead, even if it's intended to avoid fixing backwards compatibility unless absolutely necessary. If you'll excuse me a minute, I need to go see if my brand new router properly supports IPv6 yet... :-) -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Received on Monday, 20 February 2012 02:07:17 UTC