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

On Tue, Jan 5, 2010 at 5:37 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Jan 5, 2010, at 12:04, Michael A. Puls II wrote:
>
>> On Tue, 05 Jan 2010 04:03:15 -0500, Scheppe, Kai-Dietrich <k.scheppe@telekom.de> 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 <http://lists.w3.org/Archives/Public/public-html/2010Jan/0070.html> 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


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.

This group is more than a rubber stamp for any one browser company, or
even a group of browser companies.

We shouldn't change an existing attribute or element frivolously, but
if there are legitimate concerns, and a strong belief that we need to
make changes, now, before this document goes to last call, then we
should make the changes.

Shelley

Received on Tuesday, 5 January 2010 12:46:30 UTC