W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

From: Odin Hørthe Omdal <odinho@opera.com>
Date: Wed, 16 May 2012 14:42:58 +0200
To: "Tim Kadlec" <tim@timkadlec.com>
Message-ID: <op.weeixwms49xobu@odinho-fido.oslo.osa>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
Tim Kadlec <tim@timkadlec.com> wrote:
> The lack of em support is a concern though I understand the  
> complications you have brought up.
>
> Using ems for media queries (which in turn dictate layout which in turn  
> dictates the image I want to load) is increasingly looking like a much  
> wiser decision than using pixels. A perfect example are devices such as  
> the Kindle Touch which have a much higher default font size. A real  
> world example, and case study, can be found here:  
> http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/

I don't think it is fit for this round of spec. It is in direct conflict
with preloading/prefetching. It's a different model and requires a
different fix.

Model 1, before load: do image decision, fetch image while loading the page
Model 2, after load: load page, do image decision after layout

srcset is using model 1, which is faster and in the same way images are
done today. I don't think you'll be able to convince vendors to ditch
that optimization.

media queries is doing model 2. I suggest we find a way to do that with
javascript. Maybe some form of deferring image loading at all, saying
that "I will fetch image on my own". Then you can do the delayed image
loading that would need to happen in a media query world.

Having a fix for model 1, doesn't hinder something for model 2 to come
at a later point.

> Now suppose that for that layout displayed in their screenshot, the  
> header image was changed to be a vertical oriented phone and the size  
> was reduced. In that case, I would want srcset to kick in with a  
> different image. It sounds like it would not be able to accomplish this  
> right now?

No, you're right about that. Or it could work in the current proposal,
but I don't really think it's worth it.

The spec does have an algorithm for updating the image that does a new
fetch and show, but it's not required to run it. So you can't really
depend on it. But it can work. If it has already fetched a bigger
image, and has that in cache, it might not want to fetch a smaller one
when you rotate though. Why show something of worse quality than what
you already cache?

If the intrinsic sizes are different, well, the user agent doesn't
know that until it has downloaded the image anyway.


IMHO that should rather be done with a model 2. That means, in the
short term: finding a way to solve it using client side javascript.


So in clear text: I don't think that should be supported by imgsrc.
That's a job for a media query. Model 2.


> Forgive me if I'm just missing something. It's early and my coffee  
> hasn't kicked in quite yet. :)

PS: I would be very happy if you didn't top-post, and also trimmed your
quotes so that it's easy to follow and read (I read email on my phone
when I'm out, and I love when people write emails that work nicely on
the phone).

-- 
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Received on Wednesday, 16 May 2012 12:43:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:08 GMT