- From: Preston L. Bannister <preston@bannister.us>
- Date: Mon, 16 Apr 2007 18:42:11 -0700
- To: public-html@w3.org
- Message-ID: <7e91ba7e0704161842l799e9e1cvc98c9ce496033174@mail.gmail.com>
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 5.0//EN">). 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