[whatwg] Features for responsive Web design

[Florian Rivoal]

> 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.