This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Back in October 2012 a bug was submitted to remove the media attribute from <source> "if it isn't used": https://www.w3.org/Bugs/Public/show_bug.cgi?id=19619. Unfortunately this has now been adopted, and Hixie has removed it (https://www.w3.org/Bugs/Public/show_bug.cgi?id=19619#c34) from the WHATWG specification (saying "no-one uses it" and calling it "essentially useless") and Philip Jägenstadt has marked it for removal from Blink (https://www.w3.org/Bugs/Public/show_bug.cgi?id=19619#c33). It has also been adopted by the HTML 5.1 specification in the WHATWG "cherry-pick" on the 7th of February: http://lists.w3.org/Archives/Public/public-html/2014Feb/0021.html. In the bug report some usage data has been provided which indicates that this attribute has not been used much, and this data was used in making the decision to remove it. I will admit to not having any any major counter data to this but I disagree with this attribute being "useless" and I have always thought that not enough people know about this attribute, its implementation and what it can do. An argument against the attribute's usefulness has been put forth in the bug thread stating that it isn't responsive and doesn't react to changes in the browser size etc. Whilst this is true and admittedly odd, I think that it is a moot point given the problem that the media attribute is used to solve. If you use the media attribute to serve a lower quality video with smaller file size based on a smaller screen size (based on the oft used assumption that a smaller browser width probably means a mobile device and lower bandwith - we all know this is not that accurate but we developers use it all the time) you are not going to want to serve a larger, higher quality video file when/if the user flips their device into landscape mode. Nor will the user be resizing their browser. If anything the attribute should be re-specified in order to be responsive so that browser support would be improved. At the moment the media attribute is the only native way to serve smaller audio and video files to smaller browser sizes. Indeed it could be used to only serve an audio or video file when the browser size is above certain dimensions, and coupled with a "normal" media query which hides the video/audio element, not serve audio or video at all and thus preventing an unwanted http request. I ran some quick tests to see what browsers currently correctly support the media attribute as part of <source>: Firefox 15+ Chrome 4 - 33 (removed from 34) Opera 10+ Safari 5.1+. IE 9 - 11 iOS Safari 5+ Android 4.1+ Opera Mobile 12+ Since the specification is there to describe what features are currently available in browsers, it should be returned to the specification. And since only Blink has dropped it recently, it is still supported by most browsers and therefore should remain in the specification. Responsive design and responsive images are a huge topic in the web world today, and here we have something that goes some way towards supporting responsive audio and video, and it's being removed. This makes no sense.
(In reply to Ian Devlin from comment #0) > If anything the attribute should be re-specified in order to be responsive > so that browser support would be improved. I don't understand how that would work, but it seems counter to what you say next: > Since the specification is there to describe what features are currently > available in browsers, it should be returned to the specification. > And since only Blink has dropped it recently, it is still supported by most > browsers and therefore should remain in the specification. This is going to be true of any widely implemented but unused feature that's removed from the Web platform. For example, document.createAttributeNS was recently removed from Blink, but is still supported in every shipping browser I tested. Should it be added back to http://dom.spec.whatwg.org/?
I don't see how those things are counter to each other but I will admit that I wasn't very clear, my apologies. I will try to be clearer. First of all I think that the media attribute should remain in the specification for the reasons given earlier. Secondly, it could be improved upon to define that it should be treated just like other media queries in that browser resizes etc. are adhered to as they change. >>This is going to be true of any widely implemented but unused feature that's removed from the Web platform. For example, document.createAttributeNS was >>recently removed from Blink, but is still supported in every shipping browser I tested. Should it be added back to http://dom.spec.whatwg.org/? I would say yes. And this particular example potentially suffers from the same problem as media, in that people don't know about it. I for one have never heard of it and don't know what it does (I do now after looking it up - http://reference.sitepoint.com/javascript/Document/createAttributeNS).
(In reply to Ian Devlin from comment #2) > I don't see how those things are counter to each other but I will admit that > I wasn't very clear, my apologies. I will try to be clearer. > > First of all I think that the media attribute should remain in the > specification for the reasons given earlier. Secondly, it could be improved > upon to define that it should be treated just like other media queries in > that browser resizes etc. are adhered to as they change. For <source media> to be adaptive, it would require big changes to the media resource selection algorithm, which currently picks a source and sticks with it. Switching between sources mid-playback sounds really complicated, at least if you want the transition to be gapless. MSE combined with matchMedia can do it though. > >>This is going to be true of any widely implemented but unused feature that's removed from the Web platform. For example, document.createAttributeNS was > >>recently removed from Blink, but is still supported in every shipping browser I tested. Should it be added back to http://dom.spec.whatwg.org/? > I would say yes. And this particular example potentially suffers from the > same problem as media, in that people don't know about it. I for one have > never heard of it and don't know what it does (I do now after looking it up > - http://reference.sitepoint.com/javascript/Document/createAttributeNS). It sounds like you have an extremely high threshold for removing features from the Web platform. Suffice to say, (some) spec editors and implementors currently have a lower threshold, providing the occasional chance to simplify the platform.
Someone was complaining in #whatwg about this being removed and cited some page he had created that uses the media attribute as a reason to keep it. I will paraphrase in order to not single him out personally. The markup was something like this: <video controls> <source src="low.webm" type="video/webm"> <source src="low.mp4" type="video/mp4"> <source src="high.webm" type="video/webm" media="all and (fullscreen:yes)"> <source src="high.mp4" type="video/mp4" media="all and (fullscreen:yes)"> </video> (I don't remember if the media query was exactly that, but something like it.) This will always pick the low quality source and never switch to the high quality source. I think having the media attribute in the spec is a disservice because the author here thought that it would be responsive and switch to high quality when the user enables fullscreen, so the author has wasted time and is in a false sense of "I made my video responsive". By removing the media attribute from the spec, if the reaction is to implement the desired functionality with JS instead, then it will start to actually work. As to making the resource selection algorithm responsive, that would be "really complicated" like Philip said, and is very unlike how the algorithm operates today.
HTML5.1 Bugzilla Bug Triage: Incubation needed I tend to agree with the expressed feelings that it was good that the media attribute was removed. I suspect it could eventually come back, but will require some incubation work to figure out exactly how to make it work well, and rationalize it's behavior with MSE and adaptive scenarios as well. This bug constitutes a request for a new feature of HTML. The current guidelines [1], rather than track such requests as bugs or issues, please create a proposal outlining the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG [2]. As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process [3]. [1] https://github.com/w3c/html#contributing-to-this-repository [2] https://www.w3.org/community/wicg/ [3] https://wicg.github.io/admin/intent-to-migrate.html