- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 5 Jan 2010 16:50:07 -0800
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Philip Jägenstedt <philipj@opera.com>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, public-html@w3.org
On Tue, Jan 5, 2010 at 4:44 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > On Wed, Jan 6, 2010 at 11:22 AM, Jonas Sicking <jonas@sicking.cc> wrote: >> On Tue, Jan 5, 2010 at 4:05 PM, Philip Jägenstedt <philipj@opera.com> wrote: >>> On Wed, 06 Jan 2010 00:44:44 +0100, Silvia Pfeiffer >>> <silviapfeiffer1@gmail.com> wrote: >>> >>>> On Wed, Jan 6, 2010 at 5:20 AM, Philip Jägenstedt <philipj@opera.com> >>>> wrote: >>>>> >>>>> On Tue, 05 Jan 2010 18:19:11 +0100, Leif Halvard Silli >>>>> <xn--mlform-iua@målform.no> wrote: >>>>> >>>>>> Philip Jägenstedt, Tue, 05 Jan 2010 17:35:54 +0100: >>>>>> >>>>>>> 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. >>>>>> >>>>>> If we are to start with two values only, then why not "full" and >>>>>> "minimal" instead of "full" and "auto"? 'Minimal' is still only a word >>>>>> that means "as little as possible" - thus it is understandable that >>>>>> exactly how little depends on what the UA is able to do with the >>>>>> resources at hand. >>>>> >>>>> I wouldn't mind that if the absence of the attribute or any unknown value >>>>> is >>>>> equivalent to "minimal". >>>> >>>> I'm happy with that. >>>> >>>> All I absolutely wanted was an explicit specification of the two >>>> states - "full" and "minimal". I would agree to add "auto" just to >>>> give browsers the possibility to do whatever they like, which, >>>> however, is equivalent to not mentioning the attribute, so not >>>> necessary. >>> >>> I expect "auto" and be "minimal" to be equivalent, but I would have to agree >>> that "auto" as a default is more intuitive. If all browsers treat auto as >>> minimal then it's a redundant state, but oh well... >> >> This still gets back to the question: Do we expect browsers do >> anything other than minimal amount of network traffic for markup like: >> >> <video src="video.ogg"> >> >> And if expect them to just do minimal amount of downloading for that, >> why do we need another state meaning "I know you'd just download the >> minimum if I didn't say anything, but I still want to tell you to just >> download the minimum"? > > The introduction of an explicit attribute to specify "minimal" > buffering means that when the attribute is not in use, the browsers > can do whatever they like, which is effectively what is happening > today (stepping back from calling it a "bug"). Thus, if an author > really wants just the minimum, they can now explicitly say > buffer="minimal". Like I said, the distinction only matters if browsers actually do do something other than minimal download when given no hint. However Maciejs reply seems to indicate that webkit will, in which case I agree that it makes sense to make a distinction. / Jonas
Received on Wednesday, 6 January 2010 00:51:01 UTC