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