- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Mon, 16 Apr 2007 01:07:15 +1000
- To: Mihai Sucan <mihai.sucan@gmail.com>
- CC: public-html@w3.org
Mihai Sucan wrote: > Le Sun, 15 Apr 2007 13:18:15 +0300, Lachlan Hunt > <lachlan.hunt@lachy.id.au> a écrit: >> At this point, it seems all we can do is negotiate for a slightly >> less painful and disastrous outcome. > > Your suggestion is not any inch better. It might be even worse: it gives > the *false* impression we can have an "always standards mode" (latest, > greatest standards mode) rendering. Well, an "always standards mode" is exactly what we want and need, and MS has to provide that for us in one way or another. The only other alternative is to give up and accept that we will never an "always standards mode" switch, but I'm not ready to give up yet. > We all agree that an opt-in is *required* for improved rendering and > standards support in IE.next. Ah, no, we certainly don't all agree. Many of us strongly disagree with that notion. Adding any additional versioning will be a huge mistake with disastrous consequences. But, as I said, MS has made it clear that we have absolutely no choice in the matter. > I don't want the other UAs to "care" about which rendering mode I want > in IE. However, that will probably prove to be inevitable as well: > Opera, Firefox, and Safari will probably "catch"/parse those > conditional comments if they ever make it into any IE version. That is the situation really must try to avoid. > If new versions of IE will be released only on a 5-years basis, then, > yes, we will have a new opt-in for the rendering improvements, with each > release of IE. That is a serious problem. Every single one of those new modes will be undocumented, and other browsers will have no choice but to attempt to reverse engineer each one of them. Given that MS has given us no choice in whether or not we have modes, we need a way to make those modes irrelevant to both authors who don't need them, and browser vendors so they do not have to reverse engineer them all. My solution works slightly better because it assumes by default that pages don't rely on bugs that will be removed from the next browser version in incompatible ways, and doesn't force authors to learn a new opt-in every for every single browser upgrade. But it provides a quick, efficient and cost effective temporary work around for web sites in the event that they were built to rely on such bugs. There will be many sites (an increasing number of them built for standards compliance) that will not break with the next browser upgrade. If we succeed in our goal of defining HTML5 in a way that is compatible with the web, it will be significantly more than than those that will break. Microsoft's proposed solution is backwards. It assumes by default that every site will break with the next upgrade. That is significantly more harmful because it makes the existence of those modes much more relevant to other browser vendors attempting to be interoperable. -- Lachlan Hunt http://lachy.id.au/
Received on Sunday, 15 April 2007 15:07:46 UTC