Safari brings high resolution to the Web

Ever used a high resolution screen? I mean high resolution as in “more and smaller pixels stuffed into the same physical area”, not just the raw pixel count – higher DPI (dots per inch). If you are using a reasonably new Wintel laptop chances are that your screen has a higher DPI than the 72 DPI or 96 DPI that used to be the most widely used resolutions.

None of the screens I use on a regular basis are of higher than normal resoulution, so I haven’t given it much thought. But the other day I used a colleague’s new laptop to take a look at a prototype of a website we’re building, and everything was tiny. Sure, increasing text size helps, but only for the text. The images are still tiny.

As screen manufacturers get better and better at squeezing a larger number of pixels into the same physical space, this will only become more obvious, and it’s clearly something web professionals need to keep in mind. But it’s not only about us, it’s also about web browser vendors. They need to provide their users with effective ways of zooming the page, which in its current implementations (Opera, IE7) does not treat images very well. Not as well as they could be treated anyway.

To solve this problem and allow images to actually look better on high DPI screens, the WebKit team at Apple are proposing methods of using higher resolution images only for those devices that can actually take advantage of the extra information. The methods involve either using SVG images or using a combination of pixel-based image formats and the CSS3 property background-size or the ::marker pseudo-element (also CSS3).

To make it easier to offer different DPI images depending on the capabilities of the device being used to view the site, the WebKit team are also proposing an extension to CSS3 Media Queries: the CSS pixel scaling factor.

Dave Hyatt provides more detailed descriptions in High DPI Web Sites and High DPI (Part 2). He has also posted a follow-up article on CSS Units, where he explains how CSS pixels actually work. You may be surprised to learn that a CSS pixel does not equal a device pixel, contrary to what many people (including myself) have made the mistake of believing.

Being able to provide users of high DPI screens with better looking images sounds good, so I’ll be keeping an eye on how this develops.

Posted on June 12, 2006 in Browsers, CSS


  1. So why do we need this pixel scaling factor besides resolution?

  2. Also, this problem is not really new. You encounter it everywhere on the mobile market. Screens stay about the same size but the amount of pixels is “growing.”

  3. We ran into several problems at Dell when we first received high dpi LCDs. Most Microsoft titles worked fine; their coding practices enabled seamless scaling of menu text and other window widgets when the dpi setting was adjusted by the user. Many third-party apps, however, did not scale at all. I recall that WinAmp (circa 2001 - things may have changed) did not scale and some hot spots were so small as to make the app unusable.

    The goal is to reach 200 dpi. Right around that resolution, most people cannot perceive a difference between OpenType text on an LCD and ink on a printed page.

  4. So, how is this a problem for CSS to solve? I’d say that the browser should implement whole-page zooming or scaling, rather than changing the web specs.

  5. It is an interesting problem, although an old one.

    Whole-page-zooming or scaling is working now - in some browsers, but they just resize our ‘relative pixels’ and make the most out of what we give them. 72px/inch bitmap-images is what we most often provide - regardless of screen-resolution.

    Zooming or scaling to an exact match between our relative pixels and a round number of physical screen-pixels/dots is not likely, so our ordinary images will come out a bit “rough”. Even if the UI zooms to a perfect match, we still won’t get a more detailed image since we haven’t provided one.

    We will have to provide higher resolution images if we want to take advantage of the higher resolution on screens. The question is: how high image-resolution will be high enough. Ordinary bitmap-images will be quite heavy if they should match 200dpi - pixel by pixel (or px by dpi), and I think 300dpi screens are within reach. Higher screen-resolution than that isn’t really of much use, so I guess it will level off around there somewhere.

    So, now I’ll just sit back and let the UI-providers agree, or disagree, on how to solve this problem at their end. Don’t think I’ll provide any high-resolution images before some agreements are reached so I know what to provide for.

  6. June 13, 2006 by Adrian Bengtson

    Tim McCormack: Because the desire among web creators to replace 72 ppi images with 200 ppi images on high ppi screens. Instead of just upscaling those 72 ppi images.

  7. I believe Safari also already allows .pdf files as images. You should be able to use them with a raster fallback image for other browsers.

  8. I’ve been wondering for years when people (including browser writers) would finally notice that, according to the spec, a CSS pixel isn’t the same thing as a screen pixel. It makes sense when you think of printing a page: how big is something going to look on a 600dpi printer if CSS pixels have a 1-to-1 relationship with device pixels?

    It’s all explained in the standard where it’s made clear that if the output device has a resolution much different from 96dpi (such as a hi-res screen) then pixels should be scaled to suit.

    There would have been a lot less brouhaha and balderdash in the comments to Dave Hyatt’s posts on this topic if people had bothered to read the spec; to my mind, the funniest were those who claimed that automatic scaling was in fact a breach of the standard: “A pixel is a pixel!” No, it isn’t :-)

    I’m not aware of any browser that correctly supports this part of CSS 2.1 for screen devices - by which I mean, automatically scaling output, rather than relying on the user to do it.

  9. What about adding a style to the html document, like :

    Then higher DPI devices should know what to scale for unless otherwise stated in even more tags, it would also make it much easier for the deveoper I would think.

    Or maby we could detect theese devices in a simple way and just feed them with the 300DPI stylesheet, sounds like a good deal if possible.

  10. Re Kim Steinhaug’s comment, I would have thought @media the obvious place for high resolution screen detection in this situation - after all a “handheld” is a screen-based device and gets its own media type, so why not have a “highresolution” type as well?

  11. Nobody uses Macs anyway ;-p


  12. Really DPI on a monitor video system is a “font size” rather than an actual screen resolution, so I assume you meant Pixels per inch (PPI).

  13. Sure, an ordinary computer-screen has physical pixels, and resolution is measured in ‘ppi’. Printers have dots - resolution measured in ‘dpi’.

    However - related to web design anyway - I think physical resolution will be measured, and @media-arguments written, in ‘dpi’ for all media, unless W3C starts using the correct units for each media.

  14. June 14, 2006 by Kevin Marino

    I think DPI gets used, because even though DPI typically refers to a printer’s resolution (meaning ink dots per inch), using PPI which more accurately describes a computer screen might confuse people. this has a good description of the difference

    Now all that said. I think the resolution issue is a problem but maybe not as much as one would think. My laptop is high res and I know some sites will display sucky but that is my choice. Interestingly too, my laptop (WinXP) came with the Font DPI setting in properties set to 96DPI (icons looked HUGE!!). So I changed to 120 and things looked as I expected.

    So quite possible many people on new devices actually don’t have much issue. Its just us geeks.

  15. If all of this results in me being able to—simply—specify high-resolution images for high-resolution output devices (printers especially, but high-resolution raster displays too), I’ll be happy.

    Right now, producing image-laden pages that are standards-compliant, semantically marked up, and look good at both 72ppi and 600dpi is impossible cross-browser without nasty (and failure-prone) hacks which make me a sad web-monkey.

  16. […] A very accosting layout and a interesting discussion topic, do you provide any Web-based services to universities or students. […] - Sorry for the stupid question :-)

  17. Any idea when CSS3 standards will be implemented in the popular browsers (IE, Firefox, Safari..)?

  18. July 13, 2006 by Martin

    It’s about time for SVG to take off. This is just the sort of thing that SVG excels at. Way too many images on the web are lo-fi raster versions of something that was probably produced with Photoshop or Illustrator—something that should be served as vector graphics in the first place.

    Browser support is better than you might think. As always, IE falls flat on its face, but the Gecko-based Firefox includes (rudimentary) SVG support by default. Safari has (preliminary) support for it, and Opera leads the pack with full SVG Tiny support in all its incarnations.

    Eye candy on the web, that’s accessible, and an open standard? That’s the sort of thing that makes me a happy web-monkey.

  19. Ive been designing an ecommerce system thats capable of dumping a catalogue. Im not sure how friendly this is, but i simply use hires images (2400dpi) but limit their size on the page - looks good in the browser, zoom in (on IE) or print to pdf and the quality is perfect (and a damned site easier than trying to layout 40,000 products in quark)

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.