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

[Chris Heilmann]

On 15/05/2012 22:46, Bruce Lawson wrote:
> 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
>
>
I also wonder what we do with videos? Surely they have the same issues 
and there is no proposal for changing the syntax there. I do not like 
the syntax of this. Yes it is more terse but it smacks of the horrible 
syntax of window.open properties and other comma separated visual 
attributes.

 From a semantic point of view this is a terrible mix of everything - 
something that the picture proposal with multiple sources was not.

Let's not forget that this is a new use case - one that might get more 
complex with more UA changes in the future. Maybe we have holographic 
images soon with a X Y and Z position. Shoehorning this into the IMG 
element doesn't make much sense to me.

embed is the fallback to video with various sources. img is the fallback 
to embed. I'd like to see picture - done like video for consistency as 
it is a new use case for images. Old browsers could disregard them and 
new ones can use mediaqueries to apply the different sources as needed. 
Yes, mediaqueries do not all the things we need here and browsers have 
bugs loading various sources instead of only one but these are things to 
fix in the browser engines, not add an extra use case in the spec.