- From: Shelley Powers <shelley.just@gmail.com>
- Date: Tue, 5 Jan 2010 08:09:23 -0600
- 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 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. 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. The only reason I agree with abandoning autobuffer now, is that I think the name "autobuffer" is confusing, while buffer is less so. But the fact that one or two browsers may have done a partial implementation of a feature still in development should not be a deciding factor in what we do, or do not do, in the future. There is risk when user agents implement HTML5 features. There is risks to authors who use the elements and attributes now. People know this -- let's not downplay the risk. > -- > Henri Sivonen Shelley
Received on Tuesday, 5 January 2010 14:09:52 UTC