Re: Public feedback on HTML5 video

On Thu, Dec 24, 2009 at 6:47 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> e.g. A browser being used on a dial up connection or slow public wifi
> connection could detect that and opt not to autobuffer, whereas a user on a
> high speed connection may opt to autobuffer whenever possible, regardless.

I don't think this would be reasonable behavior even on a high-speed
connection, because it costs bandwidth on the server side as well as
the client.  Browsers usually try not do such antisocial things as
downloading giant files that probably won't get used anyway.  Also, if
anything, I think the logic would go the opposite way -- if the
connection is slow, you want to start buffering as far in advance as
possible.  If the connection is fast, failing to buffer might only
delay video start by a second or two, so you might want to save the
memory/disk activity.

> But the spec does not address the issue raised in John's post, whereby the
> author may wish to help conserve server bandwidth by suggesting that the
> video only be downloaded by those users who choose to watch it.

In practice it looks like all browsers agree this should be the
default anyway.  De facto, omitting autobuffer instructs the browser
not to autobuffer (bar WebKit until it's fixed).  As long as this is
the case, we don't need a new value for the attribute.  At most, we
should change the spec to include slightly stronger wording about
buffering when autobuffer is absent, like maybe a "should not".

> One way to address this would be to allow autobuffer to accept the values
> "on" and "off", just like the autocomplete attribute.

This would be incompatible with all existing implementations (which I
guess means Firefox) -- autobuffer="off" would actually tell old
implementations to buffer, rather than the opposite.

Received on Thursday, 24 December 2009 19:46:30 UTC