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

Re: A Compromise to the Versioning Debate

From: aurélien levy <aurelien.levy@free.fr>
Date: Sun, 15 Apr 2007 11:21:43 +0200
Message-ID: <4621EEA7.2080402@free.fr>
To: public-html@w3.org

Hi,

+1 why not reproduce the same shema as with the HTML 4.01 loose dtd with 
a specific dtd to switch to quirk's mode.

By the way, for my part, i don't understand the microsoft speech about 
"fix the css hack on your site". Isn't IE7 supposed to correct the ie6 
bug? If i make standard website who render good in opera or firefox for 
exemple, then add some * html hack for a good rendering in ie6 and 
under. They are supposed to be inoperant in IE7 and he is supposed to 
render standard mode correctly too (witch is often the case 
fortunately). So, i don't need any fix but maybe it's more for the non 
standard website outthere?

Aurélien Levy
---
http://www.fairytells.net

>
> 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.
>
Received on Monday, 16 April 2007 11:40:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:53 GMT