- From: Philip Jägenstedt <philipj@opera.com>
- Date: Tue, 05 Jan 2010 10:35:14 +0100
- To: "Scheppe, Kai-Dietrich" <k.scheppe@telekom.de>, "Aryeh Gregor" <Simetrical+w3c@gmail.com>, robert@ocallahan.org
- Cc: "Maciej Stachowiak" <mjs@apple.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>, "Edward O'Connor" <hober0@gmail.com>, "Jeremy Keith" <jeremy@adactio.com>, HTMLwg <public-html@w3.org>
On Tue, 05 Jan 2010 09:43:48 +0100, Scheppe, Kai-Dietrich <k.scheppe@telekom.de> wrote: > Hi, > >> What are the actual use-cases for author control over buffering here? >> The only reasons I can think of are >> >> 1) Improve user experience. >> 2) Conserve server bandwidth. >> >> For (1), is it likely that typical authors will ever be able >> to make a better guess on whether autobuffering is needed >> than implementers? >> Why would this be? What information would authors have that >> the browser couldn't figure out just as well? This is all >> keeping in mind that while browser heuristics will fail >> sometimes, so will author use of the autobuffer attribute. > > The question is not whether authors are likely to do something or not. > By not giving them the opportunity in the first place we will certainly > keep them from learning. > > Furthermore, it is not the small time authors that drive usage of > technology, but the big ones, who have a stake in doing it correctly and > serve as examples to the others. > Everybody looks at how the "big guys" are doing it. > > As such please do not discount that people are capable of doing things > correctly. > > >> For (2), is a "conserve server bandwidth" feature needed, if >> browsers only ever buffer enough to play through the video at >> worst (i.e., don't buffer the whole thing like Firefox 3.5 >> seems to do if autobuffer is set), and usually only do that >> if the user is actually going to play the video, and authors >> who really care can use script hacks? >> >> I'm concerned that autobuffering is too subtle for average >> authors to get right even with only two options, let alone if >> a third is added. > > Perhaps, but then HTML 5 is not exactly setting out to be fool proof :-) > If HTML 5 wants to be true to its goals of cleaning up what has been > done wrong before, then this is not for the timid. This is a new feature and there is nothing to clean up. I'm really keen to know what precisely the suggested feature is, because "no autobuffering" and "no buffering" is far too vague for at least me to understand. -- Philip Jägenstedt Core Developer Opera Software
Received on Tuesday, 5 January 2010 09:36:03 UTC