Re: Public feedback on HTML5 video

On Tue, 29 Dec 2009 14:38:32 +0100, Leif Halvard Silli  
<xn--mlform-iua@målform.no> wrote:

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

Yes, there is a use case, but the suggested autobuffer behavior doesn't  
address it better than not using the attribute at all, unless the  
suggestion is for autobuffer="off" to allow the browser to stay in  
NETWORK_IDLE/HAVE_NOTHING much longer than otherwise. That would actually  
be a useful feature worth implementing, but autobuffer is a very bad name  
for it.

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


-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Tuesday, 29 December 2009 14:24:13 UTC