Re: [whatwg] srcset isn't future-friendly to screen size differences
Am 07.09.2012 03:36 schrieb Tab Atkins Jr.: This email is an extension of the thread started at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-August/036953.html by John Mellor, distilling the core problem he has into a more easily-understood and digested form. The srcset attribute, as currently written, is not friendly to large screen-size differences that don't trigger different art direction. Consider the following example: img srcset=800.jpg 1x, 1600.jpg 2x style=width: 100%; height: auto; For a screen that's somewhere near 800px wide, this works just fine. However, a 1x screen 1600px wide (not too uncommon - I think a 19 monitor is roughly that width) will get served the 800.jpg image, which then gets blown up to an unattractive level. The 1600.jpg file should be identical to the 800.jpg file, just higher resolution, so delivering it instead would be ideal, but the current syntax doesn't allow that, nor does it allow any reasonably reliable way for a browser to detect that it would be okay to serve the 1600.jpg image either. 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. With respect to the threads on responsive images of the last few months, IMHO it is not possible to solve both art direction and bandwidth use cases with the same syntax in a satisfactory manner: - Art direction use case: Should be controlled by the author, which is possible via some kind of MQ. - Bandwidth use case: As you state above, this use case should be better controlled by the UA. The UA does not need MQs to make a good selection, but rather information on the image files available. The problem of @srcset is that on one hand it can't convey image dimensions, and on the other hand it's MQ possibilities are very limited and not extensible if things evolve in the future. This has been discussed in several places of the related threads in the last few weeks. I'd like to revive Florian Rivoal's (and my) suggestion of using picture for the art direction and @srcset for the bandwidth use case, so you can optimize bandwidth inside art-directed images. *But with the modification, that @srcset takes image dimensions rather than page dimensions:* img srcset=big.jpg 800w, normal.jpg 400w, small.jpg 200w src=normal.jpg style=width:100% img srcset=16.jpg 240h, 12.jpg 180h src=16.jpg style=height:15em picture alt= source srcset=mobile.jpg 200w, mobile-hd.jpg 400w source media=min-width: 600px srcset=large.jpg 540w, larger.jpg 1080w, giant.jpg 2160w img src=mobile.jpg /picture Note that with this change there is no more 1x default for the source element, thus a src attribute does not seem to make sense there.
Re: [whatwg] srcset isn't future-friendly to screen size differences
On Fri, 07 Sep 2012 06:07:30 +0200, Fred Andrews freda...@live.com wrote: From: jackalm...@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? If what's necessary here is to declare the intrinsic dimensions, why not use the width= and height= attributes for this? (They can be overridden with CSS if you want e.g. 100% width.) -- Simon Pieters Opera Software
Re: [whatwg] srcset isn't future-friendly to screen size differences
From: sim...@opera.com ... On Fri, 07 Sep 2012 06:07:30 +0200, Fred Andrews freda...@live.com wrote: From: jackalm...@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? If what's necessary here is to declare the intrinsic dimensions, why not use the width= and height= attributes for this? (They can be overridden with CSS if you want e.g. 100% width.) The aim is to declare the available raw image sizes so that the browser can choose the most appropriate image to use. That is, the image 320x120.jpg is 320 pixels wide and 120 pixels high, the image 640.jpg is 640 pixels wide and 240 pixels high, etc. This is not intended to specify the CSS pixel size the that image will occupy. The width= and height= attributes may well be used to specify the CSS pixel size of the image in the layout. If the width and height of the img element are not given then the browser will need to consult the raw image size and I presume John intends the first size to be the CSS pixel size in this case - for higher density screens the browser could then choose a higher resolution image from the set. There are a few other proposals with a similar intent. cheers Fred
Re: [whatwg] srcset isn't future-friendly to screen size differences
On 9/6/12 6:36 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Consider the following example: img srcset=800.jpg 1x, 1600.jpg 2x style=width: 100%; height: auto; For a screen that's somewhere near 800px wide, this works just fine. However, a 1x screen 1600px wide (not too uncommon - I think a 19 monitor is roughly that width) will get served the 800.jpg image, which then gets blown up to an unattractive level. In this particular case, without considering other display densities, wouldn't this suffice: img src=1600.jpg srcset=800.jpg 800w 1x, 1600.jpg 800w 2x style=width: 100%; height: auto; It's a shame that one can't explicitly say that the UA can use display density arithmetic to select substitute images. On the other hand, ror cases like this, specifying a src image for viewports that are larger than the ones specified with srcset seems like a good idea. - Hans
Re: [whatwg] srcset isn't future-friendly to screen size differences
On Fri, Sep 7, 2012 at 9:21 AM, Hans Muller hmul...@adobe.com wrote: On 9/6/12 6:36 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Consider the following example: img srcset=800.jpg 1x, 1600.jpg 2x style=width: 100%; height: auto; For a screen that's somewhere near 800px wide, this works just fine. However, a 1x screen 1600px wide (not too uncommon - I think a 19 monitor is roughly that width) will get served the 800.jpg image, which then gets blown up to an unattractive level. In this particular case, without considering other display densities, wouldn't this suffice: img src=1600.jpg srcset=800.jpg 800w 1x, 1600.jpg 800w 2x style=width: 100%; height: auto; That's basically equivalent to what I wrote. I just added an additional (technically superfluous) 1x to the final declaration. The problem, as I noted, is that it means you're duplicating the 1600.jpg url, which is a minor editting hazard. This kind of solution also only works in this specific case, when you're only dealing with two densities and no art direction. ~TJ
[whatwg] srcset isn't future-friendly to screen size differences
This email is an extension of the thread started at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-August/036953.html by John Mellor, distilling the core problem he has into a more easily-understood and digested form. The srcset attribute, as currently written, is not friendly to large screen-size differences that don't trigger different art direction. Consider the following example: img srcset=800.jpg 1x, 1600.jpg 2x style=width: 100%; height: auto; For a screen that's somewhere near 800px wide, this works just fine. However, a 1x screen 1600px wide (not too uncommon - I think a 19 monitor is roughly that width) will get served the 800.jpg image, which then gets blown up to an unattractive level. The 1600.jpg file should be identical to the 800.jpg file, just higher resolution, so delivering it instead would be ideal, but the current syntax doesn't allow that, nor does it allow any reasonably reliable way for a browser to detect that it would be okay to serve the 1600.jpg image either. 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. 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 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. ~TJ
Re: [whatwg] srcset isn't future-friendly to screen size differences
From: jackalm...@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
