Re: Version information

Chris Wilson wrote:
>> The only way a UA can promise to really never change anything for old
>> content is to never fix bugs in older versions of a specification
>> after shipping the first implementation.
> 
> Indeed.  Unless you require content developers to opt in to that changed-but-correct behavior

But different UAs would then need different ways of opting in, since they would 
have had different bugs.  While this sort of works for different standard 
versions or as a one-time thing (e.g. the quirks-vs-standards switch in existing 
browsers), this is not a reasonable way to proceed in general.  Otherwise you 
end up with one opt-in for IE8 behavior vs IE7 behavior, one opt-in for Gecko 
1.9 vs Gecko 1.8, one for Opera 10 vs Opera 9, and so forth....

In other words, the opt-in approach as suggested presupposes that pages are 
written to target a particular UA and UA version, not to target a particular 
standard.  I think for whatever specifications this group comes up with it 
should strongly discourage such authoring.

I do appreciate your not wanting to break sites, and I'm not suggesting you do 
it gratuitously.  But I do think that a line-in-the-sand approach is not the way 
to go either.  A better approach to behavior changes is to evaluate them 
individually; if a change to IE behavior makes IE behave like other UAs, perhaps 
it's safer to make than a change which does the opposite.  A good example here 
would be certain corner cases in HTML parsing, where interoperability is 
nonexistent, and where I frankly wouldn't expect significant numbers of pages to 
depend on any particular UA's behavior.

Note that there is a big difference between the set of sites a change could 
potentially break (all pages that the UA would actually apply the changed 
behavior to) and the set of sites it actually breaks (pages that rely on the old 
behavior).  Getting stats on the former is easy.  Getting stats on the latter is 
harder, but necessary if one is to make progress on implementing the 
specifications correctly, in my opinion.  Unless one writes bug-free code, of 
course.  ;)

All that said, I fully expect that the specifications this group produces will 
attempt to minimize the differences between the specification and UA practice in 
all cases where UAs are reasonably interoperable.  That's the only way to get 
the UA makers to accept the specification, really.

> Indeed, and I spent tons of time reverse-engineering Netscape behavior back in the day.

Right.  We've all had to do our share of that sort of thing.  One of the goals 
of this working group, as I understand, is to minimize the need for that on the 
part of existing and future implementors by doing the reverse-engineering of 
existing implementations once, codifying the aspects that they implement 
interoperably, and specifying the remainder in a way that is as sane as possible.

-Boris

Received on Saturday, 7 April 2007 00:12:50 UTC