Proposal: Filenames as Metadata, or Solving Retina/2x Images

[TomPenzer]

In response to certain proposals I've seen lately, including <picture> and <img srcset="" />, I would like to offer what I think allows for what might be a significantly more convenient approach for authors to add support for double-pixel-density rendering displays, such as so-called Retina displays, and eventually higher densities in the future. By taking advantage of image variant filenames in a systematic way, we might allow for a more powerful way to express the availability of various pixel density image assets. I propose we add the following elements:

1) The new 'meta' attribute 'image-scaling' with arguments listed in the format {'scaling factor' : 'scaling filename key'}, where the filename key is the often-standardized string added to the filename for 2x assets, i.e. '_2x' (it might even be possible to specify a different filename extension for the 2x asset by detecting whether the 'scaling filename key' string contains a period i.e. 'xxx.xxx'). Sub-attributes to the 'image-scaling' attribute would include the optional boolean (defaulted to 'true') attribute 'assume-present', and potentially the optional attribute 'image-scaling-path' for cases where sites store their various scaled image assets in different directories than their 1x images.

2) A new series of optional attributes to the img tag named after the scaling factor, i.e. '2x', '4x', etc., (possible values include 'true', 'false', a string for the double-res filename key, or 'url()' to specify a completely different path for the asset corresponding to that scaling factor)

3) A series of new optional CSS properties named after the scaling factor, i.e. 'background-image-2x', 'border-image-2x' and 'list-style-image-2x' (possible values for these include 'true', 'false', a string for the double-res filename key, or 'url()').

A simple example usage of these new capabilities would be the following:

<meta image-scaling={2:"_2x"} />

The effect of adding this single line to the page would be that a user agent that wishes to display double-res images would then attempt to access 'filename_2x.ext' whenever it encounters an img tag like '<img url=("filename.ext") />', or a CSS property like '.class {background-image: url("filename.ext");}', '.class {border-image: url("filename.ext");}' or '.class {list-style-image: url("filename.ext");}'. For all these, in the case that the 'filename_2x.ext' file does not exist, a second request is made for 'filename.ext'.

If the bulk of the 2x-resolution images are located in a different directory than the 1x assets, the meta tag could be extended as such:

<meta image-scaling={2:"_2x"} image-scaling-path={2:"2x_images/"} />

Then, any 2x img or css-image assets would be requested from '2x_images/filename_2x.ext' instead of 'images/filename.ext'.

If a particular 2x img tag asset or css-image asset has a '@2x' double-resolution filename key instead of '_2x' for some reason (maybe you're integrating with some 3rd party off-site content with a different 2x naming convention), you could add a '2x' attribute to its img tag, such as '<img 2x="@2x" />', or to its css properties, such as '.class {background-image-2x: "@2x";}'.

If a particular 2x-resolution img tag asset or css-image asset is not located in the same directory as the 1x asset, or if the filenames and/or file formats are not identical to the 1x asset, a separate path could be specified by doing this: '<img 2x=url("path/to/filename_@2x.ext") />', or to its css properties by doing: '.class {background-image-2x: url("path/to/filename_@2x.ext");}'.

In the case that a majority, but not all img and css-image assets are available in 2x resolution, the img assets that lack a 2x version would include the a tag such as, '<img 2x=false />, or a css property such as '.class{background-image-2x: false;}'.

In the case that a majority, but not all img and css-image assets are unavailable in 2x resolution, you would add the 'assume-present={2,false}' attribute to the meta 'image-scaling' attribute, such as '<meta image-scaling={2:"_2x"} assume-present={2:false} />', and use the '2x' attribute to flag img assets with a double-resolution asset available, such as '<img 2x=true />, and the css with '.class {background-image-2x: true;}'.

In the case that no double-resolution image assets are available, the meta 'image-scaling' attribute can be simply omitted.

By using this approach, we avoid the need to specify the same list of filenames varying only by scaling factor filename key for every single image asset. We are also able to achieve the same level of performance for those willing to put in the extra work to flag assets that deviate from the default setting (to minimize requests), and we allow the flexibility to be lazy or wrong, and have the user agent make two requests in those cases. This solution is also completely backwards-compatible with existing browsers.

As a corollary to this, a similar approach could be used to add support for different image formats without losing backwards-compatibility, and again saving many precious developer-years. Imagine <meta image-formats={jpeg2000:".jp2"} assume-present={jpeg2000:boolean} />

[TomPenzer]

Meant to say when it encounters <img src=, not url=.

[TomPenzer]

I will note that this would not have the ability that the srcset implementation has to specify a different viewport size for the 2x asset than for the 1x asset. I will admit that I am confused as to why someone would ever want to do that, however, since the layout would be changed depending on which asset the client chose to load. Can anyone explain why we might want that capability?