IE Compatibility List Pruning

re: IE Compatibility List Pruning

rusty — Thu, 02 Jul 2009 07:26:39 GMT

I've always loved this line:

"less interoperable behavior from IE"

Why don't you come straight out and call a spade a spade when talking about IE before IE8.

"buggy as all get out behavior from IE"

re: IE Compatibility List Pruning

Eden — Thu, 02 Jul 2009 08:34:23 GMT

@rusty

Because IE7- behaviours are not buggy. MS was just sticking to their de facto standard for the sake of everyone.

re: IE Compatibility List Pruning

Damian — Thu, 02 Jul 2009 10:59:22 GMT

@Eden

Same here, when I write code I don't have any bugs, they're features!

@Eden

John — Thu, 02 Jul 2009 11:05:27 GMT

For the sake of everyone? The children in Uganda, Lynx users?

re: IE Compatibility List Pruning

Philip Taylor — Thu, 02 Jul 2009 14:38:46 GMT

I'm pretty sure the file is called "IEStandards.xml", not "iestandards.xml". (The difference is very significant for anyone using e.g. Apache on Linux.)

Later in this post you also mention "IESettings.xml", which probably should be "IEStandards.xml" too.

re: IE Compatibility List Pruning

James — Thu, 02 Jul 2009 15:40:38 GMT

"As a site admin, you are always in control of how your site is displayed"

-- one major exception there - If the site in question is at the mercy of an old CMS which generates an html comment and places it before your DOCTYPE, you'll incur the IE bug that flips the browser into quirks mode regardless of your DOCTYPE or, it seems, any manually set compatibility strings set with the X-UA-Compatible tag.

Are there any plans to allow us to finally kill that bug in IE8 by making the X-UA-Compatible tag override the bug?

James

re: IE Compatibility List Pruning

Moiza — Thu, 02 Jul 2009 16:17:38 GMT

Many work/information for less result.

re: IE Compatibility List Pruning

Quality Directory — Thu, 02 Jul 2009 18:23:38 GMT

It's great the IE8 Team has added this feature to use the X-UA-Compatible tag to remove one's domain entry from a user’s Compatibility View list.

"If IE were to remove the entry for ‘example.com’ from the user’s list based solely on the presence of the HTTP header / <META> tag value found at ‘support.example.com’, the user could encounter a compatibility failure when they visit non-updated content at ‘example.com’ or ‘mail.example.com’. Checking for the ‘IE8StandardsMode’ file at the root domain level solves this case by requiring that someone “authoritative” for the domain signal list cleanup. That way, IE users can be assured of a consistent compatibility experience on the domain."

Look at this scenario here: 'example.com' and 'support.example.com' are owned by different individuals and the owner of 'example.com' places an HTTP header / <META> tag after updating the site, while 'support.example.com' has not been updated. Won't users experience a compatibility issue when they visit the non-updated content at ‘support.example.com’? In this case does IE8 still view 'example.com' as “authoritative”? Or am I missing something here?

re: IE Compatibility List Pruning

Mick — Fri, 03 Jul 2009 00:15:03 GMT

@Eden - I'm presuming you are a troll. If IE was following standards to begin with we wouldn't be in this mess now.

I agree with @rusty that the line Microsoft uses tries desperately to put a "softer spin" on what qualifies as a major mistake.

I'm just glad IE is fixed now! All I have to do now is drop support for IE7 and I'll never have to worry about coding special hacks for IE again!

re: IE Compatibility List Pruning

Mike — Fri, 03 Jul 2009 12:17:37 GMT

@Mick

I wish your last point was true "I'll never have to worry about coding special hacks for IE again!"

Maybe the following is not really a hack, but it is certainly extra time.

Most of the other browsers are now or close to supporting css rounded-corners, text-shadow and box-shadow.

If I want to create a div to hold some content which is nicely styled with round corners a slight shadow. It can be done with a few lines of css code.

If I want to get IE8 to do the same way I need to start opening a graphics editor to create a bunch of background images for the same effect.

The question is do I forget the images and let IE users see ugly blocks or waste a few hours getting it to look good in IE.

I really can't quite fathom how a phone browser can be supporting rounded corners yet my dual core super powerful desktop machine running IE8 can't.

Why can't the IE team start making more regular incremental updates to the browser and start adding these feature. Or even announce they plan to add them.

re: IE Compatibility List Pruning

Lenard — Fri, 03 Jul 2009 13:44:20 GMT

@Mike - Can I get a what, what! I would love if rounded corners were available in IE and yes they should have announced their roadmap for inclusion when IE7 beta was on the table. pity.

@Quality Directory - You are not confused. There were major flaws in the design of Compatibility mode that were pointed out to Microsoft but fell on deaf ears.

1.) Localhost/127.0.0.1/192.168.100.x **SHOULD** all display the compatibility mode icon. I could care less which mode it puts me in by default, but I should be able to switch **RAPIDLY** during testing... which always happens on Localhost/127.0.0.1/192.168.100.x!!!

2.) Since many sites use the subdomain structure to organize **DIFFERENT** code functions (e.g. Blogs, Trouble Ticketing, Beta's, Mail, Admin (DB, Appserver, Web server,...) or in the case of many shared hosting sites, multiple customers. Thus there should have been since day 1, a setting for foo.example.com AND bar.example.com AND baz.example.com etc.

Two heavy blows to developers trying to adapt to Microsofts latest version of IE. I feel very sorry for anyone that needs to go through the above steps to move a site out of compatability mode.

Personally I had 3 legacy apps that **were** subdomains that failed to function under a main app that was built to standards. Since there was no realistic support option for this arrangement I had to port the apps to a different server. Maintaining SSO was a nightmare but oh well.

@Mick - Very thought provoking. I dropped IE6 support in April which cleaned up several 'k' in hacks and horrible IE behaviors to workaround bugs but I still have a bunch of IE7 hacks in place. I think if another 10% of my users move from IE7 to IE8 or another browser I'll go for it.

re: IE8 bug lingers

ahacks — Fri, 03 Jul 2009 19:21:01 GMT

IE8 apparently has some bugs which M.S. has not ironed out that work correctly previous in IE versions.

Bug issue: Transparent animated GIFs when repeated (repeat-x or repeat-y) in a background, the transparency fails and shows as a black cover.

Replicated sample: this bug is being replicated and displayed for the time being on <a href="http://www.ahacks.com/">www.ahacks.com</a>

re: IE Compatibility List Pruning

Quality Directory — Fri, 03 Jul 2009 22:55:23 GMT

@Lenard, the problem is even more complicated when someone sells his/her sub-domain, support.example.com, and the new owner of the sold sub-domain moves it to another server. In this case, why should IE8 still give the owner of the domain, example.com, the "authority" to define how the sub-domain, support.example.com, should be viewed?

In my opinion, IE8 needs to give "independence" to sub-domains.

re: IE Compatibility List Pruning

Michael Benny [MSFT] — Sat, 04 Jul 2009 04:27:13 GMT

@Quality Directory

As a site author you always have control over how your site is viewed by an visitor. If you set X-UA-Compatible to IE=EmulateIE7 on the subdomain with legacy apps, then that will override this setting.

The purpose of this feature is to allow domains to clear themselves from a list that is stored locally on each users machine.

re: IE Compatibility List Pruning

Quality Directory — Sat, 04 Jul 2009 16:54:51 GMT

@Michael Benny,

Thanks for replying and enlightening me. One more question, please.

After setting X-UA-Compatible to IE=EmulateIE7 on the sub-domain with legacy apps, the iestandards.xml should have a root XML element: <IE7StandardsMode/>. That's Am I right?

re: IE Compatibility List Pruning

Michael Benny {MSFT] — Sun, 05 Jul 2009 11:02:08 GMT

@Quality Directory

In IE8, the iestandards.xml will only interpret a root element with the value <IE8StandardsMode /> to remove a domain that is already on a visitor's Compatibility View list.

But, even if the domain root has that available, setting the X-UA-Compatible to IE=EmulateIE7 will store force those documents to behave like IE7 (where we use doctype switching to determine using quirks mode or strict mode 'IE7')

When applying this to the documents in an entire subdomain, I would recommend using a serverside HTTP header to ensure that legacy documents do not need to be updated, and that it is applied to all the documents there.

re: IE Compatibility List Pruning

arvids — Mon, 06 Jul 2009 14:55:50 GMT

How is it possible to Uninstall Internet explorer at Win. Vista?

re: IE Compatibility List Pruning

EricLaw — Mon, 06 Jul 2009 17:21:25 GMT

@arvids: You can uninstall IE8 to go back to IE7 by following the instructions here: www.enhanceie.com/ie/ie8.asp#uninstall

re: IE Compatibility List Pruning

EricLaw — Mon, 06 Jul 2009 17:50:20 GMT

@James, as far as I can tell, the X-UA-Compatible:IE=IE8 header *does* override the behavior where a document with a leading comment is kicked over to quirks mode.

re: IE Compatibility List Pruning

James — Mon, 06 Jul 2009 18:27:39 GMT

@eric, great news - thanks for clarifying... I think I got confused since document.documentMode returns "CSS1Compat", which to my mind sounds a bit bizarre when we're aiming for full CSS2.1 compatibility... Automatically assumed this meant we were still in quirks mode.

re: IE Compatibility List Pruning

EricLaw — Mon, 06 Jul 2009 18:55:41 GMT

@James: You're thinking of document.compatMode, which is a legacy property which has only two values: "BackCompat" and "CSS1Compat".

http://msdn.microsoft.com/en-us/library/ms533687%28VS.85%29.aspx

document.documentMode will return 5 (Quirks), 7 (IE7 Strict), or 8 (IE8 Standards).

-Eric

re: IE Compatibility List Pruning

Neil Alexander — Mon, 06 Jul 2009 19:15:29 GMT

When are you IE developers going to realise that your browser is fundamentally broken?

Safari doesn't need a compatibility mode. Firefox doesn't need a compatibility mode. Opera doesn't need a compatibility mode. Chrome doesn't need a compatibility mode. Why? Because they all make a serious effort to support the web standards that have been put in place for a very good reason.

We developers do not want to mess about with "compatibility mode". We want to write websites that work in all web browsers, so that we don't have to fill our web code with extra stuff just because Internet Explorer won't play nice.

Once your browser passes the Acid3 test, then we'll talk.

re: IE Compatibility List Pruning

Mike Beeler — Mon, 06 Jul 2009 20:14:57 GMT

Compatability testing with iframes. Content hosted as a content area in a master page sizes correctly with IE 6, but any attempt to change the rendered size of an IFRAME fails in compatablity mode fails. the iframe hieght is about five lines of 10pt type regardless of settings.

Are there any solutions to this?

re: IE Compatibility List Pruning

Ian — Mon, 06 Jul 2009 20:20:12 GMT

Neil, when are YOU going to realize that the web is "fundamentally broken"-- not the browser?

Safari/Firefox/Opera/Chrome all have assorted problems rendering sites that were written (hacked together?) for IE6 and older (pre-standards/early-standards) browsers.

For compatibility with those sites, users use IE, which is why it remains more popular than all competing browsers combined. It's not a coincidence.

You should be praising the IE team for developing a new version of their browser with a default "Standards mode" that is compatible with those standards-compliant but somewhat-real-world-incompatible browsers. If IE8 didn't offer a "Compatibility mode" then the majority of the world that uses IE6+IE7 wouldn't upgrade, and users would stay on browsers that don't support standards as well and browsers that aren't as interoperable with those other browsers.

btw: your suggestion that other browsers don't have "modes" is wrong-- look up "quirks mode" and "almost-standards" mode on wikipedia or the Mozilla Developer Center.

re: IE Compatibility List Pruning

Anthon — Mon, 06 Jul 2009 23:25:36 GMT

I just want IE to fully support window.navigator.plugins and window.navigator.mimeTypes. If third party plugins and ActiveX objects are the weak link, let's make simple browser plugin detection more unobtrusive, instead of loading a potentially untrusted plugin and raising the fear level with in-your-face security warning popups.

re: IE Compatibility List Pruning

Gérard Talbot — Mon, 06 Jul 2009 23:48:16 GMT

@Ian

> the web is "fundamentally broken"-- not the browser

IE 8 does not support DOM 2 Events interface, does not support DOM 1 Core like other (Firefox 3, Opera 9, Safari 4, Konqueror 4) browsers, does not comply with DOM 2 CSS interface, does not support DOM 3 Core interface like other (Firefox 3, Opera 9, Safari 4, Konqueror 4) browsers, has HTML 4 bugs, DOM 1 bugs, DOM 2 bugs, ECMAscript specification violations, has non-compliant results or unsupported elements, unsupported attributes, unsupported properties, unsupported methods, unsupported accessibility requirements/recommendations (UAAG 1).

The web is still very much broken and this, in large part because of MS products like MS-FrontPage, MS-Word HTML export feature over the last 10 years.

> For compatibility with those sites, users use IE, which is why it remains more popular than all competing browsers combined.

If the main problem on the web is severely malformed markup code, then the solution, the real solution is to remedy+improve, to correct, to upgrade those websites, to offer customized assistive softwares (eg HTML Tidy, A real validator, iWeb, BlueFish) to help web authors to upgrade their websites and not by providing them more "IE-bugward" rendering modes, more "IE-bugward" settings, buttons, checkboxes, managed compat-lists, etc.

IE 8 is a 3-IE-browser-versions-in-1 IE . Per se, using it will not change anything on the web, with the web.

> If IE8 didn't offer a "Compatibility mode" then the majority of the world that uses IE6+IE7 wouldn't upgrade,

Again, read your very own initial statement. The problem is with the web, not the browser. So, upgrading to IE 8 does not change anything in the web, about the web, regarding the web.

> other browsers don't have "modes" is wrong

Other browsers have backward-compatible "quirks" rendering mode (document.compatMode == BackCompat) and web-standards-compliant rendering mode (document.compatMode == CSS1Compat). That's true.

But they try to maintain the number of quirks to a minimum, they offer documentation to solve compatibility issues, they do not create and implement more buttons, switches, modes, customizations, preferences, document.documentMode, compat-list and settings to manage all this which can only increase the level of complexity and at the same time, confort and encourage web authors into NOT upgrading their severely malformed+invalid markup code and CSS code with parsing errors.

regards, Gérard

re: IE Compatibility List Pruning

Gérard Talbot — Mon, 06 Jul 2009 23:55:14 GMT

@James, @EricLaw [MSFT]

> as far as I can tell, the X-UA-Compatible:IE=IE8 header *does* override the behavior where a document with a leading comment is kicked over to quirks mode.

We (Ingo Turski in march 2008 in IE Blog, Dean Edwards in september 2005 in IE Blog, and others) reported such *bug* before. Do not call such thing as a behavior when it is clearly a CSS implementation bug. A perfectly valid (markup code, CSS code, doctype declaration pointing to/referencing to a strict DTD) should honor the CSS 1 box model accordingly, as specified by the specs.

gtalbot.org/BrowserBugsSection/MSIE7Bugs/#bug140

gtalbot.org/BrowserBugsSection/MSIE7Bugs/#bug170

gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug99

gtalbot.org/BrowserBugsSection/MSIE8Bugs/#bug196

This bug happens maybe more frequently than Microsoft expected.

E.g.: the whole website of nwa.com is affected by such IE bugs.

E.g.: there are some advanced text editors which will output some comments at the beginning of an .html file

Again, this is a bug in IE (all versions since IE 6) and not anywhere else.

Gérard

re: IE Compatibility List Pruning

Gérard Talbot — Tue, 07 Jul 2009 00:27:28 GMT

@Ian

> the web is "fundamentally broken"-- not the browser

Microsoft introduced and implemented the hasLayout feature into IE. A very very wide majority of web developers, web authors denounced such feature as incompatible with CSS 1 and CSS 2.1 specs, as unbelievably difficult to understand and use.

No other browsers implemented such nebulous, unbelievably-difficult hasLayout feature.

So, while I entirely agree with saying that the problem is now on the web, with the web, regarding the web, a rational examination of the issues involved must also point out IE bugs, IE implementations, IE-rendering-engines related web authoring tools.

"If I had known about [hasLayout feature] this from the start most of my worries would've been solved. I even regard [hasLayout feature] it as a worse problem than IE6's stupid box model."

StackOverflow: What do you wish you knew before you spent hours trying to fix a bug in IE6, by Joshua, October 28th 2008

In the last 10 years, there has been even tools which have been developed to remove bad code output by MS products like MS-Word and FrontPage:

tidy.sourceforge.net/docs/quickref.html#bare

tidy.sourceforge.net/docs/quickref.html#word-2000

There's also Microsoft Demoromizer:

fourmilab.ch/webtools/demoroniser/

My conclusion:

Once you've debugged, corrected, upgraded the HTML rendering engine and the CSS parsing+rendering engines in IE, then you need to do the same with web|HTML authoring tools, assist web authors into upgrading the markup code and CS code of their malformed+poorly-written webpages. Better tools.

Also better documentation. The whole set of MSDN documentation webpages on web standards, web development, HTML, CSS, DOM, etc. is atrociously invalid, malformed, full of errors, even and especially in the code examples supposedly there to teach the readers/visitors of such webpages. Blatant wide-scale contradiction here. And many have denounced this during years.

If the problem is with the web, then Microsoft should start with their own IE Blog webpages and with its whole microsoft.com website. There is no reason - never was - to have hundreds of markup errors per page, thousands and thousands of validation markup errors all over in all websites controlled, owned, funded by Microsoft.

regards, Gérard

re: IE Compatibility List Pruning

Gérard Talbot — Tue, 07 Jul 2009 01:09:54 GMT

@Anthon

> I just want IE to fully support window.navigator.plugins and window.navigator.mimeTypes.

Anthon, please specify what you're requesting here...

(...) one of the most short sighted decisions, they [Microsoft IE team project managers] decided not only would they [Microsoft IE team project managers] not support either technique, but they [Microsoft IE team project managers] would support the collections. They [Microsoft IE team project managers] would just leave them empty. Their documentation gives a completely inaccurate description of the collections, making it impossible to understand what approach to take.

howtocreate.co.uk/wrongWithIE/?chapter=navigator.plugins

We reported this in the past. Again, while it's true that the major part of the problems is on|about|in|regarding the web, it is absolutely fair and correc to state that there are still many bugs, issues, problems with the IE 8 browser.

regards, Gérard

re: IE Compatibility List Pruning

Dave — Tue, 07 Jul 2009 01:14:37 GMT

Gerard, I hope you'll agree with me that when one comes across as a whiny child, telling others what they may and may not say, they are far less effective in bringing about the changes they seek. Food for thought?

IE8 bug lingers (gif background transparency)

Gérard Talbot — Tue, 07 Jul 2009 01:26:31 GMT

@ahacks

I checked your dynamic curtain demo with IE 8 when forced into web standards compliant rendering mode and, after a superficial examination, I'd say that there is a great probability that there is a bug in IE 8 in web standards compliant rendering mode. More time, closer examination would be required to be sure of that.

It could require quite a bit of time to figure out what exactly is the bug (curtains.gif is an animated gif), then create a reduced testcase out of it since the page uses a table unneedlessly (curtains.gif is defined as a background image within a table cell), has no doctype declaration, uses deprecated elements and attributes.

regards, Gérard

this is a little sad

Christian — Tue, 07 Jul 2009 11:41:58 GMT

The compatibility view button seems to have exactly the effect that I was afraid of. In the last day or so we had 1020 visits with IE8 in normal mode and 145 in compat mode. And this even though the site works a little better with standards mode than with IE7 or IE8-as-IE7 mode.

This is exactly the thing that I was afraid of from the start with the compatibility view feature - that in the end, one would have to opt in into sane behavior, even though IE8 is in standards compliant mode by default.

And problems like this of course lead to hacks like the one that is announced here. I really think that it would have been better to force sites to opt in into IE7 behavior, if needed. Since this was not done, those sites who can benefit from IE8, cannot trust it unless the actively opt in. In effect this reverses the model and will create problems that will still linger when IE7 has already been flushed out.

By the way: Could anyone share their ratio of IE8-in-standards-mode against IE8-in-compat-mode visitors? I would be most interested, how this looks elsewhere on the web.

Best Regards

Christian

re: IE Compatibility List Pruning

Christian — Tue, 07 Jul 2009 12:07:29 GMT

P.S. does this feature also work with IE=edge? What would the XML file contain in such case?

Also, how will this feature interact with IE9? Will it be possible to request proper IE8 behavior for IE8 and proper IE9 behavor for IE9?

There are people that just want the sanest browser behavior available instead of enumerating the versions you have released. Please try to keep this in mind.

Regards

Christian

re: IE Compatibility List Pruning

Brookeleshea — Tue, 07 Jul 2009 14:51:29 GMT

I just made a promotional video for IE 8... please check it out!

http://www.brickfish.com/Pages/VideosSeries/VideoView.aspx?vid=8980_83053190&pid=332257&scid=465

re: IE Compatibility List Pruning

Rembrandt A. Martinez — Tue, 07 Jul 2009 21:31:42 GMT

I am in compatibility View on a personal webpage and cannot locate a problem, error, or any mistake. Actually my opinion is solved and can move on to even more things.

document.domain='x.cn'; error: "invalid argument"

Chunguang Han — Wed, 08 Jul 2009 06:41:27 GMT

document.domain='x.cn';

error: "invalid argument"

document.domain='x.com'; OK

WHY?

HTANK U!

msn: cgisir@hotmail.com

Browser support

james burns — Wed, 08 Jul 2009 13:03:12 GMT

My most of the themes of wordpress not compatible in Internet explore , what i can do to fix this problem.

re: IE Compatibility List Pruning

koxp — Wed, 08 Jul 2009 14:26:56 GMT

"How is it possible to Uninstall Internet explorer at Win. Vista?"

??????

msn:cagri_tekir@hotmail.com

re: IE Compatibility List Pruning

EricLaw [MSFT] — Wed, 08 Jul 2009 18:43:53 GMT

@koxp: You can uninstall IE8 to go back to IE7 by following the instructions here: www.enhanceie.com/ie/ie8.asp#uninstall

IE8 bug lingers (gif background transparency)

ahacks — Wed, 08 Jul 2009 22:56:02 GMT

I swapped the old webpage with the newer one as you suggested w/o and the needless table and proper DTD standards:

http://www.ahacks.com

I validated and placed the W3C kosher stamp of approval :-D , this should do away with all the naysayers.

now if only the geniuses at MS would fix this bug!

re: IE Compatibility List Pruning

Mitch 74 — Thu, 09 Jul 2009 13:04:59 GMT

I second Christian's question: does it work with IE=edge?

re: IE Compatibility List Pruning

Alex — Thu, 09 Jul 2009 17:51:06 GMT

@Ian the web is "fundamentally broken"-- not the browser: It is a matter of perspective. As a web developper, I think both a brocken: IE (including IE8) is broken beacuse they still do not support a miminum of web standards. This forces web developpers to code pages that use non-standard IE-specific functions.

For example, according the W3C, Javascript event can be attached by addEventListener. This function is not available in IE and a non-standard function attachEvent must be used. When IE had more than 80% of marketshare, some developpers didn't even bother and used only attachEvent. This problem has been here for years, and IE8 still does not support addEventListener!

There is also a long list of standards (see Gérard's post), that IE8 does not support. This forces the use of non-standard IE-only solutions. Already Firefox 1.5 supported SVG, but still now one has to use VML for IE8. Currently the OpenLayers javascript library does not work in IE8 because of a VML problem. Indeed, one could say that OpenLayers is broken, but there wouldn't be this problem is IE would support SVG.

re: IE Compatibility List Pruning

mial — Thu, 09 Jul 2009 19:36:23 GMT

Please disable all activex controls from the IE's Internet Zone, don't let IE to be attacked by a next 0-day flaw.

re: IE Compatibility List Pruning

EricLaw [MSFT] — Thu, 09 Jul 2009 19:46:38 GMT

@mial: You can easily do this using the Tools / Internet Options / Security tab. You will likely find, however, that many major sites (e.g. any site that uses Flash) rely on ActiveX controls.

re: IE Compatibility List Pruning

Ian — Thu, 09 Jul 2009 19:49:16 GMT

Alex, you're missing the point... the point is that if IE stopped supporting attachEvent(), then many websites would break. The IE team has to add standards support without breaking older sites, or the new versions of IE won't be adopted, meaning that standards are much slower to be adopted.

re: IE Compatibility List Pruning

Michael Benny [MSFT] — Thu, 09 Jul 2009 21:53:39 GMT

@Mitch 74 and Christian

Yes, this behavior will get triggered when using X-UA-Compatible IE=Edge or IE=IE8 as well

re: IE Compatibility List Pruning

rick — Fri, 10 Jul 2009 12:20:10 GMT

Michael Benny, it would help web designers out alot if you fixed the bug with IE8 listed here:

http://en.wikipedia.org/wiki/Internet_Explorer_8#Bugs

re: IE Compatibility List Pruning

Christian — Fri, 10 Jul 2009 12:33:00 GMT

Dear Michael

thank you very much for the clarification.

However, my main confusion is, that IEStandards.xml contains a version number in its "IE8StandardsMode"-tag.

Which effect will this have when IE9 comes out? Will it - together with IE=edge - opt out of any future compatibility modes? Is there a way to explicitly specifiy edge-mode in the Xml-File too, so that it matches the declaration in the page, for example by writing something like:

I am trying to understand how this XML file (especially with IE=edge) would affect things, when IE9 or 10 or 11 comes out. Of course that is hard to tell, what these browsers will do but it would be important to know how you think this xml file will be extensible, if something like this should be needed again by future versions of IE. Or would there have to be new XML files for future IE versions, as soon as they require a similar switching mechanism?

Having a version number in the root element of the XML file does not seem to make it very extensible and feels a little ad-hoc to me.

Thanks & Regards

Christian

re: IE Compatibility List Pruning

Gerrald — Sat, 11 Jul 2009 04:45:36 GMT

Reading the results of a survey on Digg as to why/when they will drop IE6 support they asked IE6 users why they are using IE6.

The answers were shockingly scary:

http://farm4.static.flickr.com/3483/3707763174_5bf03a2cdb_o.jpg

7% couldn't upgrade due to windows version (e.g. win2k)

37% couldn't upgrade due to not having administrator priv.

32% couldn't cause someone at work said they couldn't

17% didn't feel the need to upgrade

7% actually preferred IE6

For the I.T. Admins blocking upgrading to IE7/IE8 Why on earth are you making your end users suffer with IE6?!

For the end users without admin priv. to upgrade themselves - I pity you. I could not work at a company like that. I would need to quit within a week.

For the end users that have been told no - ask again - raise a stink - there is no reason why you should be suffering with IE6, and your companies neglect in upgrading **IS** holding back the web.

And finally for those that don't feel the need, or prefer IE6... you need to think outside the box and explore new browsers. Not only is IE6 a horrible browser in 2009 but you are missing out on so many improvements in speed, tabs, security and ease of use that you owe it to yourself to upgrade... even if to IE7 or IE8! (yes I'm a Firefox fan, but any browser better than IE6 would be a massive improvement)

see here for the full blog post about Digg dropping IE6 support (someday soon... TBD)

http://digg.com/d1wK0V

Good read.

re: IE Compatibility List Pruning

Phil — Sat, 11 Jul 2009 04:53:30 GMT

@Christian - you are correct about the opt-in to IE7 rendering comment.

This was (as many have mentioned) an Epic Fail in terms of moving towards supporting open standards by default.

I cringe every time I think about how this was brought up in discussions over and over yet the wrong choice was still made.

Grrrr! I've got to go offline now... need to throw something very heavy and curse up a blue storm.

re: IE Compatibility List Pruning

Alex — Sun, 12 Jul 2009 00:21:03 GMT

@Ian: I know that IE would not suddenly drop attachEvent. But IE should support addEventListener in *addition* to attachEvent and depreciate the use of attachEvent. Having both functions (during a transition period) would not break a single web page. There should not be a problem supporting multiple APIs for tying events to HTML elements since all browser support at least 2 ways for defining events (addEventListener (or attachEvent) and the old-style onclick attributes).

The addEventListener is a W3C recommendation since 2000! I just cannot understand why it takes so long for Microsoft to implement this basic function crucial for DHTML.

re: IE Compatibility List Pruning

Ian — Sun, 12 Jul 2009 01:36:06 GMT

Alex, you assume that there are no pages which simply check for addEventListener and then do stupid things (like assume you're in Firefox or that some other L2 DOM functions are available). That's an incorrect assumption.

Supporting both also assumes that there aren't lots of pages which do "if (addEventListener) {foo}; if (attachEvent) {bar}" and that too is a bad assumption.

While it's fine to say: "That's dumb, break them" this isn't the way that the IE guys work.

Award : Crashes a lot !

Andrew — Mon, 13 Jul 2009 10:22:00 GMT

Hi,

using ie8

it crash a lot

sometimes it does not render well

sometimes get too busy message

sometimes it hang

congrat ! u got an award to give me the most crashing browser !

re: IE Compatibility List Pruning

Stephen — Mon, 13 Jul 2009 12:58:22 GMT

Good to see your guys are colaborating with the Office-97-Team to construct some beautiful diagrams there! ;)

re: IE Compatibility List Pruning

EricLaw [MSFT] — Mon, 13 Jul 2009 17:06:45 GMT

@Andrew: A significant majority of crashes and hangs are caused by buggy browser addons. See www.enhanceie.com/ie/troubleshoot.asp#crash

As for complaints about rendering, it would be helpful to provide URLs of sites where you're having problems.

re: IE Compatibility List Pruning

martin — Mon, 13 Jul 2009 17:35:36 GMT

What the $#@! is going on with IE8 recently? I can't edit any of my bookmarks, and I can't set any new bookmarks!

I'm pretty sure 2 weeks ago this all worked fine.

Now all my favorites don't point to a URL, but link to a file on my PC... thus creating a bookmarklet is now impossible and all the ones I have fail to work.

For the record the error I get trying to add a new bookmark is:

=====DIALOG==========================

Windows Internet Explorer [Red X]

-------------------------------------

[Red X Icon] Unable to create '{TITLE_OF_HYPERLINK}':

Class not registered

[OK]

=====DIALOG==========================

PS This occurs if I am in regular mode or starting IE8 in no-addons mode.

So much for doing any debug/development in IE this week.

re: IE Compatibility List Pruning

Alex — Mon, 13 Jul 2009 18:34:18 GMT

Ian, I agree with you that in the cases you mentioned, the web page would break. Any web page made with the assumption that IE will never implement addEventListener, will break (obviously) once this function is implemented in IE. I would already be happy if Microsoft would have implemented this function in IE8 standard-compliant mode. Web pages assuming non-standard IE7 behavior have to be upgraded anyway to use IE8 in standard mode.

re: IE Compatibility List Pruning

steve — Mon, 13 Jul 2009 19:32:29 GMT

@Alex - any site that has a test to check for addEventListener vs. attachEvent *should* be checking for the addEventListener method first. If a developer has "ASSUMED" that IE would never implement the addEventListener method they the DEVELOPER building the site need to fix THEIR code.

We can't continue to support those that don't develop half-decent code.

What *IS* important here, is that MICROSOFT publishes an INTENDED ROADMAP (hmm, that's only been said a thousand times already) that indicates that they PLAN to FIX this issue by IMPLEMENTING the addEventListener method in a future release (preferably indicate IE9 support, but even COMMITMENT would suffice)

ONCE MICROSOFT has ESTABLISHED that a FEATURE is "ON THE ROADMAP" - THEN, and *ONLY* THEN can developers have some UNDERSTOOD EXPECTATIONS of what is coming, and start addressing these concerns.

When the blog post comes out on the IE Blog that these changes are coming - developers will have the chance to start updating and investigating their code for issues etc.

NOT HAVING A CLUE what is coming up in the IE.NEXT release is what is so frustrating...

That said, someone should make a quick site that checks a site for you... finding code that should be looked at.

e.g. Test example.com

Results:

1.) Use of document.all (other than to provide workarounds for legacy IE) should be removed.

2.) Use of attachEvent (should check for W3C Standards addEventListener first)

3.) Use of createElement('HTML STRING'); should be avoided in IE8+ browsers. Use the appropriate W3C DOM methods instead.

With a service like this, developers would have somewhere to go to see if they have issues as well as provide a URL for other developers to pass on to those less experienced with Web Development to set them on the right path to future success, or help them with existing issues.

re: IE Compatibility List Pruning

ShaneP — Mon, 13 Jul 2009 20:28:21 GMT

STEVE, i LIKE capital LETTERS too!!! WILL you BE my FRIEND?

re: IE Compatibility List Pruning

EricLaw [MSFT] — Mon, 13 Jul 2009 20:46:22 GMT

@Martin: It sounds like one or more of your registry entries was corrupted. You might try re-registering the InternetShortcut class (www.enhanceie.com/dl/RegisterInternetShortcutClass.reg) to see if that helps, but you may need to repair/reinstall.

IE functionality - backspace

Greg — Tue, 14 Jul 2009 01:16:52 GMT

Please allow the backspace key (navigate to previous page) to be disabled. This is problematic when one is editing text boxes on a web page and focus on the edit box is lost due to (javascript) or page refresh. This makes normal editing keys navigate between pages. Please let the backspace key be disabled as there is ALT-LEFT ARROW to do the same thing.

This is equivalent to how you can click accidentally on an OK button when editing a word document when that other application opens a modal message box. It's happened to me many times (a nuisance at least and a security hole at most) as I spend lots of time in Word, Excel, email, etc.

June 12, 2009 -- IE8 Smart Address bar: What’s new

# Backspace / delete - Tuesday, June 16, 2009 10:59 AM by Greg

Please make the delete key delete the character in the URL edit field and NOT go to the previous page. The edit box for the URL should behave like an edit box. The delete, backspace, tab, shift-tab keys should work like a normal edit box.

# re: IE8 Smart Address bar: What’s new Tuesday, June 16, 2009 11:33 AM by EricLaw [MSFT]

@Greg: I'm not sure what you're seeing, but delete/backspace keys already work that way and always have.

If you see that backspace in the address bar does anything other than delete the prior character, chances are good that you've installed a plugin which is using a keyboard hook incorrectly. @Xepol: Agreed.

re: IE Compatibility List Pruning

Martin — Tue, 14 Jul 2009 18:00:30 GMT

@EricLaw MSFT - I tried that registry setting but had no luck. So I went to try and repair IE8, but no option for repair exists either in the IE8 menu, or the Add/Remove programs window.

Therefore I've given up and am about to Uninstall/ReInstall IE8.

I can't exactly say I'm enthused about this process since I'm a web developer that needs to test in IE regularly.

Oh well... what's half a day of downtime... mmm can't wait for the endless reboots :-(

re: IE Compatibility List Pruning

EricLaw [MSFT] — Tue, 14 Jul 2009 18:37:15 GMT

@Martin: I'd start with Tools / Internet Options / Advanced / Reset IE to default settings.

As to the "half a day of downtime," I'm not sure how long your days are, I've uninstalled/reinstalled IE multiple times per day for nearly a year and it takes me less than 30 minutes each time.

re: IE Compatibility List Pruning

Martin — Tue, 14 Jul 2009 19:08:52 GMT

@EricLaw MSFT - yeah the re-install did take less than I expected ;-)... but I still had 2 reboots (1 after the uninstall and 1 after the reinstall).

That said - NO LUCK!

My Bookmarks are still completely un-editable.

Am I the only one experiencing this? Is there an addon within windows or IE that even though addons are disabled is still affecting my browser?

I'm still in a "I can laugh at my woes" mode regarding this but if I can't solve this soon I'm going to need to test all content on another PC which won't impress me at all.

Are their any specific Registry Key values I should verify are set?

If I Google "Unable to create" "Class not registered" I get about 3,000 matches but most don't seem to match my issue.

I did get this result though...

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.beta&tid=30d9c5e1-7afe-432a-a1ad-8ba9d7f19fad&cat=en_us_2BAF8EC5-645C-4477-A380-0F1CF6C102F9&lang=en&cr=us&sloc=&m=1&p=1

which claims to have a solution pointing to here:

http://iefaq.info/index.php?action=artikel&cat=35&id=133&artlang=en

I'll try this and see if it fixes IE8.

re: IE Compatibility List Pruning

Martin — Tue, 14 Jul 2009 19:16:13 GMT

Okay! yeehaw! that worked!

well kind of. It works in that now all **NEW** bookmarks I add are editable but my current ~85 or so bookmarks all fail.

that process was a real pita. I certainly hope that (if) this happens again, using that MVP reg tool will fix IE8 without the re-install.

re: IE Compatibility List Pruning

Kevin Newman — Tue, 14 Jul 2009 21:01:28 GMT

Just a question: Why is there no IE6 mode in IE8, similar to how there is an IE7 mode? Seems like a way to get those corporate IT departments to upgrade without forcing them to redo their intranets.

New Active X Security Hole discovered (3rd in 60 days)

morton — Tue, 14 Jul 2009 22:09:10 GMT

Looks like yet another Active X security hole was discovered in IE.

http://news.cnet.com/8301-1009_3-10285486-83.html

It affects Office XP, Office 2003, Internet Security and Acceleration Server 2004 and 2006, as well as Office Small Business Accounting 2006.

----

Microsoft Quote:

Microsoft is investigating a privately reported vulnerability in Microsoft Office Web Components. An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. When using Internet Explorer, code execution is remote and may not require any user intervention.

We are aware of attacks attempting to exploit the vulnerability.

Customers may prevent the Microsoft Office Web Components from running in Internet Explorer either manually, using the instructions in the Workaround section, or automatically, using the solution found in Microsoft Knowledge Base Article 973472.

re: IE Compatibility List Pruning

Steve — Tue, 14 Jul 2009 23:01:32 GMT

Morton: You're confused. The browser and its plugins are different things. When a Firefox extension has a bug, it's not a bug in Firefox, it's a bug in the extension. When an ActiveX control has a bug, it's not a bug "in IE" (unless the ActiveX control is a part of IE).

re: IE Compatibility List Pruning

David — Wed, 15 Jul 2009 06:01:13 GMT

I think the IE team has done a very good job to make sure older websites work with IE8. Now that they have accomplished that, they need to think about future web standards.

What are your plans for IE9?

re: IE Compatibility List Pruning

anonymous — Wed, 15 Jul 2009 07:10:30 GMT

IE team, can your browser do this? http://www.neowin.net/news/software/09/07/14/webkit-nightly-builds-enable-3d-css-transforms-for-os-x So behind the times still.

re: IE Compatibility List Pruning

Steve — Wed, 15 Jul 2009 07:38:56 GMT

anonymous: Can yours? Did you actually install the nightly? Did it work on any real sites? When do normal people get to use it? Do I really want 3d CSS advertisements flying over my web pages? Really?

re: IE Compatibility List Pruning

lenen lening — Wed, 15 Jul 2009 13:05:56 GMT

@David I agree! Already very curious about IE9 :)

re: IE Compatibility List Pruning

Joni — Wed, 15 Jul 2009 18:00:57 GMT

Since I downloaded the newer version of Internet Explorer, my coputer has a window tht constantly says Internet Explorer is shutting down. Can somebody help please We brought the tower in to be repaired and no one was able to help Can You?

forcb1@aol.com

re: IE Compatibility List Pruning

EricLaw [MSFT] — Wed, 15 Jul 2009 19:34:05 GMT

@Joni: The majority of IE crashes are caused by buggy addons. See www.enhanceie.com/ie/troubleshoot.asp#crash for troubleshooting information.

re: IE Compatibility List Pruning

Alex Cranswick — Wed, 15 Jul 2009 20:14:49 GMT

Here's one for the compatibility issues. I'm filing my tax return with HMRC (HTTPS throughout) and it all worked fine last year. I have 3 machines, A, desktop with Vista Business, IE8; B, laptop with XP home, IE8; C Desktop with XP Home, IE7. Other than IE, all machines uptodate with patches.

End of tax return process is to produce an optional PDF of completed return. This year none of the machines will produce a PDF file. process apparently works, but no PDF appears. Compatibility mode does not produce any change. Out of interest I tried loading Firefox on A and the PDF file pops out no problem. However on IE8 the request for PDF generates a separate window; in Firefox its within the same window. Now however on A, uninstalling Firefox and going back to IE8 I 'can not log on'. Quotes because the logon procedure appears to work, in as much as if I put in an incorrect logon, I get an error, but the correct one just leaves me in the logon page. I wondered whether it was a timing issue, but having tried it after a delay, no change and I can log on properly on machines B & C. I'm going to try re-installing Firefox and see if that returns at least the logon functionality and then re-installing IE8, but given that it is burried in the update history, that is obviously not as simple as it could be.