
I think Mozilla (and before that, WebKit and IE) are putting the cart before the horse. 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. 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. We set CSS 1px to one device pixel times GetDefaultScale times the current zoom factor. nsIWidget::GetDPI only affects the interpretation of mozmm (unlike before, where on some platforms, some DPI values would trigger automatic scaling). The '' about:config pref overrides the result of nsIWidget::GetDPI, if present. 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). Internally, our DPI code has been overhauled. This is hardly ever going to be what you want. 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. 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'. 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 these cases we have introduced a new experimental unit, "mozmm". 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.

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.

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. For example, standard form controls such as checkboxes should look the same in Web pages as in other applications, by default.

One goal of this scaling is to give results consistent with user expectations and other applications on the system. For other output media, all these units are scaled in a medium-dependent and platform-dependent way by default. This matches the behaviour of Internet Explorer, Safari and Chrome.īy default, when printing, 1in is rendered as one physical inch. The CSS units changes that I blogged about in January have landed and will be in the next Firefox milestone.
