Surfin' Safari

CSS Units

Posted by Dave Hyatt on Sunday, April 23rd, 2006 at 6:04 pm

I figured I’d take another stab at educating people about CSS units.

In the responses both on this blog (and on Slashdot), some people argued with the high DPI proposal saying “A pixel is just a pixel! Making a CSS pixel != screen pixel is a bad idea!” Those of you who think this way have a fundamental misunderstanding regarding how the Web works even today. It is already true that a CSS pixel does not necessarily equal a device pixel, and there’s nothing wrong with doing this. It doesn’t mess up your Web site. You don’t even have to think about it if you don’t want to.

For example, whenever you zoom in a browser that supports it (like Opera), a CSS pixel won’t equal a screen pixel. Nor should it, since otherwise the zooming wouldn’t be possible. The zooming, done well, doesn’t hurt your Web site or disrupt its layout in any way, since everything zooms together. The high DPI proposal I outlined earlier is about defining how a Web site can intelligently reveal higher levels of detail when zoomed rather than just scaling up the exact same content.

Another example of where high DPI already comes into play is with printers. Printers can have very high DPI, and if you made a CSS pixel = a device pixel, your Web site when printed would be so tiny that you wouldn’t even be able to read it. Pixel scaling is already done at the printing level.

In addition to being muddled about the px unit, some people were confused about the so-called absolute units. These include units like pt or cm. These units actually aren’t absolute. The absolute unit is a myth.

The sad truth is that designers never really understood the difference between pt and px. Many Web sites even today mix those units in the same Web page. Not only do they assume that pt and px are close to one another in size, they actually mingle these units assuming that the ratio between these two units will be constant across all browsers and devices. Any browser that truly attempted to treat pt as 1/72nd of a physical inch would just end up mis-rendering Web sites.

This is why browsers use the 96 dpi rule when deciding how all of the absolute units relate to the CSS pixel. When evaluating the size of absolute units like pt browsers simply assume that the device is running at 96 CSS pixels per inch. This means that a pt ends up being 1.33 CSS pixels, since 96/72 = 1.33. You can’t actually use the physical DPI of the device because it could make the Web site look horribly wrong.

The other units worth discussing are em and ex. These units are interesting to use primarily because of the text zoom feature of Web browsers. Because some browsers (like Safari and Firefox) just zoom text without zooming other content, expressing everything in these units can give you a way of having content other than text also scale with the font size.

18 Responses to “CSS Units”

  1. nate Says:

    As much as the separation of CSS pixels and screen pixels makes my head hurt, I think a proposal like the one you’re putting forward is the only way to go.

    The idealist in me looks at em (ex had implementation issues earlier on, so I don’t think it’s as widely used) and says that people who want a scalable web site should build it using em units throughout — then it will handle scaling elegantly and we won’t have to have a 1 pixel != 1 pixel situation. But this is really an end-user issue, and backward compatibility with existing sites is pretty key.

  2. Drew Says:

    Dave, you’ve done a good job explaining this and I don’t understand why people are all up in a fuss. Resolution-independent UI has been around the corner for the last couple years for anyone who has been paying real attention to the state of the OS. And web zooming, while it will be dramatically affected by this, is even less surprising given that current browsers already support some initial magnification (like you mention, mostly limited to text magnification).

    People’s obliviousness to the obvious sometimes bewilders me.

  3. nick cowie Says:

    You can use ems to build sites, I have been doing it for a couple of years, but it does come with overheads.

    Rounding errors in various browsers
    You can’t scale background images, list-style-images etc.
    Scaling bitmap images requires big images and trusting browsers

    However, scaling vector images can be done using flash.

    You can build sites that allow zooming, it just takes a little know how, patience and luck/hope that the browser will not break it badly.

    See my comments on the previous post for examples.

  4. Avi Flax Says:

    I’d love to see some elaboration on measurement units such as cm, mm, and in. If we use these in CSS, can we expect them to be scaled correctly when rendered, regardless of the client device DPI?

  5. Brady J. Frey Says:

    Let’s just leave flash out of this:) The functions are fun, it’s spawned a generation of splash pages vs functionally unique sites (with an arguable user experience), but it’s binary presence for self contained sites have caused us more than one headache. I’m hoping SVG takes more center stage, though I’ve heard nothing of the sort come out of Adobe since the merger, does your post show us some light to look forward too? Regardless, this is an excellent, quality idea for moving forward. At first I was scared that we were going to talk of doing hi-res rasterized files vs vector art — something I hear we can enjoy in Japan, but even my cable line wouldn’t handle that friendly in San Francisco.

    I blame the confusion of pt and px to people, like me, who were taught web from print designers running dreamweaver, and taken years to break out of it. This can also be a quality point of confusion regarding css pixels…

  6. Robert Says:

    Dave, good explanation, but you still have to fix the problem of how to send hidef-browsers different jpgs. You know, you can’t use svg with every image – photos will compress badly, as an example. A way to go here would be to add some “device ratio” figure to the http request header spec, no?

  7. soosy Says:

    In effect, we’ll have two types of scaling:

    - The current browser text size scaling, which will scale the size of em, and allow the web designer to control what elements should get scaled with the text (anything specified in em). Again, this is already in place.

    - The “HD Zoom” which will scale all elements of the site together. Sites look exactly the same zoomed larger, but can use hires bitmaps.

    Sounds good to me! I appreciate that both types of scaling will exist. Even though the first type often ends up breaking site designs, it’s true to the web’s roots, where the user specifies what looks best to them (font face/size/etc) and the design isn’t locked in place.

  8. jcdeering Says:

    Robert said

    “You know, you can’t use svg with every image – photos will compress badly, as an example.”

    I don’t see that happening if you design your images for the 1920 by 1080 format. When shown on a smaller size monitor they actually compress to a higher resolution. See for yourself.

    http://deerring.com/cg/cg1.svg

    James

  9. jcburns Says:

    “The sad truth is that designers never really understood the difference between pt and px.”

    Well, gee, thanks for painting all designers with the broadest of brushes…I think the truth (in my case and among many I know) is that we knew the distinction, but when CSS was over time so inconsistently implemented, you find something that produces (mostly) reproducable results, and then you stick with that.

    Anyone who has used Photoshop since about 1994 has had the opportunity to distinguish between pt and px.

    It’s a trust situation…when designers are convinced (and increasingly, we are) that it’s safe to use all the tools in the CSS toolbox, we will. Otherwise we tell each other: “don’t touch that one, it’ll hurt’ya.”

  10. Pingback from Satunnainen Björklund » CSS-yksiköt:

    [...]

    Satunnainen Björklund 24.4.2006 CSS-yksiköt Surfin’ Safari: CSS Units. Lisää samasta aiheesta. Ennen ja jälkeen « Hupia Scoblen ja MS:n kusta [...]

  11. Robert Says:

    James, I wasn’t able to see your provided image (won’t display in Safari 2.0.3, firefox raises an error). I guess your point is that you can have a pic that looks as good as a jpg with similar filesizes and display sizes, and when displayed at a higher image size will look nicer, albeit not showing any additional data. Well my point is that a browser at higher dpi should be able to display more details for an image and _that this very functionality (requesting more image data if the browser can display it) should be a basic browsing thing, not something that requires some hacks like extensive use of javascript.

  12. jkporter Says:

    I might be the only one but I always set the Windows DPI (IE, Opera) & the DPI setting in Firefox to the actual physical DPI of my screen. I can’t recall I’ve ever ran into any problems as a result.

  13. Pingback from BlueSparc design, technology news » Blog Archive » High Definition Web Sites, Elastic Layout:

    [...] > High Definition Web Sites, Elastic Layout Dave Hyatt, of Surfin’ Safari fame has a lot to say about the potential of high-definition websites, and the CSS t [...]

  14. MacDome Says:

    James,

    It looks like the SVG you cite is invalid XML (thus failing to render in both Firefox and Safari).

    http://deerring.com/cg/cg1.svg

    It’s missing at least the xlink namespace declaration. I would encourage you to read Jonathan Watt’s SVG authoring guidelines for more information:

    http://jwatt.org/svg/authoring/

    -eric

  15. Tim Says:

    I was surprised to see that px was indeed relative. So the proposal seems entirely in line with the intention. But what makes the question mark appear above my head is why the CSS spec included no absolute (non-relative) units. It may be rare, but there are certainly times where I want to specify a non-subpixel unit that is as small as possible.

    I often stroke images with a 1px line, which I may not wish to scale up with the rest of the content. I may also place items along side each other as closely as possible, with only a 1px margin or padding — also not wishing it to scale as the objects change size.

    Whey did they include pixels when given the current specs, points would have done just fine? Illustrator, PageMaker, and other print apps have expressed everything in points forever — only recently have they had to add pixel units to meet the needs of the web design and production grind.

    On a related note, you mentioned that px and pt have been used interchangeably under false pretense. But isn’t this to solve the problem that images and other design elements are specified in pixels (with little in the way of alternate options since user agents don’t respect DPI information in image files) yet to use points to specify typefaces would yield very different looking layouts across platforms or even browsers?

  16. SoloSolo Says:

    I think that you can apply this High DPI idea to quirks mode.
    In standard mode leave 1px = 1 monitor pixel and 1in = 1 real inch, please.
    I want my logo to be 2 inches wide, no more, no less.

    Bad designers must be educated or confined to quirks mode. Leave standard mode as correct as possible for the designers that studied the CSS specs and the CSS manuals.

  17. Pingback from CSS Units of Measurement « LearningNerd:

    [...] ;. In other words, they’re never used for websites. As explained in an article about CSS Units, “The absolute unit is a myth…. Any browser that truly attempted to treat pt as 1/72nd [...]

  18. AaronShep Says:

    There’s something I’m not hearing anyone mention about automatically downscaling bitmap images. For optimal quality, an image must be sharpened _after_ it is downscaled — because the optimal amount of sharpening depends partly on the image resolution. If you sharpen an image at 200 ppi, it will be blurry again after downscaling to 100 ppi.

    If a browser is going to downscale properly, it must apply additional appropriate sharpening. And that is possibly too much to ask.

    Aaron