There are many things that we would want to add to the <source> element to allow for a better choice between the different source files that are linked, but the biggest problem is that it is currently only used to go through from top to bottom until the first file is found that can be played back - then the source selection stops. Even this is already quite a difficult algorithm.
Extending <source> to choose between alternative source files based on other aspects such as quality, screen size, contains captions, contains audio descriptions, etc. isn't going to work with the current way that the <source> element is set up. This is why the @media attribute hasnt' been used/implemented anywhere yet: it contradicts the current algorithm for source selection. And in discussion with the browser developers who have implemented the element I hear that it's complex enough as it is and overloading the algorithm further is impossible. I've been wondering if there is another way. The analogy with the source selection algorithm for mime types on a server doesn't work well, because there is only one dimension upon which to choose a source file: mime type. Here, we have several dimensions, making any automated choice a challenge. Cheers, Silvia. On Mon, Dec 14, 2009 at 2:28 AM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > Wasn't there talk of adding a @media attribute to <video> which could, > among other things, hold bitrate information which would allow the UA > to auto-determine whether it should play a file? > > This would require a change to the current selection algorithm, as the > UA now has to make a 'best guess' of which file to use rather than > just choosing the first which works, but it's probably worth it. > (Plus the other benefits of @media, such as declaring that a > particular source has subtitles burned in, etc.) > > ~TJ >