On Jan 5, 2010, at 14:45, Shelley Powers wrote: > On Tue, Jan 5, 2010 at 5:37 AM, Henri Sivonen <hsivonen@iki.fi> wrote: >> The fact of the matter is that a browser with a relatively high market share buffers more with autobuffer='off' or autobuffer='false' than when the attribute is absent. Thus, changing the spec to say that autobuffer='off' must not autobuffer, would not give authors the ability to turn buffering off, since specifying the attribute would have the effect of buffering more--not less--as long as the browser release in question has an installed base. >> >> It's one thing to refine a feature slightly but in the same general direction. It's quite another to mint syntax that has the exact opposite effect from what is desired in deployed software. >> >> For practical purposes, the current state of affairs is a legacy constraint regardless of how the current state of affairs came about: implementation of an old REC, implementation of a draft or vendors just making stuff up. >> >> -- >> Henri Sivonen > > > We can appreciate that one browser has begun implementation of the > video element, with a certain behavior, but it did so without > following a released specification. As such, the browser maker has to > be aware of the fact that it may need to change its behavior, if this > group decides that the implementation will cause additional problems > in the future. Note that the point I made above was about whether a spec change is something that would actually give authors the ability to control buffering. I wasn't making a point about making changes to a browser. > This group is more than a rubber stamp for any one browser company, or > even a group of browser companies. What this group is is irrelevant to the question of whether authors would actually be able to make browsers download less data by specifying autobuffer="off" given software that's already deployed and out there. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/Received on Tuesday, 5 January 2010 13:00:23 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:06 UTC