Surfin' Safari

High DPI Web Sites

Posted by Dave Hyatt on Friday, April 21st, 2006 at 4:48 pm

One area of Web design that is going to become more important in the coming years is high DPI. For those of us working on WebKit, this will also become an issue for WebKit applications and for Dashboard widgets.

What is DPI?

DPI stands for “dots per inch” and refers to the number of pixels of your display that can fit within an inch. For example a MacBook Pro has a 1440×900 resolution on a 15 inch screen. Screens exist for laptops, however, that have the same physical size (15 inches) but that cram many more pixels into the same amount of space. For example my Dell XPS laptop has a 1920×1200 resolution.

Why does this matter?

Consider a Web page that is designed for an 800×600 resolution. Let’s say we render this Web page such that the pixels specified in CSS (and in img tags and such on the page) map to one pixel on your screen.

On a screen with 1920×1200 resolution the Web site is going to be tiny, taking up < 50% of the screen's width and half the screen's height. In terms of absolute size, the text will be much smaller and harder to read.

Now this may not be a huge problem yet, but as displays cram more and more pixels into the same amount of space, if a Web browser (or any other application for that matter) naively continues to say that one pixel according to the app’s concept of pixels is the same as one pixel on the screen, then eventually you have text and images so small that they’re impossible to view easily.

How do you solve this problem?

The natural way to solve this “high DPI” problem is to automatically magnify content so that it remains readable and easily viewable by the user. It’s not enough of course to simply pick a pleasing default, since the preferences of individuals may vary widely. An eagle-eyed developer may enjoy being able to have many open windows crammed into the same amount of space, but many of us would like our apps to remain more or less the same size and don’t want to have to squint to read text.

The full solution to this problem therefore is to allow your user interface to scale, with the scale factor being configurable by the user. This means that Web content has to be zoomable, with the entire page properly scaling based off the magnification chosen by the user.

What the heck is a CSS px anyway?

Most Web site authors have traditionally thought of a CSS pixel as a device pixel. However as we enter this new high DPI world where the entire UI may be magnified, a CSS pixel can end up being multiple pixels on screen.

For example if I set a zoom magnifcation of 2x, then 1 CSS pixel would actually be represented by a 2×2 square of device pixels.

This is why a pixel in CSS is referred to as a relative unit, because it is a unit whose value is relative to the viewing device (e.g., your screen).

CSS 2.1 describes how a the px unit should be rescaled as needed.

What’s wrong with zooming?

Zooming an existing Web page so that it can be more easily viewed has a number of immediate benefits. Text remains readable. Images don’t become so tiny that they can’t be viewed.

Doing naive zooming, however, will result in a Web site that – when scaled – looks much worse. (Try looking at what happens to images in Internet Explorer for Windows when you change the OS DPI setting from 96 to 120 for example.) Several factors come into play here.

For example, with text you don’t want or need to “zoom” it. In other words, you aren’t going to take the actual pixels for each character and scale them like you’d scale an image. Instead you simply use a larger font size. This will allow text to have a higher level of detail on high DPI displays and ultimately look more and more like the text you might see in a printed book.

For images, you first and foremost need a good scaling algorithm. You’d like for the image to look about as good as it did on a lower DPI display when rendered at the same physical size. However, the problem with scaling of existing images is that all you’ve done is maintained the status quo, when instead you could be designing a Web site that looks *even better* on these higher DPI displays.

How can I make images look better?

Consider a common Web site example: the use of images to do UI elements like buttons with rounded corners and fancy backgrounds. Let’s say the Web designer uses a 50×50 pixel image for the button. The rounded corners and background may look reasonably nice on a lower DPI display and even continue to look nice when the image is scaled by 2x but rendered at the same physical size on a higher DPI display.

What if you could use a 200×200 image instead? Or, even better, what if you used an image format that hadn’t hard-coded all of its pixel information in the first place? The use of either a higher resolution image (with more detail) or of a scalable image format allows for the creation of images that would look *better* when rendered on the higher DPI display.

Enter SVG

Safari actually supports PDF as an image format (the hands of the clock Dashboard widget are an example of this). However other browsers do not support this format. The agreed-upon standard for scalable graphics on the Web is SVG.

Find out about SVG

SVG stands for Scalable Vector Graphics and is an XML language for describing two-dimensional images as vector graphics. Describing graphics in this fashion allows for the creation of images that will look better on high DPI displays when rendered at the same physical size.

Our goal with WebKit is to make SVG a first-class image format, so that it can be used anywhere you might use a PNG, a GIF or a JPG. In other words, all of the following should be possible:

<img src="tiger.svg"/>

div {
  background-image: url(tiger.svg)

li {
  list-style-image: url(bullet.svg)

Our current thinking regarding SVG images used this way is that they would be non-interactive (in other words you can’t hit test elements inside the SVG’s DOM). It’s debatable whether or not script execution should be allowed when SVG is used this way.

These are some issues we’d like to hammer out, since we view this use of SVG as being very different from SVG included explicitly in a compound XHTML document or included via the use of an <iframe> or <frame> element (where scripting and interactivity would be supported).

Size Matters

In addition to supporting scalable image formats like SVG, we want to make it possible for Web designers to continue to use image formats they are familiar with (like PNG, JPG and GIF), but give them the capability to conditionally include higher resolution artwork.

The idea behind this approach is that a much higher-resolution image can be specified and then either used only if the resolution is detected to be high enough, or downscaled on lower DPI displays.

In order for this approach to be viable, every place where images can be used today must support being able to specify a size in CSS pixels so that the higher resolution artwork can render with more detail in the same amount of space. (This will become clear with the examples that follow.)

In addition we would like these approaches to degrade gracefully in browsers that don’t support high DPI Web sites yet.

Let’s go over each of the places images can be used today.

The img Element

The img element already supports specifying explicit sizes, and so today you can specify a width and height and if an image is larger it will be downscaled. In a high DPI system where 1 CSS pixel != 1 device pixel, more detail can then be rendered.

In other words how you scale an image is based off comparing *device pixels* and not CSS pixels. For example, if you have a zoom factor of 2, an img tag that specifies a width and height of 100 CSS pixels, and an image whose intrinsic size is 200×200
device pixels, then that image is not scaled, since 100×2 = 200. However on a lower DPI display that might not have any zoom factor set, the 200×200 image would be properly downscaled to 100×100.

If no CSS size is specified for the element, then the size of the element in CSS pixels is simply the image’s size in device pixels. This will result in the image obeying the zoom.

This approach degrades gracefully, with the only tradeoff being that the higher resolution artwork would be slower to load on low DPI displays that couldn’t render all the detail anyway.


For backgrounds the problem is that you need to be able to specify the size of a background tile in CSS pixels. CSS3 has a new property that we now support in WebKit called background-size. This property allows you to specify the size of a tile in CSS pixels, and thus enables backgrounds to support higher DPI artwork as well.

If no tile size is specified (as is the case on the Web today), then the size used is the image’s intrinsic size in CSS pixels. Existing background images on the Web will then obey the zoom automatically.

However once you can specify a tile size in CSS pixels, then the way the image scales can then be done using device pixels. Using the background-size property inside the background shorthand can allow for a degradable approach that won’t mess up in other browsers.

For example, let’s say you have an image tiger-low.png that is 100×100 and an image tiger-high.png that is 200×200. Here’s an example of how you might make a CSS declaration that can use the low-res image for browsers that don’t understand background-size and the higher-resolution image for browsers that do.

div {
  background: url(tiger-low.png);
  background: url(tiger-high.png) (100px 100px);

In the above example, both declarations result in a tile that is the same size in CSS pixels, but on a high DPI machine with a zoom factor of 2, you will be able to see all of the additional detail of the higher resolution image.

Browsers that don’t understand background-size specified in the shorthand will throw out the entire second declaration. Browsers that do understand it will overwrite the previous background declaration.

List Bullets

As with backgrounds the trouble with list bullets using images is that you have no way of specifying the size of the list bullet in CSS2. Luckily CSS3 has a solution for this problem as well.

The ::marker pseudo-element can be used to style a list bullet. We plan to add support for this pseudo-element to provide much more control over the images used by bullets.

Once you can specify the size of the marker, then the same rules apply as in the previous examples.

li {
  list-style-image: url(bullet-low.png);

li::marker {
  content: url(bullet-high.png);

In the above example, let’s say that bullet-low.png is 10×10 pixels and bullet-high.png is 20×20 pixels. With this approach, only if the browser understands the CSS3 list marker pseudo-element, the image will be replaced by a higher-resolution version, and thus more detail will be shown when zooming on a high dpi display.

Border Images

Safari supports the CSS3 border-image property. This property essentially already works, since in the places where tiling is used, the tiles get scaled to match the widths of the borders.

The only open issue right now is tiling in the center, since right now the spec states that the center tile is not scaled. Hopefully some heuristic will be chosen that will scale the center tiles based off the border widths (e.g., using the left/top border widths). This issue can be worked around by using border-image only to render the border and using background with background-size to tile high-resolution artwork in the center.

Conditional Inclusion

The above approaches allow you to go ahead and mingle low-res and high-res rules, but this approach can get somewhat cluttered. In addition the approach only works for two different images. What if you want to offer more than 2 versions of your artwork, e.g., low/medium/high images?

Our proposed solution for this problem is to extend CSS Media Queries with a new media query feature, the CSS pixel scaling factor.

Media queries allow a Web site author to write rules that should only be matched conditionally based off features of the device (like the viewport width/height, the screen dimensions, the screen’s DPI, etc.). Unfortunately media queries do not include the ability to query based off the zoom factor. This feature is necessary in order to really understand what’s going to happen with images.

Media Queries

We plan to add a new feature, device-pixel-ratio, that can be queried to find out how a CSS pixel relates to a device pixel. Min and max versions of the feature can be supported as well.

You can then construct queries like so:

<link rel="stylesheet" media="screen and min-device-pixel-ratio: 2"

With CSS3 media queries you can then build Web sites with completely different CSS files based off the pixel-ratio of CSS pixels to device pixels, including higher res artwork as necessary.

This approach also degrades gracefully, since you can specify the lowres CSS file and then higher res CSS files inside media queries that will be ignored by browsers that don’t understand them.


This is a preliminary proposal for how to make great high DPI Web sites in such a way that the higher resolution images can be incorporated cleanly into an existing design.

We welcome your feedback (either in this blog or to and are hopeful that other browser vendors will also get involved in this discussion so that concrete standards in this area can be hammered out.

67 Responses to “High DPI Web Sites”

  1. Kit Says:

    I’m very, very impressed that this sort of work is being done; Web Design is getting stagnant with people using just styled block-level elements to produce artwork. The incorporation of SVG into sites excites me a lot.

    How long do you expect it will take for this sort of technology to be widespread? Obviously you can only speak about WebKit realistically, but if it’s going to take ten years for IE Win to gain (full) support, we can’t design with it.

  2. Francisco Tolmasky Says:

    Would it be possible to have a unit that refers to real pixels, and not relative ones? I imagine there might be certain applications that may benefit from this. Possibly a way to specify the zoom factor yourself (and keep it at 1) that could also be overrided by the user?

  3. Phrogz Says:

    Hallelujiah for SVG. Though the editors that are out there seem still quite raw, the underlying power and promise of SVG is awesome. Way to be forward-thinking, team!

  4. Trackback from change inertia:

    Scaling the web

    Scalable Vector Graphics are theoretically the way forward for creating graphical elements which can scale and change dimension based on the size and requirement of the page…. The current path to using SVG has not yet been defined – till today’s p…

  5. Randy Peterman Says:

    Kit: The Adobe Acrobat plugin comes loaded with SVG capabilities for IE. If you have IE running with that plugin then you can use SVG. Try it out (if you dare).

    Firefox and Opera both support SVG – I think once Safari has this capability built in cleanly, we’re in good shape for SVG.
    Am I reading this correctly that y’all want to NOT allow DOM access with JavaScript for SVG objects? Please include that as it will help developers create more dynamic sites.

  6. Alex Mc-J Says:

    “Am I reading this correctly that y’all want to NOT allow DOM access with JavaScript for SVG objects?”

    From what i read, they wont enable interactivity when the SVG file is loaded via a img tag or via a *-image css rule (like background-image), but interactivity will be enabled when it’s included via a object tag or included inline in XHTML douments.

    So, if you include it like a image, it will behave like a image, if you include it like a object (like you would flash) or embed the SVG directly into the markup of the document, it will behave like a normal SVG file, with access to the DOM.

  7. cying Says:

    This is great stuff, David. This is actually how Openwave’s Mobile browser supports SVG (at least while I was working on it). We supported it everywhere that images are supported; they’re composited just like PNGs and animated GIF.

    We had left them non-interactive ourselves, exactly as you propose here. Just with that, we were able to put together some pretty nifty compound XHTML content (which I’d love to share but only Openwave has ’em.).

    I’m glad to see Safari supporting this in a similar manner and look forward to authoring some desktop versions of some compound XHTML+SVG stuff.

  8. keithkml Says:

    This is exciting. However I think the proposal for img tag scaling does not take into account images which do not scale gracefully, and require separate graphics for different sizes. For example many people like to design 32×32 icons pixel-by-pixel, and make larger icons with vector graphics software like Illustrator.

    In general I think a better way to handle this would be to allow DPI specification in the image files themselves, so a 1024×768 image would not necessarily take up 1024×768 pixels. However this would be much harder to see widespread adoption, then modifying the browsers.

  9. Pingback from The Shallow End » Blog Archive » High DPI Web Sites:

    […] ites An interesting look at how high DPI displays will influence the future of web design This entry was posted on Saturday, April 22nd, 2006 at 6:43 am and is fi […]

  10. dvirasoro Says:

    I agree 100% with all you have said and I am very happy to see the direction Safari is taking… excluding your last point on the conditional inclusion.

    Safari has grown but it still has only 4% of the market. I really like Safari, but I don’t think you are in the position to start having Webkit only features (yet). On the other hand, if you managed to push some other browser to implement something similar, or even better the W3C to include it, then it would be another story. But otherwise it sounds just like a waste of time.

    All imho, of course.

  11. graouts Says:

    I’m very glad that you the WebKit truly understands the advantages being brought by SVG when it comes to Web design. The W3C Compound Documents group has actually been looking at integration issues of SVG within XHTML and CSS, and their findings I think are much aligned with what you’re talking about here. Thanks for leading the effort in implementing all this!

  12. Dimitri Bouniol Says:

    Before adding Magnification to WebKit, you should also consider the fact that future versions of Mac OS X might have a magnification feature built into the system like the “Quartz Debug” App (included with developer tools) does. If both WebKit and the system use magnification, web pages may appear too large, scaring the user into using another user agent.

  13. xfinite Says:

    I would think that the WebKit team is fully aware of Quartz zooming and that the WebKit zoom level is directly linked to the system zoom level. System zooming has to be implemented per widget, and a WebView is just another widget that needs a proper zooming technique, as the system zoom feature is unaware of CSS and whatnot.

  14. pauld Says:

    I disagree with Kit and dvirasoro; I think it’s great that Safari is leading the way with CSS 3 implementation. Camino/Firefox and Opera won’t be far behind, and I think we’re stuck with a future where users of those browsers get one experience while IE users get an inferior experience. There’s really no way around that, but all these features degrade nicely enough.

    All that said, there are still a fair number of CSS 1 and 2 rendering bugs that should probably be fixed before more CSS 3 gets implemented. I’ve filed a couple of bug reports myself.

  15. Pingback from Jason May’s blog » Blog Archive » SVG plans for Safari:

    […] « Fixing Excel charts SVG plans for Safari High DPI Web Sites (via Surfin’ Safari) Discussion of representing web page images in higher resol […]

  16. soosy Says:

    One thing that will really help resolution independence is wide-spread browser support for CSS3’s rounded borders and drop shadows, which should help eliminate the need to use bitmaps for many design elements. The more drawing the browser can do, the better, imo. Kudos to the Webkit team for being the first to implement many of these things. I bet resolution scaling was part of your master plan all along.

    On the subject of eliminating bitmaps, gradient support in CSS3 would be tremendous. (I’ve not followed closely enough to know if this is near happening or not.)

  17. Pingback from Joost de Valk - Weblog - Blog Archive » High DPI Web Sites:

    […] Hyatt raises a VERY interesting question on the Surfin’ Safari blog. He talks about High DPI Web Sites and how this could be the future of browsing the web. I’ll chew on this one over […]

  18. Pingback from a.css, esbudellant estàndards » Web d’alta resolució:

    […] a resolució 23/04/06 Al blog de WebKit en hyatt ha escrit un article anomenat High DPI Web Sites on explica molt bé el perquè els pixels es cons […]

  19. grda Says:

    let ems be scalable. but pixels? forget it. when i say pixel in CSS, i *mean* pixel, dammit!

    “device pixels”? “CSS pixels”? this way madness lies.

  20. mugginsm Says:

    I thought pretty much the whole *point* of non-pixel units in CSS was to solve this problem, and this was why we’re not supposed to use pixel measurements in layouts?

    Existing sites that have been written with hard pixel distances all over the place, are *already* broken for those of us with wide screens or non-standard font sizes, and the complete lack of caring about this from most authors indicates to me that they’re not going to care about high DPI users either.

    If sites are specified using em units, the only problem left is that bitmap images will get smaller and smaller, but can’t you set the width and height of IMG in CSS anyway?

    For serving different images to different DPI displays, I guess the cleanest thing would be to put the DPI in a request header, just like we currently put preferred language and image formats.

  21. Ashok Says:

    I’d love to use SVG in IMG tags, but served from a location that does content negotiation, and serves a bitmapped format if someone doesn’t accept SVG.
    The trouble with that is that I’d then like to set some lengths and sizes to be exactly the pixel size, if it was a bitmapped format (given the slack-jawed scaling you get in most browsers) or something in ems if it was scalable.
    I can’t figure out how to do that yet. I’m guessing it will be possible in CSS, overriding the height/width in an HTML page. If there was a rule to say ‘if you can scale this sensibly, set the size to…’, that might be handy, but I’m not sure I’ve thought this all the way through.
    Or, if enough people have SVG support having slightly ugly, scaled bitmap images for the rest might not be so bad.

  22. theallan Says:

    This is certainly a very interesting perspective. And its great to see the WebKit team are taking SVG so seriously. I’ve been following WebKit’s development of SVG and I’m quite impressed, although there are one or two ‘primary’ features still missing – in-particular animation. This is one of the big draws of SVG and I can’t wait for WebKit to include it. And idea on an eta?

  23. daesan Says:

    While I applaud the efforts by Safari team to address this high DPI issues, I’m a bit worried that this approach, albeit quite complete, might be too complex to catch on with web developers.

    I propose something much simpler and less complete. Never use “em” or other relative units for font sizes, use only “px”, or “pt” which are absolute units. Come up with a way of web browsers to recognize the monitor’s true DPI values. Use a better image scaling algorithm. (and/or scalable image formats like SVG) Build a zoom feature that scales both texts and images. Let users to specify preferred scale values for each web site.

    I think many of the complication regarding high DPI arose from the fact that traditional image formats were not cleanly scalable like font sizes and OS doesn’t recognize the DPI value for the monitor. So fixing those two should solve the problem. Adopting things like “device-pixel-ratio” will only complicate the matters still more, I’m afraid..

  24. darobin Says:

    In case you’re interested, the SVG WG worked on multires content for a while:

    It’s currently dormant as all 1.2 Full things, but there was good discussion about it which you might be interested in digging through.

  25. Snip Says:

    What an EXCELLENT blog! I have added to my RSS feedreader, for sure!

    Must say that I am somewhat distressed by the possibilities outlined in this article… as if we don’t have enough issues to deal with, we will soon be having to contend with 72/96 and (can you see it coming?) hi-def vs standard TV monitors… with SONY bringing out some proprietary stuff we will have to hack for.

    Sigh… just when you think maybe, just maybe, you have a clue…

    BTW: New here.. I cannot particularly recommend visiting the site in my profile. It’s my ‘other’ business site, and will be updated in the next week or two, but right now it is a very 2003 site 😉

  26. simonl Says:

    The CSS authors have made many really bad decisions, and the “relative pixel” is only one of them. It is the same as redefining “foot” or “meter” to something relative to your distance to it.

    CSS already has real relative units (em, ex) and web programmers should learn to use them. Those who do not are cursed anyway and the “relative px” will not help that.

    The CSS group is obviously confused about it themselves: They call px a relative value, but the fact is that they redefine it to an absolute, namely 1/90 (CSS1+2) or 1/96 (CSS3) inch. Alas, a “pt” is defined as 1/72 inch, and is listed as an absolute value.

    px is actually useful, especially when you build and manage the entire interface in JavaScript, say “web application”. For things like moving/dragging things around, or aligning them dynamically, you really want to work with real pixels. If I place something blue at position 0,0, I do not want the white background to shine through as a thin white line to the left and top because of rounding errors.

    By the way there is already a simple way to detect DPI in JavaScript, provided that the OS and browser implement them right: Create a div with width=height=1in, then query it’s pixel size (offsetWidth/offsetHeight). That is the real “dots per inch”, and I am sorry if the browser feel the need to mess that up.

    What needs to be fixed is:
    1) Browsers should ignore the “relative px”, and it should be removed from CSS specs.
    2) The browsers’ em/ex should be more reliable. There are too many cases where some browsers do not implement font-size inheritance (hence em/ex) correctly.

  27. thelem Says:

    You’ve described the advantages of this very well, but I’m still very skeptical that it is a good idea to redefine the size of a pixel. All it is going to do is make web design more complicated and less reliable in the future, in much the same way today’s user-agent strings have made user agent sniffing stupidly complicated.

    If high resolution screens are making pages too small, then implement page zoom in the short term and in the medium term web designers will see what is happening and redesign their sites accordingly (perhaps using cm or em units)

  28. nickfitz Says:

    @thelem and others: nobody’s redefining the size of a pixel. Read CSS 1 and it’s defined very clearly: a pixel is not a device pixel, it’s a relative unit which is mapped to device pixels as appropriate for the device’s pixel density.

    I’ve been trying to make designers understand this for years, but they never seem to get it. Perhaps now that Dave H has opened this debate people will actually take the trouble to read the standard and realise the difference. But the simple fact is that, if you design with the belief that a CSS pixel is equal to a device pixel, you are not designing in accordance with the W3C standards. Consider the case of a print stylesheet which uses pixel units; you’d need a microscope to read the printed page if a CSS pixel equalled a device pixel. This article is merely pointing out that the same rules must in future be applied to displays as their pixel density increases. No redefinition is involved; it’s been this way since 17 Dec 1996.

  29. Pingback from Blog > Around the web:

    […] widget | Semiologic The Fallacy of Dual Boot How-to set up BBReply on BlackBerry 8700 (c) High DPI Web Sites Daring Fireball Linked List: Safari User Growth Popularity: 1% […]

  30. #cb Says:

    Since this is all about the images, wouldn’t it be orders of magnitude simpler, and more logical, to just modify graphics file formats instead? Couldn’t SVG and PNG files (nevermind GIF and JPEG since we’re talking about new content development, so obsolete file formats don’t necessarily have to be supported) maintain backward compatibility while having some metadata to either include the additional pixels or reference the high-definition versions?

    Imagine this: make your navigation buttons in 300 dpi in Photoshop, check a box when exporting to specify saving to a 72 dpi base, and the PNG holds both versions, with the complementary pixels hidden from older browsers’ view.

    Or this: edit your photograph in 300 dpi in Photoshop, check a box when exporting to specify the creation of myphoto-72dpi.png, myphoto-150dpi.png and myphoto-300dpi (or more), with each file containing references to the others. That way, a browser downloading the 72dpi version from an img tag will know to refer to the 300dpi if the display resolution warrants it, and a graphics program editing the highest-resolution file will know to update the others accordingly.

    Okay, in both cases there’s a bit of bandwidth spoiled, but if a visitor is going to download the 300dpi version of your picture, having downloaded the 72dpi version before will almost be negligible.
    Besides, your proposed implementation is only bandwidth-efficient for decorative/navigational images, but not for content (e.g., photos published on a blog or gallery, where you can’t practically use CSS stylesheets to choose which version to download): the highest resolution image will be downloaded every time, and downsampled by the client. That’s a waste of bandwidth, CPU time, and RAM, and for now it looks ugly on Windows browsers (which don’t resample but resize pictures, unlike OS X).

    Actually, the simplest way would be server-side content-negotiation — with the browser sending its virtual display resolution as an http header, and receives the right image file in response — but then it would be up to each webhost to decide whether to upgrade its web server, whereas with improved graphics file formats it’s up to each and every content publisher to decide if they want to use a program that knows how to output such files.

  31. Pingback from Like Your Work » Blog Archive » links for 2006-04-24:

    […] Digg Defender: A Plugin For WordPress by Elliott Back (tags: wordpress plugins plugin) Surfin’ Safari – Blog Archive » High DPI Web Sites (tags: apple mac) Mac OS X Hacking Tools (tags: a […]

  32. egorFiNE Says:

    You may want to take a look at this library:

  33. keijo Says:

    If you are having trouble with tiny text in your browser because of your resoltion you might want to give opera a try… it can zoom images and text and layout doesnt suffer only things that sometimes dont go right are flash animation since you are not able to zoom them with operas + and – =(. I personally choose opera because of this feature since i have 1800x res monitor and i dont want to read one word a hour speed and like you said it is imposible to make fonts bigger in your windows since some games go nuts because of that.

  34. Pingback from Mac Web Design » MacTheWeb » Screen size meditations:

    […] « Taming Typography Screen size meditations Dave Hyatt has in interesting piece on the why and how of dealing with high resolution monitors in web de […]

  35. Pingback from High DPI Web Sites / Web Words / WizarDev:

    […] hat cram many more pixels into the same amount of space. (Article dated: April 21, 2006) Read the Article… Ap […]

  36. Pingback from fuzzz » Blog Archive » Designing for high DPI websites:

    […] laquo; Microsoft’s Mac Lab Designing for high DPI websites The good folks on Apple’s Webkit team have posted a thoughtful article on the future requirement for ha […]

  37. Pingback from fuzzz » Blog Archive » Designing for High DPI sites:

    […] « Microsoft’s Mac Lab Designing for High DPI sites The good folks on Apple’s Webkit team have posted a thoughtful article on the future requirement for ha […]

  38. Michael Z. Says:

    The object element wasn’t mentioned as a place where images appear—it’s similar to img, but has some important advantages, and with MSIE 7 being introduced, we may be able to actually start using it on web sites as intended.

    For starters, a PNG/GIF object nested inside an SVG object would allow older non-supporting browsers to load and display a raster image, while a browser with native SVG support or a plug-in would load and display the vector artwork instead.

    Since nested objects load based on their mime type, perhaps a new mime type incorporating image DPI could be used to offer a better image to a newer browser. Something like could load in hi-res displays, a nested graphic with the standard “image/svg+xml” type in other SVG-supporting browsers, and finally a plain old could be nested in the middle for the benefit of others. Adoption of the new mime-type would make this work, without an extensions to (X)HTML at all.

  39. Michael Z. Says:

    Woops, the weblog wiped out my code examples (preview would be nice). This makes more sense anyway:

    <object type=”image/svg+xml” data=”example.svg”>
    <object type=”image/png+300dpi” data=”example-hi.png>
    <img src=”example-low.png” />

  40. Pingback from Navarik : Building web browsers for true high resolution : The Marine Data Network™ :: Software for Maritime Shipping:

    […] browser, and proposes sound technical ways to make browsers, web pages, and other programs work with higher resolution displays, using a “scaling interface” (also see his followup). Th […]

  41. Pingback from Matthew David Waymost » Blog Archive » An Amalgam of Thoughts:

    […] other news regarding the internet world, Dave Hyatt has written some blog posts regarding Hi DPI Web Sites. With the inevitable introduction of high-resolution monitors (they have to come around […]

  42. frankus Says:

    > This approach degrades gracefully, with the only tradeoff being
    > that the higher resolution artwork would be slower to load on low
    > DPI displays that couldn’t render all the detail anyway.

    The problem is the lousy resizing most current browsers do to images scaled in this way: most do nearest-nieghbor rather than bicubic, so scaled-down images look like crap. For scaling up, there’s the occasional website that depends on the nearest-neighbor algorithm (like the old WIRED logo), so simply doing a bicubic at all times is probably going to break a few sites.

    I’d like to see a “resample” attribute (looks like IE7 uses the “interpolation” style property) that lets you specify how you want to scale things.

  43. Pingback from Chekhov’s gun » High DPI websites:

    […] · Filed under Uncategorized When i began with webdevelopment (1998) this was already an issue (although then the question was: “are we allowed to design for users with […]

  44. Pingback from Pig Pen - Web Standards Compliant Web Design Blog » Blog Archive » High DPI Websites:

    […] « The Great Microsoft Blunder High DPI Websites High DPI Websites This entry was posted on Wednesday, April 26th, […]

  45. Pingback from Moka-Break » Blog Archive » HDPI Displays & Hi-Res UI:

    […] ttle storm in a tea cup recently when he posted his thoughts about how Safari might handle displaying web sites on High Resolution Displays. David has […]

  46. Pingback from tdog blog » Blog Archive » Nice Unit.:

    […] « Happy April Nice Unit. Dave Hyatt recently posted (and again) about what webkit is considering doing concerning the inevitable high resolution displ […]

  47. Pingback from Pascal Pensa // High DPI Websites:

    […] arch: High DPI Websites High DPI Websites Wed, 26 Apr 2006, 08.05



  48. Pingback from High DPI wbsites » design and other revelations:

    […] Posted by 6ft5 at April 26th, 2006

    Is there a need for webpages in high resolution? This article claims there is. […]

  49. core Says:

    I don’t understand why you’ve introduced the ::marker pseudo-element. Surely to be consistent with how you’ve extended background with a background-size, you should extend list-style-image with list-style-image-size and the extra parameter to the compound list-style-image – such that, much as you have:
    background: url(tiger-low.png);
    background: url(tiger-high.png) (100px 100px);
    you would also have:
    list-style-image: url(bullet-low.png);
    list-style-image: url(bullet-high.png) (100px 100px);

    (I do, however, have to second the view that we do need an absolute unit, and that that unit should be px – let’s fix up the problems with em/ex, and let px keep its current usage, since we regularly need per-pixel positioning, esp. in interactive webpages!)

  50. ChrisDodd Says:

    I’m amused by the “Becoming more important” line in the first paragraph. This has been a HUGE problem for years — ever since HTML-2.0 was introduced to be more of a layout language and less of a markup language. For an example, you just have to look at this site. Why is all the text crammed over on the left side of the page with a big blank space on the right side? Why is the default font tiny and unreadable? Fortunately most browsers now let you override the latter problem.

  51. Pingback from -TMA-1- » Blog Archive » links for 2006-04-28:

    […] : Food) ThickBox – One box to rule them all. (tags: Tech WebDev JavaScript ThickBox) High DPI Web Sites (tags: […]

  52. roc Says:

    This all sounds good to me as a Gecko developer.

    The status of SVG s is a good question. Clearly you want event targeting and selection to treat it like any other image. You also need to disallow access to the SVG DOM because IMGs can historically have a non-same-origin SRC.

    If you disallow scripting and SMIL animation, then you can optimize by rendering the SVG to a pixmap and then throwing away the DOM. But since you can have animated GIFs, why not animated SVGs? And if you allow SMIL animation, why not Javascript animations? Hmm, tough call. I think it might be best to allow scripting and SMIL animation simply because other browsers will always be tempted to allow it as an “extension”. It should be fairly easy to detect the absence of scripting and SMIL animation and use the pixmap optimization if appropriate.

  53. Pingback from Monday, April 24 link dump :: tiffany b. brown // v 4.1:

    […] ne and offline … I think … but then I’m not sure I get it. [Via Jaschu]. High DPI Web Sites Tips for designing for high DPI screens. [Via Veerle] Office 2.0 Database A list of ki […]

  54. Robert O'Callahan Says:

    Actually, optimizing by rendering SVG to a pixmap and throwing away the DOM is not possible, because zooming in or transforming the image wouldn’t give good results. So I don’t see a reason to disallow SMIL or Javascript in SVG s.

  55. doekman Says:

    I have a solution for using highrez photo’s with the image tag. I thought the img-tag used to have the @lowsrc-attribute (although I cant find it in the HTML specs, it is present in the DOM1 spec). Maybe introduce a highsrc attribute with a list of dpi/url pairs:

    [img src=”me.jpg” highsrc=”150dpi@me-150.jpg; 300dpi@me-300dpi.jpg” style=”width:400px” alt=”me”]

    In this way a website still loads quickly, and looks awsome on high-rez screens and paper (when using Safari 3.0).
    The thing you need to consider: are bigger pictures really that troublesome to add complexity. With other words, does:

    [img src=”me-300dpi.jpg” style=”width:400px” alt=”me”]

    takes too much time for 90% of the webusers in, say 2 years…

  56. Pingback from The Daily Warthog » Blog Archive » The Next Big Thing - Vector / Hi Def Websites:

    […] e may be skewed, in which case here are the real techies talking about it: High DPI Sites Blog Leopard feature overview Apple Resolution Independant UI (the basis of this story sys […]

  57. Pingback from The Vent Core » Blog Archive » PDF in Safari:

    […] « Cringely is a Loon PDF in Safari I was reading the Surfin’ Safari Weblog and read that safari supports embedded pdfs! Very interesting! It’s not a […]

  58. Pingback from Max Design - standards based web design, development and training » Blog Archive » Some links for light reading (8/5/06):

    […] 006 Neutrality of the Net Using javascript instead of target to open new windows High DPI Web Sites Skip Link Pros and Cons Web Accessibility in UK Small Businesses Build Half a Produ […]

  59. Pingback from Tip(z) » Högupplösta webbplatser:

    […] t högupplösta skärmar. Problemet granskas av hyatt i några artiklar på Surfin Safari. High DPI Web Sites, part 2, CSS Units
    Inga kommentarer

    Inga […]

  60. Pingback from otro blog ms » Unos cuantos de desarrollo web (XCIV):

    […] ‘men rollover la mar de apaado. An de CSS, pero ms ‘para pensar’ son High DPI Web Sites, sobre los pr […]

  61. Pingback from el factor humano » Archivo » Tamaños de Pantalla, Resolución, Móviles y el Cambio Permanente:

    […] ensidad de píxeles mucho mayor en un menor espacio. En esta oportunidad no me detendré a comentar el impacto de las pantallas de alta definición, que agregan otro factor de incertidumbre y pued […]

  62. Pingback from Vladimir Vukićević » DOM-less SVG:

    […] difficult to actually ship as an image handler. I think that the WebKit guys are going down the same route, at least as of last April, and I think it’s the right way to go. I […]

  63. Pingback from el factor humano » Archivo » Resolución de Pantallas: Marzo de 2007:

    […] s alta resolución (más puntos por pulgada, dpi), además del tamaño (más sobre esto en High DPI Web Sites y High DPI (Part 2)).


  64. Pingback from Resolución de Pantallas « Cosas sencillas:

    […] s alta resolución (más puntos por pulgada, dpi), además del tamaño (más sobre esto en High DPI Web Sites y High DPI (Part 2)). Visto en: FACTOR HUMANO Esta ent […]

  65. Pingback from Broken Links » Blog Archive » SVG waiting in the wings:

    […] . Being a vector format, it can also be resized without loss of quality, so is perfect for High DPI websites. In short, it’s […]

  66. Pingback from CSS, JavaScript and XHTML Explained » Targeting Safari 3.0 with CSS:

    […] For more on Safari and DPI visit Webkit’s High DPI Web Sites blog entry. […]

  67. Pingback from Painfully Obvious » Blog Archive » Thought: WebKit Blog & iPhone:

    […] with the two-finger zooming in Safari, I remembered Dave Hyatt’s April 2006 blog post on high-DPI web sites. Eerily prescient in hindsight, he argues that web developers should make sure their images can […]