- From: Florian Rivoal <florianr@opera.com>
- Date: Wed, 08 Aug 2012 13:57:45 +0200
- To: whatwg@lists.whatwg.org
> On Wed, 6 Jun 2012, Henri Sivonen wrote: >> >> Is there a good reason to believe that * will be something other than a >> power of two? >> >> That is, could we just optimize the *x syntax away and specify that the >> first option is 1x, the second is 2x, the third is 4x, etc.? If you look at mobile phones, there are a bunch of existing devices with 1.5 device pixel per css pixel, and also some with 2.25, so I don't think we can assume only powers of 2 will be used. > On Wed, 23 May 2012, Florian Rivoal wrote: >> >> On the other hand, I think that including 600w 400h in there is >> misguided. It doesn't help for the problem of picking the right image >> for the right resolution/bandwidth combination, but is too crippled to >> be useful as media queries meant to serve different images to in >> different scenarios. <picture> serves these use cases much better. > > Could you elaborate on the use cases that it doesn't handle? > On Thu, 24 May 2012, Florian Rivoal wrote: >> >> <picture> >> <source srcset="normal.jpg 1x, highres.jpg 2x"> >> <source media="(max-width:768px)" srcset="ipad.jpg 1x, ipad3.jpg 2x"> >> <source media="(max-width:320px)" srcset="iphone.jpg 1x, iphone4.jpg >> 2x"> >> <img src="normal.jpg"> >> </picture> > > I don't understand why this is better than: > > <img src="normal.jpg" srcset="highres.jpg 2x, > ipad.jpg 768w 1x, ipad3.jpg 768w 2x, > iphone.jpg 320w 1x, iphone4.jpg 320w 2x" > alt="..."> > > ...which as far as I can tell does exactly the same thing. They are pretty close, but there are a few differences: 1) You syntax (almost, see point 2) replicates the behavior of max-width and and max-height Media Queries, but doesn't give access to other existing and future media queries, some of which may actually be useful. For example: a) using the 'monocrhome' MQ to serve gray scale images to black-and-white printers or e-ink displays. Displaying a color image on a monochrome display does not always work well, as two different colors of similar luminosity would be impossible to distinguish in a monochrome environment. I expect this need to grow together with the increasing popularity of HTML based ebooks. b) Microsoft is proposing a MQ which lets you detect that the UA has been put in hight contrast mode (for accessibility reasons), and that your content should follow along. http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx Being able to switch images based on that could be nice. c) using the 'orientation' MQ to pick a different cropping of an image, in a way that is similar to the width-only decision in the Obama example. 2) in the srcset-only notation, w and h are hints for the browser, since picking the right image is something for which browsers are given the option of doing it differently. For the pixel density of the image, leaving it up to the browser is a good thing, as there are a large number of factors that can potentially come into play. For w and h though, this is pretty much entirely up to the author's discretion, so allowing the browser to have different rules for picking the image doesn't buy us anything. If id didn't cost anything either, that'd be ok, but it does. 3) you syntax is terser, which is in generally a good thing, but I think it crosses the limit, as a large number of people have expressed confusion as to w and h were min or max, for example. The extra verbosity of my syntax gets you an extra bit of clarity, admittedly at the cost of having multiple elements. Finally, while I still think point 1) above is worth considering, I've just overcome one of the reasons I didn't like srcset as currently specified in HTML, so I'll put it out there for other people who may be reluctant for the same reason. I have always been comfortable with the 'x' part of srcset, but the w and h part felt somewhat wrong to me. What you'd really want to consider when deciding which image to pick isn't the size of the viewport itself, but the size available for the image once the rest of the layout is taken into account. This depends on the viewport size, but even with relatively modest style sheets, the relation can be somewhat painful to determine, and not necessarily linear (or even monotone), and also depends on which font was available, the font size, and who knows what other factors. Because of that, a switch based on the viewport is likely to be given somewhat inaccurate values by authors. Values provided will probably put the switch somewhere that does the right thing on a iPhone and an iPad, because many people test on that, but there is a good chance that devices with intermediate sizes, missing or different fonts, etc, will be given a suboptimal image. Because of that, I was interested in proposals involving an (optional) defer attribute, which let you wait until layout can inform the decision. Then, given accurate meta-data on the images's sizes and density, it would be possible to pick the optimum one. But of course, this means waiting, so this isn't generally acceptable and must be opt it. And I can't put my finger on exactly how that would work either. Because of this tension between doing the right thing later or doing the could-be-wrong thing early, I wasn't entierly satisfied with the w and h part of srcset, which felt to be falling short of the One True Solution that everybody would recognize as doing the right thing always. Of course, a media query based approach has the exact same problems. But I felt it wasn't worth introducing a new mechanism unless it solved this problem better than already have (MQ). I've changed my mind about this because this is a fundamental limitation of what we're trying to do here, not a problem with the particular solution proposed. Because we have to be fast and start loading images before layout is done, there is just no way we can find a solution where the browser, given sufficient metadata will pick the optimal image in all situations. We can only accept solutions that pick the image before layout is done, and any such solution will have the problem of picking a possibly suboptimal image. Given that, rejecting srcset's h and w because they sometimes result in the wrong image being picked becomes counter productive, since all solutions will share that problem. Having established that perfection cannot be reached here, I could now consider whether srcset was good enough for most cases, and I think that if we don't care about things like 'monochrome', 'high-contrast', or 'orientation', it is. To me, the only remaining question is whether we care about these. If we do, rather than reinventing a new syntax for every media query someone wants to use in a srcset, I think we're better off letting people use media queries directly, in which case then w and h are a redundant terser syntax for max-width and max-height. If we don't, srcset is probably as good as it gets.
Received on Wednesday, 8 August 2012 11:58:16 UTC