Version Two

Comments (94)

1. This is how I see how life will be harder for other browser makers:

   Basically, people are given the assurance that their site will work in older versions of IE, which will make them expect that same exact rendering behavior from other browsers. The only way other browser makers can give that assurance is by coming up with similar emulated rendering engines, rather than just use their latest and greatest one.

   That’s what they’ve had to do for the original Quirks Mode, no?

2. In that vein, I have to admit that I don”t understand the assertions that this will make life harder on other browsers, that they”ll have to support all the various rendering modes in IE.whatever. Can someone explain that to me, please? I”m not saying the assertion is wrong. I”m saying I don”t understand why that would be the end result.

   All successful browsers to date have had reverse engineer and re-implement the bugs of the successful browser(s) which came before them, at least where those bugs were significantly relied upon by websites. Different browsers have different interpretations of where the “significantly” line should be drawn, but they all do it. If they didn’t, their users would notice too many sites breaking (for various values of “too many”) and would stop using the browser.

   As such, the roadblocks for new rendering engines to come onto the stage has been ever-increasing. Their one saving grace has been that they really only need to be roughly “as good” as the currently most widely used rendering engine.

   What this proposal does is to soon multiply the possible behaviours of that currently most widely used rendering engine. As long as IE remains the dominant browser, all other browsers will be compared to it. And thus it is feared that in a couple of years, when IE9 would be the most widely used browser, for a rendering engine to be successful it would need to emulate not just the bugs of IE9 (once those bugs have become relied upon by a sufficiently large number of websites), but would still also need to emulate the bugs of IE8, and of IE7. After all, that’s what IE9 would do, and so that behaviour is what would be compared against.

   Microsoft might have the resources to throw at this problem and keep all their historical rendering engines working – but any other players wouldn’t have these resources, and so the market would be ever more closed off to new entrants, while the existing other players would constantly need to add emulation for yet another set of bugs.

   If it’s hard for alternative browsers to gain traction on the intranets of the world right now, imagine how hard it would be when every intranet has parts that rely on multiple different sets of bugs.

   Basically, this feels like a direct strike against all the hard work which has been done in HTML5. There the goal is to specify parsing and rendering behaviour to such a degree that it would become significantly easier for a new engine to enter the market (by just implementing the HTML5 algorithms).

   This, on the other hand, is going to introduce an ever-increasing amount of non-specified slightly-different behaviours, which far too many sites will rely upon.

   The only way to not end up in that nightmare scenario is if no one would actually rely on these “frozen” IE behaviours. If the bugs aren’t relied upon, they won’t need to be emulated.

   That’s where for example Hixie’s call to not use this meta tag comes from.

3. I’m with you on all of your points, Eric, except the default behavior. My argument for their plan as it exists is this: if they were to default to the newest rendering engine, it wouldn’t solve the problem that they’re trying to solve with this whole meta setup in the first place. The same people that don’t know about standards and design only for the current IE are the same people that MS is trying to avoid angering with this solution; they’re also the same people who wouldn’t know about the meta switch. If they do go ahead with this solution, it only makes sense to default to the older version.

4. @Dan
   Agreed. If they change the default behavior, then IE8 will break the web, which is the entire problem they are working to prevent with this tag.

   @Sander
   I can see things getting slightly worse, but for the most part, that is the boat they are in now. There are still sites out there designed for IE5.5 and Mozilla has to decide how they want to render those nightmares. Mozilla and Opera and Webkit already have to care about IE5.5, IE6, and IE7, so I do not see the major change in how they operate.

   Their one saving grace has been that they really only need to be roughly “as good” as the currently most widely used rendering engine.

   As stated, they already have to account for at least IE6 and 7, as they have greater marketshare than the other browsers. If the state of IE gets stuck at IE7 as you seem to fear, then they will need to still work as well as two IE browsers, which will be IE7 and whatever the newest IE is since other inbetween IE browsers won’t matter. Or do you foresee a situation where IE6, IE7, IE8, and IE9 all have major chunks of the market?

5. This post really set my mind at ease when I read it this morning. Until that point, I was trying to figure out why, in the absence of the appropriate meta tag, the IE7 engine was going to be the default rendering engine ad infinitum.

   Eric, I appreciated your efforts to present your position and your reasoning in an effort to frame and facilitate the discussion. It is unfortunate how everything on the internet inevitably descends to, well, you know.

6. @Christopher: I don’t foresee each of the IE6-9 browsers having a major chunk of the browser-market… but I definitely fear each of the frozen bug-modes of those browsers having a significant chunk of the website-market, which is much worse (for other browser-vendors; and thus in the long run for us) for all situations where any IE version is the dominant browser.

7. (And in the website-market, “significant” is often a very low value; especially if that happens to include, say, banking websites, or a favorite site of the browser reviewer who’s going to make certain that people won’t even give non-IE browsers a try.)

8. What Sander said is indeed exactly what ‘alternative’ browsers fear might happen. And there will be such issues, the only question is whether they will be serious enough to force non-IE browsers to parse the META elements that are targetting IE versions!

   I remember when Opera 7 had to implement the Doctype switch. We did that because it became clear that this switch, as implemented in other browsers inclduign IE 6, would mean we would continue to get bug reports on our perfectly spec-compatible handling of the box model and CSS error handling, because existing content would never get fixed and would continue to ‘work’. It wouldn’t be so bad if we could just say, well, this old website looks a bit weird, but that happens in all modern browsers – instead, people expect other browsers to ‘just’ handle the web the same way as the number one browsers does, as if what that browser do can easily be emulated.

   So we had to retroactively add some ‘bugs’, and try to figure out *what* this quirks mode exactly did (it is’t documented in any detail on the MS website). Over time we retired a few quirks mode changes because our reverse-engineering wasn’t good enough to emulate IE’s weirdness faithfully, and most interesting sites became to rely on IE6’s Standards mode behavior.

   I think it is useful to distinguish four interested parties here:
   – Microsoft
   – MS-oriented web developers, lazy web developers, and the consumers of their sites
   – standards oriented web developers
   – the non-IE browser makers

   The IE 8 plan makes excellent sense to help the first two groups. And it *might* encourage the IE team to move forward faster with things like HTML5. Though it is very obvious that MS as a company doesn’t have so much interest in the ‘open web’ as the only road forward, which the other browser makers for strategic and/or philosophical reasons are bound to follow.

9. Unfortunately, Dan Ott is correct. If the default behavior is “edge” the purpose of this whole exercise becomes somewhat moot.

   Let me preface my comments by saying that I really don’t know what to think of this suggestion yet…I think it has potential, but it really needs to be thought out and implemented properly.

   However, the concern of MS about breaking the web is valid. Each time a new browser version is released, there are an increasing number web sites that exist, and a higher percentage of those will effectively be ‘dead’ sites…no longer maintained. I can see a value to keeping those sites accessible.

   However, part of the beauty of HTML is that if we code our sites properly, at any point in the future we can strip away style and behaviour and be left with content.

   I also don’t see how other vendors would have to duplicate IE’s rendering engines….that argument makes no sense whatsoever. At worst, if they choose to opt in, they’d be keeping copies of their own rendering engines, not IEs. For example, if you had a site you knew worked in IE7, FF2, Safari2, Opera9, and you included the meta with all those versions, at any point in the future the site would continue to work in all of those browsers, assuming they maintained the rendering engines from the versions the site was verified to work in.

   New sites could always be coded to the latest standards and versions, and then locked in. Old sites would never need to be updated just because a new browser version broke them.

   I guess the biggest question I still have, and if someone from MS could address it that would be great, is what happens 15 years from now? Is MSIE shipped with 8 different rendering engines? At some point, do we just assume it’s safe to drop IE7, IE8, etc and make the default IE10?

   If the answer to that is no, I’d hate to see IE in 20 to 30 years….what a bloated mess it will certainly be.

   If the answer to that is yes, then I think we’re in for an even bigger issue. Folks will assume their old sites will keep working, and by the time they break, they’ll be SO far behind they might not be able to catch up.

10. @Sander: “Basically, this feels like a direct strike against all the hard work which has been done in HTML5”

    Please see http://blog.codedread.com/archives/2008/01/23/microsofts-super-standards-mode-important-facts/#the-main-point

11. Of course, after I post, I find out that using the HTML5 doctype will not require the META tag, it will automatically use the latest rendering engine (according to Chris Wilson via Snook via John Resig)

    http://blogs.msdn.com/cwilso/archive/2008/01/22/i-feel-happy-too.aspx#7202711

    Sounds like this has the potential to get awfully confusing.

12. I frankly do not give a damn what Microsoft does or does not do nor do I give a damn about the state of ‘technical’ standards. It will all work out in the end.

    What prompted the statement was reading the thread and comments and thinking about Microsoft’s proposal when your masthead image caught my eye, –the little girl touching the aquarium glass. [Excellent photo the way.]

    There are more pressing issues at hand that impact people, including children, in their use of the Web. Things such as security, safety and privacy.

    More focus needs brought to bear upon development and implementation of ‘social’ standards.

    If dropping in something as simple as a meta tag clears the way for a better application of technical standards and rendering, why all the fuss.

13. @Sander:
    There is no reason for the IE team to introduce a new bug-mode for every release. Don’t forget it has a cost for them, too, and the team itself does not appear to be very large. As long as there are not too many websites that are both targeted to use complex CSS2 effects (the kind that will need the IE8 layout engine) and feeds buggy code to IE, there will be no need for a new bug-mode and IE9 will be able to evolve the IE8 layout engine.

    To say it plainly, if you either:
    1. use only 100% standard compliant code (with or without the opt-in, it does not matter)
    2. ensure that your web site works with IE7 and don’t use the IE8 layout engine
    3. use quirks mode
    then you are not adding any motivation for new bug-modes. I guess most people here would choose 1.

    Another mitigating factor is that layout engines are converging to the same point anyway, so differences between successive bug-modes should decrease. Browsers with a lower compatibility bar than IE will need much fewer modes.

14. The only way to move forward and not “break the web” is to EOL Internet Explorer. Microsoft needs to start a new browser that’s standards compliant and can run side-by-side with IE.

    This way, anyone who needs backwards compliance can have IE and never have to move on, while the rest of us can keep moving forward.

15. Why is the focus on us solving Internet Explorer’s problems?

    We’ve heard the proposed solution from Microsoft, there’s a rather large voice shouting out from the web standards developers that its unacceptable. That means Microsoft needs to go back and try something else.

    Is that not a valid position? Why must we have a solution to deal with Microsoft’s woes before our concerns are taken seriously?

16. @Jeff Schiller: I’m aware of that, but it’s no long term solution, as Chris Wilson has already stated many times that as soon as a significant amount of sites (for a very small value of significant) relies on IE bugs while using that doctype, they’ll freeze their behaviour for it.

    Also, since you responded to my HTML5 comment with that: the HTML5 parsing algorithm doesn’t just apply to sites with the new easier doctype, but to _all_ HTML, and so it still feels like a strike against that hard work.
    (The new doctype isn’t the “html5” doctype, but merely the simplest possible doctype possible, needed only because lack of a doctype implies quirks mode. (Non-IE) browsers won’t have separate code-paths for HTML4 and HTML5; they’ll have one code-path for HTML.)

    @Lionel: we can hope. But the IE team will need to have gotten IE8 right to an astonishing degree – or IE8 market share will need to never become very high at all – for the amount of websites relying on IE8-bugs to remain low enough to prevent a new frozen mode.

17. It seems as if an almost perfect combination of measures is in place right now, in light of IE’s recognition of the HTML5 doctype. The HTML5 doctype can be used to trigger the latest standards mode in all browsers, while IE can have its proprietary (meta) flag to roll back the engine, whether HTML4 or HTML5 is being used. Current HTML4 content will use the IE7 engine in IE and the latest standards mode in the rest of the browsers. Current (and older) pages don’t break any more than they have in IE7 and web developers can use standards to get the latest standards mode.

    The only thing I’d like to see differently is see the (meta) flag become a comment (like conditional comments) so that only IE bothers looking at what rendering engine it should use (since IE is the only browser that needs this flag). I would argue the issue of having multiple rendering modes, but the IE team seems fairly content on having a switch (with arguments since, what, March 2007?) and I don’t particularly care if IE becomes so bloated that users start switching to other browsers for a faster (and better) web experience.

18. There is no reason for the IE team to introduce a new bug-mode for every release.

    Yes there is: to multiply the amount of work required to implement an “IE-compatible” browser, and therefore raise higher the barrier to entry for potential competitors.

19. “I also don”t see how other vendors would have to duplicate IE”s rendering engines….that argument makes no sense whatsoever. At worst, if they choose to opt in, they”d be keeping copies of their own rendering engines, not IEs. For example, if you had a site you knew worked in IE7, FF2, Safari2, Opera9, and you included the meta with all those versions, at any point in the future the site would continue to work in all of those browsers, assuming they maintained the rendering engines from the versions the site was verified to work in.”

    As an Opera user, I’ve seen countless pages that have a sniffing script that goes like this:

    if (IE) { do something }
    else if(FF/Netscape) { do something else }

    In other words, Opera (and others) were completely ignored. This could happen with this tag as well. Which rendering mode should Opera use for a page that uses something like this?

    <meta http-equiv=”X-UA-Compatible” content=”IE=8;FF=3″ />

    Should Opera keep track of which rendering modes in other browsers are compatible with its own? And what about combinations as in the example above? Should there be separate Opera rendering modes compatible with IE8, FF3 and IE8/FF3? If you ask me, that’s why this is a nightmare for the small players.

20. Hi Eric,

    You said today:

    I suspect that a good deal of the emotional objection springs from a perception that the proposal is to require all browsers to implement targeting.

    That may be true, but I think how this issue was positioned and presented to the community is largely to blame. When you get down to the details of the problem — sites built for IE6 are not going away and need a way to continue working in the new standards-compliant environment — and the proposed solution (a single tag!), it seems pretty simple. Easy to digest, not a huge digression, everybody should be able to discuss this reasonably, right?

    But I think the articles posted on ALA set the stage for the mayhem that ensued. To paraphrase what I said in response Zeldman’s post: your opinion piece was kind of depressing. You seem resigned to version targeting as a solution. Your piece listed many reasons why it”s a bad idea and that you’re going along because “We”re not reaching everyone, and probably never will” and what I think is the most damning bit:

    We say forward-compatible development is the mark of a professional because that”s what the profession demands. With the advent of version targeting, that need may simply evaporate, rendered not wrong but moot.

    Wow, strong words. Later in a comment you said “I still mourn the blow this will deliver to forward-compatible development…” and thereby delivered another blow yourself. Why position this option as the death of progressive enhancement or as our only option because the world will never adopt standards when the opposite is true: we can still code as we do now in a forward-compatible, progressive enhancement way?

    With all that doom and gloom it doesn’t surprise me that everyone reacted the way they did, or that level-headed reason wasn’t a bigger factor.

    As for using this tag, in general it’s a good start to a solution that will help lots of folks who are stuck supporting old IE6 code. I also I agree with most dissenters who say that locking the browser to IE7 by default is a bad idea. The only rationale I’ve heard for requiring that we “opt-in” to standards is flawed: that the uneducated will remain uneducated so the impetus is on us “special” web standards folks to add the tag (thanks Mr Zeldman for calling us “special” — could you be a little less condescending next time?). :) I think we should give people the benefit of the doubt, assume that we are all smart and capable, and just clearly communicate the pros and cons — and Microsoft should shoulder the responsibility of communicating a fix, not rely on the wider group of developers to make up for their past errors.

21. An idea is only a good idea when the reasons to do it outweigh the reasons to not. This is an idea that benefits Microsoft, and perhaps intranets using Internet Explorer, but that’s about it.

    This new meta element is simply a tool to maintain or extend Microsoft’s market share. Crucially, no other browser vendors need it (because they do things properly), and few would want it because of the security risks and increased hard drive and memory footprint all the different rendering engines would bring.

    That something needs to be done is beyond question. Just not this. It would be better if Microsoft simply ran IE7 in tandem with IE8 for a few years, touting IE8 as a new (but optional) browser experience for modern websites. Free of legacy rendering and quirksmode(s), IE8 could be awesome.

22. I think many of these things are non-issues:
    Developing competitive browsers is harder. What other browser on the market has a mode that replicates IE’s current layout model (with hasLayout)? I believe the answer is none. The fact is that the current versions of browsers have already diverged. There’s nothing more that they have to support.

    Why are we solving Microsoft’s problem? We’re not. Microsoft is developing a browser and you can choose to support it or not.

    Freeze IE and build another browser I’d say that the meta tag effectively does the same thing. The lack of which has frozen IE7 in time. Add the meta tag and you have the latest and greatest.

23. Jonathan Snook says: “Why are we solving Microsoft”s problem? We”re not. Microsoft is developing a browser and you can choose to support it or not.”

    Simple answer. If Microsoft’s browser does not support standards compliant websites by default, we chose not to support it because its not a standards supporting browser.

24. I don’t see this as us solving Microsoft’s problem. I see it as working with them to solve a problem that we all have.

    This is what the WaSP did in the beginning, particularly the CSS Samurai. It’s what many of us have done time and again over the years. Browser makers, tool vendors– all have asked for advice, and received it, from both “experts” and the whole community.

    That’s the background that informs my approach, and is why I see this as I do.

25. My principal concern is in the future, what will happen when they release IE9, suppose that they release IE8 with this meta tag, the tools that generate HTML include this meta tag like now they include the doctype, then a new specification comes along (HTML5 if you want), what will happen, IE8 can’t handle HTML5, but IE9 will, and all the content has that meta tag because the tools include it, where are back where we started, we can’t change the current super standard engine in IE8 because it will break existing pages that relay in IE8 behavior, so IE will add a new engine, super extra mega standard engine. Better yet, each release of IE should contain a new engine, the ones that care will update the meta tag, and the ones who don’t will be OK for ever and ever, it doesn’t matter if we end up with a browser with 10 engines because the web will never be broken.

26. MCW, I wrote my article without too much glossing, documenting the process I went through and accurately reflecting my feelings about it as much as I could. And also by presenting my hopes and fears in an unvarnished. If that is what triggered the emotional backlash and invited the vitriol, then I sincerely apologize for my role in worsening the debate.

27. Chasen, I share your sentiment about using a comment, like in conditional comments, except I think the rationale for using the http-equiv meta was that servers could emit the information in the headers they return, and not need the meta in the markup. A comment wouldn’t have that equivalency.

28. thacker—thank you. It’s a picture of my daughter, actually, and its coming up today was well-timed, I thought. I glanced at it more than once while writing the post in order to enforce a quick perspective check.

29. Rijk and Sander and Fyrd, thank you for making that more clear to me. I was unaware that browsers were doing quite so much cross-emulation.

    The question, though, is: should they? Much of the objection to version targeting is that IEx should just go to the standards as much as possible and not support the errors and quirks of older versions of itself. Shouldn’t the same also be true of other browsers, both with regard to older versions of themselves as well as with regard to what other browsers do? Or is the concern that such an approach only works if all browsers take that approach, whereas if one of them breaks ranks, the rest will be forced to follow suit?

30. Freeze IE and build another browser I”d say that the meta tag effectively does the same thing. The lack of which has frozen IE7 in time. Add the meta tag and you have the latest and greatest.

    It’s close, but no cigar. Freezing IE and building another browser sends a strong signal to customers and developers alike that:
    1.) We recognize that sites/apps can and will break with new and updated browsers
    2.) You can continue using IE for as long as you need to, we’ll keep it available for the next N years.
    3.) We are committed to standards and we want you to continue writing to standards in the future.

    By requiring the addition of a browser-specific tag in order to trigger the most standards-compliant mode available isn’t the right message.

    Yes, it may effectively be the same, but it’s not the same message. It’s not agreeing to the same contract of developers building standards-compliant code and vendors building standards-compliant browsers.

31. I”m not sure I buy the “strike against other browsers” concept. I think Microsoft is responding to complaints from its customers, and making IE 8 meet their expectations better. If those customers wanted a browser that still renders old, coded-for-IE sites, they wouldn”t be picking Firefox anyway.

32. @Eric: Other browsers indeed try to stick to the standards as much as possible, and should, and epic battles are fought internally to not give in. But despite that, there are many points at which gaining any foothold in a certain segment of the market is just completely stalled because everyone depends on something non-standard, or because a very-high-visibility site is stubbornly refusing to stop relying on a bug that’s having a large impact on users (luckily getting pretty rare now that Firefox has solid marketshare), and evangelism is just not getting anywhere. And then, yes, one browser is the first to break ranks, and that leaves the others with pretty much no other choice than to follow (though each will have had the same internal discussions, and it’s mostly up to chance who’ll be the first to add yet another bug emulation).

    High profile cases of this have been the adding of such “features” as marquee and a limited form of document.all support in Gecko; but there’s dozens upon dozens more where it wasn’t “features” but rendering ‘quirks’. In the best cases they would’ve been complete edge-case, and so the CSS 2.1 spec could be updated to retroactively turn IE’s way of doing things (when not completely illogical) into the new standard (hoping no real world sites correctly used the old way) – but that’s not always the case, and so everyone else will have to follow suit, as those bugs will now never ever stop being relied upon.

    This is also something where browser makers are increasingly taking the long-term view on things. They still feel the pain of having to reverse-engineer IE’s reverse-engineering of obscure Netscape table-layout-bugs. (This quote always illustrates that nicely.)
    Anything which freezes broken behaviour now will be a really large pain five to ten years down the road.

33. I’ve made comments on Zeldman’s blog and ALA already, but let me just add one simple point here:

    We’re all in the business of solving problems, right? Test this solution against Occam’s razor.

    We’re talking about adding multiple rendering engines, each presumably with a different way of rendering in quirks and/or standards modes, to all successive versions of a major browser. Developers, then, must code in either a meta tag to each of thousands of pages, or serve an HTTP header millions of times, to control the outcome.

    The standards movement has endeavored for years to move toward simplicity to solve our interoperability problems.

    Does this solution follow or support that tradition?

34. Bad timing?

    In an earlier piece you wrote “Now we have IE8 in development, and there is a real chance that it could push standards support forward in a significant way.”

    Or backwards, perhaps?

35. @Eric:

    servers could emit the information in the headers they return, and not need the meta in the markup

    The potential for pages to render differently depending on hosting environment seems like the source of endless confusion to me. For example, I still haven’t seen a good response to the problem of what happens when pages are saved locally, i.e.:

    1. Load website.
    2. Header is passed, page is rendered correctly, in standards compliant mode.
    3. Save page locally.
    4. Load saved page.
    5. No header, page is rendered incorrectly in IE 7 mode.

    A work-around (albeit ugly in my mind) would be for IE to alter the saved page, inserting the meta tag into the html source before saving to disk, if the header was received… but even this does nothing to help when pages are saved via some other means.

36. I would like simply to comment (and not with the intention to stir more the line of the topic), why when things tend to merge, to centralize, to work in unison harmoniously, to have social networkings, I could go on with examples, we still need to deal with this type of things? How hard would it be for browsers to have a common standard rendering engine? (although I don’t really know much about rendering engines). How hard would it be for browsers to act like if you were using a Flash site that renders well across every browser or Java Applets or more lately Flex? How far should it go the version of this, the hack for that, the targeting for this, the concern on this or that, etc? I don’t know, maybe this is a bit off the topic, but I always wonder about it. I’m starting to think that might be better to push more for standards, accessibility on other type of medium like Flex or Flash.

37. Why were we instructed by Microsoft to begin using Conditional Comments as a way of ensuring future-proofness if we’re still going to need to implement version specificity on a page-level granularity?

    I moved from IE-hacks that exploited flaws in the logic to conditional comments that did a much better job of loading different exceptions in certain use-cases. But, knowing IE7 would one day be bettered by a more standards-compliant browser, all my conditional comments are conditional on the version being less than or equal to 7.

    Now we’ll get a new browser with a new version number, but which has the same exact issues (by default) with rendering that IE7 did?

    So every client whose site I developed using the best practices that IE themselves recommended is now going to need to be updated; either with the meta tag so the browser can render in full standards mode, or by increasing the conditional comments’ version cap to 8?

    Why should my clients have to pay for that? Why should I?

    The meta tag solution is terrible, because it requires revision to sites that are otherwise working properly. The better solution would be a meta tag that allows content developers to insert the version of the browser that the site was developed against in a DOWNWARD sense. If the site is standards-compliant (DOCTYPE declared etc.), it should be up to the developer in question to explicitly declare that they DON’T want the IE8 fix if that’s the case, since they’ve already indicated to the browser that they prefer a standards-mode method of operating. That’d be a one-line update for developers who aren’t prepared to redesign or redevelop their websites for later browsers, and would also be a valid solution after IE9, 10, etc. is released.

    The point is, if Microsoft recommends I upgrade my browser, I don’t want to see all the same bugs in the code that was written properly. It should be in IE8 standards mode by default, allow an explicit downgrade of standards support if the developer so chooses, and if the code cannot be changed, let the user decide they don’t like standards support and revert to IE7. It’s not like they’ll leave IE for Firefox; it supports standards *better*. Then IE7 becomes a milestone, IE8 becomes a milestone, and each revision of the browser can be treated independently to eachother.

38. Setting the IE7 rendering to be the default rendering now will make it to be the default forever (well untill MS comes up with yet another ‘fix’). IE22 will still have to render pages as if it was IE7 if no switch is included that tells it to do otherwise. If it does not then the web will still be broken.

    Therefore the default behavior should be changed to “latest” as you stated. And the switch (if any) should be inserted in pages that will break, because that’s where the fixing needs to be done.
    That way not all pages will be rescued from breaking as not all will be updated with this switch. Therefore MS could include a classic mode in its browser, say the IE7 engine, and let users switch in cases where the old pages are not updated with a switch.

    That way:
    * MS only has to maintain only two engine versions instead of all from IE6 and up: the current/latest and IE7/classic.

    * MS does not have to fork a new browser (in a way this is a fork, but it doesn’t look like it) which would be like admitting that their product was bad

    * This “break the web” issue will stop showing up each and every time MS releases a new version of IE and no future fix will ever be necessary to set a new (non-IE7) baseline

    * The proprietary switch will only be inserted into pages that are already stuffed with proprietary, non standards code and probably by the developers who delivered this code themselves (let them pay for their own deeds)

    * IE-only pages that are not updated will still be accessible in IE as the user can switch the engine if necessary (of course these pages should be remembered)

39. I have 3 main issues with this:

    1 – it’s defaulting the wrong way – backwards, to the past. Ok, Microsoft needs a backwards compatibility story and this meta-tag is it. Alright. But don’t inflict IE7-forever on people who are doing the right thing. If people don’t want to fix their broken intranets of whatnote, then MS can just point them towards the meta-tag info and they can choose to retain the old rendering mode. I can’t see how this wouldn’t be a win-win for Microsoft – as this debacle shows, everyone in the web development community has been through the collective trauma of ~6 years of IE6 pain and are angry with Microsoft – rightly in my view. Microsoft could do with some good will from this camp – saying that they’re developing IE8 to be hugely more standards compliant by default (passes Acid2 in alpha, remember?) would do this; win for web devs and standards. Having the optional meta-tag as a work-around for people who need to preserve the old rendering mode would provide backwards compatibility for anyone who needs it; win for everyone else. There – win-win! Why not do it this way? Except now that they’ve announced it they can’t switch it round without invalidating their breaking-the-web straw man.

    2 – Finally – how is this really going to work, in detail? There must be, somewhere within Microsoft, a big flow chart which shows exactly what’s planned to happen with every combination of HTTP header, doctype, meta tag and javascript version and conditional comment. Or at least I hope there is. We need to see this really soon, not when the beta comes out, which – judging by past experience of IE betas – will be about 6 months before they’ve ‘committed to a release schedule to our important customers’ and too late to make any changes in the browser anyway.

    3 – Do we really expect IE8 to manage to perfectly faithfully render a page in IE6/7 mode – without any bugs in this bug-compatible rendering? The only way that I would expect _perfect_ fidelity would be for IE to be carrying 2 rendering engines around, not one big one with an extra mode. This will make the flowchart from 2 much more complex, especially in a mixed meta-version environment, like frames. I would like this clarified.

40. Pingback :: Wednesday, January 23rd, 2008 10:23pm

    The X-UA-Compatible Situation : Kempwire.com

    […] Eric Meyer gives us more insight into his reasoning on the situation. […]

41. So, when IE7 came out, lots of web developers complained that their sites—developed for IE6—broke, and they scrambled to fix them. I see this as evidence that all those sites are being updated and maintained.

    If IE8 came out with good standards compliance by default, thereby breaking sites coded for IE7, then as soon as developers started complaining that IE8 broke their site, Microsoft could say “just add <meta layout="b0rked-like-IE7">”.

    This would work. As I wrote above, IE7’s release demonstrated that there are people out there who will make minor updates to fix old sites for new versions of IE.

42. I don’t understand why Microsoft needs to do this. I understand there was some level of pain when IE7 was released for those sites that weren’t standards-based. Is the pain for those sites to move from IE7 to IE8 the same amount of pain? This would imply that the differences between IE7 and IE8 rendering is substantial. Otherwise it would appear that Microsoft is knee-jerking a solution to a problem that has already largely been fixed. Those sites that had to change did, those sites that broke but nobody really cared didn’t, and those sites that were standards-based (as mine were) required little or no changes. The release of IE7 was a non-event for me except that it was the best browser that MS has released to date. And frankly as a developer I can’t imagine that the MS developers actually working on IE8 want to hamstring their new baby along with its acid2 rendering by hiding the good bits behind a meta tag.

    I cannot see this as anything but a mistake and it’s sand in the face for the many developers who have developed to standards with the expectation that with each new browser version, IE or otherwise, that our page rendering will improve, and browser sniffing and hacks will slowly disappear. I have always developed my pages for the latest browser version and then fixed issues for older supported versions. With this proposal it makes the most sense just to target version 7 forever and if MS tells me that those pages will continue to render exactly the same way for all future releases of IE, why would I ever bother to change.

    Yay MS, they really know how to generate momentum for their new products. Maybe they could add a similar meta tag to Vista/Windows7/etc so that they behave like XP by default.

    Hmm, my original post disappeared, just checked managements reserved rights and I don’t think I’ve contravened any? Guess I’ll try again?

43. So far two main impediments to having standards-based rendering as the default in IE8 have been raised: Business-critical applications and sites, typically within a corporate intranet or for commerce, and fixed archives of pages, typically preserved on some form of media being locally accessed (though online archives such as the Internet Archive are also a potential issue).

    For business-critical applications, having an extra header applied by the server seems to be a feasible and practical approach, and I think it should be relatively straight-forward to deploy. It is highly probable that this type of content is contained within specific servers or directories within the servers, so just applying the header globally on a server or directory basis should suffice.

    For cases like pages bundled with an application, a bit more slight-of-hand is needed. One method could be for IE8 to render pages served from the local file system by default using the IE7 engine. However, if a specific metadata file exists in the directory with alternate instructions, then these instructions are followed (e.g. there could be an optional .render-web-content-db.xml file that could store the appropriate mapping). Addressing Matthew Carroll’s concerns, IE8 could save the appropriate directives into this file when the web page is saved. Web developers can manually create this file as required when developing web pages, and web developer tools can generate it automatically as needed (ideally there would be some kind of wildcard or other way of specifying a default, so all files in the current directory could be specified as requiring the latest standards-based rendering). It would be highly unlikely for existing legacy content to have this special file present in the right format, so this approach should be backwards compatible.

    Online archives would require a bit more work, since they would have to capture the value of the X-UA-Compatible header and replay it when the corresponding archived page is served. Legacy content captured before the official rollout of the X-UA-Compatible header can be assumed to be built for IE7, and the IE7 value can be passed in the X-UA-Compatible header.

    With these three approaches, I believe the major obstacles to using standards-based rendering by default can be addressed. Can anyone think of any issues with these methods, or of any other key scenarios that need to be resolved?

44. Pingback :: Thursday, January 24th, 2008 12:29am

    How IE8 Gets Standards Compliant | GrantPalin.com

    […] and later shows how some of the merits of the technique got him to change his mind. He also wrote a follow-up post on his personal […]

45. Pingback :: Thursday, January 24th, 2008 12:54am

    Shallow Thoughts » More on the Meta

    […] Meyer wrote another article expressing his disappointment at the vitriolic reactions of the web design community. Completely […]

46. Whatever the proposal’s virtues, it also has the consequence of making future versions of dominant browsers more attractive than those of minority browsers (including future entrants) merely because such versions are the descendants of a dominant browser. This effect exists today, but version targetting makes it much worse.

    In this case, the version targetting is valuable to Microsoft because it can offer support for IE6/IE7 targetted documents for free. This is good for Microsoft, because there are so many documents like that. It’s akin to providing a feature, like in-built PDF support. Competitors can’t implement that feature for free.

    Perhaps I’m wrong, but I thought standards had two purposes: 1) to make developer’s lives easier and 2) to permit and encourage competition amongst multiple UAs. Microsoft’s proposal will contribute to (1) while harming (2).

47. Since I found out that the HTML5 doctype puts IE6, IE7, upcoming IE8 and other current browsers in standards mode, and that new html-elements can be introduced to the IE6 and IE7 CSS-engine with some javascript, this switch thing doesn’t really bother me at all anymore.

    It is sad though, that standards mode is opt-in and not opt-out, because it will keep all those people responsible for all those websites that made the IE team take this decision, in the dark. And it WILL break sites that use conditional comments to target errors in IE7 and lower.

    … or maybe it isn’t sad at all actually. I really hope IE8 rocks.

48. Ok, maybe I have a few more issues.
    I don’t buy the concept of version targeting for HTML and therefore don’t think that the stuff about this being important for digital archiving is relevant to this discussion at all. This is just about a short term fix to a short term problem.
    Version targeting blatantly doesn’t work, even for software which has been doing it from the beginning (Office suites, for example) – they break themselves and have both backwards and forwards version compatibility problems or complete failures with almost every release – and, ironically Microsoft Office is especially bad at this, possibly on purpose.
    Whereas HTML by virtue of being designed to be forwards and backwards compatible with itself and being open and simple – doesn’t have these problems.

    For example this is the first web page ever written: http://www.w3.org/History/19921103-hypertext/hypertext/WWW/TheProject.html

    Works fine in my browser.

49. I suspect that a good deal of the emotional objection springs from a perception that the proposal is to require all browsers to implement targeting. Not at all.

    This was my first thought when reading about the proposal. I don’t see any need for other browsers to adopt this system, because all (most) other browsers are standards compliant enough that developers don’t need to hack their CSS to workaround their bugs. I can honestly say I’ve never had to write a single hack for anything other than IE.

    Because of this, developers aren’t generally that concerned when a new version of Firefox, or Safari, or Opera etc. is released. When a bug in those browsers is fixed, it doesn’t matter, because they never had to workaround/hack it in the first place. There are of course exceptions to this, but they are in the minority compared to IE.

    As for the proposed default behavior, where no X-UA-Compatible information gets you the IE7 rendering, I can”t defend that, nor do I have any wish to defend it.

    Agreed. The default behaviour should be the latest, and you should have to opt-out of standards mode, however this probably won’t happen.

    If the standards opt-in really is going to be the solution, then ideally I’d like to see it as a one off solution, specifically for the jump from IE7 to IE8. I’d like to think that IE8 will bring IE up to the same level as other browsers, and future updates (IE9 etc.) will be as seamless as other browser releases.

    In two or three years time I don’t want to be in a situation where I have to specifically target my pages to IE9, just in case a future IE10 update breaks something.

50. I don’t have the time to read all the posts above, so I hope I’m not repeating a point.

    I see in this a shift from theoretical to practical testing.

    The doctype switch said: “My page is made along certain rules (standards) and I hope browsers use the same rules in rendering it.” It has its uses, but with bugs and incomplete support for standards, we’ve seen this fail as well.

    This new version switch says: “My page has been tested to work in these browser versions.” This is a much more reliable test, although its succes will depend on how well future browsers maintain (bug-for-bug) backward compatibility.

    It is important to realize this is a statement, not a requirement. “IE=7” does not mean a browser (IE or others) must render it in an IE7 compatible way, but if it does, the site should work as intended. So Firefox does not need an ‘IE7 compatibility mode’.

51. But remember, “let old sites break” is a non-starter. You might as well say “let old sites not load at all in any browser”.

    No. It has always been this way for non-IE browsers (and indeed IE5 -> IE6). Once sites are seen to break, the author knows they have to update the code for the latest browser. Just like I have to update my VCR to a DVD player to play a DVD. I don’t expect my VCR to be able to play DVDs.

    Microsoft are running the risk here of permanently freezing sites that only work in one version of IE. But why? No other browser maker has this attitude. They know an old site will still be rendered by their newest browser if it was coded to standards, and if not, the changes will hopefully be small.

    What we have here is a problem with IE rendering incorrectly. And God knows how many other things it gets wrong, such as sending incorrect headers, image and cache problems, JavaScript bugs and so on. We’ve all come across these nightmares in one way or another. Why continue to support these bugs? Why not make IE8 a fresh start? If pages break, surely the authors will fix them over time? (If not they shouldn’t be doing their job.)

    In that vein, I have to admit that I don”t understand the assertions that this will make life harder on other browsers, that they”ll have to support all the various rendering modes in IE.whatever. Can someone explain that to me, please?

    Other browsers won’t have to copy IE’s rendering, as far as I understand it, but have their own back versions of engines included. So a site that works in Firefox 2 can be frozen (as if that would happen!) and rendered in that way by Firefox 3 using the meta tag.

    So. Microsoft are once again trying to steer the web towards their way of thinking. I hope it backfires and people move away from the horror of IE altogether. It’s had its day. Even if IE8 is amazing, so what? Other browsers will be even more amazing by then. Ones like Opera who have had generated content and display:table for years. To hell with bad browsers, as Zeldman I think once said.

52. There seem to be two different issues wrapped up in this debate.

    The first is whether Microsoft (or any other browser maker) should implement this browser versioning method.

    The second is the default behaviour that IE8 exhibits when the meta-tag is absent, and I think this is the one that has upset the most people, whether they see it like that or not.

    Personally, I do think that the ability to say ‘render this page like IE6’, for example, could be quite useful to a lot of people who may not have the time or expertise to update their CSS.

    The default behaviour, however, just seems wrong to me. I completely understand why Microsoft would want to implement it this way: as has been mentioned, the developers most likely to implement the tag are those who do develop to the standard box model and with advanced CSS techniques.

    Ultimately, it is up to Microsoft how they want IE to behave. In my opinion, making IE7 the default rendering engine for IE8 is a mistake : it gives them an inferior browser out of the gate, and freezes standards support, for better or worse, for those who don’t know of or refuse to use the switch.

53. In addition to my previous comment, what is the actual status of this proposal, is anything actually up for debate here, or is this now set in stone?

    As others have pointed out, one very good argument against the default mode being IE7 is conditional comments. Microsoft told us to use conditional comments for our CSS fixes before IE7 came out, and now every single site that uses an “IF IE 7” or “IF lte IE 7” condition will break because the styles wont be applied, yet the rendering mode will be the same!

    By “not breaking the web”, they are in fact breaking the web, all because of something they told us to do. And if it’s a choice between breaking old sites which aren’t standards based or breaking new sites which are, I know which one I’d choose.

54. How many sites are there that we would expect to break IE8, but to work in all other browsers? What hacks and kludges have people used to achieve this? I would expect that anything that works in Opera and Firefox should work in IE8 as well – unless it has used a bug or hack that targets all versions of IE.

55. It seems that, under the proposed scheme, that a meta element must be added to the Acid2 test for IE8 to display it correctly.

    Did you consider this issue when your first reviewed the scheme?

    Do you think WaSP should change Acid2?

56. It has to be realized that this may well be the only way for IE to advance its standards support in a reasonable time frame, or at all. Version targets let them avoid breaking existing sites, especially intranet sites, while fixing and adding their DOM, CSS, and other implementations. That has to be understood and accepted if the discussion is to be anything more than people talking past each other. Within the world of IE, they must have a way to uphold backwards compatibility with sites developed under older versions of IE.

    That was a great section, Eric. Thanks for posting this follow up.

    I think the only thing about this that irritates me is that, right now, we have to do all these special things for IE, add all these little extra pieces of code (whether it be browser detection, CSS hacks, conditional comments, etc). And now here’s yet another line of code to put in.

    This is all fine, but I think the key to this not causing an uproar is publicity since the default rendering will be for IE7. If it defaulted to “edge” then it wouldn’t matter if no one new about this. If the word doesn’t get out enough (it apparently seems to be getting out just fine) then it will just cause more and more hacks to come out of the woodwork.

    For example: IE stand alone versions are kinda crappy, I run an IE6 stand alone, it’s pretty unstable and you have to edit the registry to get conditional comments to work. So, let’s say a developer is running IE v10 and for some reason doesn’t add in this meta tag and it defaults to an IE7 rendering, but this person doesn’t have IE7, they’re running IE v10, so their site looks messed up pretty bad. what can they do? They can use hacks and conditional comments to make it look right, as they see it.

    I have a feeling that this sort of thing will happen quite a bit unless Microsoft changes the default to “edge”, maybe builds in a soft error message or makes sure developers are well aware of this tag.

    my2cents

57. Pingback :: Thursday, January 24th, 2008 10:37am

    csskarma.com/blog » IE8 - Version Targeting

    […] That was a section, from Eric Meyer’s post yesterday […]

58. @Don Field: if Microsoft go ahead with IE7 rendering as the default behaviour of IE8, then IE8 does not pass the Acid2 test. Acid2 (just as Acid3 will) requires default settings for compliance. We’ll not be updating Acid2 to make it work with IE8, as that’s precisely backwards.

    Eric, I made some notes on my thoughts about version targeting and JavaScript libraries. They became quite a long comment, so I posted them to my own site.

59. Eric, with regards to your comments of dissapointment with how some people have reacted, I think that partly because they feel let down.
    We tend to expect WaSP, and specifically people like yourself and Jeffrey Zeldman, who’ve been promoting this idea of forwards compatibility and writing good code etc… to help defend those ideas. Yet this proposal seems in complete opposition to the philosophy we’ve been fed the last few years.

    And to hear it first at ALA, with comments from the like of yourself in relative support of the idea, promoting it as a general “this is good for the web” thing, rather than what it is, an IE hack, leaves something of a bad taste in the back of my throat. It feels like a bait and switch, it feels like the antithesis of what we’ve been arguing for for the last few years.

    Not to mention the fact that Zeldman implied that we were all ingrained MS haters for opposing the idea, feeling as derogatory to me as anything that may have been aimed at those of you promoting it.

    There have been angry replies because a lot of people are angry about. Some people perhaps take it too far, and we all know what people in certain communities are like, as well as the ever present trolls. But I think most of us on the whole are angry about it because of the reasons I’ve mentioned above, we don’t like the idea, and we want to make damn sure you know how bad we think it is. To calmly discuss it in an understated way doesn’t seem like a way to stop it being implimented. Indeed, how many of the people who moaned about IE7 breaking things did so in a calm manner?
    The very fact this idea is being suggested is because those people moaned hard and loud. If that’s what it takes to make our opposition known, and give the best chance of it being stopped, expect it to be loud and hard.

60. Chris, it’s a good question. To me, as a developer, this does not unnecessarily complicate things. I either add a line of markup/emit an HTTP header/use an advanced DOCTYPE, or don’t. Compared to all the other things I have to contend with in development, this strikes me as being pretty small beer. But it’s clear many disagree with me on that score.

    Kit, I don’t know why conditionals were recommended, and I otherwise agree with you. As I said, I failed to make a persuasive argument in its favor. One of the points I made in the argument was that they could default to the latest and, if customers experienced broken pages in a future release, to tell them that adding a single line to their pages would “fix” things (by invoking IE7 or whatever). I thought it was a very simple tech support call answer. It didn’t fly. Maybe if enough people say it, it will.

    You might be right, voracity, but one of the things you said lies at the heart of the problem: “there are so many pages like that”. Which is exactly what the IE team must handle without major breakage. If there’s a way to do that which doesn’t also make future versions of their browser more attractive to people who used past versions of their browser, I haven’t heard it yet.

61. Duncan, I still maintain that version targeting has been working for years, and we’ve all been doing it. Otherwise there wouldn’t be a plethora of CSS hacks, let alone DOCTYPE switching. Yes, this is a whole other realm of versioning.

    Also, your assertion that the first page “works fine” in your browser assumes that “works fine” doesn’t mean “looks the same as when it was developed”—because I guarantee that it doesn’t. For very simple pages like that one, it’s not really an issue. For the home page of a large e-commerce site, a social networking site, a massive intranet, or even a government entity, it’s an issue.

    Agreed, Rogier.

    Chris, people keep asserting that Firefox (et. al.) will have to maintain version targeting code. No, they won’t. Not if they don’t see a need.

    I also don’t agree with your VHS/DVD analogy. This, to me, is more like an old CD not playing in a newly-bought CD player. I would expect (nay, demand) the new CD player to maintain backwards compatibility with CDs, even if the CD format specifications have been updated in the meantime.

    My analogy is probably also imperfect (as analogies are, by definition) but it’s a lot closer to how I see this. And hey, if the effort of doing all this strangles IE under the weight of its own targeting, won’t that get you the result you’re seeking?

    Jack (and others), that objection rests on the assumption that conditional comments won’t be treated according to the X-UA-Compatible value; that is, that the conditional comments will know IE8 is IE8 even if it’s in “IE7” mode. We don’t know whether that assumption is correct. I doubt that it is, but I’ve been surprised before.

62. Don: no and no. But Acid2 has never been of much interest to me.

    Adrian, here’s the thing: we are still defending those things, or trying to defend them. In fact, we’re still trying to make things better for the people who care about those things. And this proposal, at least in general, seems to offer the best way to satisfy both sides of that coin. That would be more the case if the default were “latest”, and as I’ve said, I argued hard for that. Because I was defending those principles. I failed. I’m sorry. I tried.

    I understand feeling this proposal is an antithesis. I tried to show why I originally thought the same, and why I now think it isn’t, and how it can serve the goals we share. Apparently I failed in that as well. I’m sorry. I tried. I may try again, but I get the distinct sense that it’s far too late, and that anything I tried to add would just be shouted down without a hearing. Perhaps in a week or two, things will have settled enough that I can try again. Or, then again, maybe not.

    Over the past two days, one of the things I have tried very hard to do is keep listening with an open mind, and it’s been difficult. This is due not to needing a thicker skin, but to one of my general filters in life: the more angry and loud a person is in debate, the less likely they are to be right. So far, I have not failed on this count, though I did waver for a moment on another site. I will keep trying.

63. we’re all human Eric, just keep fightin’ the good fight

64. It has to be realized that this may well be the only way for IE to advance its standards support in a reasonable time frame, or at all.

    This is the assumption that has not yet been proved to my satisfaction and is keeping me from making my peace with this proposal. There is always more than one way to achieve a goal — It would help me to know what other types of solutions were considered, and why this was chosen as the best one. I know that this type of openness may not be realistic, but it would definitley help me get on board.

65. Andrea, I don’t know what other solutions were considered, but I hope my next post will clarify the situation they face so that you can determine for yourself what a better solution might be.

66. Jack (and others), that objection rests on the assumption that conditional comments won”t be treated according to the X-UA-Compatible value; that is, that the conditional comments will know IE8 is IE8 even if it”s in “IE7″ mode. We don”t know whether that assumption is correct. I doubt that it is, but I”ve been surprised before.

    So it’s possible that setting [if IE 8] as a condition will result in code that doesn’t get executed on IE 8? I can’t imagine that’s going to work. The whole concept of conditional comments hasn’t been mode-specific in the past, and you can’t really make it mode-specific in the future (or else [if IE lte 7] should be true in quirks mode, and that’s freaking crazy talk).

    I’m severely dreading the impact of 100 or so clients having their pages all break in IE 8 when I explicitly future-proofed them to IE’s own recommendations.

    Can someone who has Chris Wilson’s phone number maybe pose the question to him about how this is all going to go down? Maybe we developers can let the clients down easy if we can get ahead of the game a little?

67. We owe it to ourselves:
    Alternatives NOW!
    Give them something to do, other than coding the original proposal!

68. @ Eric

    By the way, I didn’t mean to come off as attacking you on ALA, if you got that impression. If I offended you in any way, I sincerely apologize. I merely mean to drive home the point that this all needs to be worked out and pondered AT LENGTH, as this is something that deserves the proverbial fine-toothed comb and all of that. The potential ramifications of screwing up here are so very, very huge.

    I’m calling for alternative proposals and have attempted to give the discussion inertia with a humble offering posted on the IE Blog at the link provided in my previous post: #67 of this thread.

    Best Regards,
    Ray McCord

69. I tried for most of an hour to convince a member of the IE team that the default behavior should be “latest”, not “IE7″

    I doubt you noticed my previous comment with all the noise, but I want to apologies for what I said in the comment section of your post on ALA. You should have mentioned that in the ALA article! This is crucial! That insane IE7 default is where most of the angry reactions come from… I tried to explain that to Zeldman on his blog but he just doesn’t get how important it is, he called it an “implementation detail” and seems to be persuaded that it is just gratuitous Microsoft hatred in disguise… Maybe you can convince him? :)

    If I may suggest something that I believe would tremendously help the current situation: clarify your position on this point somewhere where it’s hard to miss (like ALA) and try again to convince Microsoft. This is the key…

    Thank again Eric, you’re the man!! :)

    Sorry again…

70. “the more angry and loud a person is in debate, the less likely they are to be right.”

    I tend to agree with you, ironically if Microsoft felt the same, or acted as if they felt the same, we wouldn’t have some of this issue :)

71. Pingback :: Friday, January 25th, 2008 1:51pm

    Bram.us » IE8 Mode?

    […] most recent ALA issue (got some time to read up?): #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11, #12, #13 and – my favorite – #14. *phew* Spread the […]

72. We owe it to ourselves:

    Alternatives NOW!

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

    IE Blog Comment

    Web developers unite!

73. Trackback :: Saturday, January 26th, 2008 6:58pm

    weboholism

    about: X-UA-Compatible, this time for real…

    In case you’ve missed it, you can warm up here, here and here.
    I’ve realized today, that it’ll be a long time till “edge” is default setting.
    Let’s just examine the problem from Microsoft’s corporate point of v…

74. I’d be very appreciative if one thing could be explained, because thus far in nothing I’ve read has it been: what kind of numbers of sites (or even “what sort of significance of site”) are we talking about getting broken if standards mode in IE 8 behaves differently to standards mode in IE 7?

    I ask this because IE 7 is relatively new—developers are generally having to put in place the conditional comments to ensure the IE 6-specific hacks didn’t apply to anything but IE 6, and (in everything I’ve seen), similar comments to ensure the IE 7-specific hacks don’t apply to anything except IE 7.

    On that basis, if the sites work properly in a standards-compliant browser, then they will continue to do so, surely?

    On the public web, the number of these sites must be tiny, because they won’t function in Firefox, Safari or Opera either (I’ll be impressed if somebody manages to find more than the odd mainstream site that triggers standards-mode and yet is obviously broken in all of the “alternative” browsers), which leads me to suspect that this is all about Intranet/Extranet/corporate scenarios—and that information, if correct, changes the game completely.

    If it’s a corporate deployment situation, this isn’t the web development community’s problem; it’s a Microsoft enterprise relationships problem, and one that can trivially be solved by rolling out a standalone copy of IE 6 or 7 to said customers.

    I suppose what I’m trying to say is: I’ve yet to see any justification from the proponents of X-UA-Compatible that the problem as stated actually exists in the wild in the public-facing web, and that lack of justification is pretty critical when you’re trying to persuade the entire web development community to alter its behaviour (seemingly in a minor way, but there have been many reasons cited in the past few days already as to why it’s not insignificant).

75. Jack & Kit:

    It makes no sense for IE 8 to obey conditional comments targetting IE 8 if it’s supposed to behaving identically to IE 7. If it’s in “IE 7 mode” it needs to be “IE 7” from end to end (that is, the parser, renderer, scripting engine and UI nuances need to be identical to IE 7).

76. Pingback :: Monday, January 28th, 2008 9:04am

    IE8, Version Targeting, and the Ruckus it’s Causing - Monday By Noon

    […] Version 2 by Eric Meyer […]

77. ok, there is the MS”s argument that trillions of old crappy sites won”t render anymore because they’ve been build for the crappy IE engine, but there actually is a simple solution:

    the kill switch should not be added to website code, but to the new browser. and it should work like this:

    if the kill switch finds a proper doctype declaration, then the browser should render like mozilla/webkit does—the proper way—, but if there is no doctype, then just use the old far-away-from-standards IE render engine.

    wouldn”t that solve all of the problems? the web developers, because we can forget to add IE hacks and extra IE stylesheets, and microsoft, because everybody will love the new browser because it works on all sites, be it bogus code or standard compiliant.

    what do you think?

78. Pingback :: Monday, January 28th, 2008 6:33pm

    purplehaze.me.uk » Internet Explorer and web standards

    […] Version two – Eric Meyer […]

79. In that vein, I have to admit that I don”t understand the assertions that this will make life harder on other browsers, that they”ll have to support all the various rendering modes in IE.whatever. Can someone explain that to me, please? I”m not saying the assertion is wrong. I”m saying I don”t understand why that would be the end result.

    Say you have a document that lacks a DTD, but *includes* the metatag. What mode do you get?

    The lack of a DTD triggers quirks mode, but the metatag would trigger IE8. What should it be? Will the lack of DTD continue to trigger quirks mode, or will the new metatag *replace* the need for a DTD in IE. What will this do to/for the other browsers? (Do i hear the word “break”…?)

    I think that the biggest fear is that with this metatag, MS is once again forking the development of web authoring, be it deliberate or indeliberate.

80. Eric says

    I suspect that a good deal of the emotional objection springs from a perception that the proposal is to require all browsers to implement targeting. Not at all. Please be clear on this: nobody is saying this should be required in any browser.

    but Aaron Gustafson wrote, in the original ALA piece:

    …define a list of browser versions that the site was built and tested on, and then require that browser makers implement a way to use legacy rendering and scripting engines to display the site as it was intended—well into the future.

    and

    This is exactly what our group decided to recommend for IE8, and we hope to see it implemented in other browsers as well.

    so I’m afraid you’re wrong about that, at least, Eric. Someone definitely is proposing to push this out for all browser makers.

    As for another point, yes there is a similarity between things like the “box model hack” and this. But the main difference is that when we include these twiddly bits to work around browser bugs, we (hopefully) code the rest of the site so the browsers without those bugs get it right.

    It’s a subtle difference I grant you, but the impact is more significant. Because we’re looking forward with the design, and just doing a little necessary patching for the laggards. By implementing version targeting, even if it’s only IE that does it, the designer completely stops looking forward, and simply designs for the past. I think we’re losing more than I’m willing to sacrifice. You recognized it as a loss elsewhere; are you so sure it’s a loss we should accept if we don’t have to? There are other options to accomplish much the same thing, that we’re using now and which don’t have those deleterious effects.

    After I wrote my own piece on the subject, I realized there was another reason not to use it as a designer: skills atrophy if not used, and once I start down the road of designing for past browsers, how far will it take me? Will time spent on that hinder my efforts to keep current? How many clients will, when hearing of this, demand designs for an older browser? What new opportunities will I miss because of that?

    I’m not at all comfortable with those thoughts.

81. Arlen, thanks to my years of spec reading, I’ve developed a sharp distinction between “we hope” and “we require”. It’s a fine-to-transparent difference to 99.9% of the world, but when you’ve trained yourself on the differences between “SHOULD” and “MAY” and “MUST” as pertains to technical writing… well.

    The first thing Aaron said very close to a “MUST”, but his second statement, the one that sums up the idea, is more of a “MAY” or even an “OPTIONAL”. That was what I focused on, since it came later and therefore (to me) had more weight.

    As for the rest, the long-term effects could be as you describe, or not; we’re all peering into our crystal balls and seeing different things. My concern is that without this or something like it, we’ll never see significant standards advances in the IE line, and thus the wider adoption of standards will be stifled for as long as IE exists as a major presence on the browser landscape.

    But I’ve made that case elsewhere, and if people aren’t convinced, well, they aren’t convinced.

82. For the most part, I’ve sat this one out, reading literally hundreds upon hundreds of comments at many other places.

    My bottom line is disagreement with the proposal, for precisely all the reasons Eric stated in the ALA article, … before he justified the so called pragmatic approach. I believe we should keep moving forward and not support any browser having a default behavior that is not standards compliant.

    My viewpoint is a bit different than I’ve read in any of the comments. Free market economics are my guiding principles. At the simplest level, if a product fails to meet its customers’ needs, the producer has two choices. Make what customers want or go out of business. Stark, but it happens all of the time. I’ll come back to this shortly, after doing a little myth busting.

    Two of the arguments in favor of the proposal are that “the web is broken” (or this will break it worse), and MS is listening to its Intranet customers.

    First, the “broken web” is seemingly justified by the millions of pages already in existence which we must keep working as they are. In fact, Eric says,

    But remember, “let old sites break” is a non-starter.

    Why is that a non-starter? Many of us in this business are very well aware of how frequently sites get redesigned. With each redesign, it’s not only the presentation that changes. Almost always, redesigns are accompanied by code updates, often needed to take advantage of new features. My belief is that almost any web site that matters to someone will be updated as a matter of course some where along the way. If the site really matters, it will be updated sooner, the way people fixed problems with IE7. On the other end of the scale, if it really is just a dead site, it probably doesn’t have serious rendering problems anyway, and few will care enough to warrant updating. In essence, “Yeah, it’s broken, but no one goes there anymore.”

    That puts me firmly in the camp of not caring that the web is broken. From the free market economics point of view, those pages are like the used goods we find in a flea market. They’re not relevant to mainstream consumers. Don’t waste energy on worrying about them. Let the old sites break. From the free market economics point of view, the old site is a failed product and there are always better that can take its place.

    Second, the intranets. Here, my perspective is from being a developer for a corporate intranet, one that serves a very large international business machines firm. I helped move that intranet’s design to standards compliant code the last time the design was updated. Here again, designs get updated, and code with them. Yes, there are probably a fair number of intranets where some portion of their content is still old, still used, still “matters,” and breaks with IE7. And yes, there is at least one “business critical” application on the intranet I worked on which has problems with IE7. However, like most everything else, that application is scheduled for revision due to other business purposes and will get upgraded to new technology at the same time.

    I haven’t heard anyone else mention the following yet, but those intranets are the real sore point for Microsoft, and the big problem is Vista! The firms who have those sorts of problems also have “managed clients” where the firm controls the software on each employee’s system. Those firms are refusing to upgrade to Vista because it breaks their intranets. Therein lies the real problem!

    To me, this looks a lot more like a Vista revenue problem than Microsoft really caring about breaking the web. The broken web and the intranet problems are real, but mythical when compared to Vista not producing the expected revenue. Think about it for a few momments.

    Coming back to free market economics. It is IE that is broken, not the whole web as some would have us imagine. Let the free market work, and bad products will eventually be driven out of the market.

    Imagine an auto manufacturer declaring that they are going to stay with old mechanical carburetors as the default for all of their engines … and justifying that decision based on the belief that all the naive mechanics can more easily maintain carburetors than modern computer controlled fuel injection systems. How long would that idea survive? Not long, because every other auto manufacturer would launch advertising that ridicules the idea, and the marketplace would reject the product. Yes, it is a far fetched analogy, but not that far. The concept is freezing technical advancement, whether staying with obsolete carburetors or staying with a non-standards compliant browser. The biggest difference is that the browser industry, unlike the auto industry, has fewer competitors and the one wanting the freeze in the browser market has monopolistic market share.

    Freezing a technical implementation is rarely a good idea. I can’t recall when it has ever worked. Why start now?

    We have been moving the web forward for almost a dozen years. We haven’t been so caring about whether “the old sites break” … until now. Why the need to fix Microsoft’s problem with the regressive approach of freezing technology … and prolonging the bad behavior (coding habits) of many old school developers?

    Like the products that don’t meet consumer needs, let the old sites fail. Let IE fail too. If Microsoft decides to stay with this idea, I can foresee the time when developers (first) and consumers (second) will come to see IE as a failed product and it will again lose market share to the standards compliant competitors. Rethink Microsoft’s proposal as one based on unfulfilled Vista revenue, and it’s not nearly as important as we’ve been led to believe. Keep moving forward and let market economics solve the problem.

    In the end, I’m disappointed that two of the people I admire, Eric and Zeldman, have been overcome by mythical rationale and have stepped away from their core beliefs.

    Disclosure: Some will be aware that the intranet I referred to was IBM’s. I recently retired from IBM after 40 years with them. My opinions expressed here are my own, not IBM’s.

83. Yet another lesson: Don’t post without previewing. Find the missing closure for the strong string and fix it before it continues for umpteen paragraphs. oooops. Mea culpa!

    [Fixed. -E]

84. In the end, I”m disappointed that two of the people I admire, Eric and Zeldman, have been overcome by mythical rationale and have stepped away from their core beliefs.

    This is something I (both of us) have been accused of over and over again in the past couple of weeks, and I guess now’s finally the time to ask: exactly what core beliefs am I supposed to have abandoned? Since I’m not aware of having done any such thing, someone else is going to have to enlighten me.

85. While I can’t be inside your heads, both of you have frequently advocated the strength of standards and have driven constantly to persuade browser publishers to become standards compliant. That is the core belief I see from your writings.

    Now, an opportunity arrives which will result in the browser with the largest market share continuing with a default behavior that is not standards compliant. The unintended consequence I see is not in ensuring all the broken web pages still render well, but in encouraging the everlasting continuation of non-standard coding.

    Zeldman laments not being able to reach more developers, not being able to persuade everyone toward standards. Well, how is this going to help? It will perpetuate IE’s bad behavior, as well as most developers’ bad behavior (much of which we think is unintentional non awarness of standards). Where is any incentive to move to standards? None, gone, nada! If the biggest gorilla in the room doesn’t care about standards, why should anyone else? All of those developers Zeldman worried about not reaching still won’t be reached. They won’t code to the standards compliant features of IE8, 9, 10. They’ll code to the (frozen) base, just as they coded to IE6. Sure, the results will be marginally better, but definitely not standards compliant.

    If you think that it’s OK to freeze the most used browser at a non-standards compliant level, and by that action to encourage people to code to that level, it turns your standards advocacy into a lot of wasted words.

    The place where I think things went awry was buying into the idea of “breaking the web.” This is the fundamental assumption justifying the pragmatic solution, and I believe the assumption is a myth. As I mentioned earlier, the stuff that really matters will get revised sooner or later anyway, and when it gets revised will be updated to work with the latest browsers … assuming they aren’t frozen.

    Out of curiosity, did the site which led to the creation of “almost standards mode” ever get revised after that incident? If so, did the revision negate the need for “almost standards mode?”

86. It’s funny, because I agree that it would be a major problem if the biggest gorilla in the room didn’t care about standards. The disagreement is how that might happen.

    Before I address that, though, I need to say something about the persistent characterization (by many people) that the breaking of web site by updating browsers is a “myth”. For it to be a myth, I would have to be lying about my experience at Netscape. As would the people on the IE team who nearly lost their jobs over the breakage between IE6 and IE7.

    We can disagree on the degree to which this breakage is a problem, but to wave away the issue as “a myth” is not at all helpful and frankly somewhat insulting. If that’s where we part ways on this, then fine; don’t bother to read on, because none of it makes sense if you insist it’s based on a “myth”.

    Now back to the main point. As you said:

    If the biggest gorilla in the room doesn”t care about standards, why should anyone else?

    Here’s what I foresee happening in the IE world without version targeting or something like it:

    “Hey, we need to fix this bug in order to enhance and add these other things.”

    “Will fixing it break existing sites?”

    “Probably a few, but they’re old and–“

    “No.”

    …and so the forward momentum of standards adoption in IE slowly (or possibly quickly) grinds to a halt. And if the biggest gorilla in the room stops pushing standards forward, why would anyone else bother?

    Even if all the other browsers did continue to push forward with their standards support, what good would that do? Authors aren’t going to use, say, advanced CSS layout if IE doesn’t support it in any form. We then have to either wait for IE to completely die out in the user base, or else wait for something to replace the web altogether.

    With version targeting or something like it, I foresee the following variant of the above hypothetical conversation:

    “Hey, we need to fix this bug in order to enhance and add these other things.”

    “Will fixing it break existing sites?”

    “No.”

    “Go for it.”

    In that scenario, there is the hope of luring more and more developers forward to make use of the advanced features in IE8 and beyond. And who knows? That might even be the vector along which more awareness of standards can finally be spread.

    At any rate, I guess we can agree on at least one thing: I’ve wasted a lot of words. I don’t think we’re talking about the same words, though; or, if we are, then the type of waste is likely very different.

    On the other hand, if your assessment of my advocacy being wasted hinges entirely on my wanting to freeze the most used browser at a non-compliant level, then hallelujah, I’m redeemed: I’ve said time and again, over and over, in multiple ways and places that I want the default behavior to be “latest”. I have argued that they should take that approach and use the IE8 beta period to get word to those who don’t want to fix their sites that a “one-line fix” will keep their sites from being disrupted.

    But I also am able to look at the situation as it is and understand why that might not be an acceptable choice for the IE team—and also to see that to at least some extent, my preference is driven by a selfish desire to push the meta tag addition onto others, instead of having to do it myself. That’s not the whole of my rationale, but I would be dishonest to myself if I didn’t recognize that it’s there.

    As for the site that mainly drove “almost standards”, it certainly has been redesigned since then. Unfortunately, their markup practices really haven’t advanced much; now they have fewer layout tables containing lots of nested divs and even a few spacer GIFs. I honestly can’t tell by reading the source if their current layout would be broken outside of quirks mode or not. But let’s remember, there were multiple sites causing the problem, IBM’s among them, not just that one site.

    Anyway, I need to stop now. I can but hope that at least a few of these words were not wasted.

87. I have been giving this topic some thought the past few days from the perspective of a server admin. Being cautious, I would appreciate a ie=7 HTTP header that I can set that will effectively prevent users from using ie8 rendering against my web site. If the meta tag is kept out of the documents then I can easily test with another virtual server using ie=8 and then choose when our site makes the transition to supporting ie8 on *our* schedule instead of Microsoft’s schedule for the IE8 roll out. I agree that it is wrong that it is something I am required to do just to get the most standards compliant rendering but on the other hand it is something I would do out of caution anyway so it costs me nothing to make Microsoft happy.

    I think that meets Microsoft’s demand for opt-in. My site would not break as IE8 rolls out (assuming Microsoft does its emulation correctly). It could only break when I change the HTTP header from ie=7 to ie=8 and who do you think will get the blame if that happens? And if someone really wants to create a document for archival that won’t change over time, they can use the meta ie=7 in those specific documents to override the server setting. Though I think it would be better if Microsoft would document and get its own DOCTYPE for something like this but I’m no document standards expert.

    As for web developers, just continue to write to the standards and just use meta to temporarily override the server default in specific broken cases or for archival. As long as I, as the server admin, keep increasing the HTTP header to keep up with IE releases, we keep the web site running with the latest standards. Isn’t that what the web developers want?

    It is a shame Microsoft didn’t solicit more feedback or think this through more thoroughly. They could do something like ie=+7,-8.0,+8.1 to mean ie7 should render with ie7, ie8.0 should also render with ie7 (presumably because bugs are found in ie8.0), and ie8.1 should use the 8.1 rendering. That way Microsoft could implement quick bug fixes in IE8 until they declare it stable. Since the only way to get the IE8 rendering is to opt-in, you either wait to opt-in until it is stable or your opt-in to an unstable version means that you are prepared to opt back out of IE8 or fix the documents if a bugfix breaks your web site.

88. OK Eric. We’ll continue to disagree about the myth, but sing together “Hallelujah” on wanting default behavior to be “latest.”

89. I think it’s too optimistic by far to assume only IE will have to support multiple rendering modes if X-UA-Compatible sees widespread usage on the web. My take:
    http://my.opera.com/hallvors/blog/2008/02/06/x-ua-incompatible

90. Eric, I have a great deal of respect for you and hopefully you’ll never give me reason for that to change.

    However the idea that adding a meta tag to the head of my documents now and for the unknown future is absurd, the http header doesn’t help much either, it simply creates a barrier that I constantly have to move forward as IE gets its act together moving forward (yeah well, read on).

    My first fear is simple, this is a hack, there is no way you can look at this as anything other than a hack (designed for one purpose, and that’s not to help transition), the biggest problem with a hack like this is the ability for that hack to be abused (we’ve seen it with every form of hack to bring a browser into compliance). The abuse though not malicious by nature, will more often than not be implemented by those that don’t know better, and what is the forecasted impact of that type of abuse? In 10 years we are going to be right back where we started… 70% of the web coded for 2001 30% for 2018 (depending on how many people will learn the meaning of this meta tag, let alone a doctype).

    I’ll leave you to ponder that…

    My second but most important fear is even simpler, while it seems like Microsoft are trying to make a transition to standards easier (like transitional didn’t give them enough time) they are in the best position out of all the bad eggs to abuse the use of this meta tag. I personally believe the IE dev team want to do right, but there is no way in the world anyone can convince me that MS management are not pulling the strings here. This is not a debate about standards or the preservation of digital content from yesteryear (why can’t I open my old word docs in the latest version?), this is a debate about “open web” vs “MS web”, if they really care about the preservation of old web pages this would be a non issue and we wouldn’t even hear about this insane meta tag.

    I think one point that has been overlooked here is the fact that their very own OS help file system is still based on antiquated technology (the same tech they are trying to maintain support for), if they switch to standards they break their own OS (as well as the BIG client interests mentioned elsewhere), this is not about us, this is about them, its time we all stand behind each other and grow some teeth, we have reached the tipping point and to buckle to their demands would negate 10 years of hard work.

    No matter which way this story is twisted it will always have the same ending if MS get their way, and I guarantee it won’t be “and the developers/users lived happily ever after” no, it will be more like “and Microsoft lived happily until the market caught up again”.

    Stall progress, crush competition… Its blatantly obvious what’s happening here. Think it over.

    Cheers!

91. Pingback :: Sunday, February 24th, 2008 10:54am

    about: X-UA-Compatible, this time for real

    […] some perfectly good and valid points about the <meta> but in terms of JavaScript. Eric Meyer suggests for javascripters to continue and to expand object detection or browser sniffing. Now have a look […]

92. Pingback :: Tuesday, March 4th, 2008 12:41pm

    EP Interactiv » Blog Archive » Microsoft Embraces Web Standards, IE8 to be Fully Standards-Compliant by Default.

    […] Johansson, Andy Budd and Jeremy Keith fought the good fight all the way through, while Zeldman, Meyer and Jonathan Snook defended Microsoft’s […]

93. Pingback :: Tuesday, March 4th, 2008 5:54pm

    Microsoft does the right thing. Web developers’ heads explode in surprise. at Mad Web Skills - Web design in Melbourne and Shepparton

    […] nature of building valid, forwards-compatible websites; and those who believe it is in the best interest of the internets, protecting Microsoft’s partners who use thier dodgy web technologies and […]

94. Pingback :: Wednesday, May 28th, 2008 5:28pm

    about: X-UA-Compatible, Take 2 at weboholic.de

    […] some perfectly good and valid points about the <meta> but in terms of JavaScript. Eric Meyer suggests for javascripters to continue and to expand object detection or browser sniffing. Now have a look […]