다음을 통해 공유

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.

Compatibility

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

Recap

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

  • Anonymous
    February 16, 2009
    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?

  • Anonymous
    February 16, 2009
    @Kelson: Type res://iecompat.dll/iecompatdata.xml into your address bar to see the Compatibility View list.

  • Anonymous
    February 16, 2009
    The comment has been removed

  • Anonymous
    February 16, 2009
    @EricLaw: Thanks.  Wow, that's a much longer list than I expected.

  • Anonymous
    February 16, 2009
    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

  • Anonymous
    February 16, 2009
    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.

  • Anonymous
    February 16, 2009
    Scott has just published a great recap of the Compatibility View on the IE blog . To summarize with one

  • Anonymous
    February 16, 2009
    The following picture summarize the usage of the META tag...

  • Anonymous
    February 16, 2009
    The comment has been removed

  • Anonymous
    February 16, 2009
    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!

  • Anonymous
    February 16, 2009
    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?

  • Anonymous
    February 16, 2009
    The comment has been removed

  • Anonymous
    February 16, 2009
    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 ?')

  • Anonymous
    February 16, 2009
    Hey Now Scott, Well written post. Thx 4 the info, Catto

  • Anonymous
    February 16, 2009
    The comment has been removed

  • Anonymous
    February 16, 2009
    The comment has been removed

  • Anonymous
    February 16, 2009
    @Stefan 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)?)

  • Anonymous
    February 16, 2009
    The comment has been removed

  • Anonymous
    February 16, 2009
    The comment has been removed

  • Anonymous
    February 17, 2009
    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).

  • Anonymous
    February 17, 2009
    @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?

  • Anonymous
    February 17, 2009
    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.

  • Anonymous
    February 17, 2009
    @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

  • Anonymous
    February 17, 2009
    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."

  • Anonymous
    February 17, 2009
    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.

  • Anonymous
    February 17, 2009
    @boen_robot 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.

  • Anonymous
    February 17, 2009
    IE8 al momento è stato rilasciato in versione RC1. Una delle cose che preferisco del nuovo IE8 è il fatto

  • Anonymous
    February 17, 2009
    The comment has been removed

  • Anonymous
    February 17, 2009
    The comment has been removed

  • Anonymous
    February 17, 2009
    The comment has been removed

  • Anonymous
    February 17, 2009
    http://www.techarp.com/showarticle.aspx?artno=621 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.

  • Anonymous
    February 17, 2009
    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.

  • Anonymous
    February 17, 2009
    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!

  • Anonymous
    February 17, 2009
    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.

  • Anonymous
    February 17, 2009
    The comment has been removed

  • Anonymous
    February 17, 2009
    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?

  • Anonymous
    February 17, 2009
    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?

  • Anonymous
    February 17, 2009
    The comment has been removed

  • Anonymous
    February 17, 2009
    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. http://webbugtrack.blogspot.com/2009/02/fixed-bugs-in-ie8.html 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.

  • Anonymous
    February 17, 2009
    Thanks for the information. IE is really troubling us too much

  • Anonymous
    February 17, 2009
    The comment has been removed

  • Anonymous
    February 17, 2009
    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.

  • Anonymous
    February 17, 2009
    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.

  • Anonymous
    February 17, 2009
    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.

  • Anonymous
    February 17, 2009
    The comment has been removed

  • Anonymous
    February 18, 2009
    @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.

  • Anonymous
    February 18, 2009
    ># 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 ?

  • Anonymous
    February 18, 2009
    IE8 ... Standards? Excuse me, I have to go out to laugh.

  • Anonymous
    February 18, 2009
    @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.

  • Anonymous
    February 18, 2009
    @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.

  • Anonymous
    February 18, 2009
    Hey Phillip: Heard of a thing called a paragraph? And you'll do everything in your power to diminish IE.....lol....

  • Anonymous
    February 18, 2009
    @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 thanks!

  • Anonymous
    February 18, 2009
    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

  • Anonymous
    February 18, 2009
    @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?

  • Anonymous
    February 18, 2009
    @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.)

  • Anonymous
    February 18, 2009
    @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 www.enhanceie.com/ie/tweaks.asp

  • Anonymous
    February 18, 2009
    @whale - you may want to edit and re-open your bug on connect: https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=415158 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".

  • Anonymous
    February 18, 2009
    @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.

  • Anonymous
    February 18, 2009
    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>>.

  • Anonymous
    February 18, 2009
    The comment has been removed

  • Anonymous
    February 18, 2009
    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 ?

  • Anonymous
    February 18, 2009
    The comment has been removed

  • Anonymous
    February 18, 2009
    The comment has been removed

  • Anonymous
    February 18, 2009
    The comment has been removed

  • Anonymous
    February 18, 2009
    @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.

  • Anonymous
    February 18, 2009
    The comment has been removed

  • Anonymous
    February 18, 2009
    @ Philip Hagen Regarding bug 413039 connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=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: www.w3.org/Style/CSS/Test/guidelines.html

  • 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

  • Anonymous
    February 18, 2009
    The comment has been removed

  • Anonymous
    February 18, 2009
    The comment has been removed

  • Anonymous
    February 18, 2009
    The comment has been removed

  • Anonymous
    February 18, 2009
    The Internet Explorer 8 team has committed to interoperability and Web standards. It means that viewing

  • Anonymous
    February 18, 2009
    i get this on all modes/views for ie8 rc1 >>window.open('http://www.google.com','_blank') Error: A system shutdown has already been scheduled. not sure if anybody else is getting it

  • Anonymous
    February 18, 2009
    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.

  • Anonymous
    February 18, 2009
    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.

  • Anonymous
    February 18, 2009
    The comment has been removed

  • Anonymous
    February 18, 2009
    Does the IE-team you have a comment to Norway (and all its newspapers and other large websites) throwing out IE6 yesterday and today? http://thatnorwegianguy.com/norwegian-ie6-spring-cleaning/

  • Anonymous
    February 18, 2009
    The comment has been removed

  • Anonymous
    February 18, 2009
    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...

  • Anonymous
    February 19, 2009
    The comment has been removed

  • Anonymous
    February 19, 2009
    @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.

  • Anonymous
    February 19, 2009
    The comment has been removed

  • Anonymous
    February 19, 2009
    The comment has been removed

  • Anonymous
    February 19, 2009
    The comment has been removed

  • Anonymous
    February 19, 2009
    The comment has been removed

  • Anonymous
    February 19, 2009
    @Ø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?

  • Anonymous
    February 19, 2009
    The comment has been removed

  • Anonymous
    February 19, 2009
    The comment has been removed

  • Anonymous
    February 19, 2009
    The comment has been removed

  • Anonymous
    February 19, 2009
    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.

  • Anonymous
    February 19, 2009
    What is with this site? The text is tiny — even with my glasses on I can't read a word of it.

  • Anonymous
    February 19, 2009
    The comment has been removed

  • Anonymous
    February 19, 2009
    The comment has been removed

  • Anonymous
    February 19, 2009
    @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 http://www.w3.org/QA/Tips/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." http://pages.prodigy.net/chris_beall/TC/Font%20size.html "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 http://www.useit.com/alertbox/designmistakes.html 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

  • Anonymous
    February 20, 2009
    The comment has been removed

  • Anonymous
    February 20, 2009
    The comment has been removed

  • Anonymous
    February 20, 2009
    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.

  • Anonymous
    February 20, 2009
    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

  • Anonymous
    February 20, 2009
    The comment has been removed

  • Anonymous
    February 20, 2009
    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.

  • Anonymous
    February 23, 2009
    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!

  • Anonymous
    March 19, 2009
    Today we’re excited to release the final build of Internet Explorer 8 in 25 languages. IE8 makes what

  • Anonymous
    March 24, 2009
    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?...

  • Anonymous
    April 16, 2009
    With Internet Explorer 8 we introduced several new JScript language features including native JSON support

  • Anonymous
    May 05, 2009
    With the “final” release of IE8 for Windows Vista and other versions of Windows in several languages