The New Standards Compliance Mode | The Coffeehouse

Rowan
Look, no errors.

http://blogs.msdn.com/ie/archive/2008/01/21/compatibility-and-ie8.aspx
http://www.alistapart.com/articles/beyonddoctype

<meta http-equiv="X-UA-Compatible" content="IE=8" />

Digg This

CannotResolveSymbol
{insert caption here}

Rowan wrote:
http://blogs.msdn.com/ie/archive/2008/01/21/compatibility-and-ie8.aspx
http://www.alistapart.com/articles/beyonddoctype
<meta http-equiv="X-UA-Compatible" content="IE=8" />

Fascinating... means IE can't pass the unmodified Acid2 test, though (darn backwards compatibility).

JChung2006

Who gives a fig about ACID 2 backwards compatibility if it will pass after just adding a meta tag? ACID 2 is a means to an end, not the goal.

Yggdrasil
Pour me a cab, 'cause I can't drink no more.

CannotResolveSymbol wrote:
Fascinating... means IE can't pass the unmodified Acid2 test, though (darn backwards compatibility).

People place a very big emphasis on the "unmodified" bit. Who really cares?
If the rendering engine can redner the ACID2 face correctly, it means that the requires CSS support is there and working. If it needs to be enabled via a <meta> tag, registry key or checkbox, that's a lot less relevant.

longzheng

As a web designer, I see both sides of the coin here.

On one side, it seems backwards to have to take additional steps to enable what should be the common standard in the first place.

On the other hand, it's always painful to see older sites broken when a new browser is released, especially if they're not worth updating.

In contrast, one line of code might be unnecessary, but it's not a death sentence.

W3bbo
The Master of Baiters

longzheng wrote:
In contrast, one line of code might be unnecessary, but it's not a death sentence.

I'm feeling a little uneasy about this.

Personally? I'd have done something at the "specification" layer than an implementation quirk. Let's face it, using a meta element to control rendering behaviour is a hack. Like introducing a "@renderIf(){}" at-block in CSS and keeping my source document "pure". You can already query DOM Level support to branch your code, let's extend this to CSS.

I'd just have tightened IE's "Standards Mode" DTD detection so only documents with Strict or 1.1 doctypes get "edge" mode.

Besides, once a feature is implemented, it's highly unlikely the behaviour will be changed in future. This is Microsoft making developing harder for the virtuous bunch for the sake of the idiotic masses still using FrontPage or VS's Design mode.

Massif
aim stupidly high, expect to fail often.

I'm not sure I like it either, I'd have preferred compliance to be the default and to introduce a "non compliant" switch.

At least that way, old pages which may be broken by IE are only a one-line fix, and everyone uses standards by default. I guess I'm concerned that either every page in existence has this extra line (down the line a bit), which is an awful lot of redundant information flying around. Or that the compliance mode doesn't get used as people develop sites for IE6/7 while 8 isn't dominant, and the "non compliant" sites are so dominant that no-one ever turns compliance on.

I guess it's just a little thing really, and this was probably the more pragmatic solution, but I'd have preferred to break the old sites now, rather than at some point in the future when compliance is the default.

stevo_
Human after all

Pretty dodgy..

And I don't understand the problem.. how is it other browsers are managing to put in better standards support?

Seems to me the main thing is the UA of IE, and so I wonder if they ever considered a new UA in IE8, no 'css expression', no 'if ie comment' etc..

It seems that their really scared about breaking the quirk standards that IE supports today because most sites out there are designed to these quirky standards.. I know right now everything is like a ton of blocks thrown onto the floor all out of order.. and we need to get everything into order.. but usually that means things get worse before they get better..

In x years time we'll still be using this meta tag to use to web as it's intended, where as the doctype was designed to distinct between quirks and standards..

Meh, I'm disappointed in some ways.. even though I understand the choices they've had to make..

Rowan
Look, no errors.

To be honest, I don't like it, but I don't think Microsoft had any other reasonable choice and I'm not complaining yet. I definitely disagree with adding this to other browsers just because IE8 will support it, there's barely enough room for one legacy browser in this word.

For the short term it will be a Godsend, but I'm not sure about the long term.

Read Eric Meyer's opinion: http://www.alistapart.com/articles/fromswitchestotargets/

W3bbo
The Master of Baiters

Rowan wrote:
To be honest, I don't like it, but I don't think Microsoft had any other reasonable choice and I'm not complaining yet. I definitely disagree with adding this to other browsers just because IE8 will support it, there's barely enough room for one legacy browser in this word.

For the short term it will be a Godsend, but I'm not sure about the long term.

Read Eric Meyer's opinion: http://www.alistapart.com/articles/fromswitchestotargets/

I'm also skeptical of any "commitments" made by Microsoft w.r.t. the future. I doubt this "feature" will be supported by any future "total rewrites" of IE. (Whilst Trident VI in IE8 features a massivly revised layout codebase, I can imagine a total rewrite within 10-15 years' time)

But basically, the main "pro" argument is forward compatibility: You "freeze" your page in time so UAs will render it the same way in future.

The #1 problem with this is that is can be pretty effing hard to maintain this if little logic changes are made over time, especially if they're bugs that get corrected. No-one cares about little bugs in Gecko or WebCore and post-8 IE shouldn't have many worth caring about either.

In conclusion, I won't be using this "feature".

Massif
aim stupidly high, expect to fail often.

W3bbo wrote:

Rowan wrote: To be honest, I don't like it, but I don't think Microsoft had any other reasonable choice and I'm not complaining yet. I definitely disagree with adding this to other browsers just because IE8 will support it, there's barely enough room for one legacy browser in this word.

For the short term it will be a Godsend, but I'm not sure about the long term.

Read Eric Meyer's opinion: http://www.alistapart.com/articles/fromswitchestotargets/

I'm also skeptical of any "commitments" made by Microsoft w.r.t. the future. I doubt this "feature" will be supported by any future "total rewrites" of IE. (Whilst Trident VI in IE8 features a massivly revised layout codebase, I can imagine a total rewrite within 10-15 years' time)

Why do people insist on the peculiar belief that any established system is going to suffer a "total rewrite" at any point in time?

Large complex systems don't get total re-writes, they gradually evolve away from their origins. MS are as unlikely to re-write IE as they are Windows, which isn't to say that five or six versions down the road any of the code will be the same.

The Cost / Benefit of a total re-write is so low that it ain't worth it, unless you're fundamentally completely broken. (Which anything that actually has a market isn't, by definition.)

W3bbo wrote:

But basically, the main "pro" argument is forward compatibility: You "freeze" your page in time so UAs will render it the same way in future.

The #1 problem with this is that is can be pretty effing hard to maintain this if little logic changes are made over time, especially if they're bugs that get corrected. No-one cares about little bugs in Gecko or WebCore and post-8 IE shouldn't have many worth caring about either.

In conclusion, I won't be using this "feature".

So you're going to go through the bother of developing for a non-standards compliant version?

Seriously, how could you not use it? As a web-dev it's going to be a no-brainer to insert that single line at the top of the page.

If it happens to completely future-proof your page, then that's a bonus.

I wasn't sure I liked it, but after reading and thinking more clearly, it's obvious that this is the only workable way or allowing changes to browsers without breaking the old web.

Sven Groot
My name has 9 letters. Coincidence? I think not...

I have to add my vote that this is a bad idea.

It means that standards-compliant sites that exist today won't work as they should in IE8. Standards mode should be the default. You've set the precedent now with IE7 that people shouldn't rely on browser bugs. Continue that precedent.

The rule for sites should become: if it's a browser (or a version of a browser) I don't know, I give them the most standards-compliant version of my content I have.

IE more than any other browser has the power to enforce this.

I really really really don't like this idea. If they want a different switch, make it the XHTML 1.1 (or newer) DOCTYPE, or even the application/xhtml+xml MIME type. Don't introduce yet another arbitrary new meta tag.

Please everyone here who can talk to the IE team, please beg them to reconsider.

EDIT: Since it's a meta http-equiv, does that mean we can also configure our servers to send an actual header with that name? That'd be a bit better already. Still a bad idea though.

YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!

Sven Groot wrote:

I have to add my vote that this is a bad idea.

It means that standards-compliant sites that exist today won't work as they should in IE8. Standards mode should be the default. You've set the precedent now with IE7 that people shouldn't rely on browser bugs. Continue that precedent.

The rule for sites should become: if it's a browser (or a version of a browser) I don't know, I give them the most standards-compliant version of my content I have.

IE more than any other browser has the power to enforce this.

I really really really don't like this idea. If they want a different switch, make it the XHTML 1.1 (or newer) DOCTYPE, or even the application/xhtml+xml MIME type. Don't introduce yet another arbitrary new meta tag.

Please everyone here who can talk to the IE team, please beg them to reconsider.

++

Sven Groot
My name has 9 letters. Coincidence? I think not...

Also, how do we get the word out to every single developer about this flag?

Many people will not know anything about this. They'll simply write their standards compliant webpage, test it in IE8 and then curse MS for still not getting it right.

Then they'll keep writing stuff that works in IE7, because they think that's all IE8 supports too.

Yes, this flag would be great for backwards compatibility. But it would be yet another roadblock on the way moving the web forward. In the long term, it could end up being a disaster.

Please don't do it!

Sven Groot
My name has 9 letters. Coincidence? I think not...

I propose the following compromise:

Pages using the application/xhtml+xml MIME type must get full standards mode by default (if they're going to support this MIME type at all, and do it properly, it doesn't make any sense not do this).

Then I'm willing to accept (grudgingly) the necessity for this flag for text/html pages only.

Massif
aim stupidly high, expect to fail often.

You're all mad!

I used to think like you, but then I read the above linked post, which explained it all to me, and now I think it's probably the only way we're ever going to make standards work. (I'm prepared to flip flop again though, should a persuasive argument come along.)

Let's start with the basics:

1 - a significant percentage of sites wouldn't work if IE8 went "standards by default". Basically most of the sites that FF or Opera break. (At least, probably many orders of magnitude more, because of all the sites which target IE specifically with code that wouldn't work under standards mode.)
2 - No developer in their right mind is going to avoid putting this single line of HTML in, if it means their site can be developed once and will run for evermore.

Let's try that again, but more rationally.

As a developer you have the choice of trying to make the site work the "old IE" way, or adding a single line and having it work the nice simple standards way.

It's a no brainer (for a web-dev).

Whatismore, you now have the option that - should there be a rendering bug, or the call for a new feature, or whatever, in any current browser that supports this new meta data - the browser vendors can fix it in their next version.

Because before, with all the work arounds that people had to use vendors were either of the "it's not going to matter because people can always use IE if we break anything" or of the "we can't fix this bug because it'll break a bunch of sites people use all the time" camps. Camp1 vendors were free to innovate, so long as they didn't mind perpetually being the underdog. Camp2 vendors were paralysed with the prospect of breaking huge swathes of the web for their users. Those browser vendors weren't free to fix bugs with their code.

They would now be free to do that, and simply use the faulty code should a site targetting the older browser be visited.

It's not nice that such a solution has to be used, but frankly it's the best that can be hoped for.

littleguru
<3 Seattle

I also think that it should be the other way around. But I can understand the reasoning here: like if they really switch the engine to 100% standards mode there will be a lot of pages broken. Even pages of big companies, like of banks etc.

This would probably mean that a lot of people wouldn't switch to IE8 because everything is broken...

Still there must be found a way to make people more design against the standards. With this way probably nobody will go with the standards since IE is still by default supporting the non standard way.

W3bbo
The Master of Baiters

Massif wrote:
Why do people insist on the peculiar belief that any established system is going to suffer a "total rewrite" at any point in time?

Large complex systems don't get total re-writes, they gradually evolve away from their origins. MS are as unlikely to re-write IE as they are Windows, which isn't to say that five or six versions down the road any of the code will be the same.

The Cost / Benefit of a total re-write is so low that it ain't worth it, unless you're fundamentally completely broken. (Which anything that actually has a market isn't, by definition.).

Actually, "total rewrites" have happened many times, but not necessarily in the form of an "in-place" rewrite.

Take the 9x -> NT conversion for example. The platforms are totally different, yet one supplanted the other. Given enough time, I believe a Singularity-based OS will eventually replace Windows.

Also, remember Netscape planned a rewrite of their epynominous browser (which led to the downfall) which rose again as Firefox.

Finally, even Microsoft is guilty of rewriting IE, IE4.x shares almost zero codebase with 3.x

Minh
WOOH! WOOH!

Massif wrote:
It's not nice that such a solution has to be used, but frankly it's the best that can be hoped for.

I agree. If you had to engineer a standards solution for a product that doesn't generate any direct revenue, and could have HUGE tech support cost because of its wide distribution.

When you really think about it. This is the best choice.

Minh
WOOH! WOOH!

W3bbo wrote:

I doubt this "feature" will be supported by any future "total rewrites" of IE.

You assume that IE8 DOESN'T already contain 2 separate engines.

Massif
aim stupidly high, expect to fail often.

W3bbo wrote:

Massif wrote: Why do people insist on the peculiar belief that any established system is going to suffer a "total rewrite" at any point in time?

Large complex systems don't get total re-writes, they gradually evolve away from their origins. MS are as unlikely to re-write IE as they are Windows, which isn't to say that five or six versions down the road any of the code will be the same.

The Cost / Benefit of a total re-write is so low that it ain't worth it, unless you're fundamentally completely broken. (Which anything that actually has a market isn't, by definition.).

Actually, "total rewrites" have happened many times, but not necessarily in the form of an "in-place" rewrite.

Take the 9x -> NT conversion for example. The platforms are totally different, yet one supplanted the other. Given enough time, I believe a Singularity-based OS will eventually replace Windows.

Also, remember Netscape planned a rewrite of their epynominous browser (which led to the downfall) which rose again as Firefox.

Finally, even Microsoft is guilty of rewriting IE, IE4.x shares almost zero codebase with 3.x

Actually I was kinda surprised you didn't point out the Mac OS9 OSX break.

As for the 9x -> NT switchover, it was more like they created two different products for different needs and then brought one of them to the point it could take over from the other. NT wasn't a total re-write from 3.1, it was a different product aimed at different people.

Replacing one product with a different one is a different proposition, and brings with it the attendant chance to get the new product polished before replacing the old. Re-writing an established system is just going to risk every possible problem, for little to no benefit.

And who used IE3, like 2 people? Wink

(My point was, that IE3 didn't have a large enough user-base to be called "established." and I'm not altogether sure it was a re-write, given that bugs in IE3 were retained until IE6.)

So ner. Tongue Out

W3bbo
The Master of Baiters

Massif wrote:
You're all mad!

No! You are!

Massif wrote:
I used to think like you, but then I read the above linked post, which explained it all to me, and now I think it's probably the only way we're ever going to make standards work. (I'm prepared to flip flop again though, should a persuasive argument come along.)

But that's the thing... doing this isn't making "standards" working, it's practically assuring "IE only" websites will continue to exist.

I'm not under any illusions that the majority of web developers/designers adhere to the specifications (so long as anyone who's only known Dreamweavers' Design Mode can call themself a "web developer" we're screwed) this "solution" isn't going to help the situation.

I'm with Sven: developers are learning more than ever before, especially after their webs broke with IE7. If we continue the trend of "strict accept" then the baseline will improve.

Besides, forwards compatibility is easy to assure, backwards compatibility isn't.

Besides, versioning based on browser version rather than layout engine version is just stupid, since different browser versions can share the same engine, and the same browser "version" can have different engine versions. Take Safari 3 for example, you can pick and choose any WebKit build you want, and Gecko hasn't changed much between FF1.x and 2.x.

Massif wrote:
1 - a significant percentage of sites wouldn't work if IE8 went "standards by default". Basically most of the sites that FF or Opera break. (At least, probably many orders of magnitude more, because of all the sites which target IE specifically with code that wouldn't work under standards mode.)

Tighten up the "standards mode" detection so it only works with documents with Strict doctypes and they're well-formed documents. This practically assures the developer "really wanted" compliancy.

"standards by default" isn't a good idea, no, but neither is "active opt-in". The system with doctypes, for the most part is fine. I believe they're overstating the "harm" of inaccurate DTDs placed by IDEs.

Might I just suggest the W3C advises authoring tool developers not to use the Strict DTDs? Or maybe move back to the GENERATOR meta value. That's a much better system since it doesn't penalise us perfectionists.

Massif wrote:
No developer in their right mind is going to avoid putting this single line of HTML in, if it means their site can be developed once and will run for evermore.

This is ironic. This proposed HTTP header and meta element isn't in any of the official W3C specifications... so it's ironic it's meant to assist us in being more "standards-y".

Microsoft: punish the evil users of authoring programs, not perfectionists!

I'm not going to pollute my code for the sake of a broken idea in a browser that, for the most part, works fine already.

Massif wrote:
Let's try that again, but more rationally.

As a developer you have the choice of trying to make the site work the "old IE" way, or adding a single line and having it work the nice simple standards way.

It's a no brainer (for a web-dev).

Whatismore, you now have the option that - should there be a rendering bug, or the call for a new feature, or whatever, in any current browser that supports this new meta data - the browser vendors can fix it in their next version.

Because before, with all the work arounds that people had to use vendors were either of the "it's not going to matter because people can always use IE if we break anything" or of the "we can't fix this bug because it'll break a bunch of sites people use all the time" camps. Camp1 vendors were free to innovate, so long as they didn't mind perpetually being the underdog. Camp2 vendors were paralysed with the prospect of breaking huge swathes of the web for their users. Those browser vendors weren't free to fix bugs with their code.

They would now be free to do that, and simply use the faulty code should a site targetting the older browser be visited.

It's not nice that such a solution has to be used, but frankly it's the best that can be hoped for.

Yada... I feel tired. I only had 4 hours' sleep last night and I've been downing caffine all day and I just bombed on my latest mathematics examination.

//not in the mood
//tldr

Massif
aim stupidly high, expect to fail often.

I'll give the IEBlog my final word on this, because I couldn't care less about standards compliancy. (And I'm currently working for a large website.)

IEBlog wrote:

We realized that the model for web development was really “write to the standard, then test against and fix problems in the most popular browsers.” This meant that the web developer had one crucial piece of information we could make use of – what version of IE they had tested against, and after much discussion in the WaSP-MS task force, we ended up with a <meta>-based “opt-in to the browser version I tested with” strategy.

So perhaps you should stop thinking of it as a "standards" flag and think of it as a "it worked in this version, so do whatever that version did" flag.

(Although, if you wanted to reference by layout engine, then perhaps you should suggest that.)

stevo_
Human after all

Dunno, perhaps we could get around this shti in the future by actually agreeing on a standard, and then a browser can only attempt to handle the standard once it's been signed off as 'yea, this is ok'..

This way, if a standards change is nec because something is hugely wrong with it, all the browsers are in the same boat, and the fix can be issued as a new version of the standard that would go through the same thing..

I know this is the way these things were intended.. but right now we're in a huge fcuking sandbox where nothing is complete, nothing is fully implemented and it's really god damn infuriating..

odujosh
Need Microsoft SUX now!

I think you guys make this way bigger deal than it is. Opera and FireFox is not Acid 2 compliant. Until thats sites will have a procarious time anyways. If I could say the others would have there story straight by the release of IE 8 I think you guys would have an argument. Till then the meta tag is a good opt in approach.

BECAUSE:
You will have to touch pages anyways to take advantage of the features Acid 2 prove exist. Unless you have a wholely static HTML site that has grown bigger than is manageable I don't see what the issue is. For most ASP.NET and PHP developers we have our pages factored around some form of templating that limits the number of peices we have to touch.