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

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".

Regards,
Silvia.

Received on Wednesday, 6 January 2010 00:45:09 UTC