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

On Tue, Jan 5, 2010 at 7:49 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Shelley Powers, Tue, 5 Jan 2010 07:31:21 -0600:
>> 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.
>>
>> And autobuffer is from which released specification, where we have to
>> worry about legacy use?
>
> Note that he said "as long as".
>
>> Regardless, perhaps the best approach is a new attribute, and we
>> encourage abandonment of autobuffer.
>
> I think we have reached this conclusion for the second time now. ;-)


Then it is past time to file a bug, and begin moving this change
through the process.

>
> It was also mentioned that @buffer/@buffering also has other
> advantages. For instance, if we find out later that we want more than 3
> values for it. E.g. something like "autobuffer="50%" doesn't sound as
> intuitive as "buffer="50%".
> --

As long as everyone is agree that autobuffer becomes a non-conforming
attribute, I have no problems with using a more meaningful attribute
name.

> leif halvard silli
>

Shelley