Apple is working on how to adapt the web for high-definition displays [via]: basically, zoom pages like Opera has been doing for years now (i.e., change the effective size of a pixel), while allowing web publishers to specify alternate high-resolution versions of their graphics so that upscaled web pages don’t look too blocky.
That would be very fine if they didn’t (quite expectedly) confuse backward compatibility with immobilism: while this is a rather major philosophical change, they’re trying as hard as they can to make it fit into existing HTML and CSS tags and attributes, and the only change to HTML they’re proposing is to add resolution-dependent CSS “media” types.
Their basic premise is this: to make a 100x100-pixel image, make it four or sixteen times as big, and use HTML or CSS attributes to specify the intended size. You can use conditional CSS to hide high-resolution images from regular-resolution browsers (although that will make a tangled mess out of your CSS files), but for <img> tags (and those are still necessary for contents — you’re not going to use CSS image replacements for your photolog) the only option Apple offers right now is making everybody download and then downscale a huge high-resolution image on the off-chance that one viewer might someday want to see it on a 30-inch screen.
So here’s the comment I posted:
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.png (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.
Want to know when I post new content to my blog? It's a simple as registering for free to an RSS aggregator (Feedly, NewsBlur, Inoreader, …) and adding www.ff00aa.com to your feeds (or www.garoo.net if you want to subscribe to all my topics). We don't need newsletters, and we don't need Twitter; RSS still exists.
Legal information: This blog is hosted par OVH, 2 rue Kellermann, 59100 Roubaix, France, www.ovhcloud.com.
Personal data about this blog's readers are not used nor transmitted to third-parties. Comment authors can request their deletion by e-mail.
All contents © the author or quoted under fair use.
