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

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 5 Jan 2010 10:19:49 -0800
Message-ID: <63df84f1001051019p7401949bgff12c14f13e7248d@mail.gmail.com>
To: Shelley Powers <shelley.just@gmail.com>
Cc: Henri Sivonen <hsivonen@iki.fi>, "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:09 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> On Tue, Jan 5, 2010 at 7:26 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> On Jan 5, 2010, at 15:14, Shelley Powers wrote:
>>> Are you saying that Firefox would be incapable of supporting something
>>> like a buffer="yes", buffer="no", or buffer="auto" (browser, use best
>>> judgement)?
>> No, that's *not* what I'm saying. Did you notice the last paragraph of http://www.w3.org/mid/124742CE-E050-4E88-ACE5-1613CC37E555@iki.fi ?
>> What I'm saying is that authors wouldn't be able to use autobuffer='off', autobuffer='false', autobuffer='no' to cause *less* traffic to their servers as long as there are browsers use that treat autobuffer as a boolean attribute.
> There's a danger though in allowing advance implementations to
> preclude redefining elements or attributes in the spec.

I don't think anyone has suggested that that.

> We run the
> risk of leaving littered, not supported elements and attributes in our
> wake--because some browser implemented some piece of functionality
> from HTML5, which isn't even in LC state yet.

What have been suggested is that we take the reality of the world into
account. Even if firefox was changed to treat autobuffer="off" as "do
not autobuffer", websites might not be able to use it for many years
until the number users of currently released versions of firefox is
very small.

So the real world question here is. Do we think using the name
'autobuffer' is worth sites not wanting to use that attribute for a
few years?

/ Jonas
Received on Tuesday, 5 January 2010 18:20:43 UTC

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