W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Browser implementations, prior to rec, used for justification

From: Shelley Powers <shelley.just@gmail.com>
Date: Tue, 5 Jan 2010 07:14:40 -0600
Message-ID: <643cc0271001050514x4dec0aa0tdf8c6656bdaca4fa@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: "Michael A.Puls II" <shadow2531@gmail.com>, "Scheppe, Kai-Dietrich" <k.scheppe@telekom.de>, HTMLWG WG <public-html@w3.org>
On Tue, Jan 5, 2010 at 6:59 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> 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

Are you saying that Firefox would be incapable of supporting something
like a buffer="yes", buffer="no", or buffer="auto" (browser, use best
judgement)?

(If I've captured the tri-state correctly)

Shelley
Received on Tuesday, 5 January 2010 13:15:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:57 GMT