Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8

by Aaron Gustafson

253 Reader Comments

Back to the Article
  1. Sounds to me like this solution will:

    a) Put control back in the hands of developers
    b) Remove the panic of ‘Uh-oh, this site could break! Quick! Find the solution before the client calls-up and complains!’

    Dog wagging tail, rather than tail wagging dog …

    Copy & paste the code below to embed this comment.
  2. Another clarification in your article which I think might be nice is on who this “our group” is who recommended this solution to MS.
    You write:
    “Unwilling to make the same mistake twice, Microsoft reached out to The Web Standards Project (of which I am a member) and to several other standards-aware developers, and asked for our help in coming up with a better method of allowing developers to “opt in”? to proper standards support.”
    “This is exactly what our group decided to recommend for IE8, and we hope to see it implemented in other browsers as well.”

    But that ‘our group’ very much isn’t the whole of the Web Standards Project, as for example “Andy Clarke writes”: :
    “Just to be clear Anne, the members of the Web Standards Project in general were not informed about this article and Microsoft’s proposal/plans”

    Copy & paste the code below to embed this comment.
  3. I have tried to explain to myself why opt-in would be a good thing. I can’t convince myself. Everytime a new browser or browser version appears, I need to change my web pages telling the browser it should render the page against it’s latest engine, otherwise it won’t do that automatically.

    Why is the meta tag introduced? To give developers an opportunity to ‘grade back’ once they have discovered a fatal flaw that they were unable to fix, in other words when the browser introduced something that has broken an existing web standard. I mean, surely, after all these years of fighting and WaSPing, no browser vendor would even think to introduce a new browser that breaks existing standards? Right?

    If there was a down-grade meta tag introduced in IE8, I could understand that Microsoft would have a solution in place for a quick-fix to their (corporate) clients. That is fine, I do not have any objection to that. In case of IE7 that triggered this whole idea: if IE7 would have had a down-grade ‘render as IE6’ option, that could also be served up by the webserver in the header, that’s great. That’s a real world solution to real world problems.

    Now, Microsoft is putting a price tag on innovation to its customers: if you want to progress, alter your meta tags first, otherwise it won’t work.

    Copy & paste the code below to embed this comment.
  4. One of the biggest mistakes of the web development community was to struggle to try and make sites work on old or buggy browsers.

    You see, we’re all really determined to give our end-users the best experience possible, even if it causes us vast amounts of pain trying to hack around Internet Exploder to try and convince it to do things properly.

    But our efforts have backfired on us. By supporting buggy browsers, we’ve actually prolonged the life of the buggy browsers and the sites that came to rely on those buggy browsers.

    If we resolutely stop supporting browsers with bugs, across the board, guess what will happen… People will stop using buggy browsers because all the sites they visit will be “broken”.

    That in turn will make people with sites that break on standards-compliant browsers wake up and think “hey, I need to fix my site … now!”. It’s not going to take as long as you think for the world to adapt to a standards compliant nirvana.

    Do you think that a big online shop will find their pages breaking on all new browsers and say “no, this is not acceptable, I want the browsers to still work like they did when they were full of bugs” or do you think they will frantically get developers in to fix their broken site? Just a hunch, but I’m guessing the latter will happen if they want to sell stuff.

    So, let’s do away with this bonkers idea of “yet more IE-specific cruft” (and no, saying that you can put other UAs in the meta tag is not going to fool us) and the utterly absurd notion of keeping broken sites on life support for the rest of time.

    Let’s just make IE8 standards compliant, like all the other browsers, and lets have regular updates (at least twice a year) to fix known bugs.

    Think of how this would affect the web community. I’d write my site once and only have to worry about fixing bugs in my site, not the browser. If the browser used to view the site is broken, then the person using that broken browser will be seeing lots of “broken” sites. They’re going to realise it’s not the sites that are broken, but their browser. That’s going to be a rather good incentive to upgrade to a browser that isn’t broken.

    If all the browsers suddenly adhered to open standards (oh, they already do, with one notable exception), do you think anyone anywhere would actually start demanding their bug-dependant site be catered for, and if they did do you think anyone would even waste time listening to them? Do you think people would still visit broken bug-dependant websites or use broken web browsers any more?

    So, rather than creating yet another feedback cycle of massively time-wasting problems, create a feedback cycle of time-saving solutions – a scenario where everyone moves, with strong and growing incentive, to open standards compliance.

    What Micro$oft are doing with this meta tag switch is the complete opposite – they are trying really hard to make people move away from standards.

    Yet, at the same time, it also signals that even Micro$oft have realised that standards support is a “must have” requirement in their browser. Why prolong the pain? Let’s just get this over and done with. Move to standards compliance by default, now, without hesitation.

    As a web developer, I’m not prepared to keep wasting 60% of each major project on “making it work in IE” and I’m sure as hell not going to implement anything that prolongs the existence of broken sites and broken browsers.

    The entire web development community needs to come together and say “enough is enough, make IE standards compliant by default, even if it breaks some crappy sites which in turn will get fixed by their owners or be doomed to obscurity, or we’re no longer going to support IE, even if it has the market share”.

    In the coming weeks, the company I work for will be announcing new pricing. We will be developing standards compliant sites for reduced cost. We will be charging extra to then make those standards compliant sites work on IE. As more and more companies take this approach, large enterprises (which we term “IE bug nests”) will quickly see just how much more IE is costing them and how much they’ll save by using the free alternatives like FF or Opera.

    Micro$oft, please understand quite clearly: It is not you who are in charge of the web development community any more. We are in charge of you. You don’t get to tell us to implement what is obviously yet another IE hack, just so that you can prolong your monopoly. You will make your browser standards compliant by default, without cludges and hacks, if you want us to support your browser. While you’re at it, “End of Life” IE6 and everything before it, publicly stating that “Microsoft are joining the move to a standards-compliant Internet”. Thanks.

    Copy & paste the code below to embed this comment.
  5. I think it’s great. I can see problems with it, sure. But there will always be some bump in the road. The main reason why I think it is good is that you have options. You could specify a certain browser. Then when a new one comes out you can go back and test it. If it fails then you can either fix the code so that it will work on the new browser. Or just say the heck with it and keep it connected with a specific browser. Having an option doesn’t seem like a bad idea to me.

    Copy & paste the code below to embed this comment.
  6. To “quote Jeremy Keith”: :

    Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.


    Copy & paste the code below to embed this comment.
  7. Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.

    When put like that, it does sound like nonsense, but, in reality, isn’t what’s actually be said?:

    “If you’ve tested your site and everything displays as it should in IE8, then go ahead and render it in IE8, otherwise, lets just leave things as they are until you’re good and ready to test and ‘fix’ things. That way you don’t get an ear-bashing off your non-web-savvy boss and / or client”

    Copy & paste the code below to embed this comment.
  8. The general idea of a standard is that a specification provides a common interface description against which everyone may implement, without fear or favour. Yet this proposal special-cases a particular implementation. It differentiates between HTML for IE8 from HTML for other user agents. This is not a standard, at best it’s a fork.

    This approach is broken by design. It is likely to lead to a situation worse than traditional cross-browser compatibility problems because there’s absolutely no motivation for any vendor to follow (real) standards.

    Copy & paste the code below to embed this comment.
  9. I love Jeremy. You’ve got to love Jeremy. I disagree with his reasoning as to what the default version should be, though. I’ve posted my response to Jeremy here:

    Copy & paste the code below to embed this comment.
  10. Another Mozilla response: “Meta Madness”:

    Choice quote: “What happens when you use importNode across iframes that have different DOM versions?”

    Copy & paste the code below to embed this comment.
  11. Zeldman: “I love Jeremy. You’ve got to love Jeremy. …”

    Jeffrey, you should tone down the Old Patronising Uncle persona a little – it may not be suitable for a Hot Potato subject like this one.  Especially when you’re in the ‘wrong’ camp.

    Copy & paste the code below to embed this comment.
  12. While this evades DOCTYPE, it doesn’t address the more fundamental issue: separate rendering standards for different browsers (or worse yet — individual versions of those browsers) are not standards at all. A standard should change the way things are, not the other way around.

    That said, achieving compatibility with older browsers is a tough job, and sometimes you have to get dirty to clean things up. That’s why I hope to see this used judiciously, for the benefit of nonstandard browsers only. I think back with fondness to the days when the first line of my HTML document read, very simply:


    That’s what I call a standard.

    Copy & paste the code below to embed this comment.
  13. I’ve been thinking about this for hours now. I’ve tried and tried and tried to understand the reasoning behind this. With learned colleagues like Zeldman, Meyer and Koch supporting this feature, I simply must look at it with an open mind. But at the end of the day, my opinion hasn’t changed from earlier today. These things give me great concern:

    • Browser footprint – supporting an increasing number of legacy renderings will bloat the software. How can this work on mobile devices where disk space is so limited?
    • Browser footprint2 – and what of the CPU resources?
    • Tabs and frames – what happens when many tabs are open with different rendering systems being used in each? And what happens with Objects, IFRAMEs and other frameset arrangements that may mix the different rendering systems?
    • Security – since the system will be forced to run older, and less secure rendering systems, will this create massive security holes? Will hackers be able to use older exploits, hiding their work in nests of different rendering systems?
    • Future standards – what incentive will developers have to adhere to modern standards, other than more proprietary features from Microsoft? Lazy developers can remain in the past.
    • W3C – what has the World Wide Web Consortium to say about all this? Is the consortium happy that Microsoft want to fix their mess with another new, non-standard feature to go along with “conditional comments”?
    • DOM – is this going to make an awful mess? Nested/embedded rendering systems will be able mess with each other’s DOMs – including any layout-related DOMmery.

    No. I think this is a disaster. I’m actually sad about it. Is this how Americans felt after JFK was killed?

    Copy & paste the code below to embed this comment.
  14. Snore.

    I thought you guys were standards advocates, not Microsoft shrills. Every other browser is able to render pages according to the spec, or close enough. IE requires a special tag to do so. You guys congratulate them. Hah, what a sell out.

    IE is introducing a third option to quirksmode with this change. More options, more problems. The only people that benefit here are the MS shareholders.

    We may as well call IE8 -> IE6.2, because essentially, that’s what we have: one more browser that can’t support a known standard.

    I’ve got a better option, I’ll just ignore everything MS releases, design for standards, and tell users to download a real browser.


    Copy & paste the code below to embed this comment.
  15. I think it’s a great idea. I’m going to quote someone else to reiterate why:

    “If you’ve tested your site and everything displays as it should in IE8, then go ahead and render it in IE8, otherwise, lets just leave things as they are until you’re good and ready to test and ‘fix’ things. That way you don’t get an ear-bashing off your non-web-savvy boss and / or client”

    The only downside is that it provides less “oh my god” motivation for a business to update their pages to the latest browser version.

    But I definitely think it’s better than the 2 approaches we’re stuck with now:
    1. Have existing pages that no one is maintaining break when a new browser version comes out.
    2. In the name of backwards compatibility, refuse to change anything in the browser because it would break existing pages.

    Bob hires me to create a small static site to promote his business. I do it, and move on to another gig. It only makes sense that when a new browser comes out that his page still work since he hasn’t changed it.

    I’m excited by the idea that newer versions of the browser will be able to fix bugs without worrying about backwards compatibility.

    Copy & paste the code below to embed this comment.
  16. I can’t believe that anyone would conceivably allow a platform specific enhancement to be added to a standard because an old version of software wasn’t patched.

    Point 1
    Microsoft should have done things right the first time and implemented the standard as it was written.  Without trying to second guess the development community.

    However, this isn’t the first time MS has done something like this.  The last time they did something that IMHO was this brain-dead, they violated a licensing agreement between them and Sun.  The result of that situation, regardless of the MS FUD is now known as C#.

    Before that, it was the successive changes between RDO, DAO, and ADO for developers.  Then COM and DCOM and ASP.

    Microsoft is forever trying to force changes to standards or rewriting standards to suit themselves, then forcing them onto the rest of the world and until their back is to the wall, they will continue to do this.  Someone needs to stand up and say “NO!”

    Point 2
    As for the need to support UA changes from browser version to browser version, someone indicated that if the UA from IE-8 to IE-9 doesn’t change, there’s no new UA to support.

    While this is correct, that doesn’t preclude a developer from putting:

    <meta http-equiv=“X-UA-Compatible” c />

    into their code and effectively breaking it without meaning to.

    There is absolutely no reason for doing something this bass-ackwards to make up for one product that was orphaned and then brought back to life.

    Heck, if Microsoft is explicitly not going to support older formats of Office documents (of which there are far more than the number of web pages in existence), then why bother changing a standard to support older formats of “Bad/Non-Standard MS HTML Coding Practices”

    Copy & paste the code below to embed this comment.
  17. P.S. I don’t think the naysayers have thought through the positive aspects of this, either. Right now my work forces me to use IE6 because “that’s what our web pages are written for”. I don’t like their decision, but they pay the bills, so that’s what I do.

    But imagine that I could upgrade to IE7 and all the IE6 pages would still work right. I could upgrade my browser today! Pretty soon, everyone would have upgraded their browsers (rather than using the crappy old version “for compatibility reasons”). Within a year of a new browser coming out, 90% of IE users would be using IE7. Now I could tell management “90% of our users are using IE7 – let’s drop support for IE6 and only write new pages for IE7”.

    That would be fantastic.

    Copy & paste the code below to embed this comment.
  18. The entire web development community needs to come together and say “enough is enough, make IE standards compliant by default, even if it breaks some crappy sites which in turn will get fixed by their owners or be doomed to obscurity, or we’re no longer going to support IE, even if it has the market share”?.[End Quote]

    Precisely. Enough is enough. This Meta idea is completely back to front.

    Microsoft need to admit the mess they’ve made, take the bull by the horns, use their considerable advertising power to tell people IE8 will be fully standards compliant. Inform them they have six months to either make the site compliant or add a Meta tag to say that it isn’t.

    Old sites should be adding the Meta, not new compliant sites. If we don’t draw the line now then this will just go on and on with Microsoft making excuse after excuse.

    Copy & paste the code below to embed this comment.
  19. “Microsoft should have done things right the first time and implemented the standard as it was written. Without trying to second guess the development community.”

    A number of people have written this, but an emotional issue overlying a logical one. Initial implementations of standards can be flawed, and sometimes a new standard unintentionally breaks the old one.

    For example – why is it that Firefox2 didn’t “just implement Acid2 in the first place”?

    Copy & paste the code below to embed this comment.
  20. A lot of people have been taking your view, however, I would ask that you consider an alternate which should still give the same results you seek:

    Why don’t they make IE8 be standards-compliant by default (it’s not caused problems with all the other browsers has it?) and have a meta (hack!) tag that says “run as IE7” for bug-dependant sites?

    A great number of sites that work on IE7 will already work on IE8. Some might need subtle CSS changes (ie. wholesale removal of hacks) and the really bad offenders can beg for IE7 with the hack tag.

    This would:

    • reduce the number of sites that need the hack tag, as I dare say the vast majority will just continue to work
    • clearly flag bug-dependant websites for all browsers, allowing all browsers to be standards-compliant by default
    • let the site owner know that they are falling behind the rest of the world, but give them plenty of time to address that issue

    I think free software would appear very quickly to add the “beg for IE7 hack” to all HTML files in a folder structure and any form of CMS can very quickly be tweaked to add it in as well.

    There are a finite number of existing web pages on the internet. There are an infinite number of future web pages that will appear for the rest of time. Why is the hack tag being imposed on the latter when it would only be needed on a fraction of the former?

    Copy & paste the code below to embed this comment.
  21. The standards should be leading. That’s the whole idea of standards.

    Microsoft is changing slowly, but they seem to be stuck in their way of thinking.

    Years ago I read a statement from Microsoft about one of their technologies (ADO or so): they guaranteed that the way the standard was implemented was considered the right way. At the time I was already baffled. Even though I should know Microsoft by now, they keep surprising me with tricks like these.

    The real solution is that:

    1. Microsoft stays closely to the standards, takes more care to avoid bugs and fixes them quickly, in this way really promoting writing to the standards;
    2. Microsoft gives a reasonable amount of time (months) to developers to make sure their sites work with the upcoming new version of IE. Just remain in beta/release candidate stage for a while.

    I know my comment is not adding that much, but the main goal here is to clearly show that most web developers think this proposal should be binned.

    Copy & paste the code below to embed this comment.
  22. Call me crazy, but this idea seems absolutely insane. Those who have developed their websites to the standards should not be punished by made to feel like second-class citizens on IE—it does not foster a greater push for standardization, but rather poses an incentive to rely on IE’s broken rendering.

    Personally, it would make much more sense to allow a meta tag that opted out of using proper standards—if you have an old website that you know works in IE 6 or whatever, and you’re too lazy to update it to the standards, why not put a meta tag that in effect says “use the IE 6 rendering engine on this page?”

    In this way, you don’t trivialize the importance of standardization, yet still preserve backwards compatibility for the lazier among us. Just a thought.

    Copy & paste the code below to embed this comment.
  23. I can understand Microsoft’s commitment to support legacy content that was built by Microsoft products for Microsoft browsers and the industry that was created around it.  Sooner or later, they will have to abandon it.  If in the interim, standards compliant content has to opt-in for standards support in IE8, so what.  This carries a caveat—It must provide that the burden of opt-in is eventually placed upon legacy content to opt-in for a quirks mode support with an eventual abandonment of all opt-in options.

    The question in my mind is whether or not Microsoft has the intent and desire for planned abandonment of the “cannot break the Web” strategy.  If Microsoft can earnestly announce such a medium to long term strategy, much of this blog chatter would diminish.

    Copy & paste the code below to embed this comment.
  24. Because MS screwed up the DocType, now we all have to pay.

    Copy & paste the code below to embed this comment.
  25. Instead of targetting certified user agent versions — of which noone can test all, esp. after some generations — via an opt-in+out switch, the selection, if deemed necessary at all, should be based on release dates, not bound to a browser maker.

    If browser A fetches a document with stylesheets and scripts, maybe images too, that are all older than one day, i.e. probably not generated on the (cached) fly, A can render them with the engine A.x that was current at the date of the oldest or newest (depends on philosophy) resource. One could then add opt-in or opt-out switches (again, philosophy) based on that, e.g. “X-Rendering-Certified: 2008-01-23”? (probably rather with the awful, US-biased HTTP date format, or keywords “˜weekly’, “˜never’). This way the author is responsible for checking all rendering engines (he wants to / must support) at the given date, but does not need to list them explicitly. He can give a date in the past of course, if he hasn’t updated his code to work with more recent browser versions. It’s also more of a meta data than a command approach.

    Copy & paste the code below to embed this comment.
  26. Why is it that, despite everything we know about the mutability of the web, people still want to make a site and expect it to last and be relevant for years to come?

    I don’t see many companies making print ads, or book covers, and then letting them sit and reprinting every so often – that stuff gets redesigned, or refitted to a new generation with new needs.

    Standards are wonderful, because they assure that we’re going to have things rendered (hopefully) mostly the same way for the current generation of what we’re using (let’s say XHTML and CSS2).

    When a new XHTML or CSS comes along, we go through and we should be going through and changing what no longer works as well, or converting to new ways of doing things that simplify the old site.

    Not only all that, but that’s kinda how designers and developers will have job security, as well.

    Just $.02 from a young, angsty designer/developer.

    Copy & paste the code below to embed this comment.
  27. the article had gone something like: “Ok, MS messed it up big time by not implementing web standards correctly since the beginning and now they’re afraid to make things worse for people who don’t know enough about standards if all of a sudden IE 8 implements them the way they should be.”

    “So they got together with a bunch of us to try to come up with a solution but the best thing we could come up with was a hack. We would have liked more, but there were also MS corporate interests to consider and we thought that some concession would be better than nothing.”

    But just trying to pass this as “the best solution” wakes up the cynic in all of us.

    Copy & paste the code below to embed this comment.
  28. Perhaps I’m being naive here, but it seems to me a better solution would be to come up with a way for a document to declare to the UA what “features” it is planning to use, rather than saying what “version of behaviour” it wants the browser to emulate. In my mind, I’m picturing something like:

    <meta http-equiv=“X-UA-Features” c />

    Maybe I’m over-engineering, but it seems like this would be smarter than pinning to a UA version.

    Copy & paste the code below to embed this comment.
  29. I’ve been programming for 20 years, and the first “user interface” (layout-based) applications I wrote was “BBS-doors” for MAXsBBS on the Amiga platform.

    If we use this same scenario, and date it back then, that would mean that if I today wrote “MAXsBBS=door” in this stupid tag my browser, which in reality means ALL browsers, would have a rendering engine (ANSI/VT102 if I remember correctly) for my document. Since we (=the programmers) want and expect this so called “backward compability” to exist. Surely, we do not. We’ve already abandoned the MAXsBBS doors 15 years ago, and are now moving on to other (and better) layout engines.

    Why not use this on executable-files aswell? Then we don’t need Java or the other look-alikes “Write-Once-Run-Nowere” frameworks, we just add “X-EXE-FORMAT: C64” to our executable file and fire it up in Windows Vista, and Mac OS X..

    Aw, come on.

    This is just SO NOT HAPPENING, please!

    Copy & paste the code below to embed this comment.
  30. allowing developers to “opt in”? to proper standards support.

    Think of email.  Think of spam.  “Opt in”?  Sorry, “opt out”.  Ok!

    As for the rest of the argument.  It’s not hard to say “my gut tells me it’s wrong and I trust my gut”, but I’m also in the position of saying that I honestly don’t have any better solutions to offer.

    Copy & paste the code below to embed this comment.
  31. “Why don’t they make IE8 be standards-compliant by default (it’s not caused problems with all the other browsers has it?) and have a meta (hack!) tag that says “run as IE7” for bug-dependant sites?”

    Well, which page do you think is vastly more likely to get a header tag added to it. The old page that isn’t being actively maintained by anyone that thinks that all browsers are IE6? Or the newly developed page where the developer wants to be able to code to the standards?

    Old stuff should keep working. It would be backwards to require a change to the old stuff to keep it working so you don’t have to add a change to the new stuff. And highly impractical.

    Copy & paste the code below to embed this comment.
  32. “I don’t see many companies making print ads, or book covers, and then letting them sit and reprinting every so often — that stuff gets redesigned, or refitted to a new generation with new needs.”

    I don’t see many companies selling books that suddenly stop being readable because you moved to a new house or are reading them outside. Do you? Wouldn’t that be painful?

    Copy & paste the code below to embed this comment.
  33. “guaranteeing a site we build today will look as good and work as well in five years as it does today.”

    If that’s your main concern, you should make books, not websites.

    I seriously can’t believe I’m on ALA, it really feels like the IE blog around here… even the angry comments from practically everyone… I’m trying to stay polite and calm here but then I read things like: “any two contemporary browsers may offer completely different renderings of the same CSS” and I have to wonder what the hell you’re talking about… And why is this published on ALA?! Is this a bad dream I’m having?

    In that sentence, you simultaneously negate Web Standards completely and too conveniently use the word “may” to turn a big fat lie into an innocent hypotheses. Every single ALA reader knows that “any two contemporary browsers” pretty much “offer” the exact same rendering of valid CSSEXCEPT IE. We don’t need proprietary version targeting, we simply need a Standards Compliant version of IE8. Period.

    And about your own example with the Word 1.0 doc not opening in recent versions of MS Office (hey look! Microsoft again! Let me guess… text file open just fine I bet…), then it’s a perfect example of why this “solution” makes no sense. MS Office has evolved, and it had to let go of some of the compatibility with older file formats in order to evolve. Are you saying OS X 10.5 should support OS 9 programs? Photoshop CS3 should open Photoshop 1.0 files perfectly?

    Sorry, but before you try to provide a solution, you should have a basic understanding of the problem. I wish there was a nicer way to tell you this but you clearly have no idea of what you’re talking about, and so do all the people that helped in the process if any…

    This is unbelievable… I still can’t believe I’m reading this on ALA.

    Copy & paste the code below to embed this comment.
  34. So, I’ve been thinking about this solution, and it seems like maybe it could work. I’m a pragmatist, so if the solution solves the problem then I am alright with it. We’ll work on bonus points for elegance later.

    First, in regard to the issue of increasing browser code bloat, which was my initially negative reaction, I have a solution.

    Instead of shipping several rendering engines with each browser, it seems logical to me that vendors could just come up with some rule sets (possibly even written in CSS…) which are applied to documents which use an older engine. For example… my document specifies that it works with IE7, but IE8 is what’s hot right now. Instead of including the IE7 rendering code in IE8, the IE team would just include some rules that use the IE8 renderer to create the look of the IE7 renderer. We do this all the time for Microsoft’s stuff already, we’re just hacking in the opposite direction. Let’s make them implement the hacks now instead of us.

    Second, let’s stop complaining about the meta-tag fix. It’s not that bad. The use of the meta-tag is no worse, in my opinion, than microformats, which use existing HTML to make sub-standards that have nothing to do with semantics, rather than creating original XML formats and utilizing the power that we will one day have with XHTML. We’re already breaking our own rules, at least this one has practical benefit.

    Copy & paste the code below to embed this comment.
  35. My take on this suggestion:

    Copy & paste the code below to embed this comment.
  36. >For example, it is possible to set a baseline lock on a whole site using the header method and then override that header on individual pages, as needed, using the meta element.

    But http headers take precedence over corresponding <meta> elements, right? Or maybe this particular header would be an exception…

    (Btw, the official abbreviation of Firefox is “Fx”, not “FF”.)

    Copy & paste the code below to embed this comment.
  37. Aside from all the stuff about how impossible this is to support over the long term, doesn’t it also give Microsoft (or whoever else) the perfect excuse to break standards compliance in the future wherever they see fit? 

    e.g. some new feature is added only to IE9, if all pages that use it are tagged with the IE9 UA, then it could in some ways be claimed they’re following the required standard.

    Surely the best solution is just to stick with the standards that already exist.  If some internal corporate web site really needs IE 6 compatibility, then it’s up to Microsoft to make some IE 6 compatible browser available to them somehow.  It’s their mess – no other browser has this problem…


    Copy & paste the code below to embed this comment.
  38. This is wrong, wrong, wrong.
    Imagine what will happen once we move to new versions of the browsers in question. Will Firefox 4 have to keep the buggy Firefox 3 behavior locked away within some obscure rendering mode just to satisfy sites that say they work best with Firefox 3?
    IE already has two distinctly different rendering backends, now with IE8 adding a third. There will have to be interaction between the modes even (think iframes, DOM manipulation etc.)
    This makes our job as web designers even worse because now we can’t even rely on standards compatibility within our sites but we also need to update all the sites to tell the latest and greatest browsers that, yes, we indeed to want them to render the site as they originally should do.

    All this is a big mess and getting out of it isn’t easy at all but adding another tag to work around another different browser implementation… you really call that an improvement?

    Copy & paste the code below to embed this comment.
  39. Maybe some IT departments would appreciate this. Financial institutions often require the use of specific browsers set with strict security. Employees cannot upgrade their browsers. Newer browsers may plug security holes, yet they’re stuck with the older version that work with older systems. Maybe this method would allow the use of newer browsers with backwards-compatible rendering methods and heightened security. IT may be able to relax, knowing security improvements are in place without the loss of front-end compatibility.

    Copy & paste the code below to embed this comment.
  40. “often require the use of specific browsers set with strict security”

    which is usually a non-issue, and mostly related to the ignorance of developers who believe that only IE can do 128 bit encryption and the like, or who use that as an excuse for their completely arcane coding.

    Copy & paste the code below to embed this comment.
  41. Can anyone tell me exactly what HTML/CSS is likely to render fine in IE7 yet break in a standards-mode-by-default IE8?  Seriously, I ask someone to name me just one thing. Because sure, IE8 may have support for generated content, columns, etc etc – but this won’t break anything that worked (degradedly) before. What will break? Because if no-one can name anything, then what’s the point of even suggesting this?

    If we’re just talking the odd gap in layout – well, I get emails from MSN to my Hotmail account that break in the Windows Live Mail interface. How can Microsoft guarantee support for their customers if they don’t even support their own interfaces?

    Copy & paste the code below to embed this comment.
  42. MS reinvents the “Best viewed in…” practise, using a meta tag this time.

    Any other software vendor must deal with the crap they’ve delivered in the past. It’s time MS deals with theirs (as do ‘IE-only’ developers).

    The default render mode in IE8 should be the one that is most standards compliant. The targeting fix should only be needed for IE-only websites. Or the option to switch between current and previous engines should be given to the users in case a page doesn’t render properly. That way bad practices from the past will only show off on MS and IE-only sites.
    I know it’s naive to think that MS would implement such a solution, making them look bad. But it doesn’t seem just to bother developers, who follow the standards, and web development in general (slowing it down) with a ‘solution’ for problems generated by MS and IE-only developers (who did not bother to do any extra work in order to make their website work cross browser).

    MS, deal with your own mistakes and do it quick. Otherwise this fix will probably need a fix of its own in IE 9 or 10.

    Copy & paste the code below to embed this comment.
  43. @Nicholas Sloan:
    Your suggestion for emulation of older engines can not be guaranteed to work as the rendering differences are in many cases the results of bugs and quirks. To make this all behave in the same manner probably just needs the same buggy engine.

    Copy & paste the code below to embed this comment.
  44. The fact is that websites are subject to dynamic changes over time. This fix assumes they are coded once then set in stone, requiring a meta tag to indicate the browser rendering that matches when the site was finished. But the web ain’t like that. Sites evolve over time, get completely remade, and so on. So all the browser has to do is render them according to standards.

    Sadly now we have a situation unthinkable before where Microsoft has alienated many leading web standards stars like Zeldman and Meyer and the developers who have followed them for many years. Nice one Bill.

    Copy & paste the code below to embed this comment.
  45. This proposition is so disconnected from reality I have difficulties to believe it is featured on ALA.

    so now the “website designed for …” or “this page optimized for …” is proposed to become a meta tag backed up by standards ?
    Wasn’t that one of the worst era of the web, when the 2 biggest market share browsers were trying to take control of the web ?

    this proposition will hinder any browser that has a low market share today to be taken into account. If this were implemented since the beginning of web, how would it help to have a page designed for mosaic or netscape ?
    If you kept your archives on obsolete magnetic tapes and forgot to transfer them to a medium nowadays computer can read, it’s your problem and shouldn’t affect those who are doing it right.

    Having trouble to render old pages in a given brower, isn’t that why web standards exist in the first place? you know as to not be locked-in to a specific browser.

    I’d rather have developpers working on improving browsers instead of keeping their codebase (bugs included) to be able to render an old web page.

    Seems the problem is shown from the wrong viewpoint.
    webpage rendering breaking when switching from IE6 to IE7 is a browser problem. if IE6 were standard compliant, this would have not happened in the first place.
    What matters in a webpage, for the sake of archiving, is content not style, isn’t that why guidelines advocates separating content from style ?
    To me, the solution is obvious: forward compatibility, graceful degradation and progressive enhancement.

    Copy & paste the code below to embed this comment.
  46. No other browser seems to be suffering from the sorts of problems IE is suffering from. So why should all browsers have to suffer the pain of solving a Microsoft-only problem? It doesn’t make any sense.

    Still, Microsoft have to do something to allow legacy sites to work as-is, while also being able to move forward with web standards. The obvious answer to me is a fork. Microsoft need to be able to split their browser development into two, one old and unchanging browser for legacy sites, and a new browser to go forward.

    IMO, the best solution would be for Microsoft to freeze a standalone version of IE6 for legacy use, forget IE7, and treat IE8 as the first step to a more unified web.

    Copy & paste the code below to embed this comment.
  47. All you have to do is insert a META tag like the following:

    <meta http-equiv=“X-UA-Compatible” c />

    ..and IE knows it has to switch to the FireFox 3 rendering engine!

    Genius idea from Microsoft.

    Copy & paste the code below to embed this comment.
  48. The idea is good. The default is bad.

    IE8 should default to rendering in it’s best mode. If I have a site that breaks in it, then there are two options:

    1. The site’s owner adds the meta tag to set it to IE6 mode.
    2. I have a compatibilty dialog in IE8 that works like the one in Explorer’s File->Properties where I can override IE8 and tell it to use IE6 for this site. (i.e. same solution as trying to run Win98 stuff in WinXP)



    Copy & paste the code below to embed this comment.
  49. Very interesting article about this subject: “End of line Internet Explorer”: by Mike Davies.

    He compares the current position of IE with that of Netscape 5 and suggests that MS should start all over (in the Netscape case this resultet of course in the development of Firefox).

    Instead of putting the name IE with the garbage. It might enough to have the User Agent verification string completely altered to such extend that current browser sniffers wont identify it as IE (did I read that here or somewhere else?).
    This would leave 2 variations of IE:

    • IE Classic
      versions up to IE7, maintained for a number of years for backward compatibility
    • IE Superdooper New and Improved – significantly better
      IE8 and onwards, with similar level of web standards support as Fx, Sf and Op

    This would mean:

    • no pollution of web development and code with yet another ‘fix’
    • MS would finally prove that they really want to support web standards
    • IE-only developers will know for sure that have to update their skills
    • Organisations using applications that rely on proprietary features in the current IE versions will have enough time to update these to ones that rely on open standards
    • IE will not become bloatware because of all the old engines they will have to keep supporting
    • ‘progressive enhancement’ will not become an endangered species
    • MS will not be painfully remembered till the end of time of their past mistakes in browser development and front-end developers might even start to like MS and even IE again

    pease brothers and sisters ;-)

    Copy & paste the code below to embed this comment.
  50. —sorry for the bad writing—

    Copy & paste the code below to embed this comment.
  51. I understand the need for a rendering switch for IE. I prefer that the switch be a cultural version instead of a product version.

    I wrote up an alternative switch, X-Web-Epoch, here:

    Copy & paste the code below to embed this comment.
  52. The people who needs a switch are the ones targetting a given version of Trident, not everyone else. Make the switch inverse of how it is proposed, and everything should be fine.

    Copy & paste the code below to embed this comment.
  53. It’s truly amazing that the inner circle of Alistapart actually supports this scheme which is as unfriendly to standards as it gets. Alistapart has always championed the eternal, the beautiful in HTML documents. And now you want us to contaminate our documents with vendor-specific version numbers from Microsoft? The leaders of WaSP had to backpedal to distance themselves from the mess yesterday. I hope Alistapart will do the same when they get out of the dizziness the NDA must have caused.

    Copy & paste the code below to embed this comment.
  54. The fuss seems like a huge storm and people should me think it over for some time. Wait until after the weekend.

    I have summed it up in short on “my blog”:
    and at this moment I think that there will be very limited occasions where I would want to use the X-UA-Compatible meta tag. It also feels a bit too non-standard, too alien. In some very special situations one would want to use, but these will be extremely rare. As far as I can see now.

    Let’s get back to the work that’s in my to do list.

    Copy & paste the code below to embed this comment.
  55. Specifying a browser has no advantage at all except Microsoft’s domination agenda.  Developers should detect available technologies.  IE 8 ought to render well in all modes not just in special modes. The doctype system is fine.  That way if a browser has a mode that supports the doctype better then it can be in that mode or can render as well as it can otherwise. Stamping a freshness date on a site is a horrible idea. Detecting for technology means all browsers that support that technology (in one way or another) will work with a site.  More openness is better for users, more exclusivity is better for companies like Microsoft. If only their agenda were to make the best tools and earn our love and respect, It is not…It is to leverage a position of dominance and control over the market by promoting dubious weapons and calling them “innovation”. Watch out!

    Copy & paste the code below to embed this comment.
  56. I do agree mostly with Joey Smith as in Post 108. Targeting a specific client version is a bad idea. Targeting “features” is better. Still bettre would be targeting some standard instead. Just add a version info to the content style type and content type and create special versions of that for IE. That would eliminate the need of endless feature lists and just name them all in one single version statement.

    And, of course, the standards compliant mode should be the default.

    Copy & paste the code below to embed this comment.
  57. This is going to make future browser development horribly difficult and further segment the market.  It’ll convince more lazy designers that they are justified in developing their site to work on only one browser.  There are very few cases when that makes sense and that’s usually when they have complete control over the browsers they use on-site.  Screwing up the rest of the web for people have have control over their environment seems shortsighted.

    Now sure, you could just shrug it off and say that since IE6’s inaccuracies were well-documented, these developers should have known better, but you would be ignoring the fact that many developers never explicitly opted into “standards mode,”? or even knew that such a mode existed.

    Oh boo hoo!  The designers got what they deserve.  If it broke in IE7 and they were unaware of the fundamentals of the very medium in which they work, then I have no sympathy.

    This feels like a sell-out by ALA.

    Copy & paste the code below to embed this comment.
  58. Sorry but this seems utterly ridiculous…

    Hopefully something will change before all this materialises

    Copy & paste the code below to embed this comment.
  59. I think it’s clear that as far as standards based web dev is concerned then this move by MS is just ridiculous and only serves to save themselves… To see the support from ALA is the worst bit though…

    Copy & paste the code below to embed this comment.
  60. I’m not real sure about this quite yet. What’s going to happen to the old sites we have? Will it default to “edge”? That could be pretty bad.

    I’m unclear on why Microsoft feels like they need to re-invent to wheel when they release a browser (using Trident and now a new rendering engine). Why don’t they just use Gecko or Webkit to really create some consistency across browsers. Maybe they have a financial obligation to fight open source with every fiber of their being… I don’t know. Seems a bit ridiculous to me – but the almighty dollar tends to rule.

    Copy & paste the code below to embed this comment.
  61. “IE6’s rendering behavior was not updated for five years, leading many developers to assume its rendering was both accurate and unlikely to change”

    What? I couldn’t disagree more… do you have stats to back this up. My experience is very different – everyone knew there were issues and that any hacks implemented would not work indefinitely.

    Copy & paste the code below to embed this comment.
  62. Still disappointed that only a few people have recognized the possible security issues this multiple browser version idea will cause.  I can guarantee this will open up a whole new world of exploits for IE . 

    Banner Ad companies and Hackers will use this to their benefit. This will cause more problems then it will fix.

    Copy & paste the code below to embed this comment.
  63. What’s wrong with conditional comments to keep the old code at bay?

    How about this as a way forward…

    Any document that doesn’t have a well-formed DOCTYPE is rendered in quirks mode. This will account for most of the FrontPage generated pages and other rubbish – so these pages will carry on working as they always have. No problem.

    Any document that does have a well-formed DOCTYPE is rendered in standards mode by default. Mostly these pages will have been written by someone at least semi-competent. Mostly, these will work in IE8, but if they don’t, they’ve probably got someone at the helm who can fix them, as below.

    If a page breaks in IE8, when it is launched, it’s very likely that it already breaks in Opera and Firefox, unless it is using IE-specific hacks.
    If it does already break in Opera and Firefox, it can get knotted – we shouldn’t be going out of our way to dig other people out of a hole if they won’t even provide the shovel.
    If it uses IE-specific hacks to make it IE6/7 compatible, as long as they’re in conditional comments that target IE lt 7 or whatever the code is, no problem.

    If IE8 offers a “view basic page” option, this is all completely irrelevant. When users get to a page that’s in a mess, just turn off CSS and bingo, you’ve got a page that you can read. Problem solved, no need for developers to get in a tizzy about it. Another one of those problems that isn’t for us to solve.

    Copy & paste the code below to embed this comment.
  64. Having built my first site 12 years ago and following Web Standards now, I make a living dev websites.
    My favorite byline on pages is:
    Best viewed in anything you want.

    As it should be.

    But for Microsoft to have the audacity to come out with a lame bowser and tell everyone that they have to add a s
    poecial meta tag to every webpage on planet earth, is the ultimate in not only audacity, but foolishness.

    If Microsoft is incapable of keeping up with Opera, Safari,  and firefox then it well deserves to go the way of the dinosaurs.

    This web development firm will never under any circumstances add this tag to clients sites, and will explain why not publically, and, unfortunately, add a special tag for ie8 users to upgrade to a real browser for the first time.

    I am amazed that this article seems to think it’s just fine and dandy. It is not.

    Copy & paste the code below to embed this comment.
  65. I think it makes sense for IE to do this just this one time. If they can keep their standards support on part with the other browsers going forward then they shouldn’t have to do something like this again for another 7 years.

    There really isn’t any reason to force the other browsers to support it…. as long as they all keep up with each other.

    And for those of you who didn’t know, (almost) near-future css and html specs will be standardising the rendering behaviour of “Quirks Mode” so new browsers companies won’t have to emulate a half dozen other rendering engines, just Standards Mode and the new standardised “Quirks Mode”.

    Copy & paste the code below to embed this comment.
  66. The reasoning behind browser versioning and/or its advocates:

    1. “Standards are buggy in themselves”.
    Maybe Microsoft-backed standards, but not real ones. W3C standards, for example, go a tortuous way to recommendation in order to avoid recommending buggy standards. And, as fas a I know, browser vendors play a significant role in this process. Go figure.

    2.“You are part of an endangered species of people who know what a doctype is”.
    OK, this “non-savvy” as an euphemism for “incompetent” really puzzles/upsets me. For that matter, let’s relax credit requirements so that people who don’t qualify for a loan can get one. It’s not like we’re going to have any problems with irrecoverable loans or some sort of crisis, are we? Lowering standards leads to disaster. Period.

    3. “Too many Web apps have been made for IE6 and it would be too expensive to migrate them to accommodate IE7+”.
    So much for software life cycle, let alone Web standards. If I hired a Web design studio/programmer/high school script kiddie to make a Web site a couple of years ago, it’s only natural that the site has to change because my company could offer new products/services, change its corporate image and/or name, have new business processes, etc. The least of my concerns would be whether my old site looks “uncool” in standards mode. The same goes for Web applications, which need to deliver new services at least once in a while to stay competitive. Web applications that did not upgrade their code to the latest standards mostly died with the first dot-com bubble. Even sites like Yahoo!, invalid code, DTD-less and everything, have a fairly consistent look among browsers.

    4. “A bug in a new version of the rendering engine could break a previously working Web app”.
    What is this, PowerPoint? Development teams are specifically trained to avoid that at all costs. Even if that’s the case, that’s exactly why you don’t upgrade blindly, no matter what Windows Update says.
    Besides, this is one case where browser versioning proves itself useless. Imagine that my AJAX-based site works flawlessly in Explorer 7. If Explorer 8’s engine contains one of this absurd bug scenarios, then versioning protects my users. But what if more probably, the bug comes with Explorer 7 SP1? Or, just for kicks, patch # KBB00BF4C3? Then <meta http-equiv=“X-UA-Compatible” c /> will mean absolutely dick, because I would have to specify subversions. Should we write <meta http-equiv=“X-UA-Compatible” c /> or cut the crap already? Oh yeah, and let’s not forget IE5Mac and platform-dependent bugs.

    5. “Bloating browsers with several engines won’t be an issue because some of them could be deprecated”. No. Browser versioning’s goal is precisely to avoid that. Besides, The deprecation of IE6 would mean a more expensive pandemonium than it is right now.

    If anything, this could be used alongside conditional comments, such as <!—[if IE] <meta http-equiv=“X-UA-Compatible” c />—>, but it would be redundant. Or even leave <meta http-equiv=“X-UA-Compatible” c /> and let real browsers ignore the tag safely, standards-compliant-ly. But urging or even hoping “other browser vendors join Microsoft in implementing this functionality” is downright irresponsible.

    Copy & paste the code below to embed this comment.
  67. Standards aren’t.  That’s what this ‘so-called’ fix from Micro$oft says to me.

    Why bother coding to ‘Standards’ when the UA with the most desktop ownership flies in the face of the rules?

    Surely, the W3C will balk, no?  Can it be that we’re truly living in a Micro$oft-centric cyberspace now? 

    I recognize that coding to W3C standards is what I should be doing.  They (W3C) are the standards bearer for things (X)HTML.  The problem with the standards bearer is that there are no ‘teeth’ to speak of.  W3C says: this is how it is done, so that all may enjoy a similar experience.  When it’s not done like that, what happens?  Designers and users suffer while the M$ folk go happily upon their way, making frequent stops at the banking institution of their choice.

    This is pure absurdity.  Like all things Micro$oft, they win because they have more assets and time to waste making sure that we play ball by their rules because, after all, it’s their ball.

    Perhaps it is finally time for W3C endorsements of UAs.  Of course, that’d be lovely if people would actually recognize that the W3C are the authority.  Problem is, the authority is nothing more than a figurehead.

    My .02, which is clearly what this rant is worth.

    I await Godot…and M$‘s realization that this is pure insanity and a blow to forward thinking re: the web.


    Copy & paste the code below to embed this comment.
  68. I don’t see why most previous comments are calling this browser sniffing.  I’ve done it, browser sniffing is when you perform javascript tests against the browser to determine it’s capabilities.

    This is the reverse, this is really document sniffing and it’ll be performed by the browser which means you as the developer aren’t writing any code.  The browser sniffs the document, ascertains its capabilities and renders accordingly.

    In theory this sounds quite nice (really depends on how well the browser vendors implement this proposed solution if at all), I’d love not to have to apply patches to my html/css/or javascript everytime a new browser version comes out but when the time/budget permits. 

    I hated it when ie and netscape were battling and breaking the web with each new release, at least this way the only casualties with this fix and the new wave of browser wars will be the vendors and not your web applications.

    Copy & paste the code below to embed this comment.
  69. By the time you get to read my message here after wading through 15 pages of comments, you will have already sensed how the community at large feels about this idea, and despite that, I am still compelled to add my opinion as more fuel the fire: it’s simply crap.

    We have STANDARDS so that browsers can be made to render predictably. That’s the solution to the problem, it’s here today and it has been embraced by the development community already. It makes the most sense for the USERS and puts the onus on the developers to hone their craft and know what they’re doing.

    Copy & paste the code below to embed this comment.
  70. “Let’s say that a new browser version launches 3 months after the application is brought online and the team has coded to web standards, has used unobtrusive JavaScript, and everything else that is considered a best practice right now. If that browser has a single bug that affects a critical part of the application, the team has to scramble to fix the break as soon as they hear about it from a user (or several hundred).”

    I know I’m late to the game, but this is about the most ludicrous thing I’ve ever heard.  This is a problem with all software, not just browsers.  Who’s to guarantee that when IE9 comes out that the IE8 or IE6 rendering engine won’t have some critical bug that has to be worked around?  Obviously you don’t even comprehend the most fundamental concepts of software engineering.

    Copy & paste the code below to embed this comment.
  71. Dylan, you’ve got it. I’m astounded how few others here have.

    This is about providing a way for IE to move into the standard compliant world, whilst allowing for the gazillion of extant web pages that do some ‘special’ when they detect IE as the browser to not break.

    This is why what works for FireFox, Opera, Safari etc, doesn’t work for IE. There simply aren’t huge numbers of web pages that rely on odd behaviour of those browsers to render correctly. It’s not that they don’t have odd behaviour, it’s just that because they don’t have the 80% market share, most web authors don’t bother to do something special to their pages to cope. For IE, it happens as a matter of course.

    What X-UA-Compatible is, is a statement of conformance by web authors of their page. It says, “I have tested this web page in IE6, Fx2 etc and it looks and behaves to my satisfaction. Any browser that treats my page exactly as one of these browser versions does, will handle my page as I intended it to”.

    To the browsers it is a HINT. Most browsers can and will ignore it. That is fine. Microsoft have stated that they will make use of it in IE to decide how to treat web pages. If it’s not there, then the page will be assumed to be a legacy page and will get legacy rendering. If it is there then it will be rendered according to the author wishes, either to a specific version that the page has been tested against, or to the latest version if the author so prefers. I fail to see what’s so objectionable about that.

    To address some specific points raised:

    Security. The problems raised here, do not affect authors, only Microsoft and web users. Microsoft’s problems are their own, and we can safely leave them to worry about how to deal with issues like XSS and DOM manipulation across different versions. For users too, there is a simple solution for anyone concerned about the security issues of this – download yourself a copy of Firefox/Opera/Safari and use that, since none of those are likely to adopt X-UA-Compatible.

    One alternative suggestion made would be for IE8 to remove all the elements that allow browser sniffing (not just the user-agent string) and then legacy web pages would be forced to treat the browser as if it were a standard compatible one. Sadly that’s a non-starter because, as anyone who uses Opera for any length of time knows, sooner or later you visit a site that simply says something like “Your browser is not supported – please use IE”. While, no doubt, the likes of Anne van Kesteren, who works for Opera, and others here, would love to see IE reduced in authors minds to the level of Opera, it’s simply not going to include anyone at Microsoft.

    I’m no Microsoft fan-boy. I hate the way they left IE to rot for so many years and in consequence did so much to create the state we’re currently in.

    I have wasted time struggling with IE. Recently my web site:
    – worked correctly in IE6
    – worked correctly in IE5
    – worked correctly in Firefox
    – worked correctly in Opera 9
    – worked correctly in Konqueror
    HTML validated 100%
    CSS validated 100%

    and when IE7 was released – it broke in that.

    I don’t see why that should happen again which is why I am pleased to be able to mark up my pages and say to IE8 – “I’ve fixed and tested my pages in IE7 – if you can render and behave like that did, I will not get support calls telling me my pages are broken and I can get on with more productive work”. At some convenient point later, I will get around to testing my site in IE8, and if everything’s OK I will tweak my CMS and all pages will be served marked as treat-as-IE8 instead.

    I wish we weren’t starting from here, but this is where we are, and this proposal is the most elegant, pragmatic solution.

    Copy & paste the code below to embed this comment.
  72. “Old stuff should keep working. It would be backwards to require a change to the old stuff to keep it working so you don’t have to add a change to the new stuff. And highly impractical.”

    Why should I have to crack open my already standards compliant web site and add a meta tag?  If I have to do it, then at least let the people who wrote non-standards compliant sites and declared them standard do so too.  Is my content rendered old by the release of IE8?  So by your reasoning it should just work too.

    Copy & paste the code below to embed this comment.
  73. This is bonkers. Just let old websites break.
    If the websites are important, let the owner pay a web professional (that’s US!) to update it.

    Doctype switching isn’t foolproof, because a valid strict doctype can be added to an invalid page by a CMS or an ignorant editor.
    It’s pretty unlikely that a page will validate by accident though.

    So here’s my idea – let the browser validate the page before displaying it, and then use strict or quirks mode depending on the outcome.
    It negates the need for all this meta tag nonsense.

    Copy & paste the code below to embed this comment.
  74. We have web standards which is fine, eventhough the standards are leaving lots of room for different interpretation, but what we really need is a way to enforce the standards we have on the browser manufacturer. Don’t let the non-conformant browser enter the market.

    Copy & paste the code below to embed this comment.
  75. “The way I see it”:

    Copy & paste the code below to embed this comment.
  76. What I don’t get is why people even bothered with IE 6 “standards mode”?

    Microsoft’s documentation and documented quirks/workaround all over the web clearly laid out the case for using quirks mode for both IE 5 and 6 and waiting until at least IE 7 came out to implement any sort of “standards mode” rendering shift using the DOCTYPE switch.

    Microsoft said quirks mode WOULD NOT CHANGE and that standards mode WOULD CHANGE with new browser versions. It was a NO BRAINER for any (competent) developer wanting their pages not to break with IE 7 or other future IE release to induce quirks mode (IE 5 rendering) in IE 6 using an HTML comment or XML processing instruction before the strict DOCTYPE and then using standards-compliant markup and CSS, with a separate compatibility stylesheet for fixing browser bugs targeted specifically to “lte IE 6” using conditional comments.

    People having done this wouldn’t have had to even touch the HTML again when/if a new IE browser version came out. The pages would render in standards-compliant mode for all current and future browsers that followed standards. The hacks/compatibility workarounds for non-standard IE issues would already have been dutifully contained and locked to the specific browser versions with the issues.

    It’s funny how it worked out that IE 7 suddenly started to render XHTML pages like this PROPERLY in standards mode, having fixed the XML processing instruction bug that triggered the IE 5/6 quirks mode for XHTML strict documents. HTML pages using the HTML comment before the DOCTYPE still render properly and in quirks mode in IE 7. All of this WITHOUT CHANGING ANYTHING.

    There is absolutely no reason pages should have broken when IE 7 came out if developers were competent to begin with and coded defensively. I mean, come on, the information has been available since IE 6 came out and quirks mode rendering workarounds have been increasingly available throughout this time for use in your conditional-comments targeted stylesheets.

    On another note: it is this very magazine, A List Apart, who recommends this ignorant meta tag proposal, that is also responsible for teaching a plethora of unsuspecting novices to standards-compliant web development to trigger and use IE 6 “standards mode”—knowing full well that that mode was far from compliant and was subject to future breakage as the mode was updated with each future IE release (at least until IE caught up to modern standards-based rendering levels).

    I mean, do you think this solution could possibly be well-conceived when is is evident that practices recommended by A List Apart are part of the problem?

    Having run across several stories confirming Microsoft is, in fact, implementing such an ill-considered scheme in IE 8 (!), let me just say this:

    Come on, Microsoft! Open up a discussion on this issue before blindly taking the first potential solution that falls in your lap and forcing us web developers and customers whom are both yours and ours to deal with the potentially massive blowback!

    And to ALA: be mindful of your belief that you possess some superior insight that affords/obligates you to profess the best course for the future of the Web. We are all in this together and all deserve to be heard and considered in the solution to our common problems.

    Thank you for your time.

    Copy & paste the code below to embed this comment.
  77. What’s most surprising about this is not yet another doctype switch, but that it was the WaSP that came up with it. This can’t be blamed on the the IE-team.

    This is the day that the WaSP failed their mission, and we started openheartedly embrace and encourage the versioned web. Let this day be known as “the day the core of the web failed”.

    Copy & paste the code below to embed this comment.
  78. Not officially endorsed by WaSP.

    Copy & paste the code below to embed this comment.

    This was a covert job between:

    • Chris Wilson of Microsoft ***
  80. and

    • individuals not representing WaSP ***

Copy & paste the code below to embed this comment.
  • “So here’s my idea — let the browser validate the page before displaying it, and then use strict or quirks mode depending on the outcome. It negates the need for all this meta tag nonsense.“

    This already happens. If the page contains the right doctype it will be shown in standards mode. If it has no doctype, or a non-strict one, it gets shown in quirks mode. But the whole page isn’t validated first. If it was, that would mean a huge delay when surfing, as each page would have to be checked first. Is that really what you want?

    Copy & paste the code below to embed this comment.
  • “This already happens. If the page contains the right doctype it will be shown in standards mode. If it has no doctype, or a non-strict one, it gets shown in quirks mode.”

    I know that. But using only the doctype to determine the rendering mode is unreliable, because there is no guarantee that it correctly declares the version of the following HTML markup.

    “If it was, that would mean a huge delay when surfing, as each page would have to be checked first. Is that really what you want?”

    Nope. You’re right—that would be a rubbish user experience.

    Perhaps it could work in the same way as the Phishing filter – check a list of known sites for standards compliance and use strict or quirks mode depending on the result. There’s still be a delay while the check is carried out, but would be quicker than validating the page, and the result could be cached.

    Intranets, extranets and web apps can be added to a whitelist/blacklist to skip this check and force whatever mode is required.

    Copy & paste the code below to embed this comment.
  • All I can say is, give IE a fair chance to correct what they screwed up in the past. The IE6 legacy is huge and cannot be solved by a simple poof

    The meta tag is not an ideal solution, but other solutions aren’t ideal either. The meta tag is quite solid in it’s current proposal, and allows us to have more control over the rendering of our documents. While it does complicates things a little, it gives us more control too.

    I’ve written a longer “follow-up to the article”: but the bottom line is simple. This is IEs solution to a path where they can actively care about web standards. I believe they’ve earned that chance with IE7 and the announcement of IE8 (and it passing the Acid2 test).

    Copy & paste the code below to embed this comment.
  • You then want to make sure developers use those specs? have browsers block ALL rendering if the DOCTYPE is missing or invalid.

    That’s not as good of an idea as you think it is. Here’s why: What happens when a new, valid DOCTYPE comes out? Now no document of that type can be rendered…at all…in current browsers, making it unusable for years.

    Copy & paste the code below to embed this comment.
  • It seems a lot of you weren’t there (or have already forgotten) but this kind of idea is just a (very bad) patch-style fix.

    Yes, a lot of IE6-only websites are broken in IE7. But it’s not OUR fault. The W3C standards were there, the IE6 team didn’t follow them. It’s YOUR fault for making your website up to Microsoft flawed understanding of the W3C specs.

    The doctype IS THE BEST WAY to ensure rendering: it’s already used by the browsers, nothing new needs to be put in place.

    As for the IE5, IE6 and IE7 websites, there’s still a hope: the Microsoft conditional comments. They’re regular comments to all other browsers, our files are still XHTML-compliant and they even allow us to target specific versions of IE, from inline XHTML to including external files.

    The C in CSS allows us to make standards-compliant websites and to over-ride these good values with whatever values the different IE versions are expecting (taking the box model as an example).

    We’re not going to help those who made a mess with their IE6 websites, get over it. You made our own mess, now clean it up. Microsoft has put the tools you need inside IE since at least version 5, use them.

    Copy & paste the code below to embed this comment.
  • While at a certain point I agree with the comment above, it’s simply not a realistic view.

    It’s easy to point fingers and say “you did wrong!”. It’s easy to tell them “fix it!”. But for the most part, the people you’re pointing at don’t really care (and I’m not talking about the IE team here).

    Most people that made broken sites don’t realize it or don’t care enough. Everyone can build websites and that’s basically a good thing. Sadly, in combination with IE6 this brought us many problems.

    We as web loving web developers should fix those problems, as good as possible. And we don’t do that by pointing to people who don’t really care that we’re pointing at them anyways. Maybe they’re not even there anymore.

    Apparently, some of us rather shift the responsability to the people that know the least about good web practises. That in itself is bad practise, making you part of the problem we’re facing today.

    Let’s face reality and work with that. It’s nice to have ideals, but let’s not hop mindlessly behind those ideals without considering the real world out there. It will bring us nowhere.

    Copy & paste the code below to embed this comment.
  • “Most people that made broken sites don’t realize it or don’t care enough.”

    So, if they don’t care, let ‘em burn.

    “We as web loving web developers should fix those problems, as good as possible.”

    No. Those who care about the broken site should fix the problem. I have my own clients to worry about, as do other web-loving developers. I do not have time to do the work because people like you, or people who have sites that broke and don’t care to fix them, say so. That, and I don’t care that their sites broke. That is not my problem.

    Copy & paste the code below to embed this comment.
  • Future versions of IE should ship with an animation that floats over the menu/tab bar area. It would be a big red boot that says “Kick Me”.

    When the user encounters a website that doesn’t render properly, she just clicks the ‘kick me’ button. The animation then floats to the outer edge of the window frame and ‘kicks’ the window, which shakes like an earthquake and re-renders the page in another mode.

    Users are already familar with the idea of banging on something that doesn’t work. Of course browsers that work don’t get the boot.

    Copy & paste the code below to embed this comment.
  • So, you’re thinking, what is the worst that could happen if they do this?

    “A Glimpse of the Near Future”:


    Our feedback was not solicited. The community was not consulted. We were not involved. This was done covertly with the participation of self-proclaimed gurus and individuals NOT REPRESENTING the web development community at large NOR the official position of the Web Standards Project (WaSP). WaSP has made public this FACT:

    1. “WaSP Statement and Discussion”:
    1. “Disclaim of Responsibility by Andy Clarke – Co-lead of WaSP”:


    Thank you for your generous devotion of your valuable time.

    Copy & paste the code below to embed this comment.
  • @Ray McCord
    You forgot to use super- and subscript (glad Textile doesn’t provide an alternative for <blink>)

    But thanks for the links anyway.

    Copy & paste the code below to embed this comment.
  • @Sander Aarts:

    Nah. No blinks or extraneous cruft for me ‒ in general, anyway. Heh.

    The fact is, it is simply more important that the post gets noticed and its point driven home than the feeling of Zen I get that comes from having dutifully pondered whether to use bold or strong, emphasis or italic, directly uppercased inline text or text-transform:uppercase.

    Fighting with Textile would just kill the buzz anyway. :)

    Try hyphenating words where the first word of the compound ends in “s”. It renders without the “s” and everything from the hyphen on to the next hyphen or rendered punctuation character is struck out. Not having a means to escape special characters without rendering side-effects is a definite disadvantage to using Textile.


    Copy & paste the code below to embed this comment.
  • It’s a shame really. I feel a lot of the vitriol stems from being denied a voice – not being consulted – not being included in the process. This is the web. We are used to the interoperability and openness of it.

    As designers/developers we take part in how the web works from a unique perspective. We are users as well as builders. We have a passion for the internet, and what we do. As diverse as our opinions can be, we expect the opportunity to at least be heard.

    But this is a proprietary piece of software we’re talking about. Microsoft doesn’t have to design by committee. The problem with this piece of software is it’s not used in a proprietary environment. The web isn’t Microsoft’s sole domain.  The internet is built on a platform of cooperation and openness. A browser/UA is just a gateway to using this platform.

    The issue is that Microsoft’s market share makes Internet Explorer the default gateway to the internet. For many people, oblivious to what a browser is, Internet Explorer IS the internet. This presents a problem for designers/developers because that default gateway is not up to the task of where we as designers/developers want to take the web. It has become the bane of our existence. This is not to say that it is a bad browser. Its problem is that it has failed to keep pace with where we, the designers/developers were headed. Microsoft, in their infinite wisdom, felt they knew where the web was going, that THEY were, or were becoming, the driving force of the web. I’d like to think that they have retreated from this idea, but I don’t think they have.

    Microsoft is staffed with intelligent people to be sure. Creative people – designers and developers themselves, with the same passions as the community at large. That doesn’t mean Microsoft’s vision for the web is best. Often it is Microsoft forcing their idea of the web down everyone’s throats, that we take issue with.

    The web moved in a different direction. We as designers/developers moved on. We developed new ways to architect websites. Designers have pushed their designs to new heights. Computers improved, software improved, and Internet Explorer sat there, broken in our minds. And it sat there until we laughed at it for it’s flaws. It sat there while we hacked at it, and bent it to our will in a desperate attempt to drag it into the future. It sat there when we screamed at it for being old and outdated. And it sat there while our workarounds became commonplace. While we documented every crack, every flaw, and wrote article after article about how to get Internet Explorer to display our websites the way the standards said they should.

    All this because we had been shown a new way forward. The Web Standards banner flew high, and we answered the call. And the COMMUNITY came together and figured how to use these old technologies and push web design in new directions. The idea could have fallen on its face, but it was the right idea at the right time, and I think it was a tipping point that helped usher in a richer internet.

    And when Microsoft finally decided to follow in the footsteps of the browser makers that had outdistanced them, and decided to update Internet Explorer, they released a better, but still broken and flawed application. And when our websites didn’t display correctly in this new browser, the engineers behind the browser blamed the designers/developers for their use of hacks. Hacks which were now so commonplace that they were written in by default. And because it was Microsoft speaking, and they had released a marginally better browser, the community splintered, and we argued over what made a good hack and a bad hack. And what was the best way to hack the old beast, while making the new beast look shiny and strong.

    And the engineers at Microsoft asked us to use conditional comments.

    A proprietary hack for proprietary bugs in a proprietary browser. THEY had now come to the conclusion that THIS was the best way to hack their broken browsers. Well sorry, but a little too late. Where was this wisdom when we found out IE5/5.5 was broken? Where was this wisdom when IE6 was still a mess of bugs and flaws? NOW they wanna play ball?

    Sorry, but Microsoft TELLING us anything anymore. They should be LISTENING to us. They are the ones who’ve fallen behind. They are the ones who can’t seem to keep up. They are the ones who have FAILED to create a browser that can properly display a site created with web standards. If they want to be leaders again, then make Internet Explorer the best damn browser available, and not for the bells and whistles, but for it’s display capabilities. Make it the most standards compliant browser available. you wanna see the design/development community rally around Internet Explorer, then do that, show us THAT, and we will celebrate.

    Now…version targeting

    It’s untenable. Regardless of protestations, Microsoft will NOT be able to support this indefinitely, and therefore it is a waste of time and effort. This is not a workable solution. It is not an archival solution. It is not a solution. It is a hack.

    The reason we’re told this is needed is Microsoft is trying to be backwards compatible, and NOT break the web. Well sorry, but they already splintered it into a thousand hacks so it’s basically already broken to some degree.

    Here’s the thing though.

    Websites (those we use regularly) usually get redesigned less often than browsers do, but when they do, they usually take advantage of the latest technologies. Therefore a site’s design isn’t archived for posterity. I can’t think of any site I use regularly that hasn’t been redesigned or upgraded within a 2-5 year cycle. Larger sites are often in constant monthly maintenance. Ask yourself how often you have redesigned your personal sites? If Microsoft would release browser updates/versions/fixes more often we wouldn’t be in this mess. And IF Microsoft could release a standards compliant browser, WE, the designers/developers could begin removing our hacks the way we talked about when we first started using @import to block content from IE5. The only hacking we’ve ever had to do was for the various versions of Internet Explorer anyway.

    So why, AGAIN, am I being asked to hack up my pages just for Internet Explorer? The reason is not archival. That’s bull. Sites designed pre-web standards display just fine. There is nothing cutting edge or broken about them. They are not maintained, they are not updated. They made little or no use of the standards, and they likely never will. In fact we’re really not talking about HTML at all. We’re strictly talking about the rendering of CSS. HTML display is just fine. So what are we really talking about here?

    We’re talking about giving Microsoft a way to hide its browsers future flaws from breaking our websites. Well if they created a browser that conformed to web standards, and had a better method of updating when they find flaws, we wouldn’t need to do that would we? Did Firefox 2 break the web? Did opera 9?

    This is a browser issue, not a document issue. There is nothing wrong with my document, and nothing wrong with my CSS. What’s wrong with your browser? Microsoft needs to keep that in mind. Stop asking me to change my document to conform to your browser. Make your browser conform to my document. You want to give users a way to see content in your broken browser? Give them a “Text Only” button that turns off your sub par renderer. make it a BROWSER feature, not a document switch.

    When the web standards movement started we talked about content accessibility. Code once, display everywhere. It was decided that if a browser couldn’t display our content properly it was Ok to deny them the bells and whistles and design in favor of accessing the content directly. What’s changed? Is the design more important now that we’re all web 2.0?

    Web design is transitory. I think some people have forgotten that point.

    If the content creators actively want their content to be accessible in the future, they will do what they have to do to ensure that. And this usually entails a redesign.

    The article gave us a scenario:

    “After all, we shouldn’t make assumptions about how browsers will behave in the future. If a change in IE9 would break the layout of our site or the functionality of one of our scripts, that could be disastrous for our users, sending our team into a mad scramble to “fix” the website that was working fine before the new browser launched (which is pretty much the boat we’re in now).”

    Well this is/and isn’t realistic.

    If I am coding to the standards, why should a new browser come along and “break” my site, unless the browser itself was broken/flawed? And if the new browser is broken/flawed, I would expect the manufacturer to “FIX” their broken browser in a timely fashion.

    But yes, the release of a buggy new browser could mean I would have to go and do updates to the site (as we all had to do with IE7). But I again stress the point—did we have to go back and recode our sites when Firefox 2 or Opera 9 were released? No we did not! These browsers supported the standards we used and nothing had to change. We expect that if we code to standards NOTHING WILL have to change, because using these standards means our site is forward compatible. And the basic idea of web standards is forward facing. Sites coded with web standards are not stagnant, are not meant to be stagnant, and are coded in a way that the presentation isn’t yoked to the structure, so again, give the user a button to turn off the display, or some other BROWSER FEATURE that allows them to view content in your broken browser, but stop asking me to change my document for you.

    Those of us who code with web standards and our clients are looking forward, not backward. We are bringing our content into the future, not anchoring it to the past. I for one will not use “version targeting”, and I would encourage the community at large to reject this HACK, since that’s all it is; another hack.

    If Microsoft starts making their browser work fairly regularly, we might even be able to achieve a nearly hack-free web.

    And I, for one, would welcome our hack-free Internet Explorer overlords.

    Copy & paste the code below to embed this comment.
  • “Alternatives NOW”:

    Give them something to do, other than coding the original proposal!

    Copy & paste the code below to embed this comment.
  • Damn you, misleading flat discussion format!

    It is at that. ;)

    Copy & paste the code below to embed this comment.
  • I’m confused.

    Let’s say I’m developing my own snazzy web browser. First I need to come up with some abbreviation for it, right? So I’ll call it XY. But since no author will bother to include XY in their meta tag, how is my browser supposed to behave if the author specifies: X-UA-Compatible:IE=6;FF=2;OtherUA=4 ? Well, the part OtherUA=4 doesn’t make any sense to me. 4…what? So the only sane thing would be to render according to W3C.

    My point here is that this browser locking proposal only applies to the major browsers, because authors will only specify IE, FF, Opera and maby Safari. They won’t care about the rest.

    Copy & paste the code below to embed this comment.
  • I’m not usually the sort that needs to put my 2 cents into blog discussions, but this is too important to ignore.  I really must add my voice to those who have already posted saying that this idea is simply untenable.

    I should also say that those who have simply been bashing MS and ignorant web developers are missing the bigger picture.  This is a really serious problem, and just telling people to design better websites isn’t going to make the problem go away.  Furthermore, I have no doubt that there are some really smart people at MS who have put a lot of thought into how to solve this problem without inflicting too much pain on the rest of us.  There aren’t going to be any easy solutions.

    That having been said, I think that this proposal will make things even worse over the long term.  This is an overly broad solution to what is really a very specific problem.  It also opens the door to a lot of other potential problems down the road.

    Version targeting isn’t really an issue with any browser other than IE.  This is partly due to IE market share, but it is mostly due to all of the bugs in IE and the long interlude between IE 6 and 7.  Pretty much all of the all of the other browser vendors have made it clear that they intend to support the standards.  If Firefox or Opera does something that is contrary to the standard, they consider it a bug that should get fixed.  If a developer codes specifically to that bug they should expect to have problems with the next update.  This is not to say that these browsers have complete support for the standards, nor that they refrain from idiosyncratic additions—but we don’t expect them to directly contradict the standards on purpose.

    Moreover, this should only be an issue for sites written to IE versions 5.x and 6 (although in reality, v7 will continue to have some problems).  IE 8 and beyond should support three (and no more than three) modes: quirks, “standards” (as defined in IE 6), and real standards.  If a developer writes to the real standards mode, they should expect bugs to be fixed in future versions, just as they are in other browsers.  MS should make it very clear to developers that the behavior of quirks and IE6 “standards” mode are forever fixed—but the real standards mode will be subject to ongoing improvements.

    We also need to take a look at the standards process.  The W3C standards process is generally fairly conservative.  It doesn’t change all that quickly and most changes are additive rather than changes to the existing portions of the standard.  When they do make changes that break backwards compatibility, the new version is readily distinguishable by its DOCTYPE.  Consequently, if I write to the xhtml 1.0 standard today, I expect it to work on any browser tomorrow.  When, at some future date, xhtml 2.0 is released there is no reason to believe that it will break xhtml 1.0 pages.  In other words, except for the IE6 problem, the DOCTYPE scheme is fully sufficient and no further mechanism for browser version targeting is needed.

    (Sidebar: I realize that the bigger issues these days tend to be with CSS, and JavaScript rather than html, but since these tend to parallel html standard development I think we can pretend like they are part of the html standards themselves.)

    I also believe that this proposal would lead to more bad web development and, more importantly, to inferior browsers.  We want to encourage developers to focus more on standards and less on specific browsers (yes, you need to test and fix for individual browsers, but hopefully you will do this in a way that adheres to the standards).  This standard does the exact opposite—it encourages the developer to say “it looks fine in my browser, so who needs standards.”

    The bigger issue, however, is in the browsers themselves.  In effect this proposal is asking browser vendors to include in each new version of their browser the capability to render a given page exactly as any previous version did—even if the previous rendering was the result of a bug.  Does any vendor (including Microsoft) really want to do this?  Do we really want them to?  No and No.

    Browser vendors might decide that the thing to do is simply to include a copy of each previous version of their rendering engine with each new release.  Pretty soon a browser release has ten extra rendering engines attached to it.  Talk about bloatware!  Even if support for past rendering quirks is kept in a single rendering engine, this leads to a significant increase in complexity of the browser code.  I would much rather have the browser vendors focus on adding better support for new standards than figuring out how to keep the old cruft alive.

    (BTW, I have to say that the archival argument is a red herring.  As with everything else, this is an IE 6 issue, not an overall web issue.  What we really want for archival purposes is more adherence to the standards.)

    So, to sum up what I have spent the last many paragraphs bloviating about:
    We don’t need and don’t want a general way to target browser versions.  What we need is a way to target IE6 rendering versus IE7 (or maybe IE8) and beyond rendering.

    Now, having said all that, we still need a mechanism that allows a developer to specify rendering mode that IE should take.  I don’t actually care too much about whether this is done with DOCTYPE’s, with meta tags, or with something else, as long as the solution is limited to solving the core problem at hand.  Perhaps MS could convince W3C to create a DOCTYPE called “IE6”.

    My strong preference would be a system that required developers to opt-out of the standards rather than opt-in as this proposal suggests (where you would add a tag to say “don’t apply strict standards”).  This would mean that old IE6 web pages would need a little modification to work under IE8, but at least the modification would be really easy.  Someone would undoubtedly come up with some good server hacks that would automatically add the required tag to every page on a site.  Nonetheless, I would be willing to accept an opt-in system if it did the job cleanly and made the headache of supporting IE go away.

    So, fix what you need to… but please don’t break anything else in the process.

    Copy & paste the code below to embed this comment.
  • Please, please, please, please, please, please don’t do this. Bite the bullet and make standards-compliant mode standards-compliant mode.

    What’s more important for Microsoft’s image, and for the future of the internet?

    A short term fix that will FOREVER ALTER THE WAY WE CODE WEB DESIGNS, or;
    A short term inconvenience for websites coded without standards in mind, but a sustainable and consistent cross-browser method of ensuring web compliance?

    I know the IE development team faces incredible opposition on both sides. So, please, look deep into yourselves and into the future and think about what you are proposing: yet another proprietary piece of code forced (yes, forced) onto the internet because of your companies past failings.

    I’m not trying to be antagonistic or super-subjective. All I know is that I spend hours every day cursing Microsoft for IE 6, and I’m willing to bet that the time it would take for IE-specific sites that break with “standards-compliant” IE 8 to fix their pages cannot compare to the hundreds of thousands, if not millions of man-hours lost to trying to conform to Microsoft’s idea of how pages should render.

    Please, please, please do your best to do away with the meta tag. Thank you for your time.

    Copy & paste the code below to embed this comment.
  • One thing I haven’t seem mentioned here anywhere is:
    Any documents that are marked as <!DOCTYPE html> will be treated by IE8+ as a standards compliant document and will use the latest rendering engine.

    So anyone whose document is valid according to HTML5 can avoid an X-UA meta tag or http header, and just use the doctype to ensure correct rendering.

    Having seen this, I’m a lot happier about things – although it means that existing pages will need the doctype to be converted, there’s no problem for ongoing development – new websites won’t need any IE specific code to work properly, and once the change has been made once, it won’t need to be made again every time IE launches a new browser.

    Copy & paste the code below to embed this comment.
  • michael paige (171) – good post.

    Ray McCord (168) – that’s the spirit!

    Derek Ahmedzai (161) – ”…using only the doctype to determine the rendering mode is unreliable, because there is no guarantee that it correctly declares the version of the following HTML markup.“

    That’s surely always been a problem. How many sites claim to be XHTML or even HTML 4 yet contain errors.

    “Perhaps it could work in the same way as the Phishing filter — check a list of known sites for standards compliance and use strict or quirks mode depending on the result. There’s still be a delay while the check is carried out, but would be quicker than validating the page, and the result could be cached.“

    Nooooooo! What would happen if a site was blacklisted as non-standard then got redesigned? It would be rendered in the wrong mode. And to list every site on a list that had to be checked would be far too slow.

    We just have to assume the site is well coded from the doctype.

    Thanks for the reply!

    Copy & paste the code below to embed this comment.
  • in the article, aaron states:

    “We could specify the version of the languages we use, such as CSS 2.1 or JavaScript 1.5. Unfortunately, browser vendors often implement only part of a spec and the interpretation of a specification often differs from browser to browser, so any two contemporary browsers may offer completely different renderings of the same CSS or may trigger completely different events from the same form control.”

    well, how’s this: what if we were to version the languages, and carry on doing EXACTLY what we’re already doing to accommodate for differences in browsers, i.e. use conditional comments and possibly a tiny amount of hacks/javascript-based sniffing (capability sniffing and/or browser sniffing)?

    personally, my gut feeling here would be that this is more “right” – you’re defining which W3C spec you’re assuming for the page to work, and make slight accommodations where you know for a fact that a specific browser hasn’t implemented it right. it’s specifying the capabilities expected of a browser, rather than the exact browser and version number that the page assumes.

    old legacy/intranet sites can stay as they are (without the versioning), and then it can be assumed they’re using the current JS spec and CSS 2.1. that would be the frozen bit: if you don’t version, this is the assumed spec. IE can then do whatever it likes when it comes across those pages…kick in a separate IE7 rendered / JS engine or whatever.

    yes, developers would have to modify their code to add versioning, even to their existing sites. but this feels descriptive (similar to doctypes, it’s something you add to your page to explicitly describe what it IS, not what it should do…a subtle, yet fundamental difference in my eyes).

    so…somebody explain to me again why this wouldn’t be far more desirable? am i missing something?

    Copy & paste the code below to embed this comment.
  • Aaron writes:
    “We could spend hours explaining why our sites broke, but wouldn’t it be better if they didn’t break in the first place?”

    No, Aaron. If the code is wrong, the site should break.

    I work with content – mostly text, and have no deep understanding of the technical aspects, but what I understand is that correct code will be displayes incorrect unless we put on this “gaffa tape” thing in meta.

    I am SO tierd of using large chuncks of the tech budget fixing up and cleaning beacause of bad IE code. I want developers deal with buisniss logic and such, not navigating in bugs and hacks.

    Even Italy managed to convert to the € witout to much fuss, Sweeden changed from righthand driving years go. Microsoft sayes “we cant break the web”. Sometimes one have to do a change in direction. I wont to make correct code and I am ordering MS to make a browser that reads that correct.

    Copy & paste the code below to embed this comment.
  • I’m sure lots of this has been said before in the previous 19 pages of discussion, but here’s my two-penneth.

    From a developer POV I like the idea of having the previous rendering engines all wrapped up in one — it saves the effort of running multiple versions of the same browser side-by-side. If this proposal doesn’t make it, maybe an off-shoot of this will be a recommendation for ‘IE8 Developer Version’ (if only to save someone at Microsoft’s time, releasing IE6 in Virtual PC every half year or so; or some other work-around). Assuming it goes through – how bloated (Mb-wise) will each new version of a browser get when all the previous rendering engines are there in the background? Surely this’ll be an extra tax on computer performance as well as disk space?

    The whole idea is to fix IE historically… what about wiping the slate clean? I’m sure I’m not the first to think it but, controversially and with no disrespect to the IE team, why not mothball the whole thing? Replace IE with something else as the main browser in Windows (we’ve already seen IE killed off on the Mac).(it could even be a new broswer from Microsoft?!?). Maybe the meta tag proposal, as being the least destructive of a list of “much more problematic options” as Molly describes it (in her blog:, is proof that the development tangent IE seems to have taken over the previous years is just too far to bring it back into standards compliance, despite everyone’s best efforts.

    Still thinking about it but my gut feeling says “˜KISS’ (keep it simple stupid), with this meta info it looks like things are going to immediately get overly complex.

    Copy & paste the code below to embed this comment.
  • The <meta> element or HTTP header seems a good way to state characteristics or properties of a web page.

    On the other hand, how would you feel to use “Content Labels”: instead? Does it make a difference to attach a cLabel to a page (or to a complete site) claiming that the resource is targeted to (or is compatible with or is tested with) a certain user agent? Would you be willing to state that?

    “Eric pointed out in another comment thread”: that clients always list the browsers in which the site has to “work”?. That could be a reason to provide Content Labels. You might even mark them as assertions: on a certain time, person X verifies that Url Y works with user agent Z version 8.

    Would you oppose if user agent Z’s future version 9 would parse this content label and render the url Y the same way version 8 did? Why?

    Of course, Content Labels are not a finished standard. Meta tags are easier and more familiar to most web developers. And changing the technical method of claiming user agent compatibility will not solve the forward compatibility issue. However, I find cLabels a better approach to mark up browser compatibility than meta elements.

    I think I would prefer user agents to use their latest and most current capabilities of rendering a resource with no ua-compatibility stated. I would not like to add a meta element or HTTP header that I consider a Microsoft hack to all my pages, but I would have no problems to add cLabels stating that I have tested the pages with a certain browser version.

    Copy & paste the code below to embed this comment.
  • I’m late to the discussion, and I admit I haven’t read every word of the previous 19 pages of comments, but I what I’ve seen is a discussion amongst experts, people who write all their own code.

    But what about people who use HTML editing software, such as Dreamweaver?

    I work in an organization where I am the CSS expert. My colleagues rely on the HTML that Dreamweaver or Visual Studio generate. But how are those programs going to handle this new <meta> tag? When a non-expert user creates a new HTML page, will their software include this new meta tag at all? And if it does, what browser versions will it target by default?

    If it omits the tag, then it’s “˜IE7 Forever’ for these users, and all of the pages they create. If it chooses a browser to target, then I can’t help but foresee numerous problems arising.

    What if Dreamweaver CS4 targets IE8, but IE8 is not installed on the user’s system? Will edited software have to sniff user’s systems to see what browsers are installed and available for testing? What if a future version of Dreamweaver is available for Windows XP, but ends up targeting by default a Vista-only version of IE?

    We all know Microsoft has created an untenable situation with IE. Currently, in my organization, we are still running Windows 2000 system-wide. We have no on-site access to IE7, and as such haven’t been able to test our web sites in Microsoft’s latest renderer (which I consider to be both a blessing and a curse).

    Copy & paste the code below to embed this comment.
  • I think I’m missing something, somewhere… I admit I only read the first 12 pages of comments, so maybe someone already said this and I apologize if I’m re-hashing.

    If I have conditional comments targeting IE6 and IE7 to load custom CSS for these browsers, shouldn’t IE8 simply ignore those and render real-standards compliant by default? If it truly is going to render like all the other browsers, it should just do it. It won’t break anything because people using IE6/7 will still have their conditional css.

    And say I have IE7 specific conditional comments, and leave out the meta tag. Will IE8, rendering in IE7 mode, be smart enough to include the IE7 conditional parts, or will it render in IE7 mode and ignore IE7 conditional statements because it’s IE8?

    How is this better than having an IE8-targeted conditional, since I’m sure I’ll need one anyway no matter how ‘standards-compliant’ MS says it’ll be?

    I just don’t see how this is any better than conditional statements… really I don’t.

    Copy & paste the code below to embed this comment.
  • Jon Waller said:

    “What if Dreamweaver CS4 targets IE8, but IE8 is not installed on the user’s system?”

    Others have raised this point, and I was concerned about this at first, but on reflection I think it’s a non-issue. Let’s consider the various cases:

    If the user doesn’t have IE at all, then the meta tag is simply ignored by other browsers – it doesn’t matter what is put in there.

    Similarly if the user has IE7, that doesn’t know about X-UA-Compatible so it too will ignore it. The issue then becomes one of graceful degredation – exactly the same graceful degredation issue as we all faced when designing for IE6/Fx when IE5 was prevalent, or designing for IE5 when many users had IE4. That is to say, the meta tag doesn’t change anything.

    What about, what if Dreamweaver CS? targets IE9, but the user only has IE8? As far as I can see, Aaron was not definitive on this point, but the implication is that forward IE version numbers are treated as if they were “edge”. In which case IE8 would render the page as IE8, which is good because it is likely to be the closest approximation to IE9 available to the user. Once again the problem reduces to one of graceful degredation.

    One possibity is that a site will render correctly in IE9 and IE7 but due to bug in IE8 not render correctly in that. In which case it would be helpful to be able to state

    <meta http-equiv=“X-UA-Compatible” c />

    but it is unclear how IE8 would treat that. Would it treat it the same as

    <meta http-equiv=“X-UA-Compatible” c />

    or is the order significant?

    Copy & paste the code below to embed this comment.
  • I’d like to sign a petition.

    Copy & paste the code below to embed this comment.
  • We owe it to ourselves:

    Alternatives NOW!

    See here for a breakdown of the problem and start helping out on an alternative solution:

    “IE Blog Comment”:

    Web developers unite!

    Copy & paste the code below to embed this comment.
  • This not only would create MASSIVE code bloat for browsers but, would make wysiwyg editors like Dreamweaver bloated to epic proportions!

    We know that professional web developers design(OK, that’s a guess) less 1% of websites on the internet today. The rest use wysiwyg. Do you really think Adobe are going to create a code generation alogorithm and application interface for every UA version that was EVER on the market? No, that’s ludicrous!

    Which, of course, is all very amusing considering M$‘s effort’s into the wysiwyg markets with the likes of SharePoint. Looks like if the IE team move forward on this one M$ could end up being one of the biggest losers…


    Copy & paste the code below to embed this comment.
  • Versioning sounds like a bad solution because of probability of ridiculous complexity.  But I am very glad to hear those who talk about preserving the older designs done by WYSISYG editors and using tables.  The web has so far been fairly free and accessible and those things have enabled just about anyone to put up a web page.  I don’t think anyone should say that those pages should disappear because you want to “change the rules”.  Making the web less accessible “in the name of progress” is wrong.

    I think that the “tables vs css” argument is like “spreadsheets vs databases”.  Tables (spreadsheets) enable people to easily do the easy things.  CSS (and databases) are available for the ‘professionals’ to do the difficult things.  I think that both should and will coexist.

    If there is some thought that making it more difficult will result in more work for web designers, my experience is that as soon as you make it more difficult or too complex on the computer, many people will go back to paper and pencil to do simple things.  They won’t hire someone to do it.  Besides, I hope that the viewers can tell the difference between the ‘amateur’ home page with some family pics in a table and a ‘professional’ web site with XHTML, CSS, AJAX, PHP, MySQL, and every other acronym you can put on your resume.

    Boy, that felt good!

    Copy & paste the code below to embed this comment.
  • Aaron,

    At one point you state:
    “In a slightly more down-to-earth version of an ideal world, browser vendors would immediately integrate regularly updated standards into new user agents—and users would have instant access to the latest version of those browsers without having to lift a finger.”

    When I read that I thought “Doesn’t my antivirus software do this every day?” Each day at 2 AM it downloads an updated database of virus information and automatically installs it. Maybe the thing to do for Microsoft (and others) is to create a “standards database” that can be updated every so often automatically by the application.

    In fact this could easily function as an improvement/extension of the Firefox update mechanism that alerts me that a new version is available. Just tell me that an updated “DTD entry” is available and tell me to install it. Or even better, have the browser automatically pull it down and install it.

    Copy & paste the code below to embed this comment.
  • Having the ability to lock website to a any given browser is really good option.

    Copy & paste the code below to embed this comment.
  • I agree with all the detractors comments. This really is a terrible idea. However, for the intranets edge case that seems to be popular at MS (and it is an edge case because it’s such a tiny proportion of sites), I can see it working really well if the logic was simply inverted, i.e. ‘edge’ standards mode should be the default.
    So your site breaks in IE9. Just add the meta tag (or better, tweak the server so that it delivers it as an HTTP header so you don’t even have to alter the pages) to make it revert to IE8 behaviour.
    This offers the prospect of ongoing standards compliance, and an easy fix for those that built broken sites. As far as not breaking the web goes, it would only break sites that were already broken, rather than breaking absolutely everything now and in future.
    Far as I’m concerned, IE6 users should be made to suffer.

    As far as sticking to the letter of CSS standards, it’s not quite that simple. Some of the cases are not all that clear cut – as it is Safari deliberately emulates some of FireFox’s misinterpretations – all too often the finger is pointed at the browser that is different, even if it’s actually the only one doing stuff right.

    Copy & paste the code below to embed this comment.
  • Dave,

    I think you missed the point – it’s using tables for layout that makes the web less accessible. Far from making anything harder, a CSS approach results in much simpler code for both developer and browser. The problems occurred when people that learned table layouts just didn’t grok the idea of styling and layout not being inline. Tables are perfectly reasonable HTML – for tables, not layout. There’s no great divide here. We’re all using the same web – it’s just a matter of using the right tools for the job.

    Copy & paste the code below to embed this comment.
  • i am a young developer from romania, and as usual i really apreciate your articles. They’re really enlightning in some ways (for some people).

    however i don’t agree with the possibility of locking browsers. It just does not seem the right way(not that IE is in any way the right way). I am really enthusiastic about the promised IE8 browser, but i was so about the IE7 browser and that proved to be “not as expected”. However, future can be full of surprises.

    Of course i am waiting for the release of IE8 and FX 3. In hope of a more standardized world that will allow me to do my work in a better way.

    I am waiting and hoping that this is at least partially true (i mean the IE8 thing).

    Copy & paste the code below to embed this comment.
  • That’s a fallacy. The DOCTYPE switch is NOT broken. The DOCTYPE switch does one thing – it puts the browser’s renderer into “standards” mode. It will apparently continue to do this in IE8. If it was broken, the IE Team would be leaving it behind. They are not. According to the IE Team:

      1. “Quirks mode”? remains the same, and compatible with current content.
      2. “Standards mode”? remains the same as IE7, and compatible with current content.
      3. If you (the page developer) really want the best standards support IE8 can give, you can get it by inserting a simple <meta> element.

    So in IE8 “standards” mode, has been demoted to IE7’s version of standards rendering (good, but still quirky and incomplete). The issue is not sites that have been developed in “quirks” mode (for those sites the DOCTYPE switch is still relevant), the issue is sites developed for IE6 in “standards” mode, by inexpert developers who likely didn’t even know there WAS a standards mode.

    Aaron says: “How do we know that it [the DOCTYPE switch] failed? When IE 7 hit the streets, sites broke.”

    Well yeah, duh? The DOCTYPE switch didn’t fix IE6’s rendering bugs, primarily it just fixed the broken box model that IE5/5.5 brought to the table. But I’m tempted to think that even the inexpert developers had to overcome IE6’s buggy rendering somehow. When the inexpert developer hit a bug that caused something to not work in IE properly, he’d have to find a fix for it.

    But anyway, let’s say that they blissfully coded away and were able to design a site for IE6 without any of the hacks the “expert” developers used to whip IE into shape. Now along comes IE7. And their sites broke. Which is what Aaron and the IE Team are telling us (and I believe them!).

    Now wouldn’t these inexpert designers/developers get a call from their clients when these sites broke in IE7? Wouldn’t these inexpert developers have found fixes for how these sites displayed in IE7? And if it wasn’t the inexpert developers, wouldn’t the client themselves have hired expert developers to update their sites?

    So how many sites out there are still broken in IE7? How many of these sites will get redesigned in the next year or two? And in the next year or two, how many inexpert developers will be coding these sites for IE6? Personally, I think these inexpert developers will be coding to IE7. And isn’t that a good thing? Isn’t IE7 a better, more compliant browser?

    So who do we need another standards mode for?

    The IE Team feel that they can’t afford to break sites again when IE8 is released, so they want to shoehorn in “IE7 standards” mode in between “quirks” mode and “standards” mode (where standards mode means best available). And it is very likely that IE8 will seem to break sites again. IE7 still has some quirks/bugs, and developers have had to find fixes/hacks for IE7 in the same way they did for IE6 (only to a far lesser degree). But without this new switch IE8 would cause a few problems. Clients will be upset, but not “expert” developers. We would relish being able to begin the process of leaving IE5/6/7 hacks behind.

    So we, the expert developers are being asked to insert a META tag into our documents if we want to change the default rendering mode in IE8. The reason that we might want to do this is because the default rendering mode is going to be “IE7 standards” and not just “standards”. It almost seems like a reasonable request, but this is problematic for a number of reasons.

    If we were strictly dealing with blogs, it would be a much easier task to test the META tag locally, and see how sites render in IE8. However, lets say I work for a large company (which I do), with many large client sites developed on different platforms (.Net, Java, etc.). The clients will never see an issue with IE8, nor will they be able to see what their site actually looks like in IE8 without this META tag.

    To truly test in IE8, this meta tag will have to be inserted into the site templates temporarily. The site will have to be staged. The site will have to be QA’d in IE8, just to check the display. Any fixes/updates will have to be worked out. There will be no easy way to QA the site in IE8 without inserting the META tag and staging these sites. This will be an arduous process to test for one browser.

    Then there is the long-term question. How long does Microsoft/IE intend to keep this up? What happens when I need multiple rendering modes for different versions of IE?

    Let’s say IE8 comes out, and I want my site to use the best standards rendering, so I insert the META tag to make it render in the best possible manner. Now IE9 comes out, and it’s a dog (it could happen!). It doesn’t even do IE8 rendering properly, so I want it to default to IE7 mode and at least give people a usable site. Now I need two META tags. Now quick on the heels of the IE9 disaster comes IE10. IE 10 is great fixes everything wrong with IE9, and I want it to display the best it can. So I need a third META tag, because I still have four IE versions in the wild, IE7/8/9/10. So how do I do this multiple META tag code – conditional comments?

    Lastly, every WYSIWYG editor and templating system out there will soon have this META tag included by default, and we will be in the same situation within a year or two.

    Copy & paste the code below to embed this comment.
  • Ah, the penny just dropped.

    Chris wilson stated in a reply post over on the IE8 blog… “In the end, we believe our highest priority is the user…  If they install a new browser and their sites are broken, they uninstall the new browser.”

    Think about it, what hasn’t been discussed here is which Operating System IE8 will support. I’ll hazard a guess and say it will be Vista only and maybe Windows Seven (or whatever the next version of Windows is named).

    And here is the rub, Micro$oft only make their money from selling Operating Systems and not web browsers. This means that Micro$oft don’t want users to purchase a new OS (e.g. Vista or Windows Seven) only for them to find some old, crappy web-sites don’t work and then return the OS or decide not to upgrade on a recommendation from one of their friends or a tech review. So by releasing IE8 only on Vista, Micro$oft will try and force users to upgrade to their latest OS, thereby increasing revenue and profits along the way. “It’s safe to upgrade to Vista and IE8 because all your old, crappy web-sites work too”.

    The way to think of this decision is that it is a Product Marketing decision (i.e. make money) rather than a Software Development (i.e. provide standards compliance) or User-centric decision (i.e. build a better web).

    At the end of the day, the fact that web browsers are “free” (in the not having to pay money sense) means that Micro$oft will try and recoup their costs in other areas. This time, through the Operating system.

    It’s a sad decision for the Web but one motivated by money and, as usual, corporate greed.

    Copy & paste the code below to embed this comment.
  • Think about it.

    It would mean that each new version of any browser (internet explorer is just one of them) would have to carry the rendering engine of the ones that came before it. Meaning more mass. Meaning huge dowloads (or maybe a download of the desired rendering engine over the wire – but then meaning that the user would have to wait for the rendering engine download each first time he or she would encounter a new version). Not good.

    Furthermore, if you locked your website to say internet explorer 7 and let’s say the website was then viewed by a user having only firefox 5. How would that browser know how to render the site? Would he render it in its quirks mode? That would be a shame wouldn’t it? Would he ask via a microsoft API the permission to load the correct rendering engine? Will each browser “vendor” be willing to make their rendering engine available as downloads? Won’t they try to break each other’s implementation? What if the rendering engine of one vendor is compromised?

    What would be a better idea would be to lock websites to CSS version, scripting version and XHTML version via doctype. That way there would be rendering engines stores wich would be vendor independant (think open source) that could be queried over the wire by each and every new browser in town. The browsers would either (open source) be containers for these rendering engines but would implement their own UI or (proprietary) would implement their own rendering engines (tuned, with added bangs and whistles, etc.) but could still query each other rendering engine store in order to render a legacy or future doctype.

    Small downloads. Thin clients. Less mass. Faster.

    But that would mean that browser will be graded (a bit like SQL or C/C++ by the ISO organization) according to their proved implementation of W3C recommendations that could then stop being recommendations and start being standards.

    That would also mean that instead of adding new features, the browser vendors would concentrate first on being standard compliant.

    Copy & paste the code below to embed this comment.
  • adrian sucho’s penny just dropped for me, too.

    To repeat the Chris Wilson quote: “In the end, we believe our highest priority is the user”¦ If they install a new browser and their sites are broken, they uninstall the new browser.”

    That’s Microsoft’s problem (it’s also a problem for Firefox, Opera, Safari, etc.) but it’s not my problem! In fact, that’s appropriate user behavior.

    Over the years, growing use of standards by developers, better standards support from competing browsers, and IE6’s problems with those standards led to a decline in IE market share as users sought better experiences. So, IE7 came along, more standards compliant… and ‘broke’ sites that coded to IE6’s faults. That was the risk developers took, and they have to fix it themselves. Users had a choice and were able to use other browsers, and were given more incentive to do so.

    If your highest priority is the user, you don’t take five years to release a better browser.

    Among the benefits of standards: developers (mostly) weren’t forced to write for specific browsers, users would get more choice, and browsers were encouraged towards compliance. Standards are winning. Would we have had a ‘problem’ with IE7 (being so much better than IE6) if this wasn’t the case?

    This new approach lets MS off the hook, just when the playing field has been leveled. As adrian noted, it enables the old forced upgrade strategy that benefits MS and does not necessarily benefit users. And developers are asked to do the enabling.

    If I as a lone developer choose not to support this strategy, and do not use this versioning, does that mean that my sites will get rendered by the latest, (assumed) more standards-compliant browsers, as older versions? Will IE8, finding no versioning tag, render my page as IE7? Is that really a price I have to pay because I refuse to endorse a system that punishes users by forcing them into upgrades they might not want? I thought users were supposed to be our highest priority.

    I have to add that such a strategy would not be considered if the browser in question was Safari, Firefox, or Opera. The reason seems to be that IE has a large share of the market (still). If that’s the reason, that undercuts everything about standards. Might as well use the old MS box model. It’s going to be supported into the future anyway.

    Copy & paste the code below to embed this comment.
  • The article’s suggestion seems rather Modest Proposal-ish. It would limit growth of new and alternate browsers, place total burden on web authors and basically exempt browser developers from any responsibility, be inherently impossible to fully standardize (is W3C going to list every browser version and what they support, so that web authors know which tags to use?), is biased towards Microsoft’s versioning / release schedule, etc.


    • HTML should be relatively constant – the structure of documents rarely is revolutionized in such a way that HTML itself should change.  One well thought-out version of HTML that lets us outline the parts of a document (and their relationships, if important) in a very open way should last us quite a while, although current versions aren’t too horrible, either.
    • CSS should change (more frequently than HTML, but still not very frequently) – browsers become more capable, designers learn more about using the medium, display technologies change, etc.


    An HTML document links to multiple stylesheets for each media, and each link has an attribute stating the version of CSS the stylesheet uses. (Or, the attribute could specify how “advanced” that stylesheet’s code is, perhaps using a system like z-index numbers). The browser then uses that information to choose which stylesheet to use.

    For example, there are stylesheets labeled “CSS 3.1” and “CSS 3.2”. Browser X v1.5 knows that it fully supports CSS 3.1 but not CSS 3.2, so Browser X v1.5 uses the stylesheet labeled “CSS 3.1”.  Alternate example: stylesheets labeled “advanced” and “basic”…Browser X v1.5 looks at the advanced stylesheet and sees CSS that it doesn’t recognize/knows it can’t support, so the browser uses the “basic” stylesheet instead. (A combination of the two is plausible when a browser knows it supports most of CSS 3.2 – the browser could scan the CSS 3.2 version to make sure there aren’t any features it knows it can’t implement.)

    This solution requires at least two versions of a stylesheet, which I think is realistic given that stylesheets are re-used throughout a site.  This solution is advanced and offers graceful degradation of features.  Non-advanced web authors could specify a single style-sheet as per the current situation.

    I prefer my suggestion because

    • in a nutshell Web authors can code to standards, and browser developers have flexibility in developing browsers that support the latest standards.
    • if correctly written, validating, standards-compliant code is displayed incorrectly, it is unambiguously the browser’s fault for not knowing it’s own abilities. (Currently, web authors are expected to know the exact abilities of all web browsers, including their errors.)
    • if a browser that chooses the correct stylesheet display a page incorrectly, it is unambiguously the web author’s fault for not coding to the standards they say they are.
    • a browser that is not “cutting-edge” is still viable (including new browsers that are still adding standards support and old versions of updated browsers (as long as the old versions support this system, which is a weakness of any change))

    Copy & paste the code below to embed this comment.
  • I’ve been reading A List Apart articles for years. Some have been more useful than others. But this one is the first that I have really disagreed with. I thought I must be missing something as I read it, but judging from the comments, I’m not the only one who thinks this is a bad idea. I’m surprised.

    Copy & paste the code below to embed this comment.
  • I don’t like this for a lot of reasons. Many of them already stated by others.

    But if there is no stopping this on the whole, I’d like to suggest it be a switch that could be placed inside a CSS file, and not in the HTML.

    I have sites that have a lot of template files/master pages, and these would all have to be updated, however CSS files are few, and there is usually a single master (or could be!) that could contain this switch.

    This would make testing/QA easier since I would only need to update one file to test an entire site. It could be as simple as:

    html { filter: XUACompatible.Microsoft.RenderMode( ie=‘8’); }

    It would also give us a way to target previous/future browsers.

    I could have a ‘rendermode.css’ file with this in it, and simply import it into my global.

    In a different scenario developers could also do:

    <style type=“text/css”>
    <!—[if IE 8]>
    html { filter: XUACompatible.Microsoft.RenderMode( ie=‘8’ ); }

    <!—[if IE 9]>
    html { filter: XUACompatible.Microsoft.RenderIEMode( ie=‘edge’ ); }

    But like I said, I’m against having to put this in the HTML – this however would simply be an alternate. Right now there is only the META tag. I prefer having more options.

    The last thing I think this might prevent is mass proliferation. CSS files are not typically CMS/application templates, so this being built in by default is less of a possibility (it could still happen though, I’m sure). It could certainly be a code snippet, but only the developers who know what it is would use it.

    Copy & paste the code below to embed this comment.
  • I’m sure nobody will ever get this far, but I do want to register my reaction. The problem is the default. I have already spent an inordinate amount of extra time on projects just to accomodate IE. I don’t want to have to add another line to the html just to have IE8 render as IE8, rather than IE7. This is asinine. I want standards mode by default—no special meta line. I’m so sick and tired of devoting extra time (both mine and my organization’s) working to accomodate inferior Microsoft products. Microsoft’s fears about breaking older sites are excessive and unwarranted. I also thought Chris Wilson’s attempt to brand this as a MS/WasP collaboration was a wee bit slimy. Was that really necessary? And the ‘closed’ way this proposal was developed only detracts further from any integrity it might have had. I respect Zeldman’s position and efforts to defend it, but agree more with Eric Meyer that the default does not make sense and that, hopefully, someone will persuade MS to change it.

    Copy & paste the code below to embed this comment.
  • I obviously didn’t read all 204 posts here before posting this, so please forgive me if this has been said.

    For those opposed to this idea, why not use this meta tag with the “edge” keyword for all browsers; then, as new versions of browsers come out and break your pages, temporarily change the meta tag to target the last working version of that browser to keep your clients happy, while you go and do that voodoo . . . to make everything halal for the new version. Then you would change back to edge again, gleefully awaiting the next breakage.

    I for one am happy about this, even though I have my reservations, because I think it will allow browser vendors to add new features and better compliance without fear of backlash from the developer community (and their clients). We shall see, apparently.

    Copy & paste the code below to embed this comment.
  • To start with, I was totally against this proposal. After reading several articles on the matter, I’ve changed my mind – it is the least worst way forward. In particular, “Zeldman’s comment”: on his own article.  C’mon, a man doesn’t support his mother-in-law unless there’s a very good reason!!

    He’s right. Microsoft want to move forward on standards-compliance. But, if they do that without any other mitigating changes, it is in danger of breaking a large number of websites. And much as I hate the fact that cowboy website builders and crappy software have allowed these sites to proliferate, we have to recognise that they are out there, and that confidence in the web as a whole will be undermined if they stop working for people using IE8 out-of-the-box.

    By requiring a meta tag or http headers or an HTML5 DOCTYPE to ensure correct rendering, IE will not break the multitude of websites out there. And those of us who do know what we are doing do know that we need to make these tiny changes to our sites, and we do have the ability to do this.

    If it was the other way round, if standards-rendering was the default, sites could break. The plumber who tinkers with the site his son knocked up for him in Frontpage Express wouldn’t know he had to make a change, and wouldn’t know how to do it even if he did.

    I don’t know how many websites will break. It might be a lot, it might be a few. I suspect that most sites won’t be affected – and will work OK (even if not things of beauty) with or without the switch.

    The comments about multiple multiple rendering engines are complete red herrings. All that any sensible designer will do is to check IE=6 or IE=7 or IE=edge against current browsers. That’s all. Just like you now check HTML 4.01 Strict against IE6, IE7, Firefox 1.5, Firefox 2, Opera 9, Safari 3. It doesn’t matter how IE=8 renders in IE9 if you’ve used IE=edge.

    Other browsers won’t support the tag, and will use the latest rendering engine, end of story.

    As for discouraging the take-up of standards by Microsoft, cowboys, etc … you what?! Take up of standards has been limited to a core of ‘activists’ and a growing minority of professionals. But there are still a huge raft of websites and web designers who have no regard whatsoever for standards, despite the push having been going on for years. There are still myriad sites that scream “1997” at you that people can’t be bothered to update. We can’t slow these people down any further – they aren’t moving! If their site broke in IE8, they wouldn’t update the site, they would downgrade their browser, and that is in no-one’s interests.

    Much as it pains me to say this, I think the proposals by Microsoft really are the most effective way to ensure that IE will support web standards, but without breaking the internet in the process.

    Copy & paste the code below to embed this comment.
    • MS will do what they want
    • other UA manufacturers will dismiss it
    • IE will continue to loose market share
    • Customers will increasingly ask for standards based sites as they understand the implications of vendor specific data formats (here and elsewhere)


    Copy & paste the code below to embed this comment.
  • 1) Version targeting – That’s it, websites should cater to the browser and not the other way around.  Better for websites to become obsolete, than browsers.

    2) If I’ve designed a site and done the XHTML-strict thing, the chances are that it’s designed to work in standards-mode.  I haven’t added a strict DOCTYPE and validated by accident.

    3) I’ve had enough of IE.  Maybe it’d just be easier on IE if I just use a conditional to serve up a CSS-less page.

    <!—[if IE]>
      Send IE to a page it CAN understand (one without CSS)
    <!—[if IE]>

    Copy & paste the code below to embed this comment.
  • @Stephen Down:
    “The plumber who tinkers with the site his son knocked up for him in Frontpage Express wouldn’t know he had to make a change, and wouldn’t know how to do it even if he did.”

    If I ask my nephew to do the plumbing instead of a professional I should not be surprised that, when I want to change the tap, I have to replace the entire watersupply system because he welded everything together (not sure if I used the correct words, but I hope you get my point).

    Copy & paste the code below to embed this comment.
  • If IE 7 broke the web, well that has already happened, do not make the problem worse.  Why codify the mistake?  And I say this as someone who has inherited responsibility for a website with this very problem.

    Microsoft manufactured this problem, Microsoft should fix it.  Further, the correction should be an intermediate solution and not something that institutionalizes an author-level hack.  MS should release IE 7.1 and 8.0 that goes into standards mode only for valid (X)HTML (and not just because there happens to be a DOCTYPE.

    Copy & paste the code below to embed this comment.
  • I doubt that other browsers will touch this meta tag with a 100 foot pole, so fundamentally the situation will stay the same as it is today. IE will have to rely on cludgy hacks, and every other browser in existence will just work right. Some IE problems will be old and some will be new, but they’re still only going to be IE problems, which we can deal with.

    I’m certainly not happy, but it could have been much worse.

    Copy & paste the code below to embed this comment.
  • I just read this the other day.  I think this is one of the best such articles I’ve ever read.  Maybe they should write the “design principles” for IE8…  Actually, they’re writing them for all of us.

    Copy & paste the code below to embed this comment.
  • This is a necessary accomplishment if standards are to become an achievable goal.  From the perspective of a browser vendor standards are a fabulous goal that improve the quality of the product without cost to performance and not significant cost to development.  The problem is that a browser vendor must continue to support code that was supported by at least the two prior versions as best as possible to maintain market share of that browser.

    It would be ideal to always meet the demands of designers and developers, but designers and developers make up an insignificant minor of a browser’s user base.  This means there are three aspects to the problem: the browser vendor, the designer/developer, and the common user.  The common user does not know, understand, or care about web standards.  These are the people browser vendors have to cater to if they wish to increase or maintain market share.  Included in the group of commonly ignorant users we also find many business owners who reflect an important presence on the use and funding of development on the internet.

    Clearly, browser vendors find themselves stuck in the middle of a perpetual tug-of-war between the business owner segment and common users versus the designers and developers who are forced to fix the problems.  You cannot make everybody happy all the time.  You cannot achieve a goal of standards compliance without eliminating support for non-compliant code, but at the same time eliminating support for non-conforming code means things break and users leave for something that won’t break.

    A good example is Google.  Their code does not comply with any standard.  Do you have the balls to create and promote a browser that fails to load the most popular search engine?  One of two things would happen: 1) Google would repent for their sins and conform to the standard, or 2) everybody would simply stop using that browser and Google would do nothing.  Now instead of merely blaming Google, consider that extremely few major commercial websites are fully standards conforming, and so most of the internet would fail to display in a purely standards required browser.

    The extreme other-side is an outlet for standards compliant code must exist in a major browser or the standards will carry no practical value.  If a designer wishes to write code in the proper mime-type for adherence to XHTML 1.1 and no browser can properly process that code why would a designer waste time chasing a standard whose output is unusable?  This means strictly standards compliant code would never become a reality until the browser can support such and immediately fail when the standards are broken.

    A compromise must be met.  A bridge must be built to allow users to sloppy websites which fail to meet the standards and still an optional fully standards compliant mode must be built to encourage proper development.  This proposed meta tag is that bridge.  It allows developers time to get their content up to the standards while simultaneously allowing processing code that is fully standards compliant.

    This means a browser must offer a mode that allows no backwards compatibility or slack ware and breaks when the standards are broken.  At the same time that same browser must also offer another mode that continues to process older code.  The common users and business leaders must be gracefully weaned into standards compliancy while also encouraging designers to produce code that won’t break from being too standards compliant.

    Compromise is stupid and browser vendors should be forcing users into standards compliance without regard to legacy code.  This argument results in law suits against the browser vendor while destroying the credibility and value of the product.  Harsh transitions do not work in a market-economy, and idealist arguments are not business solutions where real budgets and real money determine to what degree a standard must be met without breaking existing architecture.

    Copy & paste the code below to embed this comment.
  • At what proportion of market share is it worth targeting and testing a specific browser? Don’t you think that the number of browsers and the number of platforms (mobile, set-top box etc.) that they run on is soon going to exceed the practicalities of this approach? A far better return on investment can be achieved by web site developers and browser developers working toward a common standard. I think this is ultimately inevitable.

    Copy & paste the code below to embed this comment.
  • @ austin cheney, et al.

    The graceful transition period has already been provided.

    Not only have site owners and developers had a Transitional DTD for the entire life cycle of HTML 4 and XHTML 1, but also have had now half a decade of Quirks Mode and Standards Mode and incentive for gaining experience in standards-compliant development through the existence of alternative web browsers with improving standards compliance and feature additions that push the boundaries of what can be done with a web page.

    Look, as much as you and others would like to believe the contrary should be the case in this instance, the fact is that in real-world business, the market does not grind to a halt, take you by the hand, and drag you into the future with it. Business online is no different.

    People have had the chance to catch up. They have had the practical incentive through lowering site development and maintenance costs. Now that they can no longer ignore the consequences of not keeping up, they want another chance. One, which, by evidence of their past actions, will not be seized. In a few years, they’ll want yet another chance.

    Well, sometimes, for as much as it pains the most magnanimous of us, we have to let the consequences teach the lesson. It’s Life 101.

    And for those of you looking for a few one-liners to that effect:

    • A missed boat has one less passenger.
    • If you don’t heed the starting pistol, you don’t cross the finish line.

    For those seeking a business analogy:

    If you want to make a deposit, you traditionally have bank hours within which to do it. If you show up after the bank closes, they won’t open the place up again to let you in—moan and wail all you want.

    In the modern age, you have to use the after-hours standard: make an ATM deposit. Now, just because you refuse adamantly to put your deposit into a machine does not mean the bank will open up again for you.

    The bottom line is that if you don’t use the ATM and something like an auto-withdraw bill (or, for the quaint, a check) bounces for lack of funds, that was your fault, not the fault of the bank. The bank gave you all day and an alternative after hours.

    The clincher:

    If your site breaks because you didn’t read the writing on the wall, it’s on you.

    The standards told you there was a transition. Transitions are, by definition, not a permanent state. Therefore, one cannot reasonably depend on a transition state to exist in perpetuity.

    The market alternative web browsers agreed that the future was indeed standards. Their market share is growing. That’s what is commonly referred to as a clue. Even IE is moving that way (in their own lumbering and awkward way).

    The professional web designers/developers told you the importance of using standards. If you didn’t listen, going for cheap, or stubbornly clinging to tradition amidst a torrent of undeniable change, we tried.

    You made your bed. The onus does not rest upon others to help you unmake it.

    If you write a web page in a coding language of your own devise and it does not render in web browsers, would you believe it to be the web browsers which must accommodate it?

    Yes? Here’s a shock, then: if it’s called a web browser, it is supposed to render a web page. There are established coding languages for the web. If you don’t use them, your page is not a web page.

    If you choose to write a page using a random collage of ill-structured markup with unknown styling rules, is that not concocting your own language? Why should web browsers tolerate it? Even if they do a relatively decent job of deciphering your concoction now, why should they be expected to continue to do so?

    If you code to specific bugs in a specific version of a specific web browser, why should other web browsers not see that as a concoction? Why should they render it to your intent when they do not share these bugs or non-standard features? I mean, your code amounts to gibberish for all the web browser knows. How could they know your intent?

    That is why we in the rest of the world have moved to standards. As with shared human language, there was needed a way to formally agree upon our expression of a given meaning. Web standards do this for its medium.

    Now you are effectively wanting a “do-over” because your English teacher called and said your grammar is indiscernible, you punctuate with unknown markings, and you make up every other word. No wonder you failed the test. When you refuse to follow the rules, that’s what it gets you.

    The onus is on you to make sense. It is your responsibility to make a web page for web browsers, not for web browsers to understand your non-web page.

    End of story.

    Copy & paste the code below to embed this comment.
  • Although my first read through the article I was shocked and appalled like most. But after reading “Eric Meyers”: article and getting a bit better understanding of the browser it doesn’t seem to bad. Yes it could stop some developers from getting into whats new and getting them stuck in the past. But I consider it far from sniffing. Even if you have a page thats locked for ie7, you would still be using your same old browser hacks etc for ie6 as not everyone is going to be using this new wonderful browser. Your really not hacking any more/less or doing anything with your “sniffing” results. This just prevents your site from breaking in something newer until you have the chance to upgrade a little. That would save allot of angry phone calls from clients who do manage to keep up with the newest browsers. And has no effect on the clients who are living with older browsers anyway. Maybe i’ve interpreted the new browsers abilities wrong, but currently it doesn’t look so bad in my eyes.

    Copy & paste the code below to embed this comment.
  • but you would be ignoring the fact that many developers never explicitly opted into “standards mode,”? or even knew that such a mode existed.

    I can’t believe this. If you call yourself a developer you should be firm enough to understand what web standards are what that doctype is for and why it is used. You cannot simply ignore the flood of blogs and news articles in the appropriate communities about this subject.

    If you sit down in a hole in the country and code away for 5 years and suddenly pop you head up there after and realize you’ve been ignorant to the evolution of your trade don’t think the solution to a problem, that was caused by your lack of interest, should be carried out on the back of browser memory footprints or faulty default assumptions for future browsers.

    Has the web now gone bonkers or what?

    Copy & paste the code below to embed this comment.
  • If there is no doctype or the doctype is less than html4, kick in quirks mode otherwise run standards. I’d venture to guess that most sites without a doctype or are less than html4 are desparately in need of re-design any how. I’ve come across many that haven’t been updated (including content) since 2004.

    Companies that have sites that are profitable are going to keep them up to date.

    Copy & paste the code below to embed this comment.
  • The response to my post completely missed the point.  The problem with standards is that they have no meaning if their intent is not understood, and they have no value if they are up for compromise.

    The first problem is that the standards are written as DTDs and not schemas.  This means pages written under defintion of the DTDs are rarely, if ever, validated.  If measures existed to require code validation prior to uploading to a webserver or downloading into a browser then the standards might be taken seriously.

    To make matters worse the TRANSITION doctype was an abuse of the standards despite its noble attempt to supply a bridge for those behind the times.  Standards are only taken seriously if they are enforced.  Bridges to conformance are allowed by providing a specified space of time for suppliers to meet the standards before a date of enforcement.  Bridges are not built by breaking the standards to allow definable sympathy for incompetence.

    During this whole routine designers have been continuously defeated.  Many designers want to be able to create documents according to the standards, but so far there is not a single standards compliant browser for Windows except possibly Opera 9.  I have already explained how this is not the fault of the browser vendors, but this was clearly ignored the reply to my post.

    Browsers have no form of version control.  This means browsers support code now exactly as they did in all prior versions.  This applies to every browser.  IE, for example supports code in IE7 that was designed for IE3.  Firefox 2 supports code written for Netscape.  Browser vendors do this because they have no guidance on how to adapt the standards, and because they fear lawsuits.  A browser vendor cannot adapt strict compliance to a standard if that compliance harms backwards compatibility.

    Browser vendors need guidance.  A standard must be enforceable and a date of enforcement must be set for browser vendors to comply.  That would be the ideal solution, but there is not any body capable of enforcing it.  Unfortunately, it is not such the browser vendors that demand enforcement, but it is the owners of non-compliant web content.  The problem with browser vendors is that they need a solution.

    What is the standard?  The idea is to be moving from a faulty SGML markup to a XML architecture.  The standard must be XHTML 1.1 Strict with the appropriate mime-type.  The various SGML forms of HTML standards should be considered slack modes for use and limiting by browser version control.  If standards compliance is as important as designers claim then standards must be strict and forward.  We cannot pretend to be serious about standards compliance if we do not understand what the standards are.

    If these steps are not taken there will never be a standard.  Browser vendors can do more to enforce the standard than any other group, but first they must do what is necessary to fully support the standard.  IE8, through its few proposed changes, is absolutely necessary to push the web into standards compliance.

    The technological solution for browser vendors is three-fold.

    • Browser vendors must implement an optional standards mode that fails on non-compliant pages.  This will allow designers to create future compatible content.
    • Browser vendors must implement a version control system to warn web content owners that the browser will significantly limit backwards compatibility in its next version.  Fair warning is all that is required of browser vendors to keep from being sued for ending support to outdated processing schemes.
    • Browser vendors must make public what a browser version will no longer support and what new features it will support 9-18 months in advance to allow the market to prepare for those changes.

    Copy & paste the code below to embed this comment.
  • Why must site developers and non-IE browser developers pay for Microsoft’s mistakes? 

    Are Mozilla and IE going to implement this identically in the years to come? I suspect not – even if Microsoft say they will.

    The world is complicated (and hacky) enough; standards were invented for a reason and it seems that just because they don’t evolve as quickly as browsers, that they are no longer relevant.

    Copy & paste the code below to embed this comment.
  • The browser wars may be back if this proposal goes ahead. If so, do battle with words. Let Microsoft know we are NOT happy with this idea, which may well stagnate large parts of the web, locked into IE-only sites designed for out-of-date browser versions.

    I’ve made a range of “t-shirt designs”: suitable for the oncoming battle. Let’s all join forces and combat this growing threat. Don’t let Microsoft control the web and hold back standards!

    Copy & paste the code below to embed this comment.
  • In a word… terrible.

    This is an absolutely ridiculous idea. I work on a wide range of sites for an advertising agency and even in 2008 it’s still a daily struggle to deal to migrate pages out of quirks mode and into standards mode. Let alone dealing with a new meta tag just for IE8’s benefit.

    This only goes to show how out of touch some CSS developers are with the real world of web design.

    Copy & paste the code below to embed this comment.
  • I’m afraid I agree with the majority on this one, DOCTYPE was bad enough but another tag is a step in the wrong direction.  Why not go the other way?  Make IE8 standards compliant ‘out of the box’ and add a meta tag to dial down the compliance for those who aren’t bothered about compliance for their sites or who find they missed something when they developed the site and need a ‘quick fix’ to keep it running.

    It should be up to IE to follow the standards not to do the usual Microsoft route of forcing everyone else to follow their version of the rules.  For years we’ve been dancing around cobbling together workarounds to help IE because our sites were ‘broken’ when we ‘stupidly’ followed the W3C standards and used Firefox opera or Safari to preview our sites during development.

    Copy & paste the code below to embed this comment.
  • My professional carrer has been entirely in mobile since 2003, and the browser wars have been kind of non stop there.

    Fortunately an increasing number of smart phone browser are based on webkit, javascriptcore, etc. so I’m hoping we call make rich client applications against at least a similar standard now.

    Copy & paste the code below to embed this comment.
  • After having read 23 pages, I can finally reply.
    Side note: @Emil Konow: In the article example OtherUA, in OtherUA=4 is a metasyntactic variable. It could have been written foobar=4.

    Firstly: Don’t be fooled. non-IE browsers don’t have to, and won’t support this thing. Microsoft tries to make this look like a standard proposal, but it isn’t. This meta is informational. Most browsers will ignore it. I don’t even expect that IE will support IE6 quirks mode forever. In ten years, it may remove the support for it.
    Secondly: The fact that authors who wrote buggy code that breaks in IE8 are evil/faulty/daemons doesn’t change the fact that Microsoft wants users to use IE8. If IE8 doesn’t display the horrendous pages, then, people won’t upgrade to IE8, Microsoft will loose money, and people will continue using the IE7. This is bad for Microsoft. This is bad for the Web. This is bad for everybody.
    (That’s not exactly true: but the issue exists and mustn’t be ignored. I deal with it below.)

    In practice, the ONLY thing that most Web developers, or code generation tool authors will bother with, is to put IE 8 in the most standards-conforming mode as they can.

    Web developers, WYSYWIG tools & other tools, in practice will specify, depending of their opinion, religion and mood one of the following meta:

    <meta http-equiv=“X-UA-Compatible” c> <!—the simpliest
    way to switch IE-8 standards mode—>
    <meta http-equiv=“X-UA-Compatible” c>
    <meta http-equiv=“X-UA-Compatible”
    c> <!—developer who dumps every browser he has tested; This will be minority, and even if it were a majority, it would be far from 100%—>
    <meta http-equiv=“X-UA-Compatible” c>
    <meta http-equiv=“X-UA-Compatible” c> <!—developer who assume that IE-8 and IE-9 will have a similar rendering engine but IE-10 & upper may be revolutions without backwards compatibility—>
    <meta http-equiv=“X-UA-Compatible” c> <!—big number; developer who fear that IE won’t respect the IE=edge idea—>

    But, I lived long enough to know that people don’t write computer code thing for what it’s supposed to mean, but for what it DOES. In particular, it’s obvious that people who’ll use IE=edge declare it for what it’s supposed to DO (i.e. trigger the latest IE rendering mode), and not what it means, because it means: “This page is correctly rendered by the new-new-new mode of IE100000; I tested it!”.
    So, exactly like the DOCTYPE, authoring tools: WYSYWIG editors, Weblogs tools, non-professional Web servers, professional Web servers with default configurations, and everything that’s not 100% manually handled by a single human person and a good part of code 100% manually handled by a single human person, will randomly set one of them.

    Many people will test these pages in IE7 or IE6 and not in IE8, and the exact same problem than with DOCTYPE will appear. That’s for the transition phase.

    Assuming that IE8 new standards mode won’t be perfect, when a next version of IE, with major changes, is released, Microsoft will want it to be compatible with all the sites that relied on IE-8 standards-mode quirks. So, Microsoft will treat IE=edge IE=9 IE=37 equally, knowing that, there will be the same number of IE=edge pages that don’t work with the new-new-mode than IE=8 pages!
    In other words, IE9 may display all these pages in IE8 mode, and create a new mode triggered by a <meta http-equiv=“X-Some-New-String-Unlikely-To-Collide-With-Anything” c>.

    Maybe Microsoft tries to specify some semantic to the X-UA-Compatible, but only one RELIABLE meaning is usable: Pages who use IE=edge, IE=8 or IE=37, all triggered the new standards mode. Nothing more can be reliably said.

    This META is fundamentally the same as DOCTYPE sniffing.
    It’s just MUCH uglier, and so may not be adopted as easily: Standards-lovers used DOCTYPE because it’s textually required by the HTML 4 standard (the compatibility of this statement with ISO-8879 is another matter). These Web developers, among other things, tried to work around IE bugs, but without saying it too loud. They mayn’t accept to explicitly put a META saying: “This site is designed to be displayed in IE”, even if that’s true (which doesn’t imply that it isn’t designed to be displayed in non-IE browsers).

    DOCTYPE sniffing, in my opinion, did the job that it was supposed to do relatively well:
    1) Keep legacy crap code working, which was the wanted effect. This META will do it too.
    2) Promoting legacy crap code, which was expected but not wanted. This META will do it too.
    3) Creating issues with authoring tools (and ignorant authors) “lying” on their mode (i.e. pages that were only tested in IE5 but had a “strict” DOCTYPE), which was an unexpected effect. This META will do it too. We can hope that this will only happen during the “transition” phase between IE7 and IE8. But this transition phase (phase during which there’re a significant part of users still using the old browser) may be extremely long (several years), as the transition from IE6 to IE7 isn’t even ended!

    Is it a good idea to use this hack again?
    It’s clear that, keeping backwards compatibility with crap code is one of the main problem of IE and I think a day, IE will have to drop it. It’ll hurt. The transition will be painful. But, it’ll be much more painful if it’s done in ten years than if it’s done today. And, it would much more painful today than it could have been ten years back: Because the Web grows exponentially. Because Microsoft creates more & more legacy code with its “don’t break crap code” principles. Because the number of different engines to interpret legacy code grows. Because security issues stack (assuming IE8 will now have a “JavaScript quirks binding”). Because the IE6 mode of IE8 may not be 100% compatible with IE6. Because it’s better to operate tumors early.
    One could argue that IE won’t have to support more than 1 quirk mode at a given time: Just to keep it compatible with the previous version, and so, slowly code will move to standards.
    But that’s false: IE8 will have 2 quirks mode, and so, I expect IE9 to have at least 2 quirks mode, but it may very well have 3 quirks mode (IE8, IE7 and IE5/legacy).
    If IE8 stops supporting legacy, people may not upgrade to IE8, but
    (1) we can hope that people will use alternative browsers
    (2) or use IE8 on new Windows-based computers where it’s installed by default (choice of the ignorant).

    Unfortunately, Microsoft isn’t stupid, and is far too afraid of scenario #1 to drop compatibility with legacy. I’m not sure that this strategy is good for anybody (including Microsoft) on the long run. But I highly doubt they think on the long run.
    Microsoft won’t release a standards-only browser.
    What do we have to propose as a better solution than this hack?
    In the comments, I’ve seen:
    1] Use standards-conforming mode by default; Provide a META to put IE in quirks mode, so that webmasters can quickly update their broken sites to use the quirks-mode meta.
    Unfortunately, a large part of the Web isn’t actively maintained or not maintained at all.
    At least in a first time, when IE8 is released, it’ll break many sites. Users will get a bad first experience and won’t upgrade. I don’t think that any kind of big “update your crappy site to use the quirks-mode meta” warning, a few month before IE8 is released, will have any effect. Most webmasters don’t read “A list apart”.
    2] Providing a date when the website was known to render correctly across all browsers.

    <meta http-equiv=“X-UA-Compatible” c />

    And you expect every webmaster to
    1) Test their pages everywhere.
    2) Edit them to add the date.
    That’s a complex development cycle.
    Except a few “A list apart” addicts, I don’t think many will do.

    I doubt that authoring tools will make that easy.
    I rather think that authoring tools will treat the date as the META/DOCTYPE: Just a piece of code to trigger standards-mode that they’ll put at the top of every page.
    Depending on the tool, a fixed date may be stored forever. Some tools may also try to trick the system… Web servers may send the page generation date as “last update date”.

    3] Reliably testing which pages are conforming to standards by checking their syntaxic validity.
    It breaks progressive rendering.
    Using a central database containing the list of “valid” URI isn’t acceptable.
    It would multiply by TWO the time to connect to a site (One TCP connection to the database + one connection to the site).
    It’ll give incredible power to the central database server which will know every movement of everybody on earth.
    This is contrary to the open non-propreitary nature of the Web. We must surf the web without spyware. Yes, this IS a spyware.
    Moreover, it won’t work properly: People who update their sites to conform to standards will have to wait before their site is interpreted correctly. Maybe a few days… The time a robot find their site again… Do you think big companies will accept to get a broken site for a few days for “maintenance” matters?.
    There’re other issues with dynamic pages, or pages for which people have to log in, since they’re not always available to robots.
    Assuming we can drop progressive rendering, it shares a flaw with XHTML:
    It’s too easy to write a broken site. Only very few webmasters will provide flawless pages. This is especially difficult for dynamic pages whose content depends on user feedback such as forums.
    This isn’t impossible, but this means that most webmasters will fail to provide perfection, and prefer to design their sites for quirks mode in the first place.
    @Derek Ahmedzai: It looks like you failed:
    It also means that, many sites may look perfectly good one day, and the next day, because of a tiny modification which induces a bug, it’ll become completely broken.
    Eventually, valid pages may be rendered improperly in standard-conforming CSS mode, and look good in CSS quirks mode… The CSS quirks vs standard CSS isn’t all about validity of the code, but about buggy vs non-buggy interpretation of the same valid code by the browser!

    4] The idea of cultural epochs:
    This has the same issues than X-UA-Compatible: Just another piece of code to trigger standards mode.
    It’s a bit hypocrite because IE6-specific code isn’t bound to a culture: It cannot be described by a coding style or a set of standards: It can only be described by “a magma of tags that displays correctly in IE6 but may or may not display correctly anywhere else”. This isn’t a culture. Since IE6 is such a complex beast, no specification of it can be done without an incredibely complex reverse-engineering. That’s not as if it were possible to develop IE6 code without an IE6 session under the hand.
    The issue isn’t cultural. It isn’t the table layout vs CSS layout debate. It’s about the bugs and quirks of IE6 engine.
    If the issue was cultural, we wouldn’t need more than one rendering mode. Standards-based browser can perfectly display code from any “culture”.

    5] A big button in the UI to switch from standards to quirks mode.
    (See comment #167 posted by Thom McCann)
    That’s an idea I like.
    But, noobs mayn’t like it. Microsoft tries to avoid to expose details to users. Most noobs just expect IE to work in the first place. They mayn’t understand what this icon is supposed to do and bang it like monkeys. Or they may never notice it.
    I admit I’m pessimistic and I gave no evidence of my statements.
    That’s worth a try. A group of noobs beta testers should see if they can adapt to this system smoothly.

    6] DOCTYPE sniffing with the HTML5 declaration: <!DOCTYPE html>
    This shares the usual issues of DOCTYPE sniffing.
    This looks quite good, unlike X-UA-Compatible.
    But: It relies on drafts. HTML5 isn’t a released standard. I like it by some facts, and dislikes it by other facts (breaking the HTTP, MIME and ISO-8859 standards).
    I don’t want to develop HTML5 code. I want to write stable, mature HTML 4.01 code.

    Combining [1] with [5] could be interesting.

    Copy & paste the code below to embed this comment.
  • I feel this is worst for a Company, that will remain nameless in this comment, that had bought out other companies with already antiquated systems. Thus, with the release of IE7 and soon IE8 it makes it harder and harder for internal associates to use these Company WebApps at Home, making telecommuting harder and harder as well. What a Pain!

    Copy & paste the code below to embed this comment.
  • Microsoft intend that developers star again in make our code optimised to one browser, like the pass.

    How could u talk about web standards and accessibility when u target your site to a browser. Do u really agreed with that.

    That was not the way that we want to the web, i dont care what browser my users use, i just want that my user see the site, and the only way is follow the specs and hope that all browser vendors follow and work for the specs.

    When a read it, i thought it’s some kind of switch for doctype, but is not, what they intent to do is to grab the users again and dont care what consequences that will bring.

    I never thought to ear that kind of things from a person who says that cares about standards and accessibility.

    Copy & paste the code below to embed this comment.
  • What happens if we’ve used conditional comments to target everything below IE 8 (<!—[if lte IE 7]—>), [incorrectly] assuming that IE will actually support standards by version 8?

    If we don’t insert the <meta> tag, will it default to IE 7’s rendering, AND ignore the conditional comments for IE 7 (thus breaking the layout?)

    Copy & paste the code below to embed this comment.
  • disclaimer: not a web developer, but an avid follower of Microsoft antics.

    Microsoft’s big problem with legacy code, as others have pointed out, is more in intranet and in IE rendered help files etc included in their (and others) apps.  So even if all the bad code on the internet would go away, MS would still have a problem (admittedly of their own making) to deal with.
    So some form of meta-tagging, and some form of legacy rendering engines included in future versions of IE seems bound to happen.
    And that would be fine, except for the default to earlier versions and require explicit IE-8 acceptance becomes somewhat of a major problem for MS if everyone doesn’t follow along (and my guess based on what’s been said here and elsewhere, that’s simply not going to happen).
    Here’s where my lack of web development savvy shows through, but if a website, written to standards and including code that is rendered well by standards based browsers but not earlier versions of IE doesn’t include the meta tag, what happens?  If I’m getting this right, FireFox et al would render the site correctly, but IE would not.
    Isn’t this, then, just a wide open door for website developers, rather than including the meta tag, to include instead a “Get Firefox” icon and a message: “This site renders well in everything but IE”?

    Copy & paste the code below to embed this comment.
  • What’s wrong with having standards compliance mode enabled as default. You say switching it on is so simple. The same could be said about switching to quirks mode.

    When developers open their page in a standards compliant IE8 and realise they haven’t been doing their job properly, they could choose to fix their problems, or simply carry on not doing their jobs properly by simply adding that meta tag. But at least, it will give them a breif shock which could be enough to bring them into standards compliance.

    “Internet Explorer 8: taking quirks and hacks into the future”:

    Copy & paste the code below to embed this comment.
  • What’s wrong with having standards compliance mode enabled as default. You say switching it on is so simple. The same could be said about switching to quirks mode.

    When developers open their page in a standards compliant IE8 and realise they haven’t been doing their job properly, they could choose to fix their problems, or simply carry on not doing their jobs properly by simply adding that meta tag. But at least, it will give them a breif shock which could be enough to bring them into standards compliance.

    “Internet Explorer 8: taking quirks and hacks into the future”:

    Copy & paste the code below to embed this comment.
  • What’s wrong with having standards compliance mode enabled as default. You say switching it on is so simple. The same could be said about switching to quirks mode.

    When developers open their page in a standards compliant IE8 and realise they haven’t been doing their job properly, they could choose to fix their problems, or simply carry on not doing their jobs properly by simply adding that meta tag. But at least, it will give them a breif shock which could be enough to bring them into standards compliance.

    “Internet Explorer 8: taking quirks and hacks into the future”:

    Copy & paste the code below to embed this comment.
  • I have to say that after reading approximately 6000 comments on this subject on multiple blogs I have seen at least 99.9% objection to this proposal; and I also object (and commend the objectors for doing so).

    I’ll also say that there has been one shinning light for the objecting team in this debate and that is Ray McCord. Every statement he has made is valid, every statement he has made is the essence of what the standards movement is all about, and I for one support his statements to the letter.

    Ray, I salute you, please keep voicing you opinion, it means so much to so many.

    Seriously, anyone who has digested this debate in detail (since it was announced) can see that the argument against this proposal is more valid than the argument for it. If you are for this pathetic proposal than you can no longer claim to be an advocate of web standards, OR an advocate of the *open web*. The facts here are simple, the facts here are not hard to digest at all, this is nothing more than Microsoft playing the gatekeeper, and their key resides in a new non standard masked by a meta tag.

    If you think this pathetic proposal sounds reasonable than you a sorely mistaken, why? Because this meta tag will be abused in every way you can (and can’t) imagine, but not just by web developers who couldn’t care less, by people who want to exploit weaknesses, by people who simply don’t know better, BUT worst of all by the very people who made it a reality. If you need any proof of that statement you need only look at the web of the past, not to mention every piece of closed software ever written, if there is a way, there is a will and this key provides too many cretins with a way!

    I for one refuse for one second to believe that Microsoft mean well by forcing this new aid (AKA: key to the gate of the closed web) on the emerging web. They mean only to bolster their position as the number 1 market shareholder by stifling the ability for the web to mature at the rate expected by users, developers and businesses. By all means I will support Microsoft if just for once they will support us (the developers), the very people who for 6 years (minimum) have helped them save face by manipulating their malformed/retarded browsers to allow the very people who give them the market share (that they still enjoy to this day) an enjoyable experience on the open web.

    We did not break the web, yet to this day we a forced by one corporation to do their dirty work, enough is enough, we have covered their arse for too long, this key they are offering is hollow and we all know it, even those that assert blind support for this proposal know it in their heart to be nothing more than an empty promise, one we have endured long enough.

    Microsoft: it’s high time you started to give us some slack, we have backed you up for too long, we have given you enough chances to make things right, and we are simply tired of carrying you any longer. For once in you feeble life…


    Just to be sure I’m not taken out of context here, I personally believe the IE dev team are truly trying to correct the mistakes of the past and for that they have my deepest respect. However it is my opinion that the Microsoft “big wigs/marketing engine” are pulling the strings, and for that I truly am discouraged, it is my humble opinion that the web of today/the future is no place for money grabbing so and so’s; Unless they are willing to truly embrace it.

    No… Adding a meta tag is not embracing the future, but for the sake of the MS business brains that don’t understand why, it’s simple… When the market doesn’t require you to improve you will simply leave us in the stone age once again, and this will never change until you truly understand the needs of your supporters and consumers. I really do hope that message sinks in (though I seriously doubt it).

    My greatest respect to all those in opposition to this proposal, may our voice be heard (even by our own peers who for the most part seem to have turned their backs on us).

    And to those who have simply adopted this as progress, may you see the error of your ways. Zeldman, Gustafson et al, I sincerely hope you wake up out of the dream world you have entered, your light is fading and that truly is a very sad proposition for the future of “our” open web.


    Copy & paste the code below to embed this comment.
  • @ Kip Kniskern: If I’m getting this right, FireFox et al would render the site correctly, but IE would not. Isn’t this, then, just a wide open door for website developers, rather than including the meta tag, to include instead a “Get Firefox”? icon and a message: “This site renders well in everything but IE”??

    Believe me Kip, there are many who would walk this path in one second, but you have to remember that most of us are “by definition” professionals, meaning we serve others, and as such the market share pretty much dictates what we can and can’t do (i.e. clients don’t like telling people to go away and come back later with a new browser).

    Therefore MS has us over a barrel unless there is an industry wide movement against it, which is not really feasible considering at least 50% of developers out there don’t care about standards because they don’t have to (they just code for IE… hence our dilemma).


    Copy & paste the code below to embed this comment.
  • I have just re-read some of the comments here and read more blog responses elsewhere, I hope my first comment didn’t discount anyone, I am very aware that there are a lot of people (other than Ray) who are very passionate about this issue while maintaining a solid understanding of the underlying factors in play here.

    I just want you all to know that I am also passionately supporting the opposition to this idea and singling out one particular voice was not particularly ideal on my part, I do apologise. Please keep standing your ground on this subject, don’t let this become a stagnate “blog topic of the moment”. This is the most important issue the web standards movement has “ever” faced and it should not be left to pass without logical opposition.


    Copy & paste the code below to embed this comment.
  • This proposal seems to be saying that Microsoft will guarantee to web developers to retain backwards compatibility in their browser engine, as they release new versions. If a developer wants to “lock” their IE hacks to a specific version and not develop new ones as soon as each update is released then they can use this tag to ensure that all users receive a predictable experience. Other browser developers could take the same approach if they wished. The web developer then has time to explore what new hacks they need for the latest browser and release them when fully tested.

    We are in this position because browser developers have differed in their interpretation of standards, even from version to version of their own code. (Microsoft perhaps more than others.) That legacy of different interpretations will be with us for some time to come – and perhaps always. It is a pipe dream to assume that all browsers will implement all standards in exactly the same way and that all users will upgrade in step as soon as a new standard is released.

    I doubt that – even on a corporate intranet – anyone would lock their code to IE.7 and simply leave it there. At some point, even Microsoft will have to drop support for old rendering models, otherwise their browser code will be so bloated it will be bigger than the operating system.

    Copy & paste the code below to embed this comment.
  • PS – I would hope that users of IE.8 and above can choose, themselves, to have their browser ignore the new X-UA meta tag and always try to interpret a site in standards-optimum mode. Perhaps Microsoft can offer a toolbar button that toggles quickly between these modes. Given this, I think most users would opt for standards-optimum as their default and only toggle “down” if a site did not render well.

    Copy & paste the code below to embed this comment.
  • We should not be giving, meaning the web developers community should not be giving, browser vendors the chance to screw things up carlessly in the future. What’s the point of standards otherwise? What they have to do now is do their best to support the latest standards, and then NOT break appart with them in future versions of their browsers. That is the way to make sure that our standards compliant sites will still look appropriattely in the future. And no other meassure, policy or complexity should be forced uppon us.

    Now, having said that, it’s fine to give developers – that built sites targeting browsers that were not standards compliant – the opportunity to place an easy but temporary fix so that their work doesn’t look al messed up while they work on a permanent fix.

    That’s how I find the new meta tag could be usefull.

    If the practice ever got widespread as the article proposes, we’d end up with bloated instalation files, getting bigger every time a new broser version comes along, because the file has to contain all the legacy rendeing engines.

    Now there is only one vendor, Microsoft, that needs to pack only the most critical rendering engines those of IE5, IE6 and IE7. Start supporting standards appropriately with IE8 and forget about it from then on.

    For us developpers, the meta tag should be absolutely optional, so that we can take full advantage of progressive enhancement.

    Copy & paste the code below to embed this comment.
  • If one doesn’t want to use the meta-tag, fine, don’t use it. If the desired result of a new version being released that renders differently than previous releases being the breaking of a site, so be it, just don’t use the meta-tag.  See that a page is now broken fix it, move on.

    No one is forcing anyone to use the tag and those not using the tag will receive the same result as they always have.

    Personally, though, I’ll “fix” my sites so that IE-8 doesn’t puke on them, which I already know it does, the same way that I had to “hack” IE-6 and IE-7 to behave, using Conditional Comments.

    As for browsers potentially end up becoming bloat-ware, it will likely only ever be IE that ends up bloated because no other browser, that I know of, has so many different views of the same standard that IE has.


    Copy & paste the code below to embed this comment.
  • Let’s kill Internet Explorer.

    This is a proposal to all sane web-developers out there, who are not willing to cope with the nonsense Microsoft is imposing on us.

    We have control, why don’t we use it for the sake of good?

    Let’s implement one last browser-specific IE-related hack on ALL OF OUR PAGES – let’s break the IE compatibility.

    It’s obvious to me now, that the so called end-users do not have responsibility to alter the web. We were preaching about abandoning IE for years now with no (Opera) or moderate (Firefox) success. Average Joe couldn’t care less for web standarts. And it’s not his responsibility to care about them either. But make no mistake – he WILL benefit. I don’t have to spell why for you. If you’re reading this text, you allready know why.

    Internet Explorer is on life support now. And it’s us who were keeping it alive all this time. It draws our blood. Time to pull the plug

    Imagine this picture: all the pages all over the internet refuse to accept a user agent known as Internet Explorer. It’ll be painful yes, but think about it for a moment. A cleansing is required to break that cursed circle. W3C introduced DOCTYPE to handle quirks/standarts, yet IE broke it. That was an act of good will form our side, they just spited in our faces in return. Now they’re planning on imposing even more diversity by using the IE-specific meta-tag, which LOCKS your site to a specific browser version. Enough is Enough

    Think about all those hours (and days!) you spent hacking your 100% standart-complaint pages, making them WORSE, inserting bloated code, unnecessary Javascript and what not. Just take a moment and think about them. That situation was never normal, and it’s not going to be any better. Unless we do something

    The most popular argument for IE support goes like this: It has the most market share, therefore not supporting it is stupid. That is true of course, so why aren’t we doing anything to change it? People at Mozilla can spend only so much money in their firefox ad-campaigns, it will never work to the full extent. Something should motivate a user to upgrade. I say, the ‘day-internet-stood-still’ will motivate them! And yes, I think that will only take a day. In a 24-hour period everyone will get himself a brand new browser

    Personally, from this day on, I’m not going to support IE in any of my web projects. If my employer disagrees, I quit. Some things are more important then money. We’re talking about Freedom here. Sometimes you have to make a sacrifice for a greater cause.
    But if we all do that in one day (that will require some organization among the web developers, but isn’t that what internet is all about? Can’t we put a countdown/sign up site/blog somewhere to manage it?).. If we all do that in one day, on a set date, then it won’t even be a sacrifice. It’s funny if you think about it. We had that option for YEARS, but for some reason we were bending over for Microsoft downgrading our own code. But I feel a change. I feel the web is more united then ever. I feel that we do have a common agenda, a common reason, a common goal. We totally can do it !

    Have you ever saw “This page only works with Internet Explorer” banner, basicly denying your standart-compatible browser an access to the content. Well, how about we do the reverse? How about “This page works with everything other then Internet Explorer” banner?

    Yes, IE-hacking became a skill of it’s own (sadly) and many of us are even proud of how they can abuse IE to behave like it had to in the first place. But a job of web developer was never to cope with the ridiculous bugs in Microsoft software. It’s not just one bug, the whole browser is broken.
    It’s time to end this nonsense.

    vital (dot) driedfruit (at) is my email.

    • Spread the word.—not among users, but among fellow web developers!
    • Set a date.—for maximized effect
    • Gain support.—find out if we’re really taking the web back or just loosing our jobs.
    • Do your part.—you control the web sites, you know what to do.

    It’ll be a lot like a revolution, but with some MAJOR differences:

    • When plotting a real revolution you can’t set a date and ask for signatures. You can’t even be sure there’s a following. Well, we’re on internet, we CAN be sure.
    • No guns or fighting required. No chance of being killed.
    • We will definitely win. After the switch from IE is done, there’s no going back.

    See Also
    “What’s wrong with IE”:

    Copy & paste the code below to embed this comment.
  • Well, I downloaded IE8 beta 1 and gave it a whirl; waddaya know – they’ve broken the web (what a surprise – not!).

    So they back-tracked on the default behaviour – to many developers’ delight (not mine) – so it renders in IE8’s version of the standards. But wait – it’s WORSE than that; it also takes account of our IE hacks – so it’s trying to render using IE8 standards mode AND apply the IE7 hacks. NOOOOOOOO!

    Here’s what it does on my site (this is an abbreviated list!):

    • barfs on my inline tabbed lists
    • barfs on my rounded corners
    • my ‘skip to content’ link no longer works
    • randomly shows / hides some on my list bullets

    I particularly like the bug that causes the page to jump to top when using the scroll-wheel on my mouse! This happens if the pointer dares to pass over a link. (Of course, I accept that this is only a beta, but please…)

    The ‘good’ news? There’s a nice little button to the right of the tabs entitled ‘Emulate IE7’. When I click it I’m informed that I need to restart IE – but it doesn’t make it clear that I have to do that manually (I’d expected it to do that for me). Once restarted my site appears in all it’s glory – yay, no more broken web :-)

    Oh, but hang-on. I’m now using IE7…

    Question: If I now put the X-UA tag on my site, will it override the user’s choice to use IE7 emulation?…

    Copy & paste the code below to embed this comment.
  • It appears that the author has forgotten the purpose of web standards altogether.

    Standards specify how user agents should interpret a document. This allows us to create websites knowing that they will be rendered consistently among browsers. As new standards are completed and adopted (CSS 3, for example), we gain better design tools.

    But there is another, crucial element to web standards: compliant browsers must support old standards. Five years from now, when we’re all (perhaps) writing HTML 6, the latest browsers will still be required to support HTML 4.01. An old website written in HTML 4.01 will not break in a new browser.

    Although no browser is 100% faithful to the standards, their failings are so slight as to be unimportant. All except one: Internet Explorer. “Breaking the web” is not an issue for any browser except IE. If IE rendered web pages as accurately as Firefox, this article would never have existed.

    I am delighted to hear that IE is reinventing itself as a standards-compliant browser. If Microsoft insist on an extra <meta> tag to ease their conscience, so be it. Compared to the hacks I need for IE6, a single <meta> tag is nothing.

    But this approach must not spread. It is seductive and dangerous. If we require new browsers to include rendering code from all previous versions, then we will cripple browser development. Microsoft would love this: force its competitors to be lumbered with a bloated, legacy rendering engine like Trident; prevent them from ever cleaning out their codebases. Ha! That’ll slow down those pesky open-source kids.

    Let us not disinter browser sniffing. Long now has it rotted, its unwholesome charnel stench sealed beneath the ground. Leave it there undisturbed; visit its grave only to remember the misery that once was ours when it walked the earth in horror.

    But if we resurrect this monster, it will rampage beyond our control. We must not sell our inheritance for a Microsoft boon.

    Copy & paste the code below to embed this comment.
  • Hello Aaron and all of you, people of reason and haters alike.

    First, let me just say that this X-UA meta tag is really a great thing. Also, the new IE is the hell of a great software, the functions of Opera with the aesthetics and ergonomy of IE. it’s really too bad that Microsoft has backed down on the issue of what will be the default behavior when the meta tag is not there. DTDs are fine, but obviously they’re not enough. Add to that, people on the web are shouting as if continued support of old documents was not something to achieve. I wonder what’s going to happen when the silent majority realizes that their favorite websites are broken. I really hope people are going to be computer-fluent enough to click the “Emulate IE7” button.

    Of course, people are saying, “if these sites had been coded according to standards, they wouldn’t be broken.” This is just plain wrong, as your article shows as I’ve noticed many times myself. Two compliant pages do not always display the same on two compliant browsers; in fact, it happens more often than not that empirical corrections or script hacks have to be applied by the designer. This is what elementary observation shows. I wonder how these people, often much more experienced than me in the area of web design, simply fail to see the reality that’s located right in front of their eyes.

    This being said, I have questions, and I thought here was the best place to ask for them.

    What happens to the DTD when the X-UA meta tag is used? I would say that if you require either the IE7 or IE8 rendering engine, the DTD is indeed still accounted for by IE8 (the software). Please correct me if I’m wrong.

    But, I’ve noticed some weirdness related to this question with IE6. As a test, I have used the meta tag to request some IE6 rendering on my site. A few weeks ago, my work computer was still under IE6 and my site displayed (not entirely) correctly with this computer. On the other hand, it does not display correctly under IE5, in part because IE5 includes padding within an element’s height and width, which of course is not standard. I hope to correct this anytime soon.

    As I understand (hope I’m not wrong), on this width-padding issue IE6 behaves as IE5 if there is no DTD, and behaves in another, more compliant way if there is a DTD.

    Now, my site has a DTD, but the rendering obtained by requesting IE6 rendering with the X-UA meta tag is the same as IE5 rendering. I don’t understand this. Can someone explain?

    P-S: it’s funny to see that people are actually too busy shouting to even bother trying the beta1. I see very little discussion stemming on the “Emulate IE7” button

    Si Lin: I agree with you overall. And, I’ve also witnessed strange behaviors with lists, maybe not exactly the same as you. Not sure bu I was thinking, maybe my issues are related to my lists having a negative text-indent. Also, I have italic text which is cut at the end of lines. I really hope this is just a bug and not the new standards-compliant way…

    Question: If I now put the X-UA tag on my site, will it override the user’s choice to use IE7 emulation?…

    Answer: yes! Tested by me.

    Now it would have been really funny if MS had prioritized the other way around. Those haters would have regretted all their shouting for IE7 rendering being left as opt-out.

    Copy & paste the code below to embed this comment.
  • Sorry about the little mistake. I meant:

    “being left as opt-in”

    at the end of my previous comment just above. Of course you had gotten it. Sorry again people. Now it’s corrected.

    Copy & paste the code below to embed this comment.
  • At some point there must be a line drawn. The whole point of standards are to provide a common correct way to develop something, and in this case, a website. Browsers should follow this, and update accordingly with the updates of the most recent public standards release. This means having support for all the current standards, then a web browser should be able to differentiate which standard to follow by a DOCTYPE of sorts (some way of identifying the standards that the web page was chosen to follow in).

    Ultimately, this is how a browser’s architecture should be based on, not on the version that its at. Getting past this road block is the first step in creating a more complete and seamless web.

    Suggestions should be made to the browser developers to follow standards, once all browsers are capable of following any of the standards created, the web should begin to return back to a normal state. That way, browsers and designers/developers wouldn’t need to follow versions, but follow standards, which is what they should be doing in the first place.

    Version locking is an easy fix to a problem that has been going on too long. Truth be told, there is no easy fix to fix this, so we all must work on overcoming this bump in the road. Complaints and whining are not what make a good company persevere, they for one should know that.

    Copy & paste the code below to embed this comment.
  • Here is a precis of my objection to this article:

    After all, we shouldn’t make assumptions about how browsers will behave in the future.

    Yes, we should. That is what standards do!

    A standard defines, for all eternity, how compliant browsers should behave. Of course, we can also introduce new standards; but the old ones are set in stone.

    Copy & paste the code below to embed this comment.
  • of course we shouldnt try to second guess how browsers would function in the future but it is recognized that a cmmon / mutual method would be beneficial to the community as a whole

    Copy & paste the code below to embed this comment.
  • I—like many designers in a structured development environment—have been struggling to find the best “cross section” of standards for our developers to follow that both render consistently for the targeted audience, yet allow for the practicalities and compromises (validation exceptions and such) that must be made for code implementation. Choosing a doctype with some conditional css goes so far, but a meta tag might allow for further refinement for display consistency and build in more forward-compatability. But I have to agree with those above concerned for where that may take us as the browsers progress.

    So, rather than targeting a specific browser version, could the meta tag idea be used to target a range of standards rendering behaviors instead? I don’t imagine to know how that could work, but after reading this article, I wonder if meta tags for flagging rendering “exceptions” could be developed—as these could be tied more closely to the standards as they evolve. I imagine they’d offer some flexibilty and allow for progressive updating of a site as new browsers are released, as such meta tags could be inserted quickly and removed again when the site can be fully updated (instead of the rushed site updates every time new browser versions are released, as the article mentions). And using the meta tags wouldn’t lock a site to a particular browser or version, but a more of a “rendering mode” version instead.

    Copy & paste the code below to embed this comment.
  • One of the biggest mistakes of the web development community was to struggle to try and make sites work on old or buggy browsers.

    You see, we’re all really determined to give our end-users the best experience possible, even if it causes us vast amounts of pain trying to hack around Internet Exploder to try and convince it to do things properly.

    But our efforts have backfired on us. By supporting buggy browsers, we’ve actually prolonged the life of the buggy browsers and the sites that came to rely on those buggy browsers.

    If we resolutely stop supporting browsers with bugs, across the board, guess what will happen”¦ People will stop using buggy browsers because all the sites they visit will be “broken”?.

    That in turn will make people with sites that break on standards-compliant browsers wake up and think “hey, I need to fix my site “¦ now!”?. It’s not going to take as long as you think for the world to adapt to a standards compliant nirvana.

    Copy & paste the code below to embed this comment.
  • From what I can see, this is actually a good idea. If you’re a browser vendor, and you don’t want to support this”¦ well, don’t. No one’s forcing you to. Microsoft is just giving developers a way to say, “This page works with IE7. If you can, make it work like IE7 did.”?

    Saying “everyone should just follow the standards”? is good and nice—except that the standards are very complex, sometimes ambiguous, and occasionally internally inconsistent. Just like C++ code, standards are written by people and can have bugs.

    Also”¦ IE isn’t the only browser that changes behavior across versions. Firefox 3 passes acid2 whereas FF2 doesn’t—obviously, the two versions mean something slightly different when they say they’re standards-compliant. Even in the “equal”? world of standards-compliant browsers, some browsers are more equal than others.

    As someone who builds intranet-style web applications (that work cross-browser, thank you very much ;-) I’d love to be able to pin my app down and say “This works with IE7 and Firefox 2 and Safari 3. Browsers, if you can act like any of those, you’ll deliver a good experience to my users.”?

    And I know it’s a good idea to test your web work with every browser you’ll want to support. Are you sure you’ll be in your current job, ready to do that, forever? Are you sure you’ll be able to spare the time to do that testing before users get new browsers?

    Copy & paste the code below to embed this comment.
  • From what I’ve read (and this isn’t a great deal) this sounds like a good idea and even if only adopted by IE it’ll at least alleviate some headaches.

    But I do have a question about how, as time moves on, older versions of browsers implementing this strategy will handle content targeted at later versions i.e. what will IE-8’s approach be when it encounters content targeted at IE-10:

    I’d assume that in this situation it’ll adopt an ‘I’ll try my best to render’ rather than a ‘this page cannot be displayed as I’m not included’ approach.

    I’d be interested to know what is intended as without this I think there may be issues when accounting for the fact that not all end users adopt new browser updates / versions either quickly or consistently.

    Copy & paste the code below to embed this comment.
  • I definitely agree with Aaron, targeting a browser version using a meta tag is a great solution to a great problem, it’s simple, practical and at the same time elegant.  I think browser targeting will leave its mark in Internet history, from this moment on it will be easy to completely understand (content + visualization + behavior) targeted web pages.  Previous web pages will always require some archeological effort in order to be understood.  My company, Artinsoft (, has been developing tools to increase web sites’ code general quality and standards compliance (  One of our tools, the IE8 Compatibility Wizard, automates the compatibility meta tag insertion task.  I am confident that this tool can help several members of your audience and I sympathetically invite you to visit our web site and try our products.
    I look forward to hearing from you.
    Best regards,
    César Muñoz

    Copy & paste the code below to embed this comment.
  • Personally, I have to rewrite my sites at least every 3 to 4 years, often parts of some sites and some pages weekly (I want this new logo, I don’t like that color any more:-) ) As long as it is paid for I have no complaint.
    SO, I don’t understand the argument about future/backward compatible pages. I want customers to update their material, and since I use includes I just change one file; update – reload and the site is all done! and I can go back to shoveling snow. 
    I would like for browsers to be standards compliant, I though that was the whole point of having standards in the first place. I think you guys (those who see this as a way out) have just been beat down by the Standards Compliant” struggle and the “meta-code” snippet is an easy way out. The last time I looked (last week?) the IEs were down at 37% and dropping and FF was at at 45% and rising. I look forward to Standards Compliance growing and the continued growth of standards compliant browsers.


    Copy & paste the code below to embed this comment.
  • This is indeed a nice approach if your application is huge and you want to make it compatible with new version of IE i.e. IE8.
    I am using this with my web application, but I am facing some problem. When I try to open a lightbox that time the window of lightbox is not getting compatible with IE8.I guess the issue is with javascript.So I am not getting how should I make my layout(which is build with javascript at runtime) compatible with IE8. what could be the solution??

    Copy & paste the code below to embed this comment.
  • I agree this solution (implementation aside) may help solve catastrophe when a new browser is released. However we only need to look at the outcome of other applications where we force specifics in a browser to see where this path will take us. These days I’m pretty sure I only see IE6 running within companies that spent a small fortune on custom software that requires they stay in the IE6 box to function.

    Do we really want to encourage the same type of behavior within basic web development? I work with enough “old school” clients to know that the vast majority would prefer to upgrade their old outdated site in the “HTTP-EQUIV” it was originally written in than redo everything with a new more modern solution. The last thing we want to do is promote locking our clients to a specific(and dated) browser, even if it does prevent a small period of panic.

    Copy & paste the code below to embed this comment.