- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sun, 3 Jan 2010 18:04:49 +1100
- 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! Cheers, Silvia.
Received on Sunday, 3 January 2010 07:05:41 UTC