1. IE 8 which has backward compatibility with IE 7
2. A new browser that is fully standard compliant and is like Opera, Firefox and other browsers.

This will address the issues of both IE only (intranet) sites/applications and standards compliant sites/applications.

yes, a layout breaks; it can be detrimental, in most cases, not so horrible. It may not look quite right, or something may be out of alignment, or something like that.

Aaron G.

By itself, the IE bugs do not indicate how and by how much a layout will break in a given webpage. If there is a IE bug with border and my bordered box is 1px wide, I may not even notice the layout breakage or the bug. But the problem is that sometimes/often, people do all kinds of weird things with borders (like a faux-column) and then their CSS columnar webpage template breaks because of such bug.

Another issue. Many sites are over-constraining, over-coding, over-declaring, over-defining (with their CSS code and markup code), overly rigid and very much pixel-precision focused, oriented. So, then, a small layout breakage caused by a bug or bug fix brings shouts, cries, howls, unfair finger-pointing to IE 8 for breaking up a page.

Sometimes, the breakage may be just a few pixels but it nevertheless ruins the whole design. I can show you such cases where most web designers would go mad. Just a few pixels off can break a drop-down menu list, a CSS columnar webpage template, etc.

What is still unacceptable is the number of very damaging bugs that cause important, severe, grave problems in IE 7:

- Application hangs exists in IE 7
- Crash bugs exists in IE 7
- Peekaboo types of bugs still exists in IE 7
- Guillotine types of bugs still exists in IE 7
- Various content disappear bugs

and I know I’m not exaggerating or over-reacting here. What would be illogical/crazy would be to not fix those severe, incapacitating bugs in IE7 standards mode. It would be irresponsible to do that in the name of backward-compatibility or because of a absolute, blind commitment/prime directive to “not break the web”. I can document and substantiate my claims here.

The discussion is still disappointing in some aspects. Mid-term and long-term planning from Microsoft. How is Microsoft going to avoid having another new browser version release crisis later… with IE 8.5 or IE 9? regarding the same problem we have today? We have no idea. The discussion may be happening again for IE 9 (or IE 8.5) because ordinary/amateur web authors can not upgrade their web design skills, don’t read or write abandonware websites…

Web standards advocacy groups and web standards gurus – in articles, in tutorials, in web authoring forum discussion newsgroups – have always claim and recommended to learn, to read, to follow best coding practices. None of this – no plan of tech evangelization whatsoever – actually seems to be in any part of Microsoft’s agenda. You see at MSDN articles promoting user-agent exact string detection, not object/method support detection: a blatant-obvious error in my opinion. You see at MSDN invalid markup code, invalid CSS code, deprecated practices, wrong, incorrect practices almost everywhere, in articles and in code examples and code excerpts. And I’m not even mentioning IE dev. people’s own blogs or IE blog.

It’s one thing to say that ordinary/amateur web authors do not or can not upgrade their web design skills, don’t read or write abandonware websites. It’s also completely true to say that MSDN articles are abandon-blah-blah, are spectacular examples of invalid markup code, blatant demonstration of web standards incoherence, blatant examples of web standards inconsequence.

Once you fix the browser and once users upgrade the browser (or browser version) they use, then, the remaining thing to do is to upgrade the webpage code. Web authors are the weakest link in the web standards circle principle: they were 3 years ago, they are today and they will be 3 3 years from now.

Gérard

I’m already using application/xhtml+xml in my header on all my pages. This is only required for off-line testing anyway. The server itself determines how the page is served. I currently have the XML prolog proceeding the DOCTYPE so when IE supports true XML then my pages coded with XHTML will just need a change to the file extension. Instead of htm or html I will use xml or xhtml instead. I don’t have to change the source code, just the file extension.

So yes, I am in full agreement with you, pages with

content=”application/xhtml+xml; charset=utf-8″

should by default render in IE8 standard mode.

I’m all for XHTML mime-type triggering standards mode, I’m sure 99.9% of websites that would break under “full standards compliance” in IE8 will either have no DOCTYPE or they will have a HTML 4.0 loose DTD. This surly leaves the only broken sites to be those that were defined as XHTML/Strict because the author had no idea what they were doing, hence not our fault and not Microsoft’s fault.

Besides that, do MS truly believe that everyone using IE^ will instantly move to IE8 as soon as its released? Ther will be plenty of time for people to fix these issues if the Strict DOCTYPE switch doesn’t already do the job for them.

I think we should also ask if the XHTML mime-type could trigger IE8’s standards mode

Isn’t that a given? Why are we even having to question that?

Not a given. We’ve asked Microsoft to confirm whether it will finally support application/xhtml+xml. And we asked if IE8 will then use standards mode when finding this mime-type.

No answer.

You would this would the simplest answer is the world to make, wouldn’t you?

What we also have to realise that older webpages always change, so it may not break the web, how many website will be broken. Statistics!!!
Microsoft have a powerful marketing scheme could not they advertise about changing to standards mode. So that the release of ie8 people would be prepared so that they can change their sites.