There are a lot of discussions around Responsive Web design. One of the issues is how to serve the most appropriate representation for a given resource. Let me clear that. For a long time we put that into our HTML.
<img src="http://example.org/pussycat" alt="Cute Cat"/>
Plenty of people are currently doing acrobatic moves to be able to deliver the right image to the right devices, screen sizes and/or bandwidth. The issue is that it is a wider discussion, which is summarized by:
What is the appropriate content I should send for this user depending on its usage context.
We tried to come up with many solutions (Bruce article is jaw-dropping) where we duplicate the number of resources we want to deal with. This issue has been solved a long time ago… It is called content-negociation. The ability to serve different representations depending on the headers sent by the client.
The issue which hindered the HTTP content-negociation for a long time is the discovery one. How do I know which are the resources available so that as a client (the user agent), I decide which one is the best for me and not only rely on what the server decides for me.
Enter the old (never implemented) Transparent Content Negotiation in HTTP which addresses exactly the discoverability issue. The specification is old and might need some love to adjust to the current Web, but the principles behind it are still clever.
It addresses the issue with
- responsive images
- multilingual resources indexing by search engines. (See Multilingual User Generated Content and SEO)
Olivier Théreaux mentioned it in the past on W3C QA blog. How does it work?
The Alternates header is a header sent by the server for this resource, I have these choices, which one do you want.
So when the user-agent requests:
<img src="http://example.org/pussycat" alt="Cute Cat"/>
The server can answer
Alternates: {"bigpussycat" {size 1Mo} {dpi 300}},
{"pussycat" {size 100ko} {dpi 72}},
{"tinypussycat" {size 10ko} {dpi 72}
The client can decide the one which is more appropriate depending on its technical circumstances: low bandwidth, small screen and/or the user choice: I want only tiny images because it is the way I like it.
For search engines and multilingual resources, it help index the Web in many languages, still keeping the site usable in a multicultural context.
Potential issues
- HTTP Round Trip for the discoverability: Exactly like we do right now with background images for mediaqueries, we can send one the smaller images by default or having the client asking for the most optimal one through the initial headers. And then let people decide for the next ones.
\