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

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 5 Jan 2010 16:50:07 -0800
Message-ID: <63df84f1001051650g5fc21081t6b8a1f942d71c85@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:57 GMT