Wednesday, 13 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.



Posted by Robert at 11:37 AM
Labels:

32 comments:

  1. My employer has a couple of web-sites where physical units are very important: customers want to be able to print an payment-slip off the Web (including the invoice-number that's being paid, etc), staple a cheque to it, and send it in. When it's processed at the bank, the payment-slip is fed through an OCR system that looks for the payment metadata in a certain physical region of the page, which meant we had to absolutely-position the required elements with absolute length units to make sure everything appeared where it needed to be.
    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.
    ReplyDelete
  2. Of course, when printing on paper, it is "known" that, let's say, an A4 sheet is 21cm wide by 29.7cm long, so *in that case* millimeters, inches, and so on, have a "known" meaning. On a screen, it is much less obvious, especially since some systems (and users) "lie" about how many pixels-per-inch they are really using. Two screens of exactly the same size (in inches or centimeters) may have quite different numbers of pixels: in that case, text that is readable on an 800x600 screen can become much too small for reading on a 1600x1200. Rather than fix the dpi at an arbitrary value of 96, wouldn't it be better to assume that one screen is approximately as big as one paper sheet?
    (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?
    ReplyDelete
  3. CSS has the the concept of media-specific rules. Wouldn't it make sense to indeed have different conversion rates for different media? Say, an 1cm declared in a media-unspecified context is presumed to be intended for screen/print usage (and thus to follow the 1in == 96 "px" != device pixels), but when specified in a more explicit, known media context, to then more faithfully render them?
    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)
    ReplyDelete
  4. While the end result would be convenient, I don't think the appropriate solution is to bend for stupid web designers.
    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."
    ReplyDelete
  5. Robert O'CallahanJan 12, 2010 11:45 PM
    Screwtape: right, printing is one situation where the absolute length units make sense. It's screen display which is a problem.
    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.
    ReplyDelete
  6. It's scarry...
    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.
    ReplyDelete
  7. Robert O'CallahanJan 13, 2010 01:43 AM
    You can think of this proposal as browsers always zooming your content by default, if you like.
    ReplyDelete
  8. I'm really loving these latest blog posts. Please keep them coming.
    ReplyDelete
  9. Despite what the Mozilla cult seem to believe, the entire world is not abandoning desktops for mobile postage stamp browsers. Not everyone wants to use some Nokia 'smart' phone nor owns a iLoan (so named because you need a personal loan to pay for them). Your Fennec-infested assumptions are dubious at best. Not that it's your fault. I believe Fennec is a epidemic in Mozilla circles.
    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.
    ReplyDelete
  10. I agree with Red, this is rather scary.
    "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".
    ReplyDelete
  11. Also, if you want to know how many pixels one millimeter on a screen has, at least on Windows, you could try to use this:
    http://msdn.microsoft.com/en-us/library/dd144877%28VS.85%29.aspx
    ReplyDelete
  12. Alexandre de MenezesJan 13, 2010 09:21 PM
    I guess the absolute units don't make much sense if used alone to define a fixed absolute size for an element, but they can be useful when coupled with media queries.
    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.
    ReplyDelete
  13. The Anonymous above was me.
    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).
    ReplyDelete
  14. Robert O'CallahanJan 14, 2010 01:47 AM
    pd: treating 1in as always one physical inch is what breaks compatibility. As I said, IE has treated 1in as always 96px for many versions, and so has Webkit.
    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.
    ReplyDelete
  15. "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.
    ReplyDelete
  16. Robert O'CallahanJan 14, 2010 08:00 AM
    > Exactly rightly so. Maybe the unit you were
    > 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.
    ReplyDelete
  17. My screen is 140dpi - if every unit will be based on pixel size I will be unable to read this page. Without zooming by 140%
    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"
    ReplyDelete
  18. Robert O'CallahanJan 14, 2010 05:47 PM
    > Why bother with inches and centimeters if they
    > 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.
    ReplyDelete
  19. > 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.
    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.
    ReplyDelete
  20. Robert O'CallahanJan 15, 2010 01:34 AM
    > I think everyone here already explain that: take
    > 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.)
    ReplyDelete
  21. Robert O'CallahanJan 15, 2010 01:37 AM
    > I never thought that but maybe your view really
    > 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.
    ReplyDelete
  22. > Give some actual examples
    - 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.
    ReplyDelete
  23. Robert O'CallahanJan 15, 2010 04:27 AM
    > - 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.
    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.
    ReplyDelete
  24. Oh my, I was already in bed....another example:
    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.
    ReplyDelete
  25. I think HDTV and cinema projector are special cases.
    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.
    ReplyDelete
  26. Stumbled upon this while googling Robert ...
    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.
    ReplyDelete
  27. > On the Web, physical properties of the output medium are almost never known
    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.
    ReplyDelete
  28. Jean-Jacques SartonMar 2, 2010 09:05 PM
    Redifining one inch to 96px is stupid. If some web page are worse you have not to help the idiotic designer. For the page I support I had used pt because the text size was mostly OK and independant of the dpi of the screen. Unfortunatelly the WebKit people seem to mean that worse programming must be promoted, so I have all in relative units, mostly em with the benefit that the pages are barriere free.
    ReplyDelete
  29. What's happening???the print on my computer shrinks to 10% zoom while I am typing or pulling up info on Google...I have to reset back to 100% on the lower right at zoom area??
    Help
    Thx
    ReplyDelete
  30. It is much simpler to force screen makers to report their ppi to the OS. The browser would then know how to implement 1 inch. (for current devices we can just make a utility where the user puts a 2 euro coin on the inch, and draws a circle around it if she wants to have accuracy or else assume something like 96ppi) The inch will not be unusable, it will be just not used very often in webpages. Pinning it to the pixel defeats the purpose of it existing. Use pixels instead. Now we have the ability to use real-world units if we know the devices' ppi. For backword compatibility we can use zoom for high density screens and bury an option to force 1in=96px somewhere in the settings. I have a hunch that nobody will ever seek it)
    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.
    ReplyDelete
  31. "make absolute length units like "in" useful on all kinds of media, from phones to HDTVs."
    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.
    ReplyDelete
  32. Robert O'CallahanAug 21, 2010 03:50 AM
    > 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.
    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.
    ReplyDelete

Subscribe to: Post Comments (Atom)