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

[Bruce Lawson]

On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:

> On Tue, May 15, 2012 at 1:42 PM, Andy Davies <dajdavies at gmail.com> wrote:
>> Looking at the srcset proposal it appears to be recreating aspects of
>> media-queries in a terse less obvious form...
>>
>>   <img src="face-600-200 at 1.jpeg" alt=""
>>        srcset="face-600-200 at 1.jpeg 600w 200h 1x,
>>                face-600-200 at 2.jpeg 600w 200h 2x,
>>                face-icon.png       200w 200h">
>>
>> 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...
>>
>> I'd like to see media-queries extended to support bandwidth, svg etc.,
>>  then we give developers the option to detected features and choose
>> media types appropriately.
>
> The "600w 200h" bit can be directly translated into a media query -
> it's equivalent to "(max-width: 600px) and (max-height: 200px)".  It's
> collapsed into a custom syntax for terseness.

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)

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?

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.

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

bruce-speaking-for-myself-not-Opera