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

You might remember about my proposal 9 months ago. If not you can see it here: https://gist.github.com/1158855

<img src="http://cdn.url.com/img/myimage_xs.jpg" 
	media-xs="(min-device-width:320px and max-device-width:640px)" 
	media-xs-src="http://cdn.url.com/img/myimage_xs.jpg"  
	media-m="(min-device-width:640px and max-device-width:1024px)" 
	media-m-src="http://cdn.url.com/img/myimage_m.jpg"  
	media-xl="(min-device-width:1024px)" 
	media-xl-src="http://cdn.url.com/img/myimage_xsl.jpg"
>

<img src="http://cdn.url.com/img/myimage_xs.jpg" 
	media-xs-src="http://cdn.url.com/img/myimage_xs.jpg"  
	media-m-src="http://cdn.url.com/img/myimage_m.jpg"  
	media-xl-src="http://cdn.url.com/img/myimage_xsl.jpg"
>

This is between the @srclist and the picture-element. It has MQ (which are optional imo, of course the browser should have a standard "MQ" (how ever this can look like and might feature bandwidth also)) and a sourcelist. And it features a html-common usage while being shorthand.
I also believe that if the developers should ever be provided with a bandwidth API this could be handled via media-queries.

The first example shows that a developer wants to specifically target specific screen sizes with a MQ while in the second it is up to the browser which one is used.
At least the normal src="" is thought as fallback behavior for older browsers.

>> Doing the same as whatever <img> ends up doing
>> might be a good fit if the use cases are similar enough. Would be nice to be
>> consistent if that makes sense.
> 
> I'm not 100% sure I grok the difference between media queries and
> @srcset. I threw this question into the mix to see the reaction -
> maybe we need both? What would that even mean?

I don't know if we need both. Why should we? Because @media-query features are currently not enough? Standard behavior which is build in a browser won't need any of these solutions, right? Also the picture-element does not *require* a MQ. It can also be used to just serve a list of sources and let it up to the browser what to fetch.

> In addition, I wonder about the adaptive streaming case where byte
> ranges from different files are being switched to dynamically during
> playback because of bandwidth change. For video, the solution seems to
> be: use a manifest file in your @src (such as DASH) and rely on the
> browser to pick between the files. Or you use javascript:
> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
> . An attribute like @srcset would allow listing the alternative files
> directly in the HTML file. That may be preferable?

This sounds good but too complicated for a normal developer and you have to see that we also should respect CMS implementations.
I don't know (but probably only don't understand the technique correct) if this is not too complicated?

> More questions than answers right now, but we should think
> consistently between audio, video and images.

That is what I totally support except there are already adaptive streaming technologies for video-formats but not for pictures (which is another topic I came up against a brick-wall).
-Anselm

Received on Wednesday, 16 May 2012 05:41:31 UTC