- From: Anselm Hannemann Web Development <info@anselm-hannemann.com>
- Date: Wed, 16 May 2012 07:40:52 +0200
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: whatwg@lists.whatwg.org, Odin Hørthe Omdal <odinho@opera.com>
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