- From: Philip Jägenstedt <philipj@opera.com>
- Date: Mon, 04 Jan 2010 12:35:53 +0100
- To: "Henri Sivonen" <hsivonen@iki.fi>, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
- Cc: "Chris Double" <cdouble@mozilla.com>, "Robert O'Callahan" <robert@ocallahan.org>, "Maciej Stachowiak" <mjs@apple.com>, HTMLwg <public-html@w3.org>
On Mon, 04 Jan 2010 11:41:32 +0100, Henri Sivonen <hsivonen@iki.fi> wrote: > On Jan 3, 2010, at 13:14, Silvia Pfeiffer wrote: > >> I assume similar reasons may be the case with some of the other sites >> that also chose autobuffer="true". > > It's unfortunate that the term "boolean attribute" makes people assume > that the attributes take values "true" and "false". The language > implementation pattern of boolean attributes being sensitive to presence > or absence is way too late to change. If a spec change is to be made > about "boolean attributes", the best that can be done is calling them > something else (what?) that doesn't suggest they can take "false" as a > value. > > As for making autobuffer tri-state, I think changing it at this point is > too late, because it has already been implemented as a boolean attribute > in a browser that has significant market share > (http://www.neowin.net/news/main/09/12/22/firefox-35-surpasses-ie7-market-share). > > At this point, I think the available options (if there's agreement that > authors should be able to instruct browsers not to buffer) are minting > another boolean attribute 'nobuffer' or a tri-state attribute > 'buffering' (with precedence rules relative to autobuffer). At least for this implementor, the only state which is in any way different from todays two states is a state which stalls fetching before it starts. However, it's only viable if all browser vendors agree that it's a good idea and are willing to implement it, otherwise I won't push it. I don't support adding a state which basically means "download enough to get metadata but less than the whole resource, at least until the video has begun playback". That's not a very meaningful requirement and likely to be misunderstood, especially with a name like autobuffer="off" or nobuffer. As far as I can see it's not a new state implementation-wise and just gives the illusion of control where there is none. I'd like to wait until some browser which supports (the absense of) autobuffer finds that they really need explicit author control to get good performance before going ahead with anything like this. -- Philip Jägenstedt Core Developer Opera Software
Received on Monday, 4 January 2010 11:36:43 UTC