W3C home > Mailing lists > Public > public-html@w3.org > April 2007

A Compromise to the Versioning Debate

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Sun, 15 Apr 2007 16:20:23 +1000
Message-ID: <4621C427.7080605@lachy.id.au>
To: public-html@w3.org

Hi Chris,
   I do not think you are inherently evil.  The effort you put into 
making IE7 more standards compliant proved that your intentions were 
good; and the web standards community largely applauded your effort at 
the time.

During Microsoft's development of IE7, some design choices were made 
that unnecessarily resulted in some unfortunate incompatibilities.  For 
example, you fixed the * html filter, but you didn't fix the limitations 
for which it was widely used.  Thus, pages that still needed to have 
those patches applied no-longer did, and things broke.

In other words, you forced pages that used well-documented and widely 
deployed hacks, to be changed.  Hacks that were designed in the hope 
that when you introduced more standards compliant behaviour, you would 
take away the dependence on those hacks.  Things could have gone better 
if you had fixed the limitations as well as the filters, but, for 
whatever reason, you were unable to do so.

Many of us feel that your proposed solution is set to repeat mistakes 
again, and again, and again, indefinitely!  You already admitted that it 
is prohibitively expensive for Microsoft to maintain compatibility with 
legacy office suite versions.  Yet you're willing to do *the same thing* 
with HTML?

Your plans, if you go ahead with them, will create a vendor-lock-in 
situation where every single browser now and in the future will be 
inherently forced to reverse engineer every single one of your 
frozen-bug-states that you introduce with every new browser version. 
That is unacceptable.

It has become clear that you place backwards compatibility above 
interoperability.  But they do not necessarily have to be mutually 
exclusive goals.  In an ideal world, what we spec would be 100% 
backwards compatible and 100% interoperably implemented.  But we have 
find a balance between interoperability for the future and backwards 
compatibility with the past.

So I'm hoping, that by appealing to your sense of reasoning, we can find 
such a balance that we, while not necessarily fully agreeing, can at 
least live with.

Web developers *do not* want to be forced to develop with an infinite 
number of frozen-bug states in the future.  Plenty of authors have 
enough trouble trying to understand why changing or removing the DOCTYPE 
can result in completely different rendering and behaviour of scripts, 
and that won't be improved by introducing more modes.

Unfortunately, you have already made it clear that we have no choice in 
existing DOCTYPEs triggering IE7 mode from now on.  So whether we like 
it or not, you're forcing us to live with that decision.  Although it 
really is unacceptably repeating a past mistake, continuing to argue 
with you about it seems futile.

If you must, it's practical for you to go ahead and make <!DOCTYPE html> 
trigger full standards mode for future documents, leaving existing docs 
in IE7 mode.

But it is not only unacceptable for you to repeat that mistake and force 
it upon us again and again in the future every single time you release a 
new browser, it becomes exponentially worse as time goes on and more 
modes are added.

Authors must not be *forced* to learn a new opt-in every single time you 
release a new browser.  There are plenty of authors, including myself 
and many that I have spoken to, who want and *need* a way to trigger 
full standards mode now and in the future, with all future browser versions.

Give authors the choice.  Let those authors who wish to lock themselves 
into a particular IE-frozen-bug-state specifically opt-in to using that 
version.  But let the rest of us who want to make an informed decision 
to always use the *latest* standards mode do so.  Don't force us to be 
locked in to a frozen bug state that we don't want.

So here's my suggestion.  It's not an ideal solution, but I, and I think 
others, could live with it given that the alternative you're proposing 
is far, far worse.  In other words, this is the lesser of two evils.

Make <!DOCTYPE html> *always* trigger the latest standards mode, unless 
accompanied by an explicit switch.

e.g.

<!DOCTYPE html>
<!--[mode = IE8]-->
<html>
...

It doesn't really matter what syntax you use for it.  Those of us who 
choose to use <!DOCTYPE html> and explicitly omit the switch are taking 
the risk upon ourselves that something may break with a future release. 
  Those who choose to use the switch are explicitly accepting the 
continued use of IE[n] bugs.

The advantage of this approach is it not only gives the authors a choice 
when they write the page, but in the event that they had omitted the 
switch and something does break, it gives them a quick and easy fix to 
get the site working until a more long term, standards compliant 
solution can be deployed.

Please, I urge you, do not *force* authors to accept your decisions in 
ways they don't want.  We are competent enough to make informed 
decisions for ourselves, so let us do so.  Let us choose to be free from 
vendor-lock-in.

-- 
Lachlan Hunt
http://lachy.id.au/
Received on Sunday, 15 April 2007 06:20:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:42 UTC