W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Should <video> buffer control be tri-state?

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 05 Jan 2010 16:40:21 -0800
Cc: Philip Jägenstedt <philipj@opera.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, public-html@w3.org
Message-id: <BFD08CAD-2F79-437E-A03E-EADE2D56CBC1@apple.com>
To: Jonas Sicking <jonas@sicking.cc>

On Jan 5, 2010, at 4:22 PM, Jonas Sicking wrote:

> This still gets back to the question: Do we expect browsers do
> anything other than minimal amount of network traffic for markup like:
> <video src="video.ogg">

As I mentioned before, in WebKit we would likely want to use a  
heuristic based on page content in this case. So for example if the  
video is the only one on the page, we'd consider buffering more  
aggressively than if given the "minimal" hint.

> And if expect them to just do minimal amount of downloading for that,
> why do we need another state meaning "I know you'd just download the
> minimum if I didn't say anything, but I still want to tell you to just
> download the minimum"?

Some cases where you may want to explicitly ask for the minimum and  
not be potentially subject to heuristics would be:

A) When embedding <video> in a blog post, where you are pretty sure  
users will not play the video on most visits to your blog, even if it  
might be the only video showing for a while. Blog management software  
might even do this automatically.

B) When providing markup for third-party embedding of video from a  
hosting service. You might want all such cross-embedded video to avoid  
buffering by default and not be subject to heuristics (as with YouTube  
cross-site embedding today).

Whereas if you just threw together a <video> page without thinking  
about buffering, then applying a heuristic may be a net benefit to  

Received on Wednesday, 6 January 2010 00:40:56 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:56 UTC