[whatwg] So if media-queries aren't for determining the media to be used what are they for?
Anselm Hannemann Web Development
info at anselm-hannemann.com
Tue May 15 22:40:52 PDT 2012
You might remember about my proposal 9 months ago. If not you can see it here: https://gist.github.com/1158855
media-xs="(min-device-width:320px and max-device-width:640px)"
media-m="(min-device-width:640px and max-device-width:1024px)"
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
> . 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).
More information about the whatwg