In my post yesterday, I outlined how to present high-resolution images in web pages using CSS media queries to users using a high-PPI screen such the iPhone 4's new Retina display. I also mentioned that while this works for background images in CSS, the only solution currently for carrying out this same substitution for images linked to using the <img> tag is to use JavaScript. Finally, I suggested that browsers should natively support substituting high-resolution versions of images when they detect that the user is using a high-PPI display. In this post, I'd like to formalize that suggestion a bit.
Authoring web sites to use resolution independent images that display beautifully on high-resolution displays should be made as easy as possible for developers and should not require JavaScript to accomplish.
To accomplish this, I propose a new HTML Meta Tag, resolutions, that can be used to specify that high-resolution versions of images linked to from the page are available and that the browser should use them in place of the lower-resolution default images if it detects that a user is using a high-resolution screen. The resolutions meta tag lists the device-pixel ratios supported by images in the page.
So, for example…
<meta name="resolutions" content="2x"
… means that the developer is telling the browser that she has created 2x resolution images for the images linked to from the current page and named them with a @2x suffix.
To illustrate, if her image tag is as follows…
<img src="/images/flower.jpg" alt="A flower">
… then she has two image files under /images: the low-resolution default (flower.jpg), and a higher-resolution (200%) version named flower@2x.jpg.
(This is the same naming convention already used by Apple in its Cocoa Touch framework for automatically loading in higher-resolution versions of images.)
Based on the meta tag, if the browser detects that the user is running at a min-device-pixel-ratio of 2.0, it will automatically ask for the 2x version of the image (flower@2x.jpg) instead of the default image as specified in the image tag.
Finally, so as not to flood external sites with high-resolution image requests, this functionality would only work for local images specified via relative links.
The resolutions tag can also contain a list of supported device-pixel ratios so as to support even higher-resolution displays when and if they become available in the future.
For example:
<meta name="resolutions" content="2x, 4x, 8x">
In this case, the developer would provide 2x, 4x, and 8x versions of all images. So, in the running example, she would make flower.jpg, flower@2x.jpg, flower@4x.jpg, and flower@8x.jpg.
The advantages of this approach are several:
I have to admit that I'm rather clueless about whom to contact about making this happen and wouldn't even know whom to approach in the W3C so I'm planning on leading my rather more clued-up friends to this post and seeing what happens. If you think that this is a good idea and want to point the right people here to get the ball rolling, I'd appreciate it.
Update: I've now submitted this as a proposal to WhatWG. Check it out on the MetaExtensions Wiki page.
And, of course, I'd love to hear your feedback and thoughts.
The Proposal for native browser support of high-resolution image substitution article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.I propose a new HTML meta tag, resolutions, to be used to implement automatic support for displaying high-resolution images in web pages to users on high-PPI displays like the iPhone 4's new Retina screen.
excellent post!
i’d love to see this tag implemented into HTML5. good luck!
-cm
Html5 is expected to be finally approved in 2022.
Isn’t a bit premature to talk about this issue of the resolution? :)
The process for proposing meta content values in HTML5 is actually very open. It’s all based around this wiki:
http://wiki.whatwg.org/wiki/MetaExtensions
Add your proposal there. Once you’ve done that, you can raise the issue on the WHATWG mailing list:
http://www.whatwg.org/mailing-list
The process is quite similar to the microformats process: it’s community-driven with an aim to get people with similar ideas for extensions collaborating rather than making fifty different ways of saying the same thing (proposing new rel values works in the same way).
On an unrelated note, your proposal reminds of an old proprietary attribute (from Netscape, I think) called “lowsrc” that went on the img element. It did the opposite of what you’re talking about: you could point to a low bandwidth version of an image to display while the high bandwidth version was being loaded.
Wonderful idea, Aral. I, too, struggle with having to “fix” everything with JavaScript, thus your proposal is very much welcomed.
I’ll wait for you to bring this up on the mailing list (as Jeremy indicated) and then join the discussion there…
For now… What about the base tag? Can’t base tag be used to specify a different folder for these images? We can even use mediaqueries to add conditions to the base tags… Just because I don’t like forcing a particular pattern on the filenames (“@2x”). This way the author could choose where to put the files for each resolution.
I just wonder if this approach gracefully degrades…
Either way, it’s a matter that we must deal with *now*. Go ahead, sir.
1) I’d like to see a tag version of this as well. What if I only have a high res version of one or two images on my page?
2) You could propose this to the whatwg mailing list (http://www.whatwg.org/mailing-list)
Aral,
Great idea! ;) I’ve written about & implemented something similar: Inline Multiscale Image Replacement
http://gasi.ch/blog/inline-multiscale-image-replacement/
Instead of resorting to images with different resolutions, we should strive for a standard multiscale image format (e.g. pyramid storage) which would allow us to stream images over the web. My approach is simply a proof-of-concept and is based on Flash. The guys at Seadragon (http://seadragon.com/ajax) provide the same in JavaScript. Ultimately, this should be implemented directly in the browser rendering engine, e.g. WebKit with support for JPEG XR.
Cheers,
Daniel
1. Implicit pattern substitutions are not a good standard. We use URLs on the web.
2. This should be per instance, not a global setting, it is a property of the images, not a global property.
3. The point about progressive rendering in the comments above is interesting; that was one solution I thought of, as you can do progressive rendering PNG too. Browsers dont know, and it does cause some issues, such as the fact that an HTML manifest would implicitly suggest downloading the whole image, although the browser could not do that either.
4. per tag instructions adds a lot of attributes, so does not seem very general
5. conneg is nice in theory, but not sure it is the best solution, as it is not that widely supported.
My current favourite would be 3, but off to see the comments on the mailing list now…
Another way would be to take care of this on the server side.
The browser could specify what resolutions it supports in the HTTP request headers, like it does with MIME types (HTTP-Accept). Such a solution would not double the number of requests.
Yes..this is great idea and this will make good for phone browsers