Friday 20 August 2010
CSS Units Changes Landed
The CSS units changes that I blogged about in January have landed and will be in the next Firefox milestone. With these changes, 1in = 96px always. Likewise 3pt = 4px, 25.4mm = 96px, etc.
This matches the behaviour of Internet Explorer, Safari and Chrome.
By default, when printing, 1in is rendered as one physical inch. For other output media, all these units are scaled in a medium-dependent and platform-dependent way by default. One goal of this scaling is to give results consistent with user expectations and other applications on the system. For example, standard form controls such as checkboxes should look the same in Web pages as in other applications, by default. Another goal is to choose default scaling so that a document designed to print well on normal-sized paper will be readable on the output device, e.g., a phone. So, the advice for authors using CSS physical units is to set lengths so the document looks good when printed without scaling; the browser will then scale those lengths to display the document suitably on different kinds of screens.
There are some rare cases where it makes sense to include true physical measurements in a Web document --- for example, "life size" diagrams, or elements in a touch interface. For these cases we have introduced a new experimental unit, "mozmm". For media such as screens that can be touched, 1mozmm is rendered as one physical millimetre (or as close as we can get based on what we know about the medium). For other media, such as contact lens displays, brain-implanted electrodes, or lasers projecting into the sky, we reserve the right to treat 'mozmm' similarly to 'mm'. Authors should only use mozmm for elements which really need the same physical size on, for example, a 4" phone screen and a 24" monitor. This is hardly ever going to be what you want.
Internally, our DPI code has been overhauled. Everything is now controlled by two parameters: for each window, the number of device pixels per inch (returned by nsIWidget::GetDPI), and also for each window, the default scale (returned by nsIWidget::GetDefaultScale). The 'layout.css.dpi' about:config pref overrides the result of nsIWidget::GetDPI, if present. nsIWidget::GetDPI only affects the interpretation of mozmm (unlike before, where on some platforms, some DPI values would trigger automatic scaling). We set CSS 1px to one device pixel times GetDefaultScale times the current zoom factor. Currently GetDefaultScale always returns 1.0 on all platforms, although on Mac we should set it to the system "default UI scale" (and change some other code to compensate), and on Windows we should set it based on the "system font DPI", which is essentially a user preference that controls scaling of all applications on the system. It's important that the default scale be based on a system-wide setting; that will keep Firefox consistent with the rest of the system, and ensure that the user doesn't get a surprise.
Comments
You blogged this before but removed it. But not before Planet Mozilla caught it, I was very confused.
If the GetDefaultScale adjustments show up later, it seems you'll be confused by two different sets of bug reports. Will the user see fuzzy lines if it is not an integer?
Will you apply a GetDefaultScale adjustment for the proud few who are able to adjust Linux font and resolution settings, http://www.mozilla.org/unix/dpi.html ? (The Linux desktops occasionally discuss implementing device-independent one point = 1/72 of an inch, then the conversations devolve into arguments about what happens to the 8x13 bitmap terminal font, and degrees of field of view measured at the retina.)
> integer?
No, our full-zoom doesn't do that.
And there's a bug that this will done?
This ssentially ist a factor off "system font dpi" / 96. Here it's 1.04 for the current screen and using this in the equation would result in the same display as before where nsIWidget::GetDPI was part of the equation unless that now not only mm, in and pt but also px would be scaled, right?
Question is, why isn't there a pref 'layout.css.defaultScale'? I'd like to have a cm be a cm again on my screen and everyone else should also have the freedom to choose so.
See http://mxr.mozilla.org/mozilla-central/source/gfx/src/thebes/nsThebesDeviceContext.cpp?mark=667-671#660
If I wanted 96DPI I'd set my system to 96DPI.
---
What kind of BS is that. Everyone is buggy so we have to be buggy, too?
If I wanted 96DPI I'd set my system to 96DPI.
---
There are historical reasons for 96DPI being so prevalent (if only approximating reality) over the years, and that has led to a lot of lazy code. That code will prove problematic as high-DPI displays become more common (they're not all tiny phone screens) and you guys are falling into that trap.
The real solution is for designers to stop designing for specific display sizes, either in pixels or in inches. Make the text a readable size (like 12pt) and let it flow in the available space.
I'm aware that the current "solution" (1 pt = 4/3 of a pixel) is a bit of a "hack" aimed at damage control, making as many websites as possible "work" with DPIs > 96. I have been through a similar period of agony when I tried to "shoehorn" existing TrueType fonts into ClearType duty (www.rastertragedy.com, §4.1 and §4.2). Naive or innocent font "hinting" blew up characters seemingly at random and text got truncated on "pixel-perfect" dialog boxes, neither of which was a problem before, hence ClearType was implied as the culprit, and we had to "fix" it. The "solution" does not look optimal, but if nothing else, it doesn't blow up---never mind the "casual hinting" that never improved.
But why compromise pt for that "hack?" Why not compromise px, the unit few websites have any business to specify? In other words, why re-define 1 pt as 4/3 of a px instead of re-defining the size of 1 CSS px as 3/4 of 1 pt? This would render a 12 pt font at about the same physical size on my 96 DPI desktop, on my current 120 DPI laptop, and on my former 144 DPI laptop. And it would keep the concept of a pt: Unlike inches or millimeter, a 24 pt font doesn't have to be a linearly scaled-up 12 pt font. It may have slightly thinner stems and tighter character-to-character spacing than the 12 pt version.
This aspect of typography is now lost...
The reason why I say that Web authors misused pt (defined as a physical length) is that even where they avoided px and sized everything in physical pt, their sites almost certainly are not usable on both a desktop monitor and a handheld device. Physical units are simply not a good way to size fonts when you don't know the distance from the eye to the screen --- which you don't, on the Web.
Modulo that, you have a good question about why we didn't redefine 1px as 4/3 of a pt, at least for desktop users. (Another way to think about that is as a default zoom based on the user's desktop monitor DPI.) Here are a few reasons why we don't do that:
1) We'd have to resize all images, which reduces performance and decreases image quality.
2) When the user's monitor DPI is different from their manually-selected "Windows font DPI", it would make the size of UI elements such as checkboxes inconsistent with other applications. (If we made checkbox px sizes variable, Web pages would break.)
Before Firefox 4 we actually did allow px to vary based on monitor DPI, and it was a frequent source of user complaints.
However, I think we can satisfy you. We need to make Firefox track the "Windows font dpi" setting to set a default zoom based on that setting, so if you manually make the Windows font dpi setting match your monitor, you'll get the effect you want. This will avoid problem #2 above, and problem #1 will be tolerable since you opted into it.
I will also reiterate that we have done our best to limit the fallout by a) ensuring that CSS units match their physical counterparts in print, where the viewing distance is much more predictable and b) introducing a true physical unit, mozmm, for the cases where you really need the same physical length regardless of the viewing distance.