[whatwg] srcset isn't future-friendly to screen size differences

Fred Andrews fredandw at live.com
Thu Sep 6 21:07:30 PDT 2012



> From: jackalmage at gmail.com
...
> I'm not sure how best to solve this, but John Mellor suggested
> allowing the specification of the image's native dimensions somehow.
> That way, the browser could know that the 1600.jpg image is
> appropriate to serve as an 800px wide high-dpi image, or a 1600px wide
> low-dpi image.

John has a proposal here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-August/036958.html  e.g. '<img srcset="320x120, 320.jpg 1x, 640.jpg 2x, 1280.jpg 4x, 2560.jpg 8x">' . As I understand it John's proposal only declares the image sizes and is not intended for making a selection based on density or screen size directly?

I like John's proposal.  It would solve the problem of choosing an appropriate resolution image and is simple. What are the issues here?

You would still be able to use media queries to further customize image choice for particular screen sizes.  Note that there are other design approaches such as fluid design in which you may well avoid media queries.

Media queries do seem like a stop gap measure until better fluid design support is developed .  For example, if you have only four orthogonal media properties that are significant to an image, each with only two significant ranges, then you need 2^4 or 16 images.  With demands to add more and more media queries it should be clear that this approach is a dead end.

> It is possible to address this by repeating the same image at a larger
> breakpoint, like:
> 
> <img srcset="800.jpg 1x 1599w, 1600.jpg 2x 1599w, 1600.jpg 1x">

No.
 
> However, this means you're duplicating data, and have a chance of
> failing to update all of the urls when you update one.  It also
> becomes more hostile as future screens arrive with higher resolutions.
>  For example, if 3x screens showed up, one would have to write the
> following to serve things in the most ideal manner:
> 
> <img srcset="800.jpg 1x 1599w, 1600.jpg 2x 1599w, 2400.jpg 3x 1599w,
> 1600.jpg 1x 2399w, 2400.jpg 1.5x 2399w, 2400.jpg 1x">
> 
> At this point it's just silly, and very error-prone.

It's just not a good solution for this problem.  We still need Johns proposal to address fluid designs.

There are two distinct proposals, and if there is no agreement then perhaps it would just be best to split them to allow development to proceed.

cheers
Fred

 		 	   		  


More information about the whatwg mailing list