[webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set

Tom Penzer tpenzer at mailcan.com
Mon Apr 23 14:44:09 PDT 2012


Hi Everybody!

	As a first-time poster, I am sorry ahead of time for any lapses in  
etiquette. I am seeking feedback for my (hopefully relatively painless  
in practice compared to the alternatives - i.e. -webkit-image-set and  
html5 <image>) proposal to solve the problem of 2x-res (double- 
resolution) images with our current HTML and CSS standards for devices  
with high-resolution displays, such as 3rd Generation iPads and 4th  
generation iPhones and newer.

Here's what I had in mind. We add the following elements:

1) The new meta tag 'double-resolution-images' (whose value would be a  
string for the double-res filename key - the often-standardized string  
added to the filename for 2x assets, i.e. '_2x'), with the optional  
boolean (defaulted to 'true') attribute 'assume-present', and maybe  
eventually the optional attribute 'double-resolution-path' for cases  
where sites store all their 2x image assets in a different directory  
than their 1x images.

2) A new optional attribute to the img tag called 'double-resolution',  
(possible values include 'true', 'false', a string for the double-res  
filename key - the often standardized string added to the filename for  
2x assets, i.e. '_2x', or 'url()' to specify a completely different  
path for the 2x asset)

3) The new optional CSS properties '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 double-resolution-images="_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 double-resolution-images="_2x" double-resolution- 
path="2x_images/" />

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

If a particular 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 'double-resolution' attribute to  
its img tag, such as '<img double-resolution="@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 double-resolution=url("2x- 
images/filename.ext") />', or to its css properties by doing: '.class  
{background-image-2x: url("2x-images/filename.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 double-resolution=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=false'  
attribute to the meta tag, such as '<meta double-resolution- 
images="_2x" assume-present=false />', and use the 'double-resolution'  
attribute to flag img assets with a double-resolution asset available,  
such as '<img double-resolution=true />, and the css with '.class  
{background-image-2x: true;}'.

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

By using this approach, we avoid the need to specify the same list of  
filenames varying only by 2x-res filename key for every single image  
asset, which is a bunch of busy work that just seems extremely  
redundant and clumsy to me. 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. We can revisit  
whether or not this was really the best approach once 4x displays are  
out, but it's going to save millions of collective developer-hours in  
the meantime; remind me to buy future me a beer to make up for it.

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-format-jpeg2000=".jp2" assume-present=boolean />

-Tom P.


More information about the webkit-dev mailing list