Re: Public feedback on HTML5 video

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

> 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. Any browser that has
>>> gone to the effort of being conservative with network resources will
>>> want that behavior even if autobuffer="off" is given. Unless there
>>> is some browser
>>
>> Typo... even if autobuffer="off" is *not* given
>>
>>> vendor who can see themselves acting differently in case 1 and 3,
>>> this just adds a bit of complexity and the illusion of control on
>>> part of the author where there is in fact none.
>
> According to Tab: [1]
>
> ]]It's up to the UA.  The user may want to autobuffer stuff anyway, for
> instance.  Or the browser might be able to tell that the bandwidth is
> good, and autobuffer videos when they're the only video on the page
> (avoiding the scenario when they start autobuffering a video gallery
> page and cripple your connection).  Whatever turns out is best for the
> user.  The presence or absence of @autobuffer is just a suggestion
> from the author.[[
>
> If Tab's interpretation of what absence of boolean @autobuffer means,
> is valid, then a use case for autobuffer="no" could be someone that is
> offering one or several videos on a cheap web host - with a bandwidth
> serving limit - and who, for everything in the world, do not want users
> to actually load any of them unless when they actively click a
> particular video. I believe that autobuffer="no" then should be able
> solve that problem.
>
> 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.

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

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.

> 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 12:39:38 UTC