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

Andy Davies <dajdavies@gmail.com> wrote:
> Looking at the srcset proposal it appears to be recreating aspects of
> media-queries in a terse less obvious form...
>
> We've already got media queries so surelt we should be using them to
> determine which image should be used and if media-queries don't have
> features we need then we should be extending them...

Ah! What a truly great question, so simple.

The answer is: no, it is not media-queries although they look like it. A
big problem is that it's so easy to explain it by saying "it's just like
media-query max-width", rather than finding the words to illustrate that
they are totally different.

The *limited effect* also feels similar which doesn't help the case at
all.

So, even though I have a rather bad track record of explaining any
thing, I'll try again:

Media queries come from the client side. They allow the author of a web
page to tell exactly how she want to lay out her design based on the
different queries. The browser *HAS* to follow these queries. And also,
I don't think (please correct me if wrong) the media query can be subset
to only the stuff that's really meaningful to do at prefetch-time.

The srcset proposal, on the other hand, are purely HINTS to the browser
engine about the resources. They are only declarative hints that can be
leveraged in a secret sauce way (like Bruce said in another mail) to
always optimize image fetching and other features. If you make a new
kind of browser (like e.g. Opera mini) it can have its own heuristics
that make sense *for that single browser* without asking _anyone_.
Without relying on web authors doing the correct thing, or changing
anything or even announce to anyone what they are doing. It's opening up
for innovation, good algorithms and smart uses in the future.


That's the basic difference, totally different. :-)


With mediaqueries, you don't know at the time when you're prefetching an
image, what box it is in. So many media queries will either not make
sense (so they won't work like authors intend them to), OR the browser
would have to wait until it has layout for it to start fetching images.
Neither of these two would actually be good, so they are in conflict.

I'd also like to give an example on the "smart uses in the future" for
imgsrc; right-click save could fetch the biggest quality image and save
that one instead of the one it has currently fetched.


Bruce Lawson <brucel@opera.com> skreiv Tue, 15 May 2012 23:46:44 +0200
> Just so I understand
>
> 1) the 600w 200h bit replicates the functionality of the familiar Media  
> Queries syntax but in a new unfamiliar microsyntax which many have  
> argued is ugly, unintuitive and prone to error  
> (http://www.w3.org/community/respimg/2012/05/11/respimg-proposal)

No. It only works on device-width also, and it's only a hint, so it's
actually part of your part 2:

> 2) The new bit is the descriptors of pixel density (1x 2x etc). This  
> isn't "media queried" because the precise mechanism by which one image  
> is chosen over the other is left to the UA to decide based upon  
> heuristics. Those heuristics may be secret sauces that give a browser a  
> competitive advantage over another; they may be based on data the  
> browser has accumulated over time (On my current "Bruce's bedroom WiFi"   
> I know I have medium network speed but very low latency so I will tend  
> to favour images with characteristic X) and so which aren't available to  
> query with MQs because MQs are stateless; they may be based upon certain  
> characteristics that could conceivably be available to MQs in the future  
> (Do I support JS? Am I touch enabled?) but aren't yet.
>
> Is that accurate?

Yeah, sounds more like it. But it applies to the whole thing.

> I'm sympathetic to (2); why require a developer to think of and describe  
> every permutation if the environment, when she could instead describe  
> that which she knows - the images - and then allow the UA to take the  
> decision. As time goes on, UAs get cleverer, so behaviour improves  
> without the markup needing changing.

Exactly.

> But it doesn't seem necessary to saddle authors with (1) to acheive (2),  
> as far as I can see.

It's heavily optimized for the usecase that will happen most often: for
"retina" type displays:

     <img src="odin-in-suit.jpg" srcset="odin-in-suit@2.jpg 2x">


> bruce-speaking-for-myself-not-Opera

I'm not speaking for Opera either, but we do work for Opera, and it's
hard to disclaim everything always.


I hope it made sense.

-- 
Odin Hørthe Omdal (odinho/Velmont) · Opera Software

Received on Tuesday, 15 May 2012 22:38:20 UTC