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

[Matthew Wilcox]

If there was a way to do this in JS, we'd have found it. Every time we
run up against the pre-fetch problem. In fact, it is only the
pre-fetch problem that causes responsive images to be an issue at all.
It'd be trivial to fix with JS otherwise.

Also, i don't think non-pixel based layouts can be easily dismissed.
It's where the whole movement is going and already pixel based MQ are
described as limited and not a best practice.

-Matt

On 16 May 2012 13:42, Odin Hørthe Omdal <odinho at opera.com> wrote:
> Tim Kadlec <tim at 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