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

On Jan 5, 2010, at 1:03 AM, Scheppe, Kai-Dietrich wrote:

> Hi,
>
> 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.
> 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?

I think the existence of one or more implementations is not  
necessarily the end of the story; certainly it does not render further  
discussions moot. But I do think it should be given significant weight  
for the following reasons:

1) Implementing a feature in a prerelease browser or even more so a  
production browser can demonstrate that it is practically  
implementable (or flush out implementability issues at an early  
stage.) An implemented feature has more evidence of implementabiity  
than a newly invented alternative.

2) Implementing a feature in a prerelease browser tends to identify  
all sorts of problems that merely reviewing the spec does not. Often  
ambiguities, contradictions and design flaws are found at this stage.  
Implementors also tend to do testing and think about how authors would  
use the feature, so they can give additional feedback from the  
authoring point of view. Thus, a feature that has had the level of  
scrutiny that only implementation can bring is likely to be more  
refined.

3) Features that exist in browsers can get testing and valuable  
feedback from content authors - a feature that has been implemented  
for a while and through several rounds of feedback is likely to be  
more solid.

4) Once browsers ship, content may begin to rely on non-standard or  
pre-standard features. At some point, incompatible changes risk an  
unacceptable level of breakage. This is especially so when the feature  
is around for a while, and implemented in multiple browsers,  
particularly high market-share ones.

For these reasons, I believe we should give due consideration to  
existing implementations, existing deployed content, and what we have  
learned from those experiences.

Furthermore, we're probably going to have to significantly reduce the  
rate of change well before REC. Once the spec is in CR, the W3C is  
calling for implementations, and will require multiple interoperable  
implementations to advance to the next stage. After that point it  
would not be reasonable to treat any feature as if it could be  
redesigned from scratch, other than cases where we find insurmountable  
problems that require an incompatible change.

Regards,
Maciej

Received on Tuesday, 5 January 2010 09:18:17 UTC