Re: Public feedback on HTML5 video

On Tue, 29 Dec 2009 15:21:43 +0100, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Wed, Dec 30, 2009 at 1:13 AM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Tue, 29 Dec 2009 14:26:44 +0100, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>> On Tue, Dec 29, 2009 at 6:52 PM, Philip Jägenstedt <philipj@opera.com>
>>> wrote:
>>>>
>>>> On Tue, 29 Dec 2009 00:44:50 +0100, Edward O'Connor <hober0@gmail.com>
>>>> wrote:
>>>>
>>>>>> Is the absence of the autobuffer attribute an explicit request not  
>>>>>> to
>>>>>> pre-buffer?
>>>>>
>>>>> I'd rather it not be.
>>>>>
>>>>> I think it's important for the author to be able to say "hi browser,
>>>>> please do whatever is most appropriate given your platform / network
>>>>> connection / memory / etc., insofar as buffering is concerned." In  
>>>>> fact,
>>>>> I suspect this to be the most common authoring case. Most authors  
>>>>> would
>>>>> prefer it if, say, cell phone browsers defaulted to no-autobuffering,
>>>>> whereas they might prefer desktop browsers to behave differently.  
>>>>> Given
>>>>> that, I'd prefer the default/lazy authoring behavior (not specifying  
>>>>> the
>>>>> attribute at all) to have this meaning.
>>>>>
>>>>> Essentially, we have three things we'd like authors to be able to  
>>>>> convey
>>>>> to the browser:
>>>>>
>>>>>  1. Do whatever the browser thinks best.
>>>>>
>>>>>  2. Please autobuffer.
>>>>>
>>>>>  3. Please *don't* autobuffer.
>>>>>
>>>>> And there are a few things we'd like to be able to say about whatever
>>>>> design we settle on:
>>>>>
>>>>>  A. (1) above should be the default condition, so its syntax should  
>>>>> be
>>>>>    what most authors will do anyway (not provide attributes at all).
>>>>>
>>>>>  B. Any new boolean attributes should behave like the other boolean
>>>>>    attributes already present in HTML (presence means t and absense
>>>>>    means nil).
>>>>>
>>>>>  C. If at all possible, we should be able to use different values for
>>>>>    the same attribute for (2) and (3). (Minting separate attributes
>>>>>    for (2) and (3) means allowing authors to write nonsensical  
>>>>> markup,
>>>>>    and having to spec what HTML5 processors should do when they're
>>>>>    both present. What does <video buffer nobuffer> mean?)
>>>>>
>>>>> There's a lot of tension between (B) and (C), so much so that I think
>>>>> autobuffer="" should probably become an enumerated attribute[1]  
>>>>> instead
>>>>> of a boolean attribute. Something like the following:
>>>>>
>>>>>  1. Do whatever the browser thinks best. [no autobuffer attribute]
>>>>>
>>>>>  2. Please autobuffer. [autobuffer="on"]
>>>>>
>>>>>  3. Please *don't* autobuffer. [autobuffer="off"]
>>>>>
>>>>>
>>>>> Ted
>>>>>
>>>>> 1.
>>>>>
>>>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#keywords-and-enumerated-attributes
>>>>>
>>>>
>>>> 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 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.
>>>
>>> I believe as a desktop browser on a web page with only one video in a
>>> prominent location ("above the fold"), I would decide to autobuffer.
>>> The same web page on a mobile phone browser, I would not decide to
>>> autobuffer.
>>>
>>> With more than one video on a page, I would probably autobuffer  
>>> nothing.
>>>
>>> This is a minor distinction though. Maybe you are right and there is
>>> never a need to autobuffer unless the autobuffer attribute is given.
>>> In this case, though, we should change the specification and make it
>>> clear that when autobuffer is given, it will autobuffer and when
>>> autobuffer is *not* given it will *not* autobuffer (unless autoplay is
>>> given).
>>>
>>> There are in fact two problems with the current specification:
>>>
>>> 1. it doesn't allow specification by the page author to *not*
>>> autobuffer - all the page author (and user) can *hope* for is that by
>>> not specifying the attribute, the user agent will not buffer.
>>
>> It just seems to me that any sane browser would conserve bandwidth if it
>> knows how to, allowing the author to ask for that is a little bit like
>> <script slowdown="no">.
>
> I would say that John Gruber's discovery has contradicted this statement.

Isn't it just that most browsers (all except Firefox?) are ignoring the  
autobuffer attribute? It seems that the solution is to implement  
conservative network usage and to let the autobuffer attribute disable  
this behavior. In my opinion, the difficult part is actually being  
conservative to begin with and I don't know if there's any point in  
introducing shades of conservative.

> Also, if we really are asking for no autobuffering when the attribute
> is not present, then this has to be stated in the HTML5 standard. So,
> either we introduce a autobuffer=yes/no option or we prescribe that
> when autobuffer is not present it means no autobuffering. Either
> requires a change to the spec.

We could add a non-normative note to implementors that it's nice if they  
don't waste bandwidth, even though I'm sure all implementors are already  
very aware of this.

>>> 2. it does not allow a user override of a page author's decision,
>>> where the page author actually may not have all the information (e.g.
>>> that it's running on a mobile phone or on a low-bandwidth connection -
>>> as Laura's example states; or the opposite - that I want to autobuffer
>>> everything cause my bandwidth is unlimited)
>>
>> Since the spec allows the UA to ignore the autobuffer attribute, the UA  
>> is
>> allowed to have a user-settable pref for this, so I believe this is  
>> already
>> covered. Perhaps a note or something in the spec would help clarify this
>> though.
>
> Yeah, I think a recommendation to user agents to have such a
> preference would be good. I am aware that user preferences are not
> part of the HTML5 specification, but it is a good recommendation to
> make.
>
> Cheers,
> Silvia.
>


-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Tuesday, 29 December 2009 14:36:12 UTC