The main advantages of doing it this way are: 1) You don't need to specify a different path for every scale of every image if you follow a naming convention. 2) the user agent makes the decision of which asset to request (based on factors such as screen resolution and network quality/value of bandwidth) 3) It's backwards-compatible and degrades gracefully.
-Tom On Apr 27, 2012, at 1:50 PM, Jason H <[email protected]> wrote: > I think the approach of attacking it from setting a scaling is wrong. > The real approach is to set the final dimensions, and let the software give > the appropriate scaling based on the image metadata. > > If you want a double-density image, you're just asking for 100x100 to be > rendered in 50x50. The image tag already supports this. <IMG HEIGHT=50 > WIDTH=50 SRC="100x100.png"/> Far too often it is implied that the display > density is identical to the sampling (pixel density) by not including the > height and width attributes. > > The real challenge as I see it, is having an efficient way of not sending > over-sampled data across the wire, unless you mean to. Sending a double > density image actually sends 4 times the data as a native resolution image. I > would suggest we leave it up to java script to handle the pixel density > matching, where it can dynamically assign the assets to the proper > size-density, if needed. For the most part pick something not over sampled > and let the browser scale it up if need be. A server-component could > dynamically render and cache the common sizes of an image. But I don't see a > need to change HTML. > > > > > > > > From: Tom Penzer <[email protected]> > To: [email protected] > Sent: Friday, April 27, 2012 3:47 PM > Subject: Image Scaling for High-Pixel-Density (i.e. Retina) Displays - Re: > -webkit-image-set and <image> > > Hi everybody, > > I'm 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. > > 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/[email protected]") />', or to its css > properties by doing: '.class {background-image-2x: > url("path/to/[email protected]");}'. > > 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, 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. > > 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}" /> > > -Tom Penzer > humble web coding noob > > > >
