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 08:52:04 +0100
To: "Edward O'Connor" <hober0@gmail.com>, "Jeremy Keith" <jeremy@adactio.com>
Cc: HTMLwg <public-html@w3.org>
Message-ID: <op.u5ov42rxatwj1d@sisko.linkoping.osa>
On Tue, 29 Dec 2009 00:44:50 +0100, Edward O'Connor <hober0@gmail.com>  

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

Philip Jägenstedt
Core Developer
Opera Software
Received on Tuesday, 29 December 2009 07:52:49 UTC

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