static.html

— a blog about web development and whatnot by Steve Webster

The HTML5 specification explicitly allows browsers to ignore the autobuffer attribute on media elements such as <audio> and <video>, and some browsers auto-buffer content regardless of whether this attribute is present. Is this a case of the specification being too pragmatic, and if so what can be done to improve the situation?

John Gruber recently wrote about what he feels is a failing with the current specification for the HTML5 <video> element; that it gives browser vendors the freedom to ignore the presence (or absence) of the autobuffer attribute as they see fit. Here's what the HTML5 specification has to say on the matter:

The autobuffer attribute is a boolean attribute. Its presence hints to the user agent that the author believes that the media element will likely be used, even though the element does not have an autoplay attribute. (The attribute has no effect if used in conjunction with the autoplay attribute, though including both is not an error.) This attribute may be ignored altogether.

John has tested how browsers react to the autobuffer attribute in Safari, Chrome and Firefox, which are the only mainstream browsers that support the <video> element at the time of writing. He discovered that two of these browsers, Safari 4.0.4 and Chrome 4.0.249.43, will automatically begin buffering the video content once the page has loaded even if the autobuffer attribute is omitted.

This behaviour is in line with the wording of the specification. If the autobuffer attribute is present, it can be interpreted as a hint that automatically buffering the content may be desirable. However, as I mentioned earlier, browsers are free to ignore the presence or absence of this attribute as they see fit. This freedom is at the heart of John's issue with the the specification:

This browser behavior is very much undesirable for both publishers and users in common contexts. Users loading the page over a slow connection, or a pay-by-the-megabyte metered connection (which is common with wireless networks), should not be forced to download a potentially large video every time they load the page. Likewise, publishers should not be forced to pay for the bandwidth to transmit videos that won’t be watched.

Putting aside my uncertainty that John's use case of posting video to a blog represents “common contexts”, his suggestion for fixing the HTML5 specification places way too much control in the hands of the content author:

Web browsers should only buffer HTML5 media content when the autobuffer attribute has been explicitly turned on in the markup

The whole point of automatically buffering video content is to improve the user's experience; to reduce how long the user has to wait for the video to buffer once they click the play button. I would argue that the content author, who is making decisions based on Joe Average internet user, is far from ideally placed to determine whether or not automatically buffering video content is in the user's best interests.

The browser, on the other hand, is in a much better position in this regard. It lives on the user's device, it knows the capabilities of the device and the network connections is has access to, it knows about the current network, memory and CPU load, and it can observe and adapt its behaviour to the user's previous browsing habits. A specification that prevents the browser from taking advantage of this kind of contextual information will simply be ignored, and a specification that is routinely ignored may as well not exist at all.

This is why I believe the HTML5 specification is right to give browser vendors freedom to ignore the autobuffer attribute. The browser holds most of the cards when it comes to determining what level of autobuffering will give the user the best experience, and on the web user experience trumps almost everything else.

“Right” doesn't mean “perfect”

The autobuffer attribute is a boolean attribute, and as such omitting it is equivalent to setting the autobuffer property to false on the DOM element:

<video id="video-01" height="320" width="480" controls>
    <source src="my-video.mp4" type="video/mp4">
</video>
…
<script>
    document.getElementById('video-01').autobuffer = false;
</script>

However, while the specification states that the presence of the autobuffer attribute is a hint to the browser that auto-buffering the content would be beneficial, it does not explicitly state that the inverse is also true. I think it's worth amending the specification to support this use case — content authors have knowledge about the nature of the content that browsers do not, and therefore should have some influence over browser behaviour. Something like:

The autobuffer attribute is a boolean attribute. Its presence hints to the user agent that the author believes that the media element will likely be used, even though the element does not have an autoplay attribute. (The attribute has no effect if used in conjunction with the autoplay attribute, though including both is not an error.) Conversely, the absence of this attribute hints to the user agent that the author believes that the media element will likely not be used. This attribute may be ignored altogether.

The above makes clear what the current specification only implies; that the author can omit the attribute to suggest that the browser should not auto-buffer the content. This still gives the browser freedom to auto-buffer or not based on all the information it has available to it, whilst giving content authors the power to provide hints either way.