Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8

253 Reader Comments

1. I think this is fabulous idea. One more way to get around buggy implementations. Have you been in contact with other UAs concerning Version Targeting, or only Microsoft?

2. I understand the need for us a web developers and designers to be able to “set it, and forget it” but I really think that the best option is the one we have now. The one that doesn’t lock us into any given version of a browser and keeps us honest with our code.

   I am fearful of the possibility that companies stop thinking about how to offer improved accessibility, usability, and functionality buy building a site that is IE7 compliant and then leaving it for the next 10 years, bugs and all.

   The current method almost requires companies to keep up with the times, or at least make an effort to give their users a better web. The web needs to be able to “shed it’s skin” every ten or so years and get rid of some of that old, unmanaged, outdated code.

   How many people are going to miss those old Yahoo!Geocities sites anyway?

3. OMG! That’s a terrible solution and impossible to implement. That would mean that if I wanted to create a browser, I would have to emulate the rendering behavior of all other browsers. That’s just so absurd.

   Rendering and behavior should be standards based, not browser based.

   Microsoft would like that solution because it is anti-competitive and would cause significant problems for the rest of the industry (everyone else would have to attempt to emulate IE 5,6,7,8,N’s rendering behavior as Microsoft are the dominant player). In fact, this solution is even unsustainable for Microsoft because it would make their codebase huge as they keep all their bugs forever in their browsers. Stupid solution. I don’t see it happening.

4. I don’t believe this solution would require Firefox to implement an IE rendering model. Since Firefox would be targeted by the FF abbreviation.

   I am not convinced about this solution either though. I welcome the attempt to bring some sort of order to all this. However, I can’t see Opera (or whoever) in 5 years time delivering an Opera 15 with 5 different rendering engines for versions from 10 to 14!

   In any case this will only work if all browsers agree on this convention and I just can’t see that happening.

5. I’m not sure this is a good idea. I find it hard to believe that browsers will render pages correctly in backwards-compatibility modes. Heck, *most* browsers are inherently buggy and laying bugs on top of other bugs is a recipe for failure.

   To handle the past for *those* browsers we already have IE conditional comments, right?

6. It’s inevitable that standards change, eventually making light switches, office buildings and webpages obsolete. When products in that state still ought to be useful to a broader market, they should be renewed or replaced. so I agree with Douglas Tondro: site owners have to continuously invest in standards compliant web content. They shouldn’t leave that to other parties like their audience or any browser manufacturer.

   In a industry that wants to take itself seriously, site managers are responsible for keeping pages up to date and browser manufacturers are responsible for prevailing standards above the little and big innovations they’re longing for. Any mechanism for versioning will be bad for the process of becoming a standard compliant industry.

7. I’m ready to agree with Marcos Caceres, this is really a terrible solution and nothing I would like to see in future browsers. This will only lead to extremely bloated browsers with thousand of render modes and a web full of ugly and unmaintained sites.

8. There’s a big case of weasel words in this article. While it’s fair to say that IE8 in standards mode renders Acid2 correctly, that’s completely not equivalent to ‘passing Acid2’. Passing Acid2 requires the browser to render http://www.webstandards.org/files/acid2/test.html correctly, and I don’t see any meta tags on there.

9. This sounds like the same half-assed approach that lead to the DOCTYPE switch in the first place.

   In an environment with a potentially unlimited set of UAs to access pages on the Internet, how can anyone think it’s a good idea to UA hardcode support information into the document?

   If you want to render my document, there is a defined set of standards. If you aren’t up to implementing those standards then make your own excuses, don’t expect me to update my document to suit.

   Now, I understand that this is a fundamentalist view and in “the real world” there are “allowances” that should be made. But something along the lines of what is being suggested here is just going to make the web less document-centric, and more about the “big” browsers. And here’s a hint – the focus of the web should be the content, not the viewer.

10. So we’re reinventing browser sniffing?
    Great, being an opera user, I’m going to be so thrilled with that, when people specify IE8, FF3, and then some lower number for everything else because they can’t be arsed with other browsers. So I get some crappy version when I run Opera? Maybe Opera will have some sense and just ignore it.

    Browser sniffing wasn’t good the first time round, many of us spent a lot of time giving people reasons why browser sniffing wasn’t bad, and now here we are, saying it’s the best way forward?

    As GarethAdams says, there are potentially an unlimited number of UA’s, what are we going to do about mobile browsers? How about Flock, or other browsers that use the Gecko engine?

    This sounds like a complete cave in to MS’ demands, when they should be doing everything possible to bend over backwards to get this stuff right, they got themselves into this position, they need to get themselves out of it, without forcing web developers into bad practices.

11. bq. Sure, most trips through the “Wayback Machine”? don’t suffer in modern browsers because the DOCTYPE switch still serves them well, but what about a site built to IE6’s implementation of “standards”? mode? We already know that, in many cases, IE7 won’t render it properly.

    Agreed, IE7 won’t be able to render it — but Firefox or Safari will, because the author didn’t need to use wholesale hacks and workarounds for these browsers to get the layout to work in the first place.

    You’re proposing a Microsoft-centric solution to a problem that Microsoft created for themselves, by not keeping up with modern browsers post-IE6. That five-year gap produced the millions websites designed just for IE6 — that Microsoft bosses are desperate to support at all costs.

    Why is the onus on people who are actually trying to use standards to declare it, rather than on the people who only support obsolete technology like IE6?

12. Firstly, if MS can get IE8 to render correctly via me using a meta tag – particularly one other browsers can use – I’ll live with that. Their ‘not break the web’ mantra means that this is about the best we’re likely to get from them here, so I’ll settle.

    That’s what my head tells me. If there’s something new, something that doesn’t in itself break standards, I’m prepared to add it to my template.

    Secondly, like wot Gareth Adams says:

    “If you want to render my document, there is a defined set of standards. If you aren’t up to implementing those standards then make your own excuses, don’t expect me to update my document to suit.”

    It in my heart it _feels_ like a backward step. But I’m still prepared to give it a go.

13. Maybe this is a difficult concept to grasp but intuitively it doesn’t seem like the right thing to do. It seems to be a solution designed solely to support the various versions of Internet Explorer which aren’t able to easily co-exist with other browsers (or even themselves).

    What’s really needed is a concerted effort to make front-end web development a recognised profession. This might help to ensure that more developers have sufficient knowledge to overcome the differences between browsers whilst we move to a more standardised rendering situation.

    After all there doesn’t seem to be a problem with Progressive Enhancement when you know what you’re doing.

14. Sounds like you put a reasonable amount of work into this concept, which rather flies in the face of many years of web standards effort.

    Can I ask if you were paid by Microsoft for this effort, and if so how much?

15. Well, as some other people noticed, I think this is not the right move to make. Because every website is already defining how it wants to be rendered. Just take a look at the doctype and you know.

    There is a good solution; the browser vendors should implement standards as defined by the W3C. So we all know how a browser will render a site. Maybe not in the most smooth way, but you only have to build your site once.

    This new standard will not be implemented by all browser vendors, so again we will have the problem fixed for only a few browsers. Its just another patch.

    And by the way, how many MB is Safari for iPhone after 10 new render engines?

16. Not about a browser compatibility declaration, but the fact that Microsoft are concerned about standards compliance and not breaking existing websites. Maybe there’s hope for the future after all.

17. So some people are trying really hard to fight standards, interoperability, and maintainability. I admire the tenacity, but I’m about to lose any motivation to deal with that in a constructive fashion. (Qed.)

18. I’m afraid that, on this occasion, I agree with most of the posters on the IEBlog that this is a very regressive step and I think the Webstandards folk really should be ashamed of going along with this.

    There may have been some layout compat problems when IE7 launched, but the world has not fallen apart, and the IE7 Trident is certainly a major improvement on IE6 Trident.

    I still don’t really see why this metatag ‘solution’ should be needed. The only sites that are really going to need serious checking of layout are the kind of sites that are done by people who understand CSS and therefore more likely to be actively maintained.

    People using table tags and other stuff are surely not likely to be affected for the simple reason that IE already implements all of the basics, and the vast majority of CSS stuff to the standards, with only more complex floats and other more complex areas less consistently supported (but again, IE7 Trident got alot of that closer to other browser vendors’ implementations).

    I think we just have to accept within the web development community that some breakage will occur as the web moves on. The same has happened in the security and other arenas. Otherwise we face the bad old world of browser sniffing, which surely we all tried to move away from years ago?

    And also, how does this solve the issue of maintaining support for older browsers? Do we now have to maintain two copies of a site, one with the meta tag and one without? I’d say the use of the odd CSS hack is far preferable to that kind of situation.

    I really hope that other browser vendors do not implement that and that the IE team think very seriously again about the consequences of implementing this. Compatibility is important but we have to accept that some breakage CAN occur as the web is a constantly evolving medium, and that people have to accept that.

19. I will be very welcome to see “legacy rendering and scripting engines to display the site as it was intended—well into the future”. I hope that The Web Standards Project are able to get this rolled out with IE8, and as Hal Stephenson says it is great to hear that Microsoft are concerned about compliance. I like the consensus though am not happy with adding meta tags to effectively “code fork” the correct rendering of websites that I build.

20. bq. Can I ask if you were paid by Microsoft for this effort, and if so how much?

    The Web Standards Project has always been a grassroots, _volunteer_ effort. Members _donate_ their time. They are not paid for it.

21. I agree with the majority that this is not the best solution. Moreover, it is likely to be a source of future browser instabilities. However, we are going to have to live with that.

22. The main problem with browsers and html interpretation has been that IE was bugged, and no one fixed it for a long time.
    So everyone used it, thought the behaviour they witnessed was normal, and everyone was happy… Until other people came up with browsers that actually performed correctly.
    But there were so many of those sites that were built wrong, that Microsoft could not do much without breaking compatibility. And with every version that came out, they had to be really careful about what they did, otherwise the world would collapse.
    So standards were held back because:
    – IE could not go the ‘normal way’ easily
    – people building sites felt bad about writing correct code knowing 70% of the world wouldn’t see it right

    Here is a solution that makes it easier on Microsoft to move towards standards AND also has potential support for legacy browsers. How can this be bad (as long as it’s not perverted) ?

    The argument that companies can’t support multiple versions is irrelevant: Microsoft still does it inside IE7 and they’re the ones with the biggest stack of bugs.

    I welcome this idea.

23. Rather than specifying a particular browser/s to render with, how about specifying a date when the website was known to render correctly across all browsers.

    Browsers would keep records of when a particular rendering agent was introduced, and render the page according to which engine was used at that date. This method allows all browser developers to support the method and removes any developer specific values.

24. bq. So we’re reinventing browser sniffing? Great, being an opera user, I’m going to be so thrilled with that, when people specify IE8, FF3, and then some lower number for everything else because they can’t be arsed with other browsers. So I get some crappy version when I run Opera? Maybe Opera will have some sense and just ignore it.

    Absolutely. This new proposal would be a disaster for the web, it would be a disaster for the development of web standards and technologies, it would be a disaster for everyone who doesn’t use IE or Firefox.

    New browsers are going to support web standards. No new browser that doesn’t will get very far. If even IE is going to support them, we should be in the clear as far as new browsers go. What that means is that any site that is coded to web standards should be fine in new browsers. If you’re not relying on bugs and hacks, you won’t have a problem.

    Specifying which browsers get a cutting-edge version of the page is completely the wrong way to go about things. Design the “current” version, using the methods of progressive enhancement – and then ensure that any browsers that are known to not support technologies used get a stripped-down version that they _can_ understand.

25. I am sorry, but this can only be described as _madness_. We are talking about *browser sniffing* and *code forking* here, are we not? Although I appreciate the problem of dealing with legacy web documents, any solution that allows browser vendors to drift away from web standards and do their own thing is wrong, wrong, wrong.

    bq. That’s because even Eric Meyer can’t predict layout or scripting bugs that may be accidentally introduced by a new browser version.

    There shouldn’t be a need to do that. If a new browser version emerges with such bugs, the developer community should notify the browser vendor so that they can roll out an update that fixes the problems.

    This kind of feature also opens up the possibility of allowing browsers vendors to start creating device-specific browsers. Already, I see completely unnecessary iPhone-specific sites springing up all over the place – a slap in the face for CSS standards designed to cope with many devices.

    No. This seems to be something conjured-up for the benefit of Microsoft, and not for the benefit of the web or the developer community.

26. _”The IE team began work on a completely new rendering engine for IE8″_

    According to Chris Wilson in a recent “interview”:http://www.sitepoint.com/article/ie-standards-chris-wilson he states:

    _”We’re not actually building a whole new engine, like the whole – In IE, our component was code-named a long time ago, ‘Trident.’ It’s kind of the rendering engine and the object model and the parser – all of these pieces pushed together.”_

27. This idea is full of fail. How many versions back must a mobile browser keep? Or let’s say something renders ugly in version 8.1, like transparency. Would I specify 8.2 and hope it’ll get fixed in that version, or would I specify edge and see all my other fixes break in 8.5, or will I specify 8.1 and forever have an ugly site?

    This will solve one problem for Microsofts introduktion of IE8, and that’s it. For me a a developer, this will be just another thing to keep in mind while doing workarounds. And what’s next? Specifying 8.1+FIX#14+SP3?

28. This feels, and I think is, a very bad idea for the reasons mentioned above. The way it’s been “revealed”, while obviously going against the grain of openly developed standards, feeds into the negative feelings.

    I, for one, won’t welcome our new silly tags like this.

29. The problem here center’s around preservation of old websites. What I think we have to remember here is that the web is still in its infancy. As it grows, things are going to be lost…that is the nature of not just the web, but any new technology, dating all the way back to written word. As browsers become settled around established standards, this problem will solve itself.

    In simpler terms, you don’t need to throw a Hail Mary in the first quarter when you are down by a field goal. There is still plenty of game left to play, and urgency to solve every problem all at once is only going to hurt us in the long run.

    On a different angle, I have to also state that in any website, content is king. While I am sure some of us would like our designs to be saved and looked upon by future generations in the same way that we look upon some of the great posters of the 40s and 50s, that is mostly irrelevant as long as users can get to and understand the content. And no matter how much of a disaster any older website comes out in modern browsers, people will figure out a way to get to the content.

30. They already have!

    And now they want to fix it by reintroducing browser sniffing? If all you standards guys managed to get wuality time with Microsoft, surely it would’ve been a lot more beneficial to the web and its future to look them in the eye and say:

    “You want to fix the mess you’ve made? Quite simply build IE8 to render standards TO THE LETTER. No interpretation, no second-guessing, just do what the specs say. Everybody else does it, why are you any different?”

    But of course it’s Microsoft and the real reason for all this is simply “but if we do things properly, there will be no reason for our users to stick with our browser, so let’s act like we’re doing the right thing and perpetuate IE-specific code”.

    You want to make sure everything renders properly on the web? Then make sure all browsers render the specs correctly. You then want to make sure developers use those specs? have browsers block ALL rendering if the DOCTYPE is missing or invalid.

    No excuses on either side of the fence then.

31. So how will previous versions of browsers handle things when they see a page marked as using a greater version number? How will IE8 handle a page that is marked as IE9?

    This solution seems to only be a crutch to help with backwards compatibility between versions 6-8. I can’t see how the approach will help with versions 9+.

32. I must admit that I have different feelings on this suggested approach.

    On one hand I can see the use of a way to preserve the site in a manner as it has been designed and implemented even some years furter in the future (think about campaign sites that are not developed further when they are done).

    On the other hand I do agree with others that it most likely is un-doable to ship new browser versions with a couple of legacy versions to support old sites. There are various reasons why this is not easy to do for browser vendors, but I will just highlight the big 2:

    File size:
    Every new browser version will carry at least 2 older versions with it making the distributable much bigger. This will make the threshold for low bandwidth regions like Asia and Afrika to adapt new browsers even higher then it already is (which is the reasons why IE6 is still a very big player worldwide).

    Browser start-up time:
    When each request to a site tells the browser to run in a differnet version it probably will not be uncommon to have the browser spin off multiple processed running an older version of the browser making the rendering time to view a site much higher. Also this will slow down the machine which again is the biggest problem in less evolved IT regions like Asia and Afrika. IE might solve this problem by adding all supported versions to the OS start-up process, making that slower again.

    And as a last comment I have to admit that we have not had many problems for the company that I work for to make sites work in IE6, IE7, FF2, Safari 2 and Opera 9. Usually we only have to add aditional logic for IE6 and that only runs when accessed by an instance of IE6.

    Conclusion:
    I like the idea, and in theorie it could have it’s benefits, but in reality I do see far too many obstacles in the way for this to ever reach the production environment.

33. “The solution you guys all came up with was great but we want to dominant like we did with Windows. So… Rather than fixing our browser to work like everything else we’ll invent something new so you have to go and change everything. Wooo go us!”

    How about they just change the damned box-model problem and we can all get on creating new stuff rather than adapting our perfectly good code to suit Microsoft’s browsers?

    Two words… Web and Standards

34. First we get doctype, now we get an extra meta. What’s next.
    Why not adjust the doctype and put this info there?

35. I want to code to standards, not browser versions.

    The ideal web is a web where you don’t have to think about differences between browsers – because there are none. Now Microsoft is moving away from that ideal by introducing another rendering trigger, while there should be only one.

    A strict doctype should trigger standard-compliant rendering for all browsers. Until IE is not fully compliant (hopefully that won’t take too long), I’m all for

36. I’ve read what Microsoft had to say, I’ve read both articles here, I’ve read Anne van Kesteren’s post, and now I’ve read through the comments up till now.

    The one thing thing that finalized my thoughts was what Blaise Kal just wrote, “I want to code to standards, not browser versions.”

    I’m sorry, but this is a sad day in web development.

37. Is keeping the exact rendering engine of older browser versions REALLY that important in displaying older websites?

    Most of the content will still display in some from or another in future browsers, if it doesn’t, just turn off the styles! If the exact rendering is important (which it really shouldn’t be in most cases), then yes, people who care enough can boot up their virtual PCs and load it up in the browser it was intended for.

    Keeping an ever-increasing stack of rendering engines in a browser just for a small percentage of cases (which most of the time will display well enough anyway) seems like madness to me.

    I’m wondering if this is actually a test by the upper-level standardistas. “Will you go with something stupid just because we endorse it, or will you use your common sense and renounce it?” Still, I’ll try to keep an open mind.

    Oh, and one last thing…shouldn’t Microsoft have collaborated on this with the W3 as well as WaSP?

38. Here’s a better solution: If a document is served as application/xml+xhtml and validates as XHTML (any version), render it strictly according to that standard (using the new IE8 standards-compliant mode). Otherwise, behave like IE7. This is the best of both world: The current web behaves as-is and developers who are moving forward get full support for standards.

39. I reached the end of the article and thought “I must’ve missed something, I must’ve misunderstood”.

    I then read the comments and, no, it really is as stupid as it first appeared:

    1. we’re imposing on browser-makers to provide increasingly bloated applications to service obsolete rendering standards

    2. we’re encouraging web developers to take the easy route and produce sites that favour a particular browser – so much easier than coding to W3C standards … hey! We can all go back to using Front Page Express!

    WaSP, Zeldman, Molly, et al just took a major nosedive in credibility for clear thinking – although this is *exactly* the sort of ‘feature’ we’ve come to expect from MS.

    We’ve had enough of needing hacks for MS … and now they’re adding more. [expletive] idiots.

40. What’s the problem with breaking badly designed sites? A car that’s not road worthy is kept away from the road.

    The mantra for MS shouldn’t have been “Don’t break the web” when it’s already broken, it should have been “Let’s fix the web”. And if that means that some sites won’t work properly on newer versions of IE, then so be it. Web owners will have to update their sites, as they no doubt do every once in a while anyway.

41. I am totally and utterly confused.

    When creating websites I take the tactic of “build for the best and test for the rest”. I do not know if Firefox is the best, but that’s the one I built initially for. And having been in this work for a couple of years already I manage to create sites that at first not completely fail in the rest. And with a few tweaks I make things work.
    I take Web Standards as my starting point.
    If a new browser (version) comes along I might test if it is relevant for the site or target users. When something breaks, I fix it.

    But now a new concept is introduced. When I am done with building the site and it is fully tested. I must mark it with all the compatible browser versions (_what about the combination of browser version and OS?_) and I have to do that really careful so as not to miss a browser or version.
    When a new browser (version) comes along I have to test it to see if does a good backwards compatible test (_does IE 11 renders correctly as IE 10?_) and test again to see if IE !! renders correctly as it self?
    And finally I will have to make a change to the META tag.

    Confusing and unnecessary extra work to say the least.

42. Having just read the comments at http://blogs.msdn.com/ie/archive/2008/01/21/compatibility-and-ie8.aspx, which are similarly negative to the ones here, it occurred to me that this decision reeks of MS Marketing.

    This isn’t a decision to help the end user, or web developer, which is how it’s being sold. This is a damage limitation strategy by MS Marketing and it’s another ‘divide and conquer’ mechanism that the mighty MS is so fond of.

    Opera, Mozilla, Safari don’t ask for special treatment when they release a new, improved browser – but then they’ve adhered as closely as possible to W3C standards, so the impact is usually minimal.

    MS/IE on the other hand steals more time and resources with every release – doctype switches, CSS hacks, conditional comments for 5.5, 6, 7 and now they’re giving us meta switching. Where does it end?!

    We all accept that the web is an evolving entity, and most of us have come to recognise that adherence to a strict set of standards is the absolute best way to ensure future compatibility. Everyone apart from Microsoft and now, sadly, WaSP.

    “Web design – 10% creativity, 90% Microsoft Internet Explorer”.

43. First off, let me say that I too shared the reservations many of you are expressing. In fact, it took me nearly two months to realize that this was the best way to move the web forward while preserving our investments thus far.

    In response to a few questions/statements:

    bq. I am fearful of the possibility that companies stop thinking about how to offer improved accessibility, usability, and functionality buy building a site that is IE7 compliant and then leaving it for the next 10 years, bugs and all.

    God, I hope that’s not the case. But think about a site built for the current field of browsers, perhaps something critical like an online banking application. 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). With version targeting, the team can test the new browser version internally before updating the @meta@ element (or the HTTP header) to add support for that new browser. And no users experience problems, no bosses freak out, and customer service isn’t fielding endless calls they have no idea how to respond to.

    I think that’s a pretty good trade-off for adding a standards compliant @meta@ element to documents.

    bq. I can’t see Opera (or whoever) in 5 years time delivering an Opera 15 with 5 different rendering engines for versions from 10 to 14!

    I am not a browser vendor nor have I ever made a browser, so I don’t know what percentage of browser code is specifically devoted to rendering and scripting support, but I can say that it would seem reasonable to me that browsers may retire certain rendering modes as time passes. Broswers will have the ability to read the rendering modes of pages and report on that. If, over time, certain rendering modes start to take up a smaller and smaller piece of the content pie, it may be justifiable to end support for them. But, again, I’m not a browser maker.

    On a related note, computers (including those that drive mobile devices) are becoming exponentially faster and storage is much cheaper than it has ever been. If maintaining support for a legacy rendering and/or scripting engine adds an additional 5-10% to the size of the app, I don’t see that being a huge problem. That said, I am as concerned as anyone with code bloat and hope that knowing these engines will need to exist well into the future will provide the impetus needed to keep developers honest and their code clean.

    bq. There’s a big case of weasel words in this article. While it’s fair to say that IE8 in standards mode renders Acid2 correctly, that’s completely not equivalent to “˜passing Acid2′. Passing Acid2 requires the browser to render http://www.webstandards.org/files/acid2/test.html correctly, and I don’t see any meta tags on there.

    An astute observation, “Robyn”:http://www.alistapart.com/comments/beyonddoctype?page=1#8; it’s true that the ACID2 test doesn’t have the @meta@ required to trigger IE8 to use the latest rendering mode, so IE8 does not _technically_ pass the test. But it is also possible to use an HTTP header to accomplish the same thing as the @meta@ element. So, with the X-UA-Compatible HTTP header applied, IE8 would, from what I understand, pass the ACID2 test.

    bq. Can I ask if you were paid by Microsoft for this effort,
    and if so how much?

    As “Jeffrey said”:http://www.alistapart.com/comments/beyonddoctype?page=2#20, I received no money for my work on this project. In fact, the one time I did fly out to Microsoft for a discussion of IE8, I paid my own way.

    bq. I am sorry, but this can only be described as madness. We are talking about browser sniffing and code forking here, are we not?

    Actually, no. This implies no code forking whatsoever. Version targeting simply lets browsers know what browser version the site was built against. It does not require or endorse browser sniffing or code forking. Nothing we have been doing, to date, would change, except we would have to include the @meta@ element to tell IE (and perhaps, eventually, other browsers) we are targeting a particular version of that browser. We will be able to continue using progressive enhancement techniques as we have been for the last few years, the only difference being that we will be able to introduce support for new browser versions on our timetable instead of the browser vendor’s.

44. I have to agree with the majority of posters here, that this is a really bad idea. Do we really want to return to the days of “Designed for Browser X” (albeit in a programmatic form)? If a document claims to follow a particular standard, the user agent should do its best to respect that. How do we explain to amateur designers who are trying to follow the standards why they need to add some additional bit of code to make IE work ‘properly’? If IE and various authoring tools have made a mess of things previously that’s their lookout.

    Authoring tools can be upgraded, and if IE7 really “broke the web”, I’d expect people who got burned then to have fixed things in a much more future-proof way, or at least to be much more aware of the issue when IE8 launches.

    Moreover, any designer worth their salt will have their site working in Firefox etc. these days. So surely a standards-compliant next version of IE would behave pretty much as Firefox et al. does now, and hence not break that much anyway. (You’d need to rename the trigger string in IE conditionals so things like >IE6 aren’t triggered, but that’s no big problem.) Even if IE8 does break things, all the designer has to do is ensure the main standards version is sent unaltered to IE8 and that should fix most issues…

45. In “his comment”:http://www.alistapart.com/comments/beyonddoctype?page=4#39 (posted while I was writing my last one), David One preposed the article was making the following statements:

    bq. 1. we’re imposing on browser-makers to provide increasingly bloated applications to service obsolete rendering standards

    bq. 2. we’re encouraging web developers to take the easy route and produce sites that favour a particular browser — so much easier than coding to W3C standards “¦ hey! We can all go back to using Front Page Express!

    On the first point, I am not im complete disagreement with you, but would like to bring up the fact that browsers may not implement a new rendering or scripting engine between releases, so IE9 may be the same as IE8, meaning no extra bloat would be added to the application. The same goes for any browser.

    And as I pointed out in “my previous comment”:http://www.alistapart.com/comments/beyonddoctype?page=5#43, I think the trade-off is worth it.

    On the second point, I couldn’t disagree more. No one (not even Microsoft) is saying “too hell with standards.” I plan to continue advocating, as I have for years, building sites to web standards, using CSS layouts and such. This is just another tool to allow developers to control the evolution of the sites we build and make sure they stand the test of time.

46. You know, I’d hope my online banking site has developers who will get beta versions of upcoming browsers and fix any major bugs and issues before the site goes live. Surely that’s what you should be expecting as a client?

    Regarding my comment about Acid2 and meta elements, my comment still holds. For the moment at least the webstandardsproject.org server isn’t sending any IE-specific headers, so it still won’t pass the test. Fair enough, the server might be altered in the future to add these, but then there’s the whole irony of the ‘webstandards’ server implementing non-standard code to work around the non-standard bugs of a non-standards-compliant browser.

47. The idea is basically desastrous. It simply resembles those old nasty “optimized for browser XY” messages. Not at all a good idea.

    If there is a need of adding some kind of compatibility information, there would be a way to do this with minimal efford and without specifying a specific _browser_ but a specific standard.

    So already known is the old . There do exist similar constructs for Script () and style (). All could be expanded by a version info required, added optionally with a separating semicolon, as with the charset in the content-type property. This might be a minimum requirement or an exact requirement, which is up to the browser to decide. This specifies the version of the required _standard_, not the required _browser_, which would be much more useful.

48. One Mozilla dev gives initial thoughts:

    http://weblogs.mozillazine.org/roc/archives/2008/01/post_2.html
    http://weblogs.mozillazine.org/roc/archives/2008/01/slipping_the_ba.html

    I’m looking forward to the response from HÃ¥kon (http://people.opera.com/howcome/), whom I suspect will be even more damning.

    Finally, this is what Microsoft wrote in *1998*:

    “Microsoft has a deep commitment to working with the W3C on HTML and CSS…We are still committed to complete implementations of the Recommendations of the W3C in this area (CSS and HTML and the DOM).”

    *10* years ago they were claiming deep commitment to W3C, and yet they’re still trying introduce more junk code to avoid adherence to those standards.

    If it were funny, it’d be a joke.

49. Why are we, again, having to fix the web for Microsoft. Shouldn’t Microsoft be fixing itself for the standard web? Why are we treating Microsoft as a charity case?

50. If such a scenario happens when, say, Firefox 3 is released, the only people scrambling to fix breakages would be the Mozilla team.

    The people making the website would—quite rightly—blame Mozilla for Mozilla’s bug and there’d be a Firefox 3.0.1 within two weeks. Simultaneously, thousands of other websites would be fixed.

    The only people this idea will benefit is browser makers who can’t be bothered to fix their own bugs in a timely fashion.

51. It seems strange that nobody has mentioned potential security holes in maintaining old rendering engines and them being implemented into new browsers. Wouldn’t certain changes sometimes affect the rendering engine in future releases of software which could impact a small minority of sites that browser vendors may not be aware of?

    Another issue that I can see emerging if this is put into practice is that business website owners stop updating their site with newer standards. We already have enough trouble convincing them that re-writing a site with accessibility and standards compliance in mind, how will this change when a site currently works in all browsers plus all future ones and therefore costs little to maintain, whereas embracing newer standards would lead to training costs and re-design costs?

    The maintenence costs for this would be phenominal, imagine changes to the DOM 10 years down the line, imagine minor changes in browser behaviour that affect server-side issues, how would the browser-type be detected and so forth…

52. I read through most of the comments, thinking I was in agreement with most people, cursing Mr Zeldman for entertaining this as a good idea for even a second – but then I re-thought. It’s not as bad an idea as all that, seeing as there is a hole that needs to be plugged (legacy sites coded for IE6 by chiefly .NET developers), but surely this is just a leaky and mostly perished plug, applied when most of the water has already drained clear of the sink.

    The time to add this meta declaration was on the release of IE7, because there was a much greater disparity between the standards support of that browser and that of IE6. IE8 seems to be shaping up to be pretty compliant. So as a web author I’m happy to serve mark-up/CSS in conditional comments for versions less than 8, and then wait for the IE8 release. If I’m coding according to standards and declaring DOCTYPE correctly, why won’t my code be future-compliant?

    Furthermore, this IE7-compatible mode in IE8 won’t be the same as real IE7, but will just be a patch to avoid any predictable gotchas, or at least any predicted by the dev team of that browser. And as IE9 is released, the IE7-compatibility mode will likely just have even more quirks. So your putative bank will tell you, the agency, that all you have to do is put in this magic meta tag and their app won’t break in the new browser, when there’s no way that can possibly be predicted – and as Mr Gustafson pointed out in comment #43, it only takes one edge case. Would you as the agency warn the bank that the declaration is only a bad sticking plaster or would you allow yourself to carry the can once the app fails regardless?

    And anyway, what’s the point? There are bugs in IE7, but we should already be writing to the standards and hacking back for specific browsers. Because Microsoft looks like it’s going to bring out the goods in IE8, more or less, that’s a strategy that should work well today even for IE. So what exactly is this fixing?

53. bq. I am not a browser vendor nor have I ever made a browser, so I don’t know what percentage of browser code is specifically devoted to rendering and scripting support, but I can say that it would seem reasonable to me that browsers may retire certain rendering modes as time passes. Broswers will have the ability to read the rendering modes of pages and report on that. If, over time, certain rendering modes start to take up a smaller and smaller piece of the content pie, it may be justifiable to end support for them. But, again, I’m not a browser maker.
    …
    That said, I am as concerned as anyone with code bloat and hope that knowing these engines will need to exist well into the future will provide the impetus needed to keep developers honest and their code clean.

    I understand that some apparently simple changes to a layout engine require wide-ranging alterations to source code. Sometimes keeping code clean means throwing out the old stuff and starting again.

    bq. On a related note, computers (including those that drive mobile devices) are becoming exponentially faster and storage is much cheaper than it has ever been. If maintaining support for a legacy rendering and/or scripting engine adds an additional 5-10% to the size of the app, I don’t see that being a huge problem.

    What about mobile phones? Where I work we have to account for every kilobyte of data and code that gets put into ROM. This simply would not fly.

    bq. [B]ut would like to bring up the fact that browsers may not implement a new rendering or scripting engine between releases, so IE9 may be the same as IE8, meaning no extra bloat would be added to the application. The same goes for any browser.

    They may take the opportunity of a new browser release to modify the user interface, but I cannot think of any a situation where changing the browser’s major version number that hasn’t been accompanied by a change in the rendering characteristics of that browser.

54. Wouldn’t it be possible to reverse this?
    Let IE8 work by default in standard compliance mode as it should but give the option of adding a metatag to regress to stupid-mode.
    This way devs who can’t be bothered/are stupid/have stupid management/don’t have money or time to code to standards can use the metatag as a simple band aid while the rest of us can keep doing what we want to do; code to standards.

55. it’s not often i’m left speechless…

    here’s a thought: if a site properly separates content from presentation (and behaviour, though admittedly that can complicate things slightly), then even if the rendering isn’t exactly “how the author intended”, the content (which is really what we’re trying to preserve in terms of digital preservation?) is still perfectly clear? and if somebody really needs to see it as it would have been rendered in an old browser, maybe it’s a case of making sure emulators are easily available? (i’m thinking along the lines of MAME, Amiga/Atari emulators, for instance)

    and i agree with some of the previous comments that this sounds dangerously like an MS solution to a problem that MS created in the first place…

56. bq. like an MS solution to a problem that MS created in the first place

    Well, we want MS to come up with solutions for problems they’ve created. We just want the solutions to be tenable ones, not ones that require anyone who wants to do the right thing to do the wrong thing.

57. You said:

    bq. On a related note, computers (including those that drive mobile devices) are becoming exponentially faster and storage is much cheaper than it has ever been. If maintaining support for a legacy rendering and/or scripting engine adds an additional 5-10% to the size of the app, I don’t see that being a huge problem.

    My response was:

    bq. What about mobile phones? Where I work we have to account for every kilobyte of data and code that gets put into ROM. This simply would not fly.

    I realise that you did mention mobile devices, so simply assume I didn’t include the question, and just consider my substantive point.

58. I agree with paul steffens.

    To combine this with my proposal some comments before, why not add a new mime type for Microsoft css and then set the version info as metatag or http header:

    This would advise clients to use the Microsoft interpretation of css as in IE6. Any browser (including IE8) might then use this buggy css interpretation, or try to nevertheless use a standard css version, choke, not use any css or not render the page at all. This way even a FF4 might try to support that broken engine.

    And, if that info is not present, the default should always be the w3c standard.

59. If old pages are rendered correctly by FF Opera and other “standard” browser, but not by IE, the source of the problem is probably “browser sniffing”. Pages are made to detect IE out of the crowd.
    Now, what if MS changes the user-agent string (MSExplorer/8.0 instead of Mozilla/5.0, please don’t use “IE” in the UA string), and the variables names used in conditional comments (to counter-effect the bad use of

60. My mother always taught me that if you don’t have anything nice to say, don’t say anything at all. I admit that I feel a bit guilty about what I am about to write, but I must get this off my chest.

    As a motorist, I don’t want policies put in place that make it safer for other motorists to drive drunk. I want policies that smack them upside the head and then teach them the error of their ways.

    Same thing here.

    We shouldn’t be making it OK to write poor markup, just because someone once built a browser that would render that markup OK.

    We should be educating these people as to why standards matter, and why their code should follow them.

    To me this just sounds like a cop-out. One more step toward the argument, “Who needs standards when my non-sensical, half-assed markup looks just fine on my computer.”

61. I “previously explained”:http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html how version switches in browsers reinforce browser monopolies, and thus slow progress on the Web.

62. bq. 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). With version targeting, the team can test the new browser version internally before updating the meta element (or the HTTP header) to add support for that new browser.

    Uh, you realise you just shifted the responsibility for a dealing with a browser bug onto the *users* of the browser.

    My guarantee that my page displays correctly is (should be) the *standard*. If you can’t stick to it well enough to provide a reasonable rendering of my page then you shouldn’t be in the browser market.

    If I decided to break standards compliance and use non-standard markup and styles on my page, you can bet I’d get no sympathy from people when I told them it didn’t render properly. Why should the browser makers get it any easier?

    It’s only been possible to take this attitude recently, since there _have_ been browser vendors who can create reasonable renderings of standards-compliant pages, and it’s an attitude that you can now start pointing at people creating new, badly built pages.

    Microsoft has to bear the burden for not meeting standards properly in the past, and letting the situation get as bad as it is. It’s not unforgivable; someone mentioned earlier that the web is still in its infancy and there were bound to be things that went wrong. However, the solution to having broken the web is *not* to fix it by fouling and clogging it up for the future.

63. First question – how many websites that were designed _to web standards_ broke under IE7? Or Firefox 2? The only sites that have broken (as far as I know) are those that were hacked together out of play-dough and sticky-tape and written in green crayon. So now that IE7 and Firefox 2 are here, anyone whose site is broken by web standards and relies on IE6 hacks is probably stuffed up like a turkey already. IE8, IE9, Firefox 10 and Opera 27 won’t make it any worse…

    Second question – the more old hacky websites _are_ broken by new browsers, the better it is for us! Anyone who can design a website that works is going to be in higher demand to redesign and replace the old-skool kludgey websites that are broken. That’s good!

64. bq. 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*.

    A developer should not need to “opt in” to standards mode, it should be the default behavior.

    bq. 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*.

    Again, this seems like a very foolish approach. Essentially, this is encouraging developers to *NOT* develop to standards. Developers should have the option of “opting in” to non-standards support, not the other way around.

65. New versions of Safari, Firefox and Opera have all come out and I’ve NEVER had to create workarounds because those browsers were worse than the previous versions. Each newer version fixed bugs in the previous. Yes, new bugs may be introduced, but those bugs should be fixed with patches, not left in until the next version.

    I also read on the IE Blog that they thought developers expected IE7 to act like IE6. I expected the opposite. I coded pages to work in standards browsers, then hacked for IE6. I expected IE7 to act like Firefox, Opera, Safari, et. all. I was disappointed then, but hopeful for IE8. Now I’m disappointed AGAIN with IE8. Here’s how to resolve the problem:

    1. No doctype or malformed doctypes should trigger Quirks mode.

    2. Including a proper doctype should trigger full Standards mode, without regard to which standards the browsers support. It just means the browser supports standards and I’m coding to standards.

    3. Get rid of conditional comments in standards mode. If the browser properly supports Web standards, there is no need for conditional comments.

    I don’t code to a certain rendering engine, and certainly not to a certain version of that rendering engine. I code to the standards. The standards themselves have backwards compatibility and forward compatibility in mind and that’s what we need. I don’t want to change every site I’ve made in the last X number of years because Microsoft came out with another broken browser. I guarantee Internet Explorer will be the only browser we need to use this new META tag with. When only one browser requires this, that right there is a red flag saying something is still broken and needs to be fixed.

66. bq. Essentially, this is encouraging developers to *NOT* develop to standards.

    Looks like someone’s beaten me to making my point, but surely the whole thing should be a case of opting-out of the all singing, all dancing brand spanking new standards-based rendering engine?

    bq. Developers should have the option of “opting in” to non-standards support, not the other way around.

    I can see why, as a company, Microsoft would make this decision though – many of Microsoft’s apps use the IE rendering engine to render user interfaces and with the introduction of Internet Explorer 8, many of these interfaces could be adversely affected. I’ll bet that there are product managers all over Microsoft lobbying for this meta tag so that their interfaces don’t break once IE8 is installed.

    I’m not saying I agree with Microsoft’s decision to force those of us who care about standards (count me in) to add this meta tag to their pages, but I can see why they would choose to do it.

    With that in mind, I see the ‘edge’ declaration as a solution to a problem that should never have existed in the first place.

67. 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?

68. It doesn’t do what you are thinking it does. You need to add this magic tag to make IE8 act better than ie6/7.

    This isn’t going to fix the testing with every browser problem. It just makes testing harder, because you’ll have to test each browser and test each browser at different versions.

    So, you’ll be testing:
    * IE8 running as IE8, IE7, IE6
    * IE7
    * FF2
    * FF3 running as FF3, FF2, FF1.5
    * Opera9 running as opera9, opera8
    * Safari3 running as safari3, safari2,
    * safari2

    Why do you have to check this? To see if your page works better as a newer browser version or an older one.

    What a mess.

    This is a horrible idea. I don’t mind adding an opt-out like “I really need IE6 type behavior”, but adding opt-in for the best standards compatibility is ridiculous.

    Ciao!

69. “Saying “everyone should just follow the standards”? is good and nice—except that the standards are very complex, sometimes ambiguous, and occasionally internally inconsistent.”

    You mean like IE is? At least all other browsers do a significantly better job at it then IE.

    “IE isn’t the only browser that changes behavior across versions. Firefox 3 passes acid2 whereas FF2 doesn’t”

    Other browsers do not change behavior. Passing Acid2 is done by adding features and fixing bugs, not changing how the browser acts in different contexts.

70. Aaron, in comment #43 you say: “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).”

    this is the line i heard often from many of our suppliers for large enterprise systems (SAP etc) with web interfaces. they were frantically telling our university staff not to upgrade to IE7, because their systems broke, a month or so before launch of 7. strangely though, fairly feature-complete beta versions of 7 were already available to everybody ages before then…the developers just didn’t bother testing their product (written in superbly poor, IE6 specific code, which wouldn’t even run in Safari or Firefox) against it by the look of it. i seem to remember even 37signals moaning when IE7 was released. so, i don’t quite buy the “totally surprised by the unexpected new release and the bugs/differences in rendering that we scrambled to fix it” line.

    “With version targeting, the team can test the new browser version internally before updating the meta element (or the HTTP header) to add support for that new browser.”

    or they can leave it exactly as it is and think that current and future browsers will faithfully emulate the old browser behaviour.

71. I must preface by saying that I am wholly in shock at the suggestion of going back to browser specific rendering. This seems a giant step back in time.

    Browser sniffing by any other name is still browser sniffing. And it stinks.

    Keep in mind that all the hacks and workarounds for IE are just that – hack and workarounds used to compensate for IE’s lack of ability to implement relatively straightforward simple clear standards. Therefore it falls upon web developers to fix their hacks – not browser manufacturers. Be responsible for your work. New meta directives are not needed to correct this.

    Implementing a new meta directive to select which browser versions that you want your site to work in strikes at the very heart of web standards. How does this in any way, shape manner or form help standardize anything? It does not. In fact it is difficult to imagine anyone that values a web industry based on standards and open access even contemplating a scheme like this.

    It does seem that IE is promising a holy grail, beckoning us to come up from the swamp that we wallow in, hoping all the while that we forget that it is they who made the swamp in the first place.

    Does all this seem patently absurd to anyone else?

72. While I see where the author is coming from with this idea a few this bother me.

    I worry about new set vulnerabilities that could appear with this browser lock idea. Lets look at this with the eyes of a hacker. Using the mixing of browser versions on one page, or browser window, can I use the security vulnerabilities, or standard abilities, from one browser version to take over, hijack, steal, or obfuscate the data in another version.

    You think XSS is a problem, now all the browsers will have to deal with XBS (cross browser scripting)

    I think this might be a can of worms that might be best not opened.

73. Okay. After thinking about this for a while, I’m confused.

    What is a browser supposed to do with this tag. We have one use case at the moment: IE8 only renders fully standards compatible if and only if the web page is marked compatible with IE8.

    Does that mean IE8 acts like IE6 otherwise? Are transparent PNGs broken? Does it pollute the global JS namespace? In what way does it work like IE6?

    So if FF3 applied this, would it act like FF2 unless FF3 is marked compatible?

    I’m confused. Is this meant to lock the web to it’s current version?

    Regarding the amount of work needed to leave quirks available: It’s hard and requires a lot of code. A lot of the quirks are actually bad architecture decisions. If you change the architecture, that means you have a whole ‘nother code base to manage. I imagine the hasLayout() was fixed by actually fixing the design. That means that they have to emulate the old architecture. How can a web designer be sure that they will emulate hasLayout() correctly?

    I think emulating old bugs is a waste of browser developer time and will just lead to wonderful hacks like “Well, if you use IE=6 compatibility, you have to work around hasLayout() like this, but if you actually are IE=6, then you need to do this instead so you can detect if this is IE6 or not by….”

    Ciao!

74. This versioning seems to assume that a browser is the same across all platforms, as well. Shouldn’t there also be versioning of the operating system? We know from the past that, for example, IE5 for Mac was quite different than IE5 for Windows: doesn’t this versioning assume that Firefox 9 (and all browsers) is the same across all platforms? Or does the versioning get more complex?

75. When I wrote my previous comment (ungrammatical subject header and all) I hadn’t read the part yet where it was explained that a web author would need to declare this meta tag in order for pages not to render like IE7 (or IE6?). So what percentage of the pages published to the web are likely to render any different in IE8? If that percentage were as low as I expect it will be, much of the world will then be running a hobbled browser in emulation mode, and if that percentage were high, wouldn’t we just be polluting the web with what is effectively proprietary MS declarations (as the other browser vendors surely won’t touch this suggestion with a hundred foot pole)? And won’t we have to then change our meta tags when IE9 is released so it can properly render what was already perfectly compliant, validating mark-up? When will it end (it will end, right)?

    Nope, this is all the very epitome of that which is bass-ackwards.

76. Here’s an idea that came up on a mailing list I’m discussion this topic on:
    This problem is more or less IE specific only. All other browser vendors just looks forward with the current version being the only one. So how about when IE8 renders a page that it suspects might look weird (because it’s coded correct) it will pop down one of those nifty little bars saying “This page might look weird to you. Wanna try showing it in IE7 mode? [Yes] [No] [Always for this site] [Don’t ask this again]”.

    Everyone happy?

77. Oops, I messed up. This is what I intended to write: “This page might look weird to you. Wanna try showing it in IE7 mode? Yes / No / Always for this site / Dont ask this again”

78. I’m a bit hesitant to comment so soon after reading this, but after a couple hours mulling it over it still seems like a bad idea in many ways. First of all, the goal of developing with progressive enhancement is to make things forward-compatible and embrace “enhancements” as they come out. Since we are building using web standards and fairly compliant browser rendering, we can safely assume that future browsers will not drastically “break” what we build today. For backwards compatibility we have conditional comments, and as older versions of IE slip off the traffic map we can remove the conditionals accordingly. In my experience so far, this approach actually works really well!

    So assuming this idea gets implemented, aren’t we punishing the wrong people? In order to continue building using progressive enhancement, we will now have to add a new meta tag specifying “edge”? Shouldn’t it be the default for a browser to render using the latest and greatest it’s got? Does this mean we have to dig back into all our future-proof sites on the web and add this tag to keep them future-proof? For the sites out there that are breaking now because they were built for IE5, isn’t this the job of that site’s developers to update things to proper standards?

    At the very least, I really hope the default behavior will be to use the current rendering engine if no override is present in the markup.

    What will motivate users to upgrade their browsers if the sites they use can’t take advantage of any of its new features?

79. Aaron: For the benefit of future readers who’ll come across your article through googling and don’t know context, I think you should make it more clear in your article that FF=3; is just an example, and won’t actually work unless Gecko devs support this – which it “looks like”:http://weblogs.mozillazine.org/roc/archives/2008/01/slipping_the_ba.html they strongly “don’t intend to”:http://weblogs.mozillazine.org/roc/archives/2008/01/post_2.html . (For, as you can read there, very good reasons; reasons which in due time will apply just as much to IE.)

    Version targeting is a short-sighted non-solution, and any widespread use of the practice will leave the web in a worse state than it currently is in.

    Personally I don’t intend to implement this silly switch in my websites unless I really have no choice. They’ll be readable just fine in old-IE, but all the real beauty is reserved for modern browsers. If MS thinks it does IE8’s users less of a disservice by having a default mode of emulating its broken predecessors than by operating to its full capability… well, then that’s just too bad for them.
    In those cases where I don’t have a choice, what I’ll implement is the “edge” version. That’s the way the browser should perform _by default_.

80. First: Most of this would already be possible using Conditional Comments. As most of the professional webdevelopers must use them already it should be easy to just skip IE8 in all those extra-shyesheets and give IE8 the version every other browser renders without problems.

    Second: The DOCTYPE-Switch actually was the right solution. The problem is not the Switch itself, it is the IE. Not only the developers did not improve the rendering for websites, that webstandards would work correctly, they even implemented a standards mode, that is terrible broken. This could have been fixed with continuous releases of new versions to keep up with other browsers. Again, IE missed this oportunity and has to work around this self-made issue now.

    Third: Having to support old, broken versions of some software is a pain. You at Microsoft should know that. 😉

    Fourth: Every other browser works fine in standards mode. This workaround would only help IE development. I don’t see any reason to change standards or add things to standards only because one vendor failed to do things right in the first place.

    Just my 2 cents.

81. 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 …

82. 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.”
    and
    “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”:http://annevankesteren.nl/2008/01/ie-lock-in#comment-6376 :
    “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”

83. 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.

84. 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.

85. 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.

86. To “quote Jeremy Keith”:http://adactio.com/journal/1402/ :

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

    Ciao!

87. bq. 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”

88. 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.

89. 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:

    http://www.zeldman.com/2008/01/22/in-defense-of-version-targeting/

90. Another Mozilla response: “Meta Madness”:http://ejohn.org/blog/meta-madness/

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

91. 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.

92. 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.

93. 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?

94. 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.

95. 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.

96. 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:

    into their code and effectively breaking it without meaning to.

    *_Conclusion_*
    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”

97. 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.

98. [Quote] 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.

99. “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”?

100. 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?

101. 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:
     # 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;
     # 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.

102. 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.

103. 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.

104. Because MS screwed up the DocType, now we all have to pay.

105. 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.

106. 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.

107. 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.

108. 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:

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

109. 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!

110. bq. 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.

111. “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.

112. “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?

113. “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 CSS… EXCEPT 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.

114. 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.

115. My take on this suggestion:
     http://my.opera.com/hallvors/blog/2008/01/23/suggestions-for-chris-wilson

116. >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 elements, right? Or maybe this particular header would be an exception…

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

117. 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…

118. 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?

119. 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.

120. “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.

121. 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?

122. 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.

123. @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.

124. 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.

125. 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.

126. 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.

127. All you have to do is insert a META tag like the following:

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

     Genius idea from Microsoft.

128. 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)

     Regards,

     Rob…

129. Very interesting article about this subject: “End of line Internet Explorer”:http://www.isolani.co.uk/blog/standards/EndOfLineInternetExplorer 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 😉

130. — sorry for the bad writing —

131. 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:

     http://tagneto.blogspot.com/2008/01/x-web-epoch-instead-of-x-ua-compatible.html

132. 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.

133. 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.

134. 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”:http://roho2003.blogspot.com/2008/01/trying-to-understand-what-fuss-is-all.html
     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.

135. 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!

136. 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.

137. 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.

     bq. 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.

138. Sorry but this seems utterly ridiculous…

     Hopefully something will change before all this materialises

139. 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…

140. 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.

141. “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.

142. 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.

143. 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.

144. 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.

145. 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”.

146. 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 will mean absolutely dick, because I would have to specify subversions. Should we write 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 , but it would be redundant. Or even leave 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.

147. 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.

     -DdD

148. 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.

149. 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.

150. “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.

151. 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.

152. “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.

153. 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.

154. 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.

155. “The way I see it”:http://meyerweb.com/eric/thoughts/2008/01/23/version-two/?caught_as=moderation#comment-304820

156. 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.

157. 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”.

158. Not officially endorsed by WaSP.

     http://annevankesteren.nl/2008/01/ie-lock-in#comment-6376

159. READ THAT AGAIN: NOT OFFICIALLY ENDORSED BY WASP.

     This was a covert job between:

     *** Chris Wilson of Microsoft ***

     -and-

     *** individuals not representing WaSP ***

     http://annevankesteren.nl/2008/01/ie-lock-in#comment-6376

160. _”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?

161. “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.

162. 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”:http://www.onderhond.com/blog/work/IE-meta-switch 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).

163. bq. 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_.

164. 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.

165. 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.

166. bq. “Most people that made broken sites don’t realize it or don’t care enough.”

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

     bq. “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.

167. 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.

168. So, you’re thinking, *what is the worst that could happen if they do this*?

     “A Glimpse of the Near Future”:http://www.webstandards.org/2008/01/22/microsofts-version-targeting-proposal/#comment-59762

     *THIS IS AN ATTEMPT TO UNDERMINE OUR STANDARDS AND SILENCE OUR DISSENT ONCE AND FOR ALL*. *DO NOT LET THIS PROPOSAL GO UNCHALLENGED*. *DO NOT ACCEPT THIS BLEAK FUTURE FOR OUR WEB*.

     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*:

     # “WaSP Statement and Discussion”:http://www.webstandards.org/2008/01/22/microsofts-version-targeting-proposal/

     # “Disclaim of Responsibility by Andy Clarke – Co-lead of WaSP”:http://annevankesteren.nl/2008/01/ie-lock-in#comment-6376

     *DO YOUR PART TO PROTECT THE OPEN WEB*. *BOYCOTT THIS ATTACK ON CHOICE, INTEROPERABILITY, AND STANDARDS*.

     Thank *_you_* for *_your generous devotion of your valuable time_*.

169. @Ray McCord
     You forgot to use super- and subscript (glad Textile doesn’t provide an alternative for )

     But thanks for the links anyway.

170. @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.

     Regards

171. 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.

172. “Alternatives NOW”:http://blogs.msdn.com/ie/archive/2008/01/21/compatibility-and-ie8.aspx#7228772

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

173. bq. Damn you, misleading flat discussion format!

     It is at that. 😉

174. 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.

175. 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.

176. 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.

177. One thing I haven’t seem mentioned here anywhere is:
     Any documents that are marked as 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.

178. 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!

179. 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?

180. 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.

181. 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: http://www.molly.com/2008/01/24/me-ie8-and-microsoft-versioning/), 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.

182. 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”:http://www.w3.org/2005/Incubator/wcl/XGR-report/#objects 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”:http://www.alistapart.com/comments/fromswitchestotargets?page=2#16 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.

183. 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 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).

184. 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.

185. 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

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

     or is the order significant?

186. I’d like to sign a petition.

187. *_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”:http://blogs.msdn.com/ie/archive/2008/01/21/compatibility-and-ie8.aspx#7254512

     *Web developers unite*!

188. 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…

     Dum Dum DUUUUUUUUUUUMB!

189. 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!

190. 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.

191. Having the ability to lock website to a any given browser is really good option.

192. 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.

193. 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.

194. 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).

195. 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 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.

196. 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.

197. 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.

198. 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.

199. 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.

     *Assumptions*

     * 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.

     *Suggestion*

     _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))

200. 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.

201. 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:

     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.

202. 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.

203. 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.

204. 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”:http://www.zeldman.com/2008/01/22/in-defense-of-version-targeting/#comment-29366 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.

205. * 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)

206. 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.

     
     

207. @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).

208. 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.

209. 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.

210. 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.

     http://www.w3.org/TR/html-design-principles/

211. 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.

212. 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.

213. @ 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.

214. Although my first read through the article I was shocked and appalled like most. But after reading “Eric Meyers”:http://www.alistapart.com/articles/fromswitchestotargets 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.

215. bq. 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?

216. 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.

217. 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.

218. 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.

219. 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”:http://www.flickr.com/photos/christopherhester/sets/72157603847933333/ 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!

220. 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.

221. 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.

222. 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.

223. 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:

     
     Or:
     
     Or:
     
     Or:
     
     Or:
     
     Or:
     

     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 .

     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.

     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: http://validator.w3.org/check?uri=http://www.monkeymountain.co.uk/quotes/
     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:
     http://tagneto.blogspot.com/2008/01/x-web-epoch-instead-of-x-ua-compatible.html
     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:
     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.

224. 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!

225. 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.

226. What happens if we’ve used conditional comments to target everything below IE 8 (), [incorrectly] assuming that IE will actually support standards by version 8?

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

227. 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”?

228. 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”:http://blog.vftw.com/view/browsers/ie-8-taking-quirks-and-hacks-into-the-future/

229. 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”:http://blog.vftw.com/view/browsers/ie-8-taking-quirks-and-hacks-into-the-future/

230. 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”:http://blog.vftw.com/view/browsers/ie8-taking-quirks-and-hacks-into-the-future/

231. 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…

     *STAND ON YOU OWN TWO FEET*

     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_*.

     Cheers!

232. @ 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).

     Cheers!

233. 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.

     Cheers!

234. 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.

235. 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.

236. 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.

237. 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.

     Craig

238. 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) gmail.com 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”:http://www.howtocreate.co.uk/wrongWithIE/

239. 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?…

240. 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 tag to ease their conscience, so be it. Compared to the hacks I need for IE6, a single 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.

241. 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.

242. 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.

243. 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.

244. Here is a _precis_ of my objection to this article:

     bq. 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.

245. 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

246. 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.

247. 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.

248. 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?

249. 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.

250. 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 (www.artinsoft.com), has been developing tools to increase web sites’ code general quality and standards compliance (www.aggiorno.com). 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
     http://www.aggiorno.com
     http://www.artinsoft.com

251. 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.

     v

252. 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??

253. 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.