Just The Facts: Recap of Compatibility View

We’ve said a lot about our approach to website compatibility in general and the Compatibility View feature in particular. But because we've shared this information across multiple blogs and sources, I’d like to quickly recap what we’ve previously announced in summary form and provide links to additional content / reading as necessary.

IE8 Standards by Default

Going into IE8 Beta 1, the Internet Explorer team demonstrated its commitment to interoperability and web standards by announcing that IE8 will interpret web content in its most standards compliant way - by default. This means viewing pages in IE8 Standards Mode isn’t opt-in, it’s the way the product works out of the box. We believe this to be the right decision as it’s forward looking and supports developers and designers as they create the next billion web pages. We want to both respect the site author’s intent AND create a positive end user experience. We've reinforced our commitment at subsequent releases (Beta 2, Release Candidate) and still believe "standards by default" to be important.


There’s a short term consequence to the “standards by default” decision, namely compatibility problems with existing pages. Many of today’s web pages, even pages written “to the standards”, expect the old, less interoperable behavior from IE and, as a result, don’t work perfectly in IE8’s standards-by-default mode. Here’s what we’ve done to address this problem –

  • We’ve evangelized all of the great work the team has done to better support web standards in IE8 (like CSS 2.1, a better Document Object Model,  ARIA, and cross-domain requests (XDR) and cross document messaging (XDM) and our start on HTML5 support) and asked web developers to update their existing pages to support IE8 Standards mode.
  • We’ve evangelized use of the X-UA-Compatible tag to websites unable to update to support IE8’s Standards mode. The tag allows a web author to declare the exact standards mode behavior for which their website works best – IE8 Standards (again, the default when no header is present) or IE7 Standards. For example, using the value ‘IE=EmulateIE7’ causes IE8 to display a website “as IE7 would have”.
  • We’ve provided end-user and corporate / IT mitigations to the website compatibility problem under the umbrella term ‘Compatibility View’. ‘Compatibility View’ allows IE8 users to have a great experience even when visiting websites that haven’t yet performed either of the above two steps. It also helps IT organizations preserve compatibility with the large number of line-of-business websites that are Internet Explorer 7 capable today.

Compatibility View

Compatibility View first appeared in Beta 2 builds. We refined the experience further in the Release Candidate build by incorporating feedback received during the Beta. Most notably, Compatibility View list updates were added at that time.

A deeper description of the feature set can be found in previous posts. Below I’ve tried to summarize important points and/or aggregate information that was sprinkled across several sources –

  • When installing, users can choose to use the Compatibility View list (and thus opt-out of IE8’s standards-by-default configuration). Users have to choose to use the Compatibility View list, and receive updates for it – it’s not on by default.  Users can also “click the button” that places a site into Compatibility View. Both actions involve users exercising choice to override IE's defaults.
    There are two cases where select Compatibility View features come pre-configured as part of IE's "smart defaults". For one, sites that map to the Intranet zone display in Compatibility View by default. This allows IE8 to be most compatible with line-of-business applications that expect IE7 behavior. (This can of course be changed by the user as well as configured via Group Policy.) Another case of "smart defaults" is the setting ‘Automatically recover from page layout errors with Compatibility View’. The topic deserves its own deeper handling as a stand-alone blog entry, but I’ll just quickly state here that the setting makes an otherwise completely unusable page usable again. When the IE Layout Engine encounters an unrecoverable error during page processing it shows a blank page rather than allowing the user to interact with a corrupt or otherwise obviously incorrectly displayed page. In such a case, IE attempts to reload the page temporarily (read: until you close and re-open IE) in Compatibility View based on the setting mentioned above. We believe that showing a page the way IE7 would have is a better user experience than showing no content at all. We’re working hard to fix known causes of these unrecoverable errors in our layout engine and we get Watson data for the rare occasions when they do happen.

  • Site owners are *always* in control of their content. By default, Internet Explorer uses DOCTYPE switching to determine Quirks v. Standards mode (again, Standards mode maps to IE8 Standards by default). Site owners can choose to use the X-UA-Compatible tag to be absolutely declarative about how they’d like their site to display and to map Standards mode pages to IE7 Standards. Use of the X-UA-Compatible tag overrides Compatibility View on the client.
  • Compatibility View list updates make sure IE8 customers have a great experience with highly trafficked sites that have not yet fully accomodated IE8’s better implementation of web standards.

    Whether or not developers are able to update their sites to support IE8 Standards, people who use IE8 expect that the web will keep working. They want *both* interoperability and compatibility. The Compatibility View list feature attempts to provide just that for the web’s most trafficked sites.

    I’ve seen a few blog posts of late that express concern over the compatibility list feature, namely that it will encompass a zillion sites and live on in perpetuity (and thus negate our standards-by-default promise). I want to take a minute to speak directly to that concern. First, the list is only enabled by user choice - it isn't active by default. Second, the purpose of the list is to ensure that IE users are given the option to have a great experience on the web's most trafficked sites. Research data shows that the percentage of unique visitors (reach) and average number of minutes users spend on a page are skewed considerably towards very popular internet destinations like microsoft.com, facebook.com, and cnn.com. Having a great experience on these domains means our users have a great experience with IE8. There’s a finite number of such popular sites, and it’s on the small side. Third, we use customer feedback via product telemetry, bug reports, Report a Webpage Problem, etc… as inputs to a system for generating the list. This is real customer data that relates to real-world compatibility experiences; it's a very accurate measure of exactly how IE users are experiencing these high traffic sites. Next, we view list updates as a short term compatibility option and have committed to regularly revisit the need to ship the list at all. We recognize that it takes time for organizations to update their sites for Internet Explorer's transition to better web standards. This update timeline can vary greatly by organization. The feedback we've received so far has been overwhelmingly positive as many see it as a way to help organizations concentrate on supporting IE8 Standards in the long term. Lastly, we contact the site owner (as identified by WHOIS) for each domain on the list to let them know about the experience that IE8 users are having on their site and to give them removal steps (if they so choose). We ship regular updates to the list on the same schedule as, but separate from, IE security updates, in an effort to make the process predictable to both websites and IT organizations. 

  • Sometimes the Compatibility View button isn’t displayed. The button is located on the address bar next to the ‘stop’ and ‘refresh’ buttons. There are a few cases where there’s no action for a user take and, thus, the Compatibility View button will not show:
    • If you're viewing an internal-to-Internet Explorer page (such as about:InPrivate)
    • If you're viewing a page that has declared it's "ready" for Internet Explorer 8 through use of the versioning <META> tag / HTTP header (it doesn’t matter if this tag triggers Quirks, IE7 Standards, or IE8 Standards, the button won’t be displayed)
    • If you're viewing an intranet page and you have the ‘Display intranet sites in Compatibility View’ checkbox selected
    • If you're viewing any webpage and you have the ‘Display all websites in Compatibility View’ checkbox selected
    • If you're viewing a webpage that is included on the Microsoft-supplied compatibility view updates list and you have the ‘Include updated website lists from Microsoft’ checkbox selected
    • If you've toggled either the ‘Document Mode’ or ‘Browser Mode’ settings via the Developer Toolbar
  • Compatibility View and the X-UA-Compatible tag are not equivalent. Compatibility View is something you do on the client. It affects three things: the User Agent string, the Version Vector (used in evaluation of conditional comments), and what mode DOCTYPEs that trigger Standards map to – IE8 Standards or IE7 Standards. The X-UA-Compatible <META> tag / header is something you use in page content / server-side and, when present, completely overrides Compatibility View settings on the client. It affects two things: the Version Vector and what mode DOCTYPEs that trigger Standards map to. It can’t affect the UA string as it’s already too late to change that – the client’s already made the GET request to the server (and it contains a UA string). What this means to developers is that if your site pivots on the User Agent string, adding just the X-UA-Compatible tag (to cause IE8 to display your site in IE7 Standards mode) won’t make your website compatible – you’ll also need to update your User Agent string detection logic as well.


I’ve seen come confusion in the blogosphere regarding the Compatibility View feature set and I sincerely hope the above helps to clear it up. As always, if you still have questions, please feel free to post them in the comments and I’ll try to answer them.

Scott Dickens
Program Manager

Update 2:16 - removing duplicate paragraph.
Update 2/17 - minor text correction.

Comments (104)
  1. Kelson says:

    Something I’ve been wondering and haven’t been able to find: is there a way to check the current contents of the compatibility list the way Opera users can look at the ua.ini or browser.js files in their profile folder?

  2. EricLaw [MSFT] says:

    @Kelson: Type res://iecompat.dll/iecompatdata.xml into your address bar to see the Compatibility View list.

  3. boen_robot says:

    I have a question:

    In case you can’t successfully contact the site owner for whatever reason (invalid/changed email for example AND there isn’t any readable email on the contact page either), how would you contact the site author? I guess you won’t, and I won’t blame you either… but in that case, would the list content be visible from somewhere? In that case, the site owner may still get a chance to see that he’s on that list, even though he wasn’t contacted by you. And, when people ARE on that list, where can they opt out from? That is, to what email (or something) they can write to with a request to be removed from the list?

    Have you considered using X-UA-Compatible information (in combination with CEIP) to automatically remove sites from the list? That would make smaller site’s removal much more easier and smoother.

    Also, again, it didn’t come clear for me from this post, are you manually checking in sites before you add them to the list? At least to see if there are indeed ANY problems at the time you added them? Or do you trust the telemetry enough to make it automatic? If you do, excuse the bloggers for not trusting it as much as you. I too don’t.

    On a side note, I’d recap a request for IE8RC2… see the comments at the previous entry.

  4. Kelson says:

    @EricLaw: Thanks.  Wow, that’s a much longer list than I expected.

  5. Site owners are *always* in control of their content!  I really liked this point and I’d like to add that as a site owner this is exactly how you should behave.  Adding the X-UA-Compatible tag solves the problem.  You should not only add it if your site has backward compatibility issues but you should also add it as an insurance moving forward.  If you tell the browser that a page has been tested on IE8 you will not have to worry about future changes.

    Aggiorno can help you with the tagging process, it is so easy that every site owner should use it: http://www.aggiorno.com/aggiornoexpress.aspx

  6. Alex says:

    Thanks, IE team.  Working with IE has been painful in the past (and the hangover is still lingering), but it’s really apparent that you’re working hard and keeping web devs in mind.

  7. Scott has just published a great recap of the Compatibility View on the IE blog . To summarize with one

  8. The following picture summarize the usage of the META tag…

  9. Isofarro says:

    Federico says: "Site owners are *always* in control of their content!  I really liked this point and I’d like to add that as a site owner this is exactly how you should behave.  Adding the X-UA-Compatible tag solves the problem."

    That means a site has to opt-in to web standards to ensure that it gets triggered. That’s the problem we had with this last year, and why this Compatibility View is still the same thing.

    I am bemused by the title of this post of "Just the Facts". What happened to the ‘fact’ that you are not capturing subdomain information, so blacklisting of sites happens at the top-level domain. Is this a genuine omission, or has this been withdrawn?

    Where is the complete list of domain names that can potentially land up on this Compatibility View blacklist? Surely this is a fact that should public information?

    What number of Compatibility View button clicks will it take to trigger off a process that results in a top-level domain being added to the Compatibility View Blacklist?

    What is the scope and process of human testing that takes place between a top-level domain receiving enough clicks to trigger a blacklisting process to actually being added to the Compatibility blacklist? Do you just check one random page on the top-level domain, just the home page, do you check a couple of subdomains – how are the pages chosen, are the tests repeatable? These are the sort of facts website owners and developers need to know.

    Why are the contacted ‘domain name owners’ offered the choice to opt-out of this blacklist instead of being offered the chance of opting in to it? This smacks very much like email spam that asks you to reply if you don’t want to receive more spam.

    Why can a top-level domain be added to the Compatibility View blacklist immediately, but getting taken off happens once a quarter (or any other time frame that is not as immediate)?

    You’ve mentioned at least twice of how a top-level domain can be added to this black list, but I still don’t see a clear set of guidelines and a process to get a top-level domain off just as quickly. Where is that?

    What is the definition of high-profile and popular destinations being used here? What are the process, metrics and decision paths being used to determine whether a top-level domain is one or the other?

    Why are these sites being treated differently? Surely it is just as important for online banking sites, shopping sites, software download sites to be covered in this blacklist? Surely an online bank, local government, government voting, monthly rates paying services are far more important to have working than microsoft and myspace? What is the point behind the Compatibility Blacklist: that the web  doesn’t appear broken to people who use it (like paying bills), or only a stick for sites that have lots of traffic?

    This is what should have been covered in a blog post titled "Just the Facts", rather than selective regurgitation of a selection of previously mentioned facts and ignoring the elephant in the room.

    Why should we webstandards developers accept this strategy of divide and conquer? (Target the high traffic sites into opting in to standards mode in IE8 to avert/workaround sites being blacklisted)

  10. Jan says:

    When I use an activity, I get a new webpage with the result, but the address bar is in edit mode. This prevents things like instant zooming on google maps for example. Please do not set the address bar in edit mode when first opening the activity!

  11. Jack Sleight says:

    So, if I’m using the HTML 5 DOCTYPE, I still need to include the X-UA-Compatible tag if I want to ensure that my pages *always* use IE8 standards mode, regardless of client settings?

    Or is the HTML 5 DOCTYPE an exception to the rule?

  12. Mitch 74 says:

    @Federico: fifty bucks for a software that adds an X-UA-Compatible meta-tag to the HEAD of any HTML-like file it finds? If at least it looked at a page’s DOCTYPE, and took that into account, it could look half-serious!

    – on a page that would be displayed in XHTML mode (with application/xhtml+xml MIMEtype), this meta-tag shouldn’t be used (IE doesn’t support XHTML, only XHTML-as-tagsoup); this could be determined through PHP or Apache (or IIS) global settings, thus such an app can’t guess. It has been said more than once that IE will make use of its most compatible mode on HTML 5 and XHTML pages as soon as it can support them (IE 8 still doesn’t).

    – instead of processing a whole batch of files, adding a single line to an Apache’s .htaccess (and similar for IIS) will do that for less markup and much more reliably: this was described in previous blog posts. The meta-tag should be limited to the occasional page on a server that requires a different rendering mode than its ‘neighbors’ do.

  13. FremyCompany says:

    There’s a bug with your compatibility feature :

    X-UA-Compatible: IE=7, IE=edge

    IE8 load the page as IE7 does, but it’s not what I expect. I say : IE7 can load the page, as well as any higer version of IE. IE should use the best mode, so it should use IE8. It’s important, because the site may works on IE7, but show better on IE8.

    It should also be greater to have something like :

    X-UA-Compatible: IE=gte 5, IE=lte 8 (like conditionnal comments), and IE would choose the best version based on this constraints IE>=5 && IE<=8 ==> IE8 for IE8

    ‘edge’ should be the same as ‘gte 5’.

    Another thing : the browser should tell the user if the compatibility mode requested is not availlable (if, in 5 years, a site say IE=9, IE8 should say, when I saw the page ‘This page request an higer version of IE. It seems that an update of IE exists on the microsoft site. Download now ?’)

  14. Catto says:

    Hey Now Scott,

    Well written post.

    Thx 4 the info,


  15. Stefan says:

    I did try IE8 RC1 on a clean installed XP SP3. What a crap! I crashed over and over and over… This can’t be a RC. It can only be a pre-alpha or something. IE8 will be blacklisted on all computers i admin.

    I also noticed it is very slow on many sites. It doesn’t accept many plugins either.

    Sad to say that IE8 is the same as Vista – pure crap!

  16. Stefan says:

    I did try IE8 RC1 on a clean installed XP SP3. What a crap! It crashed over and over and over… This can’t be a RC. It can only be a pre-alpha or something. IE8 will be blacklisted on all computers i admin.

    I also noticed it is very slow on many sites. It doesn’t accept many plugins either.

    Sad to say that IE8 is the same as Vista – pure crap!

  17. boen_robot says:


    What are the computers in questions? Which add-ons are not running?

    (I’m assuming the crashes are caused by the incompatible add-ons, but again, which one(s)?)

  18. If you want to know whether your site is on the Compatibility View "blacklist" check it at http://ie8blacklist.appspot.com/

  19. Isofarro says:

    Why is uk.com listed on the IE8 Compatibility blacklist? (I’d be very interested in seeing the IE8 team outreach to that particular listing).

    The same for mod.uk – is there a problem with the Ministry of Defence, or perhaps one of the top-level domains under it like raf.mod.uk and army.mod.uk? (I fear for our other government domain name hierarchies, e.g. police and nhs)

  20. Tino Zijdel says:

    I sincerely hope that the current ‘compatibility list’ will be flushed upon release of IE8 final since I am totally unhappy with the fact that our site (tweakers.net) is listed without any apparent reason for it (at least not by my knowing, the only issues in IE8 are imo caused by bugs in IE8 itself).

  21. Phil says:

    @Stefan – I’ve got IE 8 RC1 installed on XP, Vista, Windows 7, Virtual Machines… no hard crashes at all, only typical "beta-type" issues.  Maybe it’s the way you admin your machines that’s the problem?

  22. JAB Creations says:

    I would imagine the vast majority of issues at this point are incorrectly written websites that are statically written. There are too many people who don’t do object detection in JavaScript or use conditional comments to serve a second stylesheet for IE (as of now IE7 and earlier).

    @Scott Dickens There are no such things as "tags" in (X)HTML, they’re called elements. Also web designers work on clientside while web developers work on serverside so when you guys are dealing with web sites that don’t work correctly you’re dealing with web developers who aren’t also web designers though outsourced to do web design.

  23. @Scott Dickens

    Your post tries to explain the complexities, intricacies of the (browser|document) modes, meta-tag, list, etc.. Microsoft’s strategy is a complex one, certainly not an easy-to-grasp, easy-to-understand one for ordinary users and web authors. A time consuming and energy demanding one too: list to manage, to download, to update, telemetry to gather, clicks to register, software adjustments (options, checkbox, etc) to do, dev. tools buttons, etc.. all of this requires time, energy, etc..

    Microsoft, as a browser manufacturer, tries with such list to insert itself between the web author and the user, as some sort of "buffer" conciliator so that both sides don’t "suffer" one bit or doesn’t waste a lot of time.

    Instead of (otherwise, in parallel to) spending so much energy on compatibility list, settings, meta-tag, etc.., why Microsoft has not developed documentation and assistive software to help web authors into upgrading their web pages, to make them more compliant? That was constructive to do, proactive to do. In the long term, there is no better solution for all parties involved.

    Once browser manufacturers have fixed a large set of compliance bugs and implementation bugs, then it becomes very interesting for web authors to adopt web-standards conformance coding practices.

    I feel you over-excessively worked on the safety net, on padding this and that, on defending, protecting the web relation … to a point where ordinary people don’t see the point of upgrading and how to upgrade, to fix their webpages.

    microsoft.com is on the compatibility list. Why do you choose this? You create a browser (the most web standards compliant IE rendering engine) that you refuse to honor, to serve on your very own website!

    Gérard Talbot

  24. Dan says:

    JAB, that’s a comically broad generalization.  Although I guess you admit that you’re imagining.  As for the pedantics of "tags" vs "elements", no one was remotely confused.  The terminology "HTML tag" is well understood by everyone in this industry.

    Tino, did you check the email specified in your WHOIS?  MS claims above that they emailed you there.

    Steve, that’s a fine little webservice, but why bother using it?  Everyone has the XML list locally, and finding a domain is just one CTRL+F away…

    FremyCompany, you don’t understand the X-UA-Compatible feature.  In the header/META, you specify the LATEST version of IE you’re known to be compatible with.  Specifying multiple values doesn’t make sense.  Using "Edge" means "give me the latest behavior, even though it might be 10 years from when I first developed the site and it’s very likely to be broken."

  25. Dan says:

    Gérard, why do you persist in leaping to the demonstrably incorrect conclusion that web authors WILL do the work to make sites more compliant?  There’s 10+ years of history that shows sites are far from universally willing to do so (see also: Why IE6 persists; Business Value).  

    While I think it would be great for Microsoft to offer such tools, their adoption is guaranteed to be limited.

  26. Scott Dickens [MSFT] says:


    As you’ve pointed out, getting accurate contact information for domains is an imperfect science. When we (Microsoft) have something better than WHOIS, we try to leverage that. In any case, site owners (and anyone else for that matter) can always view the list by navigating to res://iecompat.dll/iecompatdata.xml.

    We do consider the presence of the X-UA-Compatible tag as an indicator that a site is compatible with IE8. However, this too is imperfect (which is why it is just one indicator). As an example, suppose that the entire site ‘Microsoft.com’ is on the list but one area of the site, msdn.microsoft.com, has done great work to support IE8 Standards mode. Removing the entire ‘Microsoft.com’ domain from the list based on content in a page at msdn.microsoft.com would be bad in this example as only one portion of Microsoft.com is really ready for IE8 Standards.

    There are indeed human elements to the process. Though, as I mentioned in this other post (http://blogs.msdn.com/ie/archive/2009/02/06/compatibility-list-faq.aspx), the IE test team just doesn’t scale to in-depth testing of every piece of functionality on every page of every site. That’s why telemetry and other feedback mechanisms are such an important part of the process.

  27. IE8 al momento è stato rilasciato in versione RC1. Una delle cose che preferisco del nuovo IE8 è il fatto

  28. Scott Dickens [MSFT] says:


    I appreciate that you’re looking for clear "black and white" answers on some of these points, but the reality is that there are gray areas.

    For example, you’ve asked for a complete list of domain names that could potentially end up on the list. A simple question. However, there’s a complex answer – this changes over time. For example, barackobama.com wasn’t an incredibly important, high traffic domain several months ago. It now is. There are seasonal changes too – tax preparation websites, holiday shopping, etc…

    RE: testing and the human element. Yes, there are human elements to the process. As I mentioned in a previous post (http://blogs.msdn.com/ie/archive/2009/02/06/compatibility-list-faq.aspx), though, the IE test team honestly just doesn’t scale to in-depth testing of every site. That’s why we rely on telemetry data and other feedback mechanisms as well. The question of how much of a site one needs to be tested to determine compatibility is also difficult to define. For example, it’s somewhat more straightforward to prove the presence of a compatibility problem than absence of a problem. If we didn’t find a problem, does that mean there isn’t a problem or that we didn’t test the right areas?

    As I stated in the post, list updates occur regularly, about every two months. That means neither additions nor deletions are "immediate" (asuming "immediate" here means basically instantaneous); they follow a regular, predictable cadence.

    Lastly, as I called out in a separate post (http://blogs.msdn.com/ie/archive/2008/12/03/compatibility-view-improvements-to-come-in-ie8.aspx) and this post, the purpose of the compatibility list is to offer IE8 users a choice of experiencing high volume sites in a more compatible manner than IE’s ‘standards-by-default’ experience allows for. Having a "compatibility problem free" experience on these high volume sites means a significant number of users will have a great experience with IE8. This analysis is done per region so government entities, banks and other financial institutions, and retailers do bubble up. It’s interesting that you use the term "important" because it implies that there should be more subjectivity to the process. For example, my daughter’s day care website is "important" to me. Most IE users also have sites that are "important" to them. But, there’s only one list and it ships to all IE users in all regions.

  29. @Dan

    > While I think it would be great for Microsoft to offer such tools, their adoption is guaranteed to be limited.

    Of course it would have limited adoption, a relative adoption. But it would be better, much better than nothing. Better than 10 years of MS-FrontPage. Better than 10 years of MS-Word exporting to HTML. Better than 10 years of silence, of negating W3C web standards.

    Web Pages are NOT Created Equal:




    Recently, MAMA study (january 2008)


    reports that a web authoring tool (Apple iWeb) can produce valid markup code. Over a sample of 2504 webpages examined output by Apple Iweb, 81.91% passed validation.

    Microsoft FrontPage: 0.55%

    Microsoft MSHTML (whatever that is): 1.29%

    Microsoft Visual Studio: 1.19%

    Microsoft Word: 0.62%

    HTML Tidy


    first appeared in 2000 and was designed to remove invalid, incorrect markup code specifically produced by MS products. That’s 9 years ago!

    If you want billions and billions of webpages to be more compliant and more interoperable, then you should work on improving your existing HMTL edition softwares and/or develop better ones along with better documentation, really helpful documentation. Improving the rendering engine is nice but not enough.

    I’ve never ever read anything helpful at MSDN rearding markup code validity, web standards compliance, etc.. 95% of all code examples in MSDN webpages make use of invalid markup code, quirks mode, proprietary extensions, document.all, etc.which is supposed to work for IE 5 and IE 6.

    Gérard Talbot

  30. Andrew says:

    @Scott Dickens

    Isofarro raises a good point in his second comment; it’s really strange that you put uk.com on the Compatibility List because each subdomain is operated by a different person, company or organisation:


    Also, I’m a little confused as to how it qualifies for the Compatibility List because most of the websites (on subdomains, the http://www.uk.com main site is really just advertising with no real content) look like small companies and organisations, and I thought you were only adding the high-traffic websites that don’t work in IE8. (Of course, if you’re aggregating all traffic to *.uk.com, then I guess that would explain it.)

    But it again raises the issue (as Isofarro mentioned on his blog: http://www.isolani.co.uk/blog/standards/Ie8BlacklistForcingStandardsRenderingOptIn ) of what happens on subdomains (more examples are *.wordpress.com and *.blogspot.com) that are operated by different people/organisations?

  31. IE Not Standards Compliant says:


    IE8 Final/Gold to be released in March.

    As said previously, MS and the IE Team doesn’t care one bit about code quality, they just want to ship it in time for Windows 7.

  32. Paul says:

    IEblah blah blah– Your ranting doesn’t even make sense.  Windows 7 isn’t coming out in March, so saying that IE is coming out then so it’s "in time for Windows 7" is dumb.

    Most people that make stuff up to write in these comments at least bother to make it self-consistent.

  33. Disappointed says:

    How many of you are getting bonuses for getting IE8 out at a certain time?

    I would find that the only gold digging reason to release an unfinished product.

    But hey, you hit it right on the mark! AWESOME JOB!

  34. martin says:

    I thought I read that "hasLayout" was no longer in IE8?

    If so, in IE8 standards mode, why does 25%-75% of the elements on a page have .hasLayout set?

    moreso, why is it that the elements that don’t have it – seem to be the ones that won’t render properly.

  35. Tino Zijdel says:


    "Tino, did you check the email specified in your WHOIS?  MS claims above that they emailed you there."

    That’s right, and they did, and I blogged about that mail (in Dutch: http://crisp.tweakblogs.net/blog/1221/tweakers-punt-net-en-internet-explorer-8-compatibility.html )

    Basically the mail wasn’t helpfull at all; it looked like a standard mail and only mentioned that they had ‘tested’ our site at ‘www.tweakers.net’ (sic – we dropped the www years ago) and found that it was incompatible with IE8 (bèta 2 at that time) because ‘parts of the layout could look different’.

    It didn’t go into any details nor provided any pointers. It then gave some tips on how to prepare our website for IE8 which basically boiled down to add the X-UA-Compatible tag set to IE=EmulateIE7.

    I know of one minor layout issue on our site in IE8 which I consider a bug in IE8 since it’s the only browser that has this issue; IE6 didn’t have it, IE7 didn’t have it, nor do any other of the bigger browsers. If IE8 ships with this bug then I know how to work around it, but I still have some hope that it will be fixed before RTM. Maybe I can find some time to set up a testcase, obviously MS didn’t try to find the cause of the layout difference on our site and assumed it was our mistake and not IE8’s…

  36. Ian says:

    Can we not get an IE6 compatibility View? At least it would get all these stubborn IT managers to upgrade and we can finaly get rid of IE6 for good.

    I have to many clients that I go to see, how are still using this dinosaur browser and have no clue that newer versions or other browsers exist.

    How about a force upgrade that doesn’t allow the user to cancel?

  37. joseph@southwell.org says:

    I am trying to run a product called tiddlywiki. It is one file local javascript based wiki. It can’t save changes to itself. This worked in IE7. I have noticed the the security zone at the bottom says internet when I am looking at a local file. I think this may be the problem. I tried to add it to trusted sites but I can’t because it is not a url it is just a file. How do I control security on local files?

  38. Glen Fingerholz says:

    @MS: What exactly is different in compatibility mode in IE 8 from IE 7? I’ve noticed a few things and I’m concerned that we’ll have to test in IE 7 anyways, regardless of IE 8’s compat. mode. For instance, that button artwork stretch bug was fixed in IE 8, and for some reason it’s now additionally fixed in the "IE 7" part of IE 8. Does compat. mode use the old version of JScript that IE 7 used?

    @Gerard: The HTML produced by Word has a lot less junk if you choose the "Filtered" option. It’s obvious why that junk is there. People are expecting HTML files to work the same way Word documents do in regards to what they store e.g. document properties, data to re-create vector graphics converted to bitmaps, embedded excel worksheets, etc. People expect things to just work, and so ugly things end up getting done to appease them. Otherwise you end up with your average idiot user puzzled why all the sudden their document is "broken" and stuff isn’t working the way it was earlier. There are more of those kind of users than there are people who care about things like "web standards", so Microsoft made the right decision with the approach they took (from the standpoint of making the most people happy).

    That said, I hate the inconsistency in which quotes are used with attributes (and even which quote, for that matter), the wonderful indention used in the generated source, the style tags missing the required type attribute, and the lack of a DOCTYPE. That’s more of complaint for the Office team, though :P.

  39. miller says:

    Glad to see the fixes in IE8 so far in RC1.  There is lots still to fix and it is too bad that so many simple bugs just are not getting fixed.

    there is a good tally here of the fixed vs. won’t fix bug list.


    there is actually a pile more bugs but most are still open without any confirmation from microsoft if any of them are fixed or being addressed.

  40. kristr says:

    Thanks for the information. IE is really troubling us too much

  41. Philip Hagen says:

    Microsoft is refusing to fix basic rendering issues with IE 8, as demonstrated by their refusal to fix bug number 18372, among others.  The Microsoft Connect URL for that bug is listed below:


    In case anyone on the IE team actually cares, I am reposting my validation comment from that bug here.


    As the person who originally reported this bug, I am extremely disappointed that Microsoft has decided that it won’t fix this bug because it is in too much of a rush to push a buggy and incomplete Internet Explorer 8 onto the public.  This is a major bug that is going to break a lot of web sites (although, given how huge the list of sites that Microsoft forces into "compatibility mode" is, one wonders if Microsoft even cares about fixing IE 8, or if maybe they actually want to force the entire web to use non-standards IE 7 rendering mode forever, as that would give them a competitive advantage).  After years of attempting to work around IE bugs, and even attempting to make IE better by submitting bug reports, only to be snubbed and ignored in this matter, I’ve had it.  I’m tired of wasting hundreds of hours and thousands of dollars of development time working around Internet Explorer’s bugs, only to have my hopes raised and then dashed that IE 8 was finally going to be "different", standards compliant, and less buggy.  I’m not going to work around Microsoft’s arrogance and incompetence any longer, and I’m not going to implement a stupid and non-standards compliant "render like IE 7 forever" tag just to work around Microsoft’s incompetence either.  It’s time that Microsoft starts paying the price for its arrogance and incompetence.  Therefore, since Microsoft has decided to tell web developers that they should eat the costs of Microsoft’s bugs such as this one by implementing stupid workarounds, I will return the favor and join the growing number of web sites and developers that are advising users to switch from IE to more modern and standards compliant browsers by adding notices to all of our web sites and on-demand applications (which are used by hundreds of thousands of people each day) informing people that they will have a suboptimal experience if they use IE and advising them to switch to a more modern browser such as Firefox, Chrome, Opera, or Safari.  With this type of attitude on Microsoft’s part, it’s little wonder that Internet Explorer is rapidly losing market share, and unless Microsoft decides to reconsider its decision to stab us and other web developers in the back by not fixing basic bugs such as this one because it’s in such a rush to foist an unready and extremely buggy version of Internet Explorer onto the public, I and many others will do everything in our power to ensure that the decline in IE’s market share continues and even accelerates so that one day we won’t have to waste time dealing with Internet Explorer at all.  As noted by many on the web already, it’s painfully obvious that Internet Explorer 8 RC 1 has major issues and is nowhere near ready for release, so if Microsoft actually rushes its release in this state, web developers may not have to do much to lower its market share, as users will avoid it in droves.  To sum up, as others have already pointed out, if Microsoft can’t be bothered to produce a decent, modern, standards compliant web browser that actually works properly, it really should just stop wasting everyone’s time with IE altogether.  You’re already years behind the competition, and the attitude expressed by Microsoft in this bug report is only putting you further behind the competition.  Either do it right, or get out of the browser business.

  42. Philip Hagen says:

    In my post above, I incorrectly cited the bug number as 18372, which is the build number for IE 8 RC 1 that was listed in the bug report.  The actual bug number is 413039, as referenced in the URL that I included.

  43. Stifu says:

    Philip Hagen: shameful thing, indeed. No other browser vendor would have closed a valid bug like that. Besides, if they weren’t going to fix it for IE8, the least they could have done is leave the bug report open for IE9, rather than marking it WONTFIX.

  44. Mitch 74 says:

    The closing of a bug in Connect isn’t the same thing than, say, Mozilla’s Bugzilla; Connect is ‘IE8 only’ since it is not the internal issue tracker used by MS. It is not rare for other browser vendors to mark a bug as being postponed to a further release.

    It is, however, bad in that case as it is actually a REGRESSION; and marking a regression as WONTFIX is sure to create heaps of trouble: why use the ‘new’ version if it’s more buggy than the older one?

    Other browsers also do frequent releases (major and minor), about one every six months (on average). New IE versions are released only once every 3 years, and older versions stay ‘active’ much longer: there hasn’t been a ‘minor’ revision since IE 5.5.

    I’ve given up on IE 8 imrpoving (even though a beta 3 AND a RC2 would have been useful), and I hope there will be an IE 8.5 correcting all those regressions and bugs in Standards mode soonish.

  45. Justcheckin says:

    @Steve Webster

    The whole thing about the blacklist doesn’t work at all!!!

    try nl.wikipedia.org. It says YES! However the default is rendering it in IE8 mode. Same goes for nearly 95% procent of the sites I tried.

    So it looks you have some kind of randomizer at work..

  46. george says:

    @Philip Hagen /@MSFT

    I agree. If there are regression bugs being marked as WONTFIX (and there are quite a few) – then IE8 RC1 is NOT the Release Candidate to build the RTM off of.

    Lets get serious for a moment.  IE8 RC1 is not bug-free enough for us to even start porting our code to ensure that IE8 Final users will get a quality user experience.  An IE8 RC2 is no longer a whimsical desire – its a given need.

    We can’t fully test our code because IE8 isn’t ready for production yet.  There are still major issues with InPrivate and Web Slices, Regression bugs in very basic HTML rendering, JavaScript scoping issues, half fixed DOM methods *cough* .getElementsByName( name ) is still massively broken, window resize events are still not firing properly, rendering alignment is all over the place in standards mode, select lists don’t render properly, not to mention all the other bugs from IE6 and IE7 days that keep getting swept under the rug.

    What I’m really concerned about is what happens if IE8 gets shipped in its current state. – What happens when IE9 comes out? Will there be 2 buttons for Compatibility? 1 for the "almost kinda standards" mode of IE8, and another for "not even close to standards" mode of IE7?

    The more core JavaScript issues that get fixed now the better… this way when IE9 comes out you won’t be in the mess IE8 is trying to clean up.

    I sincerely hope that all the commenters and bug submitters that are informing you that you need an RC2 are not having their statements fall on deaf ears.  It would be a real shame to ignore the experts that are trying to help you make a better product.

  47. ># re: Just The Facts: Recap of Compatibility >View

    >Monday, February 16, 2009 7:32 PM by Alex


    >Thanks, IE team.  Working with IE has been >painful in the past (and the hangover is >still lingering), but it’s really apparent >that you’re working hard and keeping web devs >in mind.

    You certainly are a developer from IE team to say that.

    Define "working hard". What I see for now (for the RC !!) about IE8 RC1 :

    – Not stable. Often crash

    – Renders more or less the same as IE7 do.

    – No support for XHTML 1.1, custom entities, application/xhtml+xml mime type, SVG… All those old standards are still unsupported by IE8 in 2009 ! My test website http://www.gabsoftware.com, which have XHTML 1.1 with extended DTD and custom entities and tags is still rendering as badly as IE7 did.

    – Still slow.

    – Still that stupid delay before it is actually possible to enter an url in the address bar.

    That’s a lot of handicaps for a RC.

    Working hard ? Then we don’t have the same definition of hard-working. It’s maybe time for the IE team to stop to send themselves some flowers, stopping all the "hurray" and actually go to WORK.

    Let’s be realistic : it’s broken from the begining. Presto is bad. Then why are you, IE devs, wasting more time on it ?

  48. graffic says:

    IE8 … Standards?

    Excuse me, I have to go out to laugh.

  49. charles says:

    @Alex re: "Still that stupid delay before it is actually possible to enter an url in the address bar" – Microsoft has confirmed that they will not be fixing this in IE8. http://tinyurl.com/bzmul6 [bug# 342]

    I don’t think they should have quit trying to fix this bug since it affects every single IE user – but apparently they have other priorities.

  50. @Justcheckin

    In my testing http://nl.wikipedia.org renders in IE8 Compatibility View using the IE7 Standards document mode (as reported by the IE Developer Toolbar).

    The http://ie8blacklist.appspot.com application uses data that was extracted directly from Internet Explorer using the res://iecompat.dll/iecompatdata.xml URL. If you are not seeing the expected behaviour, it’s possible that either your Compatibility View isn’t up to date (it’s listed as non-critical via Windows Update) or you have the  ‘Include updated website lists from Microsoft’ turned off in the Tools > Compatibility View Settings option window.

  51. sonicdoommario says:

    Hey Phillip:

    Heard of a thing called a paragraph?

    And you’ll do everything in your power to diminish IE…..lol….

  52. EricLaw [MSFT] says:

    @Steve: The best bet is probably for the user to examine the XML resource directly from their own machine.  

    @Charles/Alex: Don’t believe everything you read.  An improvement was made here post-RC1, but the fact remains that buggy addons will slow new tab creation.  On my system (2+ years old) with few addons installed, I hit CTRL+T and can type in the address bar less than 100ms later.

    @Gabriel: Accusing people of not being who they say they are is rather pointless in a forum that doesn’t authenticate users.  Microsoft IE team members post with MSFT after their names.  

    I’d like to remind everyone (including the new folks) of the rules for commenting here: http://blogs.msdn.com/ie/archive/2004/07/22/191629.aspx


  53. HD says:

    Not directly related to compatibility but, I have few problems.

    I am using ie8 rc1 on xp sp2

    1.*.mht files take a very long time to open in ie (sometimes ie crashes while attempting) but in opera this is much faster

    2.when some web pages that are saved as html are opened in ie images do not get displayed ,but i do not have this problem with other browsers

    3.the shortcut key combination ctrl+s works for

    save,which is disabled always when a web page has to saved saved .So I have to use save as instead which does not have a shortcut key combination assigned

    4.downloading a web page takes time on dialup.

    the download window for webpages in ie does not allow me to use the browser till the download is over(it’s a big headache)

    I save a lot of webpages for future use and all these problems are related to saving and viewing webpages in ie. As a result I find it quite hard to manage my tasks with ie

    Weren’t any of these problems reported before? Strange !!!is it only in my computer that these problems appear???

    I would like a quick answer

  54. Phil says:

    @Eric Law – I have no addons installed and when I hit CTRL-T, I can type in the url bar in less than 5 secs later.  But not less than 4.  I hope it really has been improved in post-RC1 – but as we’re not getting an RC2, roll on the final release…

    What’s the rationale for no RC 2 anyway?

  55. EricLaw [MSFT] says:

    @Phil:  We often find that users who have "no addons installed" actually have a few (e.g. the Java SSV helper, etc).  Do you see exactly the same delay when you start IE explicitly in no addons mode?  www.enhanceie.com/ie/troubleshoot.asp#crash explains how to do this.

    Can you tell me a bit more about your configuration?  What OS & Service Pack are you using? What page appears when you hit CTRL+T? What are your hardware specs?

    (While it’s a somewhat awkward workaround, one thing you can do in your current build is simply hit ALT+D to get to the current tab’s address bar, type a new address, and hit ALT+ENTER to open the typed address in a new tab.)

  56. EricLaw [MSFT] says:

    @HD: What generated the MHT files?  How long is a "long time"?  Do you see the crashing  problem in no addons mode?

    2> How are you saving the web pages?  

    3> Unfortunately, mapping CTRL+S to "Save as" is not something we got to in IE8.  It’s a little more complicated than one would expect because IE can host other document types beyond plain HTML.

    4> Yes, downloading pages takes time on dialup.  I’m afraid this has always been true.

    5> I’m not sure what you mean when you say that you cannot use the browser while downloading.  IE’s download dialog does not block you from using the browser while the download progresses, although obviously your bandwidth will be limited.  If you’re on dialup, the browser is limited to two connections per server (suggested by the HTTP RFC).  If you want to increase that limit, check out the first "speed tweak" at http://www.enhanceie.com/ie/tweaks.asp

  57. steve_web says:

    @whale – you may want to edit and re-open your bug on connect:


    It appears that the IE Team did not read your report and just slapped the generic: "This looks like a feature request, and we don’t have time for those" responses on it.

    Seeing that it already has ~12 "Very Important" flags set on it – it obviously isn’t just a "nice to have".

  58. Phil says:

    @Eric – Really, no addons.  Except Adobe helper, whatever that is.

    Hardware – Dell Optiplex, 1.6Ghz, single core, 1Gb memory, XP SP 3.  When I do the CTRL-T and the tab opens, it’s the about:tabs page that lists recently opened pages, etc (which is a nice touch, by the way – handy if you accidentally close the wrong tab).

    If it’s relevant, I don’t use web slices or accelerators.  Clicking the new tab gadget is as slow as doing CTRL-T.

    I’m not a developer in any way, so from a user perspective, I’m liking IE 8 and only had a few issues which I totally expect as it’s beta.  I’d still like to know why there’s no RC2 coming though.

  59. Ted says:

    phil read carefully: did… you… actually… try… running… in… -extoff… mode???

    stevewb>> more likely, they read it, concluded that it was a suggestion (which it is) and declined without explicitly saying <<no>>.

  60. Phil says:

    @ted – i’m… not… a… retard… don’t talk to me like one.  With NO ADDONS ENABLED the problem still exists.

  61. Ben Amada says:

    The version number of IE8 RC1 is 8.0.6001.18372 and I’ve heard the version number of IE8 in Windows 7 is 8.0.7000.0.  I would think 8.0.7 is a version later than 8.0.6001.18372, however in the "IE8 in Windows 7 Beta" blog post, it was said that IE8 in Windows 7 is a pre-release candidate.

    So my question is, which version is newer — 8.0.6001.18372 or 8.0.7 ?

  62. jim says:

    So this compatibility list res://iecompat.dll/iecompatdata.xml is interesting.

    about 2,400 fairly predominant sites that can’t render in IE8 properly…

    What I find interesting is that *NONE* of these sites are pornographic sites!

    I’m impressed!  I always knew that the porn industry pushed development of new web technologies (e.g. they mastered the popup, popunder, abusing JavaScript, driveby activex installs, etc.)

    But man! If all of their sites render perfectly in IE8 Standards mode by default – that’s very impressive!

    All sarcasm aside lets not kid ourselves – this is a major IE (demographic?, timeslot?) user group that will experience a significant amount Compatibility Mode support – will there be updates for them?

  63. Phil says:

    @jim – you said porn and popup, heh heh 🙂

  64. EricLaw [MSFT] says:

    @Ben: You cannot compare IE component version numbers in that way.  IE8 RC1 is a later build of IE8 than is found in Windows 7 beta.  

    @Jim: If you encounter sites that don’t render properly in IE8 Standards mode, please do use the Compatibility View feature to attempt to resolve the problem.  Thus far, that demographic seems to be happy with IE8.

    @Phil: It sounds like you’re saying that you’ve started iexplore.exe -extoff and you’re still seeing slowness on new tabs.  Do you see the same slowness if you use about:blank as the new tab page?  Which operating system are you using?  What are your proxy settings inside Tools / Internet Options / Connections / LAN Settings?

  65. Phil says:

    @Eric – yes, -extoff.

    Using about:blank – interesting test – still slow, but maybe half as slow – 2 secs approx for new tab.  An improvment nonetheless, sad to see the new tab page having to leave me though… 🙂

    OS is XP, SP 2 – company machine, not a domain I admin so not auth’d to put on SP 3.

    I use the corporate proxy on port 80, but I don’t see why that would affect opening a new tab.

  66. boen_robot says:


    I’m sure whale would have opened the bug if he could.


    Sarcasm aside, you always have the compatibility view button (if applicable) on the address bar. Whoever visits such sites will know how to use the button and whether (s)he should use it to begin with. If they don’t… they’ll probably catch a virus or something and reinstall Windows either way.


    "No add-ons except…" isn’t what is meant by "Using IE without add-ons". There is a specific shortcut for running IE with all add-ons disabled in Accessories > System Tools > Internet Explorer (No Add-ons). The question is whether this happens THERE as well. Please don’t get offended. I’m sure Ted didn’t mean it in that way.


    I believe the removal of domains from the list could be made a little more automatic. I’m sure if you do THAT, web authors won’t complain. How it can be automatic? Accept emails from the email at the WHOIS at a certain email with a certain subject (e.g. "domain.com[list-remove]"). Upon receiving an email with that subject, check if the email that sent it matches the WHOIS record on the domain in the subject, and remove the domain from the list if it does.

    I understand that X-UA-Compatible is one way that sites can opt-out (and do so instantly), but realize that any true web standardist doesn’t want to use proprietary stuff like this one. Providing them with an easy way to remove themselves from the list while still not using X-UA-Compatible is vital for them. For the rest of the world, what you have already is great.


    I’ve said it before, and I’ll say it again – there is a need for RC2. I’m among the people who voted at the Connect item which steve_web references:


    THAT, or something should be added to Connect which will let users know if a problem is fixed internally (and thus, that there’s a high probability it will be fixed in the next public release*) and if a fix is being worked on (and thus if the issue is picked up as a valid one). Right now, only the "Won’t Fix" and "By Design" get the spotlight, and this, as you can guess, isn’t good, especially for valid regressions that get "Won’t Fix" as a resolution.

    *I understand there’s always the possibility that a fix will not go into a public release due to QA concerns, and thus you don’t want to make promises you may not fulfill. But that’s no excuse for keeping secrets. If you must, make a bulk response on such events which will say something like "We believe we have fixed this internally. Please note that due to various reasons, this fix may not go into the next public build. We’ll later mark it as ‘fixed’ if it does get into a public build."

  67. @ Philip Hagen

    Regarding bug 413039


    even before filing that bug, I emailed you that

    "(…) such layout bug is rather minor. But it’s still a valid bug. I will report it."

    I still think your bug is a minor thing according to standards of gravity and severity: no application crash, no dataloss, no CPU hanging, no loss of functionality, no detrimental effect on accessibility to content or to navigation functionality for the user.

    Keep in mind that many bugs are dependent or inter-dependent: you fix a bug here and some other bugs sometimes get fixed or behave differently. There are now a small set of bugs filed regarding system fonts like Courier New (monospace), MS Sans Serif and MS Serif. I remember testing &bull; and &#8226; when doing that testcase and the problem still occured with such character entity in that particular font.

    I fully agree with you that IE Team has mismanaged the resolution field of your bug with "Won’t Fix": this has happened in at least 20 bug reports that I know of. The "Won’t Fix" resolution field contradicts the comment saying "We will track the issue and hope to address it in a future version of IE". The danger is that later the IE team may query bug reports with "Postponed" as resolution field to create a bugs-to-fix-list for a next release… and then your bug would then get ignored … with many other "bureaucratically" mismanaged.

    One alternative solution. Create your own little IE 8 bug report list corner (or IE 9 bug report list or unfixed bug regressions, … whatever you like). I encourage you to scrupulously follow CSS 2.1 testcase authoring guidelines:


    – keep formal in the testcase: steps, actual and expected results

    – minimized testcase: very important

    – clear pass or fail condition

    – entirely valid markup code and CSS code

    Then link your IE bugs webpage to others like mine. We can/will create a solidarity web ring: we already have.


    One last thing, not solely directed to you but to some others. IE Team has fixed many hundreds of bugs, CSS 2.1 property implementations, unsupported CSS 2.1 properties, HTML 4 issues, some DOM bugs, acid2 test, etc. The fact that, so far, IE Team has not fixed one particular bug – say, 413039 – does not mean that IE 8 RC1 build 18372 – at least in standards rendering mode – is not a "decent, modern, standards compliant web browser".

    Regards, Gérard

  68. Philip Hagen says:

    @Gérard Talbot

    You may consider that bug to be "minor", but I certainly don’t, as it breaks several of our web sites.  We’re not the only ones who use bullet points or those fonts either, so I suspect that it will break many other web sites as well.

    We are talking about Internet Explorer 8 not being able to render basic HTML bullet points (list items) here.  This is something that all of the web browsers that were available in 1995 could do!  It may not be "major" in the sense that it doesn’t crash the browser, cause dataloss, etc., but it’s still a pretty big regression on the most basic of HTML rendering.

    I appreciate your help in posting this and other bugs, as well as the work that you do in tracking and reporting IE bugs.  I may also take up your suggestion of making my own IE bug list and linking it to yours.

    Regarding your final point, I wouldn’t (and didn’t) claim that IE is not a "decent, modern, standards compliant web browser" solely because of bug 413039, but because of the hundreds of similar such bugs that exist in the browser, as noted on your site and in numerous posts here and elsewhere.  I agree that Microsoft has made some progress here, but their new standards engine has also introduced a number of new rendering regressions that really need to be fixed before going final.  I stand by my original assertion that IE 8 RC 1 is nowhere near ready for release, and that if Microsoft is going to "WONTFIX" numerous valid rendering bugs and rush this browser to release before it’s ready, then IE 8 is going to bring a world of hurt to both developers and Microsoft itself.

    I’m not anti-Microsoft.  I want IE 8 to be better, or I wouldn’t bother posting here and reporting bugs.  I’m just frustrated that once again, Microsoft appears to prioritize rushing IE 8 to market over getting it right so that their customers (developers and end users) will have a better experience.

  69. Gyrobo says:

    @Scott Dickens

    You wrote:

    "…suppose that the entire site ‘Microsoft.com’ is on the list but one area of the site, msdn.microsoft.com, has done great work to support IE8 Standards mode."

    Haven’t you just made the case for using subdomains instead of TLDs for what is now apparently an opt-out mechanism?

    And doesn’t this kind of blacklist encourage developers to litter their sites with "IE-EDGE" headers and tags, _not because they are needed_ but to escape being potentially blacklisted?

    It seems like that could cause you a problem when working on IE9. If the purpose of X-UA-Compatible is to target specific versions of IE, why include a catch-all term like "IE-EDGE" anyway?

  70. > We are talking about Internet Explorer 8 not being able to render basic HTML bullet points (list items) here.

    I have been talking about RC1 build 18372 and have been talking about specific fonts. Bug 413039 is very specific and well targeted; same thing with its testcase. The bullet list markers are there – misrendered – (as thin vertical blocks) but not as filled disc. Other fonts do not have such layout issue.

    Yes, I still think this is a minor layout bug.

    > because of the hundreds of similar such bugs that exist in the browser, as noted on your site and in numerous posts here and elsewhere.

    The last time I counted on my IE8 webpage, there were 55 items which were not fixed; some are DOM implementations, accessibility issues, HTML 4 bugs, DHTML object bugs, reflow bugs, repainting issues and not all of them are objectively grave, severe, a wide majority of them are not regressions.

    Claiming/stating that there are "hundreds of similar such bugs that exist in the browser" is definitely not my opinion, definitely not my conclusion.

    IE Team created 7005 CSS 2.1 tests. I haven’t seen this sort of colossal effort anywhere before. Some of these tests are simple, a few of them are wrong, invalid, failed but overall this set of tests is extremely valuable for the web at large (users, authors, manufacturers, W3C people, web standards groups).


    "Renders more or less the same as IE7 do." Gabriel Hautclocq …

    is definitely not my opinion, definitely not my conclusion.

    Regards, Gérard

  71. The Internet Explorer 8 team has committed to interoperability and Web standards. It means that viewing

  72. yoshi says:

    i get this on all modes/views for ie8 rc1


    Error: A system shutdown has already been scheduled.

    not sure if anybody else is getting it

  73. hAl says:

    Anybody expecting a browser to be released with zero issues would be dreaming.

    IE8 is huge improvement in CSS 2.1 rendering. Not a single browser has a flawless implementation of CSS 2.1 and we can expect IE8 to have some bugs as well.

    As long as those are in features that are not used very ofen and/or have very limited impact on rendering of webpages or on security this is not troublesome.

    I seem to remember Firefox 3 was released with about 600 open issues to be resolved.

  74. hAl says:

    Anybody expecting a browser to be released with zero issues would be dreaming.

    IE8 is huge improvement in CSS 2.1 rendering. Not a single browser has a flawless implementation of CSS 2.1 and we can expect IE8 to have some bugs as well.

    As long as those are in features that are not used very ofen and/or have very limited impact on rendering of webpages or on security this is not troublesome.

    I seem to remember Firefox 3 was released with about 600 open issues to be resolved.

  75. John says:

    IE8 RC1 errors when `var foo = Element.toString;`

    Errors -> Object doesn’t support this property or method

    In at least strict doctype.

    You can test it by going to jQuery.com and typing `javascript:alert(foo = Element.toString);` into the url.

  76. Does the IE-team you have a comment to Norway (and all its newspapers and other large websites) throwing out IE6 yesterday and today?


  77. Anon says:

    You know what I’d do if I were you

    * Make quirks mode / IE7 compatibility mode the default. I.e. put every single site on the compatibility list. Allow websites to opt in to "IE 8 standards mode".

    The users will be happy. Of course a load of people that absolutely hate Microsoft will be angry. Those people aren’t your customers though, they hate your guts and wouldn’t use IE if you forced them at gunpoint. There’s no point pandering to them and risking annoying people that are customers and do use your software because nothing you do will ever please them. Even worse, their advice is designed to make people who are your customers stop using IE8 because gmail and yahoo won’t render in it.

    Read Joel on Software, he’s absolutely spot on.


    The web standards camp seems kind of Trotskyist. You’d think they’re the left wing, but if you happened to make a website that claims to conform to web standards but doesn’t, the idealists turn into Joe Arpaio, America’s Toughest Sheriff. “YOU MADE A MISTAKE AND YOUR WEBSITE SHOULD BREAK. I don’t care if 80% of your websites stop working. I’ll put you all in jail, where you will wear pink pajamas and eat 15 cent sandwiches and work on a chain gang. And I don’t care if the whole county is in jail. The law is the law.”

    On the other hand, we have the pragmatic, touchy feely, warm and fuzzy engineering types. “Can’t we just default to IE7 mode? One line of code … Zip! Solved!”

    Secretly? Here’s what I think is going to happen. The IE8 team going to tell everyone that IE8 will use web standards by default, and run a nice long beta during which they beg people to test their pages with IE8 and get them to work. And when they get closer to shipping, and only 32% of the web pages in the world render properly, they’ll say, “look guys, we’re really sorry, we really wanted IE8 standards mode to be the default, but we can’t ship a browser that doesn’t work,” and they’ll revert to the pragmatic decision. Or maybe they won’t, because the pragmatists at Microsoft have been out of power for a long time. In which case, IE is going to lose a lot of market share, which would please the idealists to no end, and probably won’t decrease Dean Hachamovitch’s big year-end bonus by one cent.

  78. If MS could concentrate on the relevant tasks instead of workarounds as always, life would be easier. Why so much effort in creating a compatibility view with a server connection somewhere instead of just implementing full CSS 2.1 and 3 and making sure web sites look at IE8 as it looks at Firefox and Safari…

  79. markham says:

    @John did you mean to type:

    var foo = Element.toString();//note the brackets

    e.g. were you trying to call the toString() method and set foo to the result?

    or were you trying to assign the toString method on "Element" to the variable foo?

    Both *should* work, presuming that "Element" is a reference to some JavaScript Object.

    If this is failing in IE8 RC1, please file a bug.

  80. Anon says:

    @Adrian von Gegerfelt

    It’s not as simple as that. IE6 introduced a lot of features before CSS was standardised. Websites used those features. Then Netscape/Mozilla/everyone else implemented things differently and the standards were set to follow what Mozilla did. So now you have websites that serve IE specific stuff to IE and ‘standard’ stuff to everything else. If IE8 abandons the old IE features and only implements CSS, all those sites will break.

    If you look at the Joel on Software blog entry I linked to, you can see that Google Maps is hopelessly broken on the IE 8 beta in standards mode. It worked fine on IE 7. Hence if MS ship IE defaulting to "standards mode", people will see it as a broken browser. If it defaults to "quirks mode" they will see it as a working browser.

    See here’s the thing. 99% of people don’t care about standards. They want websites to work when they upgrade from IE7 to IE8. Defaulting to quirks mode makes that happen. If web site authors want standards mode, they can opt in.

  81. Matt says:


    "Anybody expecting a browser to be released with zero issues would be dreaming.

    IE8 is huge improvement in CSS 2.1 rendering. Not a single browser has a flawless implementation of CSS 2.1 and we can expect IE8 to have some bugs as well.

    As long as those are in features that are not used very ofen and/or have very limited impact on rendering of webpages or on security this is not troublesome.

    I seem to remember Firefox 3 was released with about 600 open issues to be resolved."

    I completely agree.  However, Firefox fixes those issues in weeks, months at worst.  Currently, MS only release an IE version with a new OS (so at best every 3 years or so).  Don’t misunderstand me, I HATE firefox with a passion, but thats mostly for reasons that have nothing to do with html rendering.  However, they do handle updates and version releases far better than MS do.

    So far as I know, no rendering issue (short of it causing a crash) has ever been fixed in an MS Update that wasn’t a full service pack.  And I understand why.  With their backward compatability baggage, and telling people ‘develop for this and all will be fine’ they can’t very well move the goalposts on a regular basis.  Other browsers without the corporate penetration don’t have this to deal with.  For better or worse the kind of people writing in house intranet apps and the HTML to go with it aren’t designers, they’re VB monkeys who know how to make things work.  They don’t really care if its ‘right’ or not.  If it works, its good.  So if they do bizarre things in their HTML and javascript because its really working around an IE bug, they don’t know better.  

    This is, to a large extent, the baggage that holds MS back.  Yes, they shot themselves in the foot, but because they don’t want to alienate these people and encourage them to adopt the newest versions of software, they can’t arbitrarily break things.

    However, this does mean that anything not fixed by release time is going to be around for a couple of years at least.

  82. Jet says:

    @Philip Hagen: Ya, it is horrible Microsoft isn’t fixing a problem that renders correctly in every other browser on every other platform using a font that only comes with Microsoft operating systems (and looks like ass on a website).

    Certainly it is a bug, but for goodness sake, remove "ms sans serif" from "font-family: ms sans serif, tahoma, arial, helvetica, verdana, sans-serif;" and the problem is solved. Why would someone use such a narrow, non-antialiased and badly kerned font for a website in the first place? It appears the authors of that site care deeply about ensuring their markup validates as XHTML, but doesn’t give a damn that they make their visitors’ eyes bleed with such a horrible default font choice.

    Yes, yes, I already know your answer: Why should anyone have to change their horribly misguided, ugly and awful default font choice when I can rant and rave about what I perceive as Microsoft being horribly misguided in not fixing a (relatively minor) bug that I happen to have fixated on this week!

  83. Mitch 74 says:

    @Anon: I call bull. While, indeed, people want websites to work, it’s web developers that want browsers that behave correctly.

    I’ll take your IE8 example with Google Maps.

    – Google Maps provides a standards-compliant page using SVG to all browsers, detecting supported methods and objects as described in standards, and failing gracefully with browsers that don’t meet criteria.

    – Google Maps provides an IE6/7 specific page using VML because IE6/7 renders HTML and CSS differently than other browsers, generate an error when you try to detect their capabilities (or merely don’t answer), and supports rejected as standard, declared deprecated by MS, VML.

    Now, you try Google Maps with IE8 beta 2, knowing that it complies better with standards than IE 6/7, but still fails somehow: bugs, unsupported features:

    – Google Maps detects it as IE and tries to implement IE-only workarounds that don’t work in IE 8 in ‘Strict mode’: IE 8 fails. Example: in Strict mode, IE 8 beta 2 doesn’t support VML.

    – Google Maps detects it as not IE 6/7, and loads standards-compliant version of the page: IE 8 beta 2 has sub-par DOM support, doesn’t support DOM 2 events (all otehr browsers do), and doesn’t support SVG Tiny (all others browsers do, to a point): IE 8 fails.

    Had IE 8 beta 2 supported Web standards like DOM 2 events and SVG, Google Maps wouldn’t have failed. These aren’t planned for RTM. These have been supported by Webkit, Gecko and Presto for years. And Google wouldn’t have to develop an IE-8 specific page.

    Joel is overly generic, and has a American-Microsoftian outlook. See, at the end, he says: ‘98% of the world will install IE8 and say, “It has bugs and I can’t see my sites.” ‘


    There are still Windows 2000 users, or corporate XP users, stuck with IE6; they can’t update to IE 8. However, they can run Firefox from an USB key, or as a secondary browser. These people will want a webpage that complies with standards or default to IE6 mode, as IE 7 doesn’t support either modes.

    There are Mac users, deserted by Microsoft, who represent 8% of all personal computers on the Intarwebs now, and don’t have an IE browser: they use Safari – which adheres quite closely to Standards. These people will want Standard web pages.

    There are mobiles/consoles users, that don’t have much choice in browsers: many use Opera, several have a Webkit based browser, or have the brand new IE6 Mobile (!): either IE6-optimized or Standard web pages.

    There are people that have Windows, but don’t use IE but use another browser instead: Firefox, Safari, Opera, Chrome. Depending on where you are in the world, these people represent 5% (South Korea, governmental lockdown onto an ActiveX addon) to 75% (some European countries) of all Web users.

    In short, not everybody can have IE.

    As such, you have (to make things short, disregarding IE5) two categories:

    – Standards-abiding browsers; more often than not, creating a page correctly (testing for methods support and interrogating collections) will cause a page tested against any of those browsers to work with others, or at worse to degrade gracefully

    – IE, where IE 5 doesn’t render pages like IE 6, which doesn’t work like IE 7, further fixed in IE 8, still not quite Standard; a webpage created for IE 6 (that needed fixes for IE 6’s bugs) demands some fixes for IE 5.0 (garbled rendering, misplaced elements) not required for IE 5.5, fixes that must be disabled from IE 7.0 to let way for IE 7-specific fixes (high CPU use with off-screen variable size boxes’ parents); IE 8 requires the fixes to be corrected under all browsers because it throws an error on some, but needs others that depended (until now) on these first ones. So, I now have to re-code, re-test and re-validate under all IE versions these fixes that are just not necessary in any other browser.

    As such, I now have 5 code paths to consider, starting from the same (X)HTML I feed all browsers:

    – a Standards one, for all browsers in both Javascript and CSS (comes as ‘true’ XHTML)

    – an almost standard one, where CSS is the same as above but with specific IE DOM fixes (XHTML as HTML, following XHTML 1.0 Strict Annex C recommendations)

    – an IE 7 one, that has the same DOM fixes as above

    – an IE 6 one, that has specific CSS instructions and the same DOM fixes as above

    – an IE 5 one, that has yet another layer of specific CSS instructions and some more DOM fixes piled on above’s.

    Now, let me count the ways:

    – 1 development for Firefox, Safari, Chrome, Opera, and older browsers, with SOMETIMES some less pretty looking elements on older revisions that don’t support a specific feature (Firefox 2’s lack of support for inline-block)

    – 4 developments for each of currently vendor supported IE versions (gray box around images – IE 5/6 -, overlapping text boxes – IE 5 -, scroll bars all over the place – IE 5/6/7 – , 100% CPU use leading to a system crash – IE 7 – or disappearing page elements – IE 6,8)

    Now, users may want to see working web pages; developers want to make pages that work. Creating a page that works with Firefox makes one that works with Opera and Safari, and degrades nicely with older versions; it’s also pretty much a given that it’ll keep working very well with newer versions or brand new browsers that follow the same standards; moreover, due to frequent releases in all these browsers, in case of regressions, they are very often solved a few days later.

    And then you have to support IE, with a different code path not only for IE in general, but also for each version: right now, 3 or 4. Moreover, if the past is any indication, new versions WILL contain regressions, that WON’T be fixed (see all regressions marked WONTFIX for IE 8 RTM) requiring websites to be rewritten on each and every new IE release: IE 8’s IE 7 mode isn’t identical to ‘plain’ IE 7; IE 8 doesn’t work like IE 6 at all (but Quirks mode works like IE 5.5).

    Meaning that Web developers will create a site with a small information box saying: "having trouble viewing this website in IE? Try any other browser!"

    At one time, there were ‘best viewed in IE’ or ‘optimized for Netscape’ tags all over the Web; now, we’re going to see ‘best viewed with any browser but IE’. It’s already started.

  84. HD says:

    @EricLaw [MSFT]

    Thanks for listening

    Let me clarify my problems further

    1. the web archive files(*.mht,which is the default file type which ie saves web pages)

    were generated by ie .(I do not use any add ons,except the flash extension,disabling this does not make any difference either).the "long time"lasts from a minimum of 5 about seconds(not counting the time that takes ie to start up) to infinity(if ie crashes)

    In opera it takes no more than 3 seconds

    for the same page to be opened.This problem only applies to *.mht files, both browsers take almost equal time in loading pages saved as html.

    2.The web pages were saved as html using ie8(basic save as procedure,ie is running under defaults,I did not meddle with any settings)the funny thing is some web pages display correctly (with pictures) but most do not .I am certain that these picture files were saved in the computer

    (they are present in the "xxxxx_files" folder which gets saved with the html file)

    they get displayed correctly in other browsers such as firefox and opera.but not in ie8


    3.you have missed my point, yes I am an experienced dial up user I know its slow,

    the problem is ; as it’s slow it takes sometime to download a web page.The dialog that shows the downloading process of a web page (this ONLY applies to web pages,not other files)does not allow me to use the browser till the downloading is complete.

    I think my questions are clear now.

    Waiting for an Answer

  85. EricLaw [MSFT] says:

    @Øyvind Selbek– The IE team has long encouraged IE6 users to upgrade to IE7, and when IE8 is released, we’ll further encourage upgrades to IE8.

    @yoshi– It sounds like you might have a corrupt installation; I’ve never seen the error you’re reporting or heard of it from any other source.

    @Anon– I liked Joel’s post, but his supposition was incorrect.  The Compatibility View & List is how we chose to address the compatibility issues that arise from non-standards-compliant sites.  IE8 will default to Standards mode.

    @Adrian asked "Why so much effort in creating a compatibility view"– Because most users expect their favorite sites to work, and have no idea (or inkling to care) if those sites are standards compliant.  IE8 cannot only be released "for web developers"– if it doesn’t appeal to the normal end-users, it will not get deployed, and will thus be of no help to web developers either.

    @HD– "The dialog that shows the downloading process of a web page"– are you referring to the dialog that is shown only when SAVING a webpage?

  86. Bubba says:

    More proof that the Blacklist is a terrible indicator of standards:

    http://www.wired.com is on the blacklist

    Wired has always been designed to be viewed with standard browsers, as indicated in this article:


    The blacklist needs to be more reliable. It’s the farthest thing from it.

  87. Simba says:

    I feel your pain you guys… Internet Explorer is an old dog with legacy issues. So, maybe it’s time to put it down.

    Here’s my idea….

    Retire the Internet Explorer rendering engine with all of its legacy issues, and release a "brand new" browser with a brand new rendering engine with a new name (and user-agent string) that makes a clean break with the legacy problems of the old browser. Make the rendering engine open source…so that it actually works properly.

    Since the new rendering engine (with the new user-agent string) won’t have any legacy targeting towards it…it will behave and act just like other "standard" browsers that don’t require hacks.

    To cater to the legacy sites… Continue to offer "Internet Explorer Classic" as a free (downloadable) application for people who still want to view those really old IE-only legacy sites.

    Sooner or later people will figure out which sites only work in "IE Classic." And eventually those sites will fade away into oblivion…

    Problem solved…. Thank you very much.

  88. Tino Zijdel says:

    I said before that I’m not happy with our site being on this "compatibility list" (which imo should read "incompatible-with-IE8 list"): http://crisp.tweakblogs.net/blog/1411/ie8-standards-compliant-by-default-but-not-for-tweakers-punt-net.html

    Please let me know:

    1) why we are on this list

    2) if this is because of issues encountered in IE8: which issues, and why you believe these are issues in our website and not in IE8 itself

    3) how to get off this list (without having to resort to proprietary headers/META-tags)

  89. Ryan Kaldari says:

    I am a web developer for one of the sites listed in the non-compatible list, CMT.com. Like many of the other sites in the list, CMT.com is standards compliant and renders perfectly fine in IE8 in strict mode (I’ve tested it, without Compatibility View turned on). I was never contacted by Microsoft since they are contacting domain name owners, not site developers or webmasters. I would very much like for Microsoft to remove CMT.com from their list, unfortunately, they do not seem to have provided any means for sites to opt-out of this, other than adding proprietary tags to my site’s HTML.

  90. Nameless says:

    What is with this site? The text is tiny — even with my glasses on I can’t read a word of it.

  91. 3-D says:

    First we all complained when it was said you would default to IE7 mode. An IE7 mode which, at this moment, doesn’t render entirely like IE7. So the web design and standards community went in to an uproar. So we get a beta that defaults to standards compliance. The standards compliance is still behind the pack right out of the gate, but at least it’s something. Then you slip this blacklist in.

    Seriously guys, are you trying to shoot yourselves in the foot? Like actively aiming for a specific toe or something?

    Let me make a (quickly ignored) suggestion on how you help us designers: Kill IE7 from the mix. Just kill it. Anyone NOT needing IE8 will know it. They can disable it on their internal network through GPOs and keep IE6, IE7, or whatever previous version they want. Everyone else (you know, the masses running the current browser that don’t even know *what a browser is*) will just dutifully click the auto-upgrade button and be on their way. Corporate web presence needs to just be aware of the new version and deal with it anyway, because the new browser won’t render like IE7. Their sites WILL BREAK in the IE7 mode, so they have to revise their code anyway.

    Kill off the IE7 mode. Kill off quirks mode. Just render in standards mode and deal with the fact that no matter what you do, you will be breaking the vast majority of the web. Make it a clean break and, for the sanity of designers like myself around the world, just get on the standards compliance track already.

    This cat and mouse game with standards and foisting yet another new rendering engine on us is getting really old now guys.

  92. Dan says:

    "Kill off quirks mode"

    Hahahaha… It’s not April 1st yet!

  93. @Ryan Kaldari

    > CMT.com is standards compliant

    I wouldn’t say that. 266 validation markup errors (many unencoded ampersands and missing closing single slash in empty element errors) and font-size is small, defined using px unit (10px!), so making the whole thing difficult to read and definitely non-text-resizeable, not accessible.


    Do not specify the font-size in pt, or other absolute length units for screen stylesheets. They render inconsistently across platforms and can’t be resized by the User Agent (e.g browser).


    W3C Quality Assurance Tips for Webmasters:

    Care With Font Size


    "If you do not specify any font size at all (as on the pages you are reading), text will appear in the default size that was selected by the user."


    "Bad fonts won the vote by a landslide, getting almost twice as many votes as the #2 mistake. About two-thirds of the voters complained about small font sizes or frozen font sizes"

    Top Ten Web Design Mistakes of 2005

    1. Legibility problems


    Your site has other problems – web design problems – maybe not necessarly web standards ones but nevertheless: – obvious "divitis": 145 <div> containers within 576 lines of code.

    Regards, Gérard

  94. Ryan Kaldari says:

    Dear Gérard, like most large commercial websites, the content of CMT.com is not created by the web developers, we merely build the framework into which all the content is placed. That framework is standards compliant. If the content is not, it needs to display as broken so that people adding content will learn to use standards. If we are required to be 100% standards complaint to be removed from Microsoft’s blacklist, it will never happen and CMT.com and most of the rest of the sites on this list will forever be stuck in 2008.

  95. boen_robot says:

    @Ryan Kaldari and/or Tino Zijdel

    It’s your responsibility as the developers of the framework to make sure that users/owners aren’t able to post invalid content with it. I understand there’s no way to automatically detect and/or fix accessibility and browser compatibility issues, but code validity (especially (X)HTML validity) can easily be checked upon content updates.

    If you allow the users/owners to input raw (X)HTML, you can always check the (X)HTML by validating the page against its DTD, and only update it upon successful validation (and present an error message otherwise). If you allow (X)HTML fragments to be inputted, wrapping them in a minimum document, and validating that is just as easy. And if you allow plain text to be added, you should always escape special cracters (<,>,&,",’) to entities, and only then place it where it should be.

    If you want, you can go one step further, and try to fix the invalid (X)HTML for the user by using something like Tidy. But the point is that you can always make the final output page valid – it takes only one (or few) "if"s in your code. While "Valid != Standards Compliant", "Valid" is still a requrement for a site being "Standards Compliant".


    I’d really like to hear someone else say this, as I feel I’m talking to myself – if you could easily remove your site from the list without using X-UA-Compatible, would you use this method? Define what method would you consider "easy"?

    I already defined one earlier – sending an email from your WHOIS email to a specially crafter MS email with a special subject, that once received will schedule you for removal on the next update (and a permanent "no IE8 compatibility blacklisting" ticket).

  96. boen_robot says:

    Oops… Tino… sorry… I believe your case (unlike Ryan’s) is more valid. For a moment there, I though you were with CMT.com too. Sorry again.

    I’d still like to see comments on my automation idea though.

  97. ZDNet recently covered Microsoft’s IE8 incompatibility list in nice detail. Not surprisingly, about 2,400 major web-sites are not "IE8 ready", meaning that they don’t render properly in IE8. Sadly, just about every important site is on this incompatibility

  98. @Ryan Kaldari

    1- "If we are required to be 100% standards complaint to be removed from Microsoft’s blacklist(…)": I don’t know why cmt.com was added to the compatibility list. I do not think cmt.com was added to the compatibility list just because the site (main entrance webpage) failed HTML validation.

    2- I listed 3 precise issues which, I believe, could be fixed rather easily. 2 of those issues (unencoded ampersands and missing single slash in empty element for XHTML; why did you choose XHTML to be served as text/html anyway/to begin with?) could be explained to users.

    From a code maintenance point of view, 145 <div> containers in that framework is a rigid, impossible nightmare. 145 <div> is what makes a page over-constrained, unneedlessly over-coded, over-excessively difficult to untangle.

    3- One point that, in my opinion, has to be fixed imperatively is the font-size issue. The solution: just do not define a font-size (or define it as 100%) for the web page and then

    a) the users will see the page with their preferred font-size and

    b) the users will be able to text-resize the webpage as they wish/need to

    Web standards checklist, sections 3.2 and 3.3 is for you


    The 100% Easy-2-Read Standard


    Top 10 Reasons Why Big Type is Good Business


    4- I agree with boen_robot: you can always check the (X)HTML by validating the page against its DTD, and only update it upon successful validation. Best would be to inform users on steps they must do before submitting their content, otherwise on how to fix/correct frequently encountered markup errors before submitting their content.

    Regards, Gérard

  99. I’ve noticed that when I’m working on a page hosted on my own machine, I do not get the option for going to Compatibility Mode and back. This is a problem as I don’t have IE7 for testing, and I don’t always want to put pages available online just to test whether the page works in one browser (or compatibility mode) or not.

  100. bruiloft says:

    It’s sad, because of the fact that I had to adjust my website to IE6, then to IE7 and now to IE8. Please create a browser that shows a valid website like it should!

  101. IEBlog says:

    Today we’re excited to release the final build of Internet Explorer 8 in 25 languages. IE8 makes what

  102. Microsoft released the final version of IE8 last week (3.19.2009); your users will soon be automatically upgraded unless auto-updates have been explicitly blocked. Are you ready?…

  103. JScript Blog says:

    With Internet Explorer 8 we introduced several new JScript language features including native JSON support

  104. IEBlog says:

    With the “final” release of IE8 for Windows Vista and other versions of Windows in several languages

Comments are closed.

Skip to main content