W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: Public feedback on HTML5 video

From: Philip Jägenstedt <philipj@opera.com>
Date: Tue, 29 Dec 2009 09:01:50 +0100
To: Philip Jägenstedt <philipj@opera.com>, "Edward O'Connor" <hober0@gmail.com>, "Jeremy Keith" <jeremy@adactio.com>
Cc: HTMLwg <public-html@w3.org>
Message-ID: <op.u5owlcfuatwj1d@sisko.linkoping.osa>
On Tue, 29 Dec 2009 08:52:04 +0100, 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

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



-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Tuesday, 29 December 2009 08:02:32 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:55 UTC