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

Wed May 16 09:07:07 PDT 2012

Matthew Wilcox <mail at matthewwilcox.com> wrote:
> Odin wrote:
>> 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?

Uh, well, I'm saying I think it's something we can propose. For it to
actually be an option, vendors would have to agree and also implement
it.

But, yes, I think it can be done. We already have @defer on <script>. If
it's actually a bad idea, we'll hear about it - and look for an
alternative way. I'm not yet able to see any big drawbacks though.

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

Yes, but the seperation between "before load" and "after load" is how
*browsers* work today, and also are expected to work.

Opera tried lazy loading on desktop and it caused all sorts of compat
problems:

   <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034846.html>

That weights very heavy with browser vendors.

The technical problems I highlighted in lots of the different posts made
in these threads. E.g.

   <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035886.html>

They should be quite readable for anyone, and if not, better ask on
specifics.

I have looked at the use cases, and I believe the use cases should be
split into two different ones. And I prefer punting the one you're most
interested in for later. That could be done with something akin to
<picture>, although that has definite drawbacks as well.

Anyway, I believe the solutions doesn't have to conflict, so that srcset
would be able to exist just like it is now, and live besides a more
higher level solution for "art direction" (load image after load)
however that one might look in the future.

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

That is a valid concern. But it's possible to have best practices so
that you use @srcset in a more limited fashion than what is possible. So
that you can always have "these and these" image sizes, and you will
only use it to get different image sizes (not switch other stuff). And
the viewport queries can only be the same width as the picture's
intrinsic width.

Then you should be in a much easier place to redesign and change your
breakpoints, or even add new ones. Resizing the images using CSS for the
last mile of flexibility ofc.

Anyway, that should be solvable down the road.

-- 
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com