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

Wed May 16 06:40:46 PDT 2012

On 16 May 2012 14:30, Odin Hørthe Omdal <odinho at opera.com> wrote:
> Oh, please do quote what you are answering. It's very hard to follow
> such a conversation like this.
>

OK, I am not sure what format to reply to emails with - some people
complain when quotes are left out entirely, other people complain when
replies are in-line in the style you request, other people complain
unless the whole thread is included verbatim in any reply. What's the
actual WHATWG proscribed format for conducting conversations in email
format?

>
> Matthew Wilcox <mail at matthewwilcox.com> wrote:
>>
>> 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.
>
>
> I could be more clear. I believe this is what you are talking about:
>
>
> I said:
>>
>> 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.
>
>
> When I say find a way to defer it, I mean spec a way to do it, and
> implement that. Something like:
>
>    <img defer src="blabla.jpg">
>
> I understand the problem :-)
>
>

Cool - so you're saying we have the option of being able to instruct
browsers *not* to perform prefetch in certain circumstances?

>> 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.
>
>
> ... But it doesn't work. Please read my emails, and come with
> constructive technical feedback on why you think it *can* in fact work.
> I can not see a method where that would work in an non-broken way.
>
> Technical problems won't just magically go away by not acknowlegding
> them.
>

I am unable to give technical feedback of the required level; I'm here
as an author to tell you this is how we build stuff and this is how
we'd want to use images - just like we do with CSS. Just as technical
problems won't go away, neither will authors use cases and
requirements :) And, unfortunately, I am not skilled enough with the
technical side to be able to give you answers to the problem. I'm just
stating that the problem is not one that can be ignored lightly
because it would mean that the proposed solution does not work with
how websites are being built today.

>
> And I did find a way forward for the model 2, make a way to defer the
> image load and find a way to load it. Maybe <picture> element should
> always defer? It actually *has to* because it uses media queries, so in
> fact, <picture> might be a solution for model 2 in the future.
>
> But @srcset is solving the other part of the equation (model 1).
>
> --
> Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com

I'm not entirely convinced about this abstraction of model 1 and model
2. <picture> is flawed anyway, and srcset in the same manner, by
baking the response tests into the mark-up. When it comes time to
re-design there will be new breakpoints and they are not likely to
match the one's in the <img> / <picture> tags. It's the major hold-up
I had with <picture> and why I suggested looking into abstracting
breakpoint conditions away from the responding element and into the
<head>.