Versioning and the end user

After reading far too many emails, I find the "voices" in this ongoing
conversation are finally coming clear.  This is an attempt at summing up
(and perhaps helping those other folk trying to catch up).  I fully expect
to be shot down in flames ... but you have to try. :)

Please keep in mind that what matters the most is the end user.  Standards
and implementations are a means to an end, not the end itself.  Not breaking
existing web applications is primary.  Adherence to standards is desirable,
but secondary.

Put simply:  Don't screw the user.

Summing the long ongoing interchange over HTML and versioning seems to break
down as follows.

   1. Folk representing non-IE browsers would like to render existing web
   applications that work with IE.
   2. Folk representing the IE browser will not make changes that break
   web applications.
   3. Folk (web authors mainly) who would like a cleaner HTML spec with
   better compliance from all browsers.
   4. Random new features lobbed in from the side. :)

These are in fact quite different goals - not necessarily in conflict.

The goal (1) of better interoperability with IE is certainly worthy and
pragmatic.  I suspect that to the folk implementing other browsers,
interoperability with IE is (and should be) the single most significant
problem in their world.  To achieve this means throughly describing the
current behavior of IE (no matter how ugly).  This goal means nothing to the
IE-folk as they do not need to change.  Chris Wilson of Microsoft has
recently offered to help the folk interested in understanding IE's quicks
(which is a big deal, and something I hope Chris does not come to regret).

I suspect there is legacy code in IE that Chris would much prefer not to
admit exists, much less describe in public detail, and even less bake into a
standard for the next iteration of HTML. :)

Note also that goal (1) must be achieved without any version specifier other
than those already in use.

The goal (2) of not breaking the web, or more to the point, not screwing the
end user - must be absolute.  I am glad to see that Chris (and his manager)
seem to understand this thoroughly, and very relieved to see that they are
absolute on this point.  Less experienced developers often do not at first
understand the importance of versioning and compatibility (and sometimes
even older developers don't "get it" either ... so I'm unsurprised to see
this discussed).

Note that changing any existing browser behavior absolutely requires some
means of explicit "opt-in" from web authors.  The usual way to be this is
via a version identifier (i.e. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML
Yes, there might be odd cases where you can sneak in new function without
changing versions, but this is risky (unexpected interactions), and very
much the exception.

The goal (3) is aimed mainly at cleaning up (somewhat) HTML for future
applications.  After the last few years digesting the current state of
HTML/CSS/Javascript it is clear that the aftermath of the browser wars left
a huge mess.  Still, you can pick out a relatively clean and somewhat
consistent model for the browser side of web applications.  As a single
crystallizing thread I would pick:  How should we best teach browser-side
programming for web applications?  To do this we a model.  The model should
tell us what to ignore (a great deal), and what to emphasize.

Given a model we can identify "quirks" both in the specification and in the
browser implementations that are most important to address.

A good set of validation tests as part of the standards effort is in fact more
important than the actual specification.  Given a good set of validation
tests all the browser implementations should be much closer to the
standard.  Given a really good set of validation tests, web applications
that work across browsers should be more the rule than the exception.

As to goal (4) ... that is something I do not want to touch :), other than
noting we must keep the other goals in mind.

Received on Tuesday, 17 April 2007 01:42:14 UTC