Responsive Images: Why Do We Need Another Tag?

I recently started to read about responsive web design, and quickly hit the image problem. This can be summarized as "How to deliver the correct images for a given device?"

There are a lot of approaches using JavaScript user agent sniffing to tackle this problem, but none of these appears to be satisfactory. I also came across this proposal of the W3C Responsive Images Community Group. Regarding past problems in browser implementation, I am not at all enthusiastic about having a new tag with complicated semantics to support in browsers' code bases.

I suggest this approach, although they say that attempts at changing the processing of <img /> tags was shot down by vendors (why? please educate me):

Use a new meta tag for images or other media in the same way than "base", only with different values for different types. Eg:

  <meta type="base-img" condition="CSS3 media selector statement" url="some url" />
  <meta type="base-video" condition="CSS3 media selector statement" url="some url" />

That should mean: Load images from a different base URL than ordinary stuff if their src is relative, and videos from another URL. Expand this scheme to cover all interesting things (<object />, <video />, ...).

  In effect, this should construct a tree for accessing resources,
  that the browser can evaluate as it wants to.

The idea is that web site owners can pre-compute all desirable images and stuff, and place them where they find things convenient, and that browsers don't have to do much to actually request them. I expect these additional benefits over the suggested <picture /> tag off the top of my head:

  • Since image (or object) URLs are stable, caching is not a problem.
  • Since image URLs are stable, images can be statically pre-computed, and statically served from low-power servers.
  • By using CSS media selector statements, required computing power on the client should be small, improving battery life.
  • Since the method uses CSS3 media selectors, user agent sniffing is not required (= requires little power on the server).
  • Except for maintaining the tree of base URLs and using it to calculate image paths, no changes to the process of digesting the "HTML soup" are required.
  • Bandwidth to convey the required information is reduced to a few <meta /> tags per page, not the rather verbose <picture /> tag.
  • The method is extensible to other content types.
  • The method requires no re-learning for web designers.
  • The method is compatible with existing design tools, as it does not change the user-facing part of the <img /> tag in any way.

In case a <meta /> statement for a given tag would not be present, the browser would fall back to the next best resource type. I suggest this hierarchy:

  1. Not specified: Use the default method of calculating the base URL.
  2. Standard <meta /> tag: Same - keep the existing behaviour.
  3. Specify base-img as the value to the type attribute <meta />: Use this for all heavy objects.
  4. Specify base-video as the value: Use this for videos, but continue to use other methods to find images.
  5. Conduct a topological search for base URLs, eg using this ordering: (nil) (base) (img) (object) (video) ....

Yes, I am very late to the discussion, but would still like your input and pointers to relevant arguments. Thank you!

License of this text: CC-BY-NC-NA 3.0