Re: Public feedback on HTML5 video

Philip Jägenstedt, Tue, 29 Dec 2009 13:38:52 +0100:
> On Tue, 29 Dec 2009 11:14:39 +0100, Leif Halvard Silli 
>> Philip Jägenstedt, Tue, 29 Dec 2009 09:01:50 +0100:
>>> On Tue, 29 Dec 2009 08:52:04 +0100, Philip Jägenstedt
>>>> On Tue, 29 Dec 2009 00:44:50 +0100, Edward O'Connor
>> 
>>>>>   1. Do whatever the browser thinks best. [no autobuffer attribute]
>>>>>   2. Please autobuffer. [autobuffer="on"]
>>>>>   3. Please *don't* autobuffer. [autobuffer="off"]
>> 
>>>> I do not support making this distinction, because as an implementor
>>>> I cannot act any differently in case 1 and 3. 

>> According to Tab: [1]
>> 
>> ]]It's up to the UA.  The user may want to autobuffer stuff anyway, for
>> instance. [...] [[
   [...]
>> Again, provided Tab's interpretation is correct, then autobuffer="no"
>> would not be an illusion, unless user agents tended to ignore it - and
>> thus autobuffer - anyhow.
> 
> No, I believe browsers would ignore autobuffer="no" by using the same 
> behavior as when autobuffer is missing altogether. If the browser is 
> clever enough to be conservative with bandwidth (which is what 
> autobuffer="no" asks for) then there's no reason to not do it when 
> the autobuffer attribute is missing too. While it's certainly 
> possible to make an implementation that does make a distinction, I 
> don't see what bandwidth saving techniques should be used for 
> autobuffer="no" but not when the attribute is missing and why.

The "no" would require bandwidth saving. While the "auto" would permit 
both band width saving and buffering. The techniques could be the same, 
yes.

>> It seems logical to me that user and user agents may choose to not
>> autobuffer - and thus that this should be permitted - even if
>> autobuffer is set to "yes". But that overriding autobuffer="no" should
>> be banned. If you think that absence of @autobuffer (in any shape or
>> form) should be equal to banning autobuffering for that element, then
>> a) Tab is wrong and b) I agree that they are equal ...
> 
> I'll let Tab speak for himself and not argue with your interpretation.
> Suffice to say, making autobuffer a 3-state attribute doesn't seem 
> relevant for implementations and would break shipped implementations 
> (FF3.5) which treat autobuffer as a boolean attribute.

I don't remember how well FF3.5 claim to support <video> (when I last 
time checked a released user agent, then I could not get <source> to 
work.) At any rate, there is no better time to change the spec than 
now, when only one user agent has some support ...

> Sites that need to aggressively conserve bandwidth would be better 
> off using <img src="tinyposter.jpg" 
> onclick="replaceWithVideo(this)">, as that is the only way to prevent 
> the browser from accessing the video resource at all before it is 
> needed.

This is certainly a good tip. In the same go one could also wrap the 
image in an anchor element, with role="button", for better 
compatibility when JavaScript is disabled ... 

But this also kind of acknowledges that there is a definition of -  and 
use case for - autobuffer="no".
 
>> Perhaps we need 3 attribute values: autobuffer="on|off|auto", where
>> "auto" is the default.
>> 
>> [1] http://lists.w3.org/Archives/Public/public-html/2009Dec/0458

-- 
leif halvard silli

Received on Tuesday, 29 December 2009 13:39:08 UTC