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

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 3 Jan 2010 18:04:49 +1100
Message-ID: <2c0e02831001022304h53b1624dw759ee447a504dcc4@mail.gmail.com>
To: robert@ocallahan.org
Cc: Maciej Stachowiak <mjs@apple.com>, HTMLwg <public-html@w3.org>
On Sun, Jan 3, 2010 at 5:53 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Sun, Jan 3, 2010 at 5:47 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> On Sun, Jan 3, 2010 at 5:42 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>> It would have no visible effect other than performance, and the difference
>>> would be much less in the typical test environment where the author has a
>>> very fast pipe to his or her deployment server.
>> The performance effect is very noticeable, and if your controls UI shows the
>> buffer state, it's quite obvious what's going on.
>> One problem with making 'autobuffer' tri-state is that autobuffer="off" (or
>> whatever) is actually going to enable buffering in user-agents that support
>> the current autobuffer spec (i.e., Firefox).
> Only until current implementations have caught up. I don't see this as
> a big problem. Everyone expects HTML5 to still change and I have seen
> more Webpage with the video element wrongly coded with
> autobuffer="off" and autobuffer="on" than just using it as a boolean
> attribute. Even tinyvid.tv - Chris Double's test platform for Mozilla
> - is using autobuffer="true" and controls="controls" as attributes.
> It's more natural.
> Also, since Firefox is currently the only browser actually not
> autobuffering, it is only noticeable for people who rely on the
> Firefox behaviour - which would be few.

Did a few more checks on the big HTML5 video supporters, FWIW:

Dailymotion and Archive.org use autobuffer="true"
Wikipedia uses autobuffer=""
Metavid and Pad.ma don't use the attribute

I know the person at Wikipedia who needs to change it. Then we should be set!

Received on Sunday, 3 January 2010 07:05:41 UTC

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