[whatwg] Features for responsive Web design
florianr at opera.com
Wed Aug 8 04:57:45 PDT 2012
> 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:
>> <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
>> <img src="normal.jpg">
> 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"
> ...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.
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
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.
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
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
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
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
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.
More information about the whatwg