Tuesday 12 January 2010
CSS Absolute Length Units
While reexamining the way we handle screen resolutions in Gecko, we had to reconsider how to handle CSS "absolute length units" --- especially pt, but also in, cm, mm and pc. The spec says that these units should be displayed at their physical sizes, so CSS "1in" is rendered as one inch, etc. Unfortunately this breaks Web content, because most Web pages were designed on desktop screens. A one-inch margin may be fine on paper or on a desktop screen but doesn't make much sense on a two-inch-high phone screen. For related reasons, IE and Webkit have already redefined these units to be fixed numbers of CSS pixels, i.e. 1in = 96px, etc.
After I raised this issue on www-style, it became clear that this is not just an issue of compatibility with existing content. In fact, absolute length units as defined in CSS are only rarely useful. When do you want to force a length to be one inch, no matter what kind of screen is being used or how far from the user's eyes it would be? The only use cases I know of would be touch interfaces and "life size" diagrams. Indeed, the CSS spec says
Absolute length units are only useful when the physical properties of the output medium are known.
On the Web, physical properties of the output medium are almost never known, so the spec suggests that currently absolute length units are useless on the Web.
It seems to me that it will be far more useful, as well as compatible with existing Web content, to specify that absolute length units should take those physical lengths when printed to "normal paper" --- paper (or other media) that you hold when reading, like almost every printed page. Then the browser decides how to render the content on a screen to best express the author's intent. Common sense, as well as Web compatibility, will dictate that the ratios between "px", "pt", "in", "cm", "mm" and "pc" will be fixed based on the assumption that 1in = 96px.
We may find it useful to define a new unit or units, say "truemm", that is a true physical millimeter, for the rare use cases of touch interfaces and "life size" diagrams.
Redefining "in" to not always mean physical inches is quite controversial in www-style. I hope sanity prevails.
Comments
We did briefly toy with the idea of presenting invoices as PDFs rather than as HTML, but by default Acrobat Reader will shrink the document to fit within the printer's margins (well outside our assigned physical space), and it was easier to teach people how to reset the print margins in their browser than in Acrobat.
(Thinking out loud) Maybe we should use "pseudopixels" too, and decide that one screen height = 8 pseudo-inches = 8*96 i.e. 768 pseudo-pixels?
Obviously, the entire situation isn't ideal (calling something an inch or a cm when you just don't have a clue what it really is isn't the brightest idea there's ever been)
In addition, such a change, regardless of rationale, seems like the source for potential headaches resulting from hard to track down problems and those scathing indictments (or simple blurbs in break-into-a-technology guides) about the stupidity of a given system:
"In their infinite wisdom, browser vendors decided that 'in' would just be an alias for a multiple of 96 pixels. If you use these units hoping to, you know, actually specify a measurement in inches, you have to use 'truein'. I suppose by the same reasoning, to be safe you should probably use 'truepx' and 'color: true#92B;' when that's what you really want. Interestingly enough, these don't work."
Anonymous: my point is that this is not just an issue because of stupid Web designers. If you're a brilliant Web designer who faithfully follows the specs and expects 1in to always be one physical inch, then you basically can't use 'in' etc for screen media.
What kind of "standard" it is, if CSS didn't respect standard units?
Argument about cell phones is wrong. Browsers have ability to zoom in and out web page, but in 1:1 zoom level 1cm should be 1cm.
Redefine px unit if you must. Pixel is not a _real_ unit, it can have different size on each screen, but please do not touch real world units.
If a designer wants to use inches as a measurement, they might well have a damn good reason. It is arguable that PCs hooked into HDTVs are giving mobiles a good challenge in terms of future browser output resolutions. If we're to follow your logic that inches are not relevant on mini mobile phones, inches surely are much *more* likely to be relevant on massive HDTVs? More so than desktop screens. Therefore there is a case for not only maintaining inches as a measurement but encouraging developers to use them!
Just because you assume that use cases for existing measurements are low, doesn't give you the right to dictate compatibility-breaking changes to a browser that should be 'owned' by it's users, not the Mozilla cult.
"Common sense, as well as Web compatibility, will dictate that the ratios between "px", "pt", "in", "cm", "mm" and "pc" will be fixed based on the assumption that 1in = 96px"
No one ever expected a pixel to be 0.26458333 mm. If you have another screen than I do then it might well be that your pixels are of different size than mine. It's pixels which have not fixed size, not meters.
Ad common sense:
"We may find it useful to define a new unit or units, say "truemm","
There is already perfectly good unit to describe such length, even better, everyone agrees on its value - it's called "mm".
http://msdn.microsoft.com/en-us/library/dd144877%28VS.85%29.aspx
We can use pixels for screen and inches for printer, for example. Another option is to define element sizes based on display sizes: 1in border for output over 8in wide, 1mm border for output smaller than 3in, and so on.
Solution for font sizes: use ems. This doesn't mean "body { font-size: 0.86 em; }" or whatever. David Baron's Bugzilla comment from 2000 about web designers' font size styling choices is apropos: https://bugzilla.mozilla.org/show_bug.cgi?id=24846#c2
As for the other problems, web designers should say what they mean. If they are expecting these physical dimensions to map to some absolute measurement in pixels, use pixels instead, though ideally they wouldn't be trying to do this anyway. Otherwise, it's just deception so that they can wear their "I care about accessibility" bonnet (or whatever the hipsters are wearing these days).
Treating 1in as one physical inch would be terrible for a browser on an HDTV. Millions of documents containing stuff like "text-indent:0.5in" will suddenly have negligible text-indent when displayed on your HDTV.
Exactly rightly so. Maybe the unit you were searching for is not "in", but "%"...
"treating 1in as always one physical inch is what breaks compatibility. As I said, IE..."
I assume you just wanted to tell pd who's really breaking what in current situation. I also assume you don't take IE as a norm.
> searching for is not "in", but "%"...
They're not *my* documents. I'm just pointing out that millions of documents on the Web will not be displayed in a way that satisfies the user. We may all wish that wasn't so, but we have to deal with reality.
However, I'm also pointing out that if you want your documents to be viewable on phones and HDTVs (which I hope we all do!), then treating "in" as physical inches means that you basically can't use "in" anymore. Instead, I think we should define "in" in a way that makes it actually useful.
This is only beginning, soon there will be many e-book readers with even bigger resolutions (200dpi and more).
This "redefinition" will sacrifice future in the name of past and some broken pages. Try to explain your daughter why "this 4 inch box is smaller than 1 inch". Think about medical displays.
I see no point to use other units at all if they will be tied to pixel size. Why bother with inches and centimeters if they are not real units?
What next? Assumption that every screen is 1024x768? How many pages looks bad at higher resolutions?
Maybe there is better solution? For example some media query to provide "quirk mode screen" and "real display"
> are not real units?
They'll be "real" when printed.
For 140dpi screens, all browsers today make 1px = 1/140 inch, and 1in will be 96/140 inches. So my proposal will change nothing at all for you. However, you will be able to opt in to using some other size for 1px ... for example on Windows, you could set the system "font DPI" to 144.
For 200dpi devices designed to be read at arms length we can make 1px equal 2 device pixels. That decision depends on how the device is intended to be used and what other apps on the device do (we don't want buttons in Web content to be twice the size of buttons in other apps).
All the people who insist that "in" should always be one physical inch need to explain how they're going to use "in" when the page might be displayed on a phone or an HDTV.
> be one physical inch need to explain how they're > going to use "in" when the page might be
> displayed on a phone or an HDTV.
I think everyone here already explain that: take a pencil and draw 1 inch line with a ruler - either on HDTV or a phone.
> They'll be "real" when printed.
The key here is "when printed". What does it mean? When I put ink on a paper do I print? When I put e-ink on e-paper do I print?
If I am graphic designer and I set text in 8/10pt for a billboard which you wont be able to read from a car 100 meters away - who is responsible for it? The graphic designer or the company which printed the billboard?
I think the real question here boils down to "angle of view". If I understood you correctly you have no problem drawing 1 inch on a phone because it's close to your eye. However, since HDTV is across the whole room you might not even notice 1 inch, right? Then, "inch" is not the unit you want. And if the document already uses inches then zoom-in - but this is something completelly different than to redefine the length of "inch". And lastly, redefining inches wont help you because various devices use various DPI and are shown at various distances. I never thought that but maybe your view really is a bit "web browser on a PC"-like..?
Why don't you use pixels in the first place?
> 1in will be 96/140 inches
> For 140dpi screens, all browsers today make
> 1px = 1/140 inch
Wait... you said 1 inch is 96 pixels.
> a pencil and draw 1 inch line with a ruler -
> either on HDTV or a phone.
But what are you going to use "1in" *for*? Since you have no idea how it will be perceived by the user. Give some actual examples of Web page designs where you would use "in" to mean a physical inch and the results are useful on both phones and HDTVs.
(I've actually given you a couple of examples in my post ... try to come up with something more common than those.)
> is a bit "web browser on a PC"-like..?
No. The whole purpose of this exercise is to a) make existing Web pages display as the author intended on all kinds of media, from phones to HDTVs and b) make absolute length units like "in" useful on all kinds of media, from phones to HDTVs. If I only cared about "Web browser on a PC" I'd be wasting my time with this discussion.
- Maps. A map could have defined a scale so just by looking at it you might know that those 10 cm are actually 10 km.
- Medical devices. Maybe there could be a database of some somatic features which you might want to consult / compare with.
- School books. There could be a book for children showing how big various bugs and butterflies are.
- Typography. If a medium has fixed dimensions then you might want to prevent the text from reflowing or to force it to follow the design manual.
- Physical interfaces. Maybe one day, while designing a user interface you would like to follow some ergonomic norms for finger size or arm length.
> No. The whole purpose of this exercise
Hey, I hope I didn't offend you. This is all dear to my heart, too. Peace.
> by looking at it you might know that those 10 cm
> are actually 10 km.
I don't see how that is useful if you're displaying the page on an HDTV, you can't even tell what 10cm looks like that far away.
> - Medical devices. Maybe there could be a
> database of some somatic features which you
> might want to consult / compare with.
> - School books. There could be a book for
> children showing how big various bugs and
> butterflies are.
That's "life size diagrams" which I mentioned.
> - Typography. If a medium has fixed dimensions
> then you might want to prevent the text from
> reflowing or to force it to follow the design
> manual.
I'm explicitly talking about Web pages where you almost never know the dimensions of the medium. If you just want a fixed layout that is scaled to fill the viewport, you can do that without physical length units (e.g. using SVG viewports).
> - Physical interfaces. Maybe one day, while
> designing a user interface you would like to
> follow some ergonomic norms for finger size or
> arm length
Right, that's the "touch interface" use case I mentioned.
Personally, I think the "life size" and "touch interface" use cases are important enough to have a true physical unit for them, but they're much *less* important than being able to specify lengths that are a particular physical length when printed but are scaled appropriately when viewed on a phone or HDTV.
in typography, there are two parameters: character size and line height. The relation between those two is non-linear meaning that, roughly, the smaller the size is the greater relative line spacing should be. E.g. for 8pt text size the line height is usually 10pt. For 10pt text, 12pt lines, and 20pt / 24pt (?). What's worse, these numbers don't really follow an objective rule as they are the subject of ever day disagreement among type designers.
If you don't know what the character size really is, how do you want assign a line height then?
> I don't see how that is useful if you're
> displaying the page on an HDTV, you can't even > tell what 10cm looks like that far away.
You can come closer. The point I was making was about maintaining of the visual clue of distance.
They are designed to display everything much bigger (even 100:1).
Phone is just another extreme. Reading web on it, is like looking through keyhole… You wrote about margins – good. Then scroll page to the left by default. Do not resize until user doesn't want to. If you scale margins, you will scale font size too, but it's not good, Nobody want small unreadable text.
But… There are many other devices where you really need real units.
I want to buy new phone very soon. I'm looking at specifications, but I wish to know it's size, today I can't. This is a big failure…
Another, maybe stupid example: Think about near future, when almost any device will have some display… refrigerator? kitchen table? You want to interact with physical item on this table? You have know its size, and be able to display everything using real world units.
And think about maps once again… I like mountains and I like to use 1:50000 maps. For me it's much easier to "feel" distance by simple looking, than using abstract kilometers. Having ability to both zooming page _and_ map is… wrong.
BTW. Your proposition to zoom page by 140% on 140dpi screen is wrong. User should know nothing about it's DPI. 100% zoom should mean 1:1 size.
There is one thing I hate on modern web. Default font size can be so different from page to page. Sometimes I can hide whole paragraph under my thumb. Sometimes even 180% is too small.
This discussion reminds me when the authors of the original XML spec, with the purpose of finding out real word requirements, talked to the browser makers (maybe NN4 and the like).
The makers wholeheartedly recommended to make the language strict, arguing that more than 50% of the browser development work was devoured by making HTML less strict, more "flexible", like for example not forcing the authors to close some tags. I believe that this was the origin of the quirks mode: patronizing the authors.
This thread is IMO a revival of the quirks by trying in absolute good faith to solve the authors problems.
In the discussion between inches and pixels we already know that each one has its own strengths and weaknesses.
IMO the valuable arguments so far are those regarding the angle of view and the browser's zoom capabilities.
IMO a reasonable solution would be recommending that the UA had a default zoom ratio depending on the view distance, screen resolution and pixel size, and getting advice from experts about the recommended settings for different devices and sights.
During installation of the browser, or upon a display device change, the ratio would be set giving the user reasonable choices like Robert's 140%. With a try-and-accept functionality like when one changes the screen resolution in Windows XP.
No browser or standard will solve the problems raised by sloppy design and development. Also, IMO it is not the charter of the experts. This would patronizing the developers with the inevitable side effect of hurting the users.
I have done some web development, and I do browser type detection to get a good idea of what the output medium is. I deliver completely different content to handhelds than I deliver to a regular browser. I admit, I hardly use “in”, but I often use “pt” to make sure the text is readable irrespective of the handheld resolution. Specifically, the Blackberry family has a variety of pixel densities, and I am grateful I can get my web page to show my text at the same point size on all of them.
Assuming 1 inch=96px is not a good thing, and will force me to design different pages for each type of handheld: A 10pt (=0.138in =13.3px) font is just right on a Curve, and too small on a Bold.
Help
Thx
Px is indeed a very useful length unit, because pixel density is often relative to the distance that you view a screen. So the real viewing angle of 1px is about the same in all devices. Imagine drawing webpages on a phone 1:1 with the size on a desktop screen. It would be unusable.
By radically redefining their semantics, thereby changing their meaning to everyone who has ever used them, contravening SI units and generally throwing common sense out of the window.
Microsoft have to worry about overarching backwards compatibility - that's why they iterate so slowly. Mozilla is about innovating and improving, not appeasing old mistakes.
If people wanted pixels, they used pixels. If they wanted inches, they chose to use inches for a reason. There's no reason to second-guess it, they opted in to doing so.
> for a reason. There's no reason to second-guess
> it, they opted in to doing so.
Inches isn't the most commonly used physical length unit, "pt" is. The assertion that every Web author who uses "pt" chose it because they want their fonts to be the same physical size on 4" phone screens and 24" monitors is false.