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