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

Philip Jägenstedt, Tue, 05 Jan 2010 19:20:04 +0100:
> 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".

Sounds OK to me. I assume that "minimal" could also avoid the reversion 
confusion you spoke about above.

If we really would like to have a boolean attribute, then it strikes me 
that an active sounding name, such as "buffer", would have been easier 
to understand than "autobuffer". Authors could then have interpreted 
the buffering feature to work like this: when @buffer is present, then 
UAs will buffer. Otherwise, when not present, they will not buffer.

Since the actual trouble is in _preventing_ the buffering, then it also 
is a misnomer to use "auto" about what happens when it _does_ buffer: 
In a pipe the water flows where gravity leads it. You would not label 
the handle of a water valve an "autoflow" feature ... 

You want <video> to have a default autochoke feature ... Which authors 
can disable when needed.

Btw, the spec should also explain which factors that limits how small 
the buffering can become. Namely, it should explain that use of a 
poster image and some other attributes and features may affect this.
-- 
leif halvard silli

Received on Tuesday, 5 January 2010 19:52:51 UTC