- From: Philip Jägenstedt <philipj@opera.com>
- Date: Tue, 05 Jan 2010 17:35:54 +0100
- Cc: "HTML WG" <public-html@w3.org>
On Tue, 05 Jan 2010 14:00:00 +0100, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > On Tue, Jan 5, 2010 at 8:35 PM, Philip Jägenstedt <philipj@opera.com> > wrote: >> 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. > > To me it means "whatever you do, dear browser, for god's sake do not > download the full resource. Only download as little as is absolutely > necessary from the media resource to display that there is a video > that can be played. Preferably download nothing at all". > > It is basically an outcry of a Web author that currently cannot be > expressed in HTML5 - it is only implicitly assumed. A Web author can > only hope that this is what a browser will do when he/she doesn't use > the autobuffer attribute. It is almost like declaring a variable but > not initialising it and hoping that the compiler will explicitly set > it to 0, even though the compiler specification doesn't say so. I support replacing the autobuffer attribute with a buffering attribute, Absence of autobuffer is replaced with buffering="auto" (um, this reversion *will* confuse, but oh well) while its presence is replaced with buffering="full". It's possible to add any number of states, but I don't support adding a third buffering="minimal" until it is shown in a browser that distinguishes between the first two states (e.g. Firefox 3.5) actually need a third state. If speccing only two states makes the change seem pointless, I would tend to agree, but at least it leaves the possibility of adding more states should they become necessary. Note: I'm not saying that a "minimal" state will be pointless for all future, I'm saying that it's better to wait on a proof-of-concept implementation that does something useful before deciding what to call a new state and what its conformance requirements should be. -- Philip Jägenstedt Core Developer Opera Software
Received on Tuesday, 5 January 2010 16:36:35 UTC