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

On Jan 5, 2010, at 12:04, Michael A. Puls II wrote:

> On Tue, 05 Jan 2010 04:03:15 -0500, Scheppe, Kai-Dietrich <> wrote:
>> I have a question to the group.
>> Browser manufacturers have already begun implementing parts of the HTML
>> 5 specification, while this document is far from ready.

The thing is that the document cannot (in practice) become ready (HTML 4-level "readiness" doesn't count) without implementations starting.

>> In several threads I have noticed comments pointing out that browsers
>> have already created facts and that discussion at hand therefore is a
>> moot point.
>> I find it very disturbing that arguments in discussions are being met
>> with such statements.
>> The spec does not get any better by turning off the brain just because
>> some browser already did something with a half baked recommendation.
>> Am I alone with this assessement or would it be better to focus on the
>> specification irrespective of who did what when?
>> PS: I appreciate the testbed that browser provide in this fashion, but
>> would prefer to keep seeing it as such
> I was thinking the same thing when I read Henri's message <> earlier. In my mind, I was like, "Wait a minute, what?", to be honest.
> Peronally, I don't think we should be held back just yet by sites or browser impelementations. (At least for browsers where new versions are release frequently)

The "held back" and "turning off the brain" rhetoric doesn't change the situation that authors would face.

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

Received on Tuesday, 5 January 2010 11:38:39 UTC