awfully nervous....good concept but there is a LOT left to be fleshed out.

Yes, I really like to have dozens of UA noted there. We’re doing web standards, not Browser specific code. This is basically useless. Websites don’t break in standards compliant browsers if they are designed according to the spec. Else Firefox, Opera and every other major browser would have introduced such a concept from the beginning.

Surely it would be better for every browser to render html in the same way. That way designers dont have to guess at how things will display!

I must say, I am not too excited about it. I have read over it a couple of times, trying to get myself excited - but I just end up thinking how backwards it is.

You should probably also mention that Microsoft is supposedly forcing everyone still using IE6 to IE7. Not sure if worrying about IE 5 or lower is even worth it (I guess there's still a lot of win98 users out there still).

http://www.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/08/01/17/Microsoft-warns-businesses-of-autoupdate-to-IE7_1.html

@nogg3r5, every browser rendering the same would be nice, but unfortunately we don't live in a perfect world. I don't think this will ever happen, especially as new standards are released. No one will get HTML 5 or CSS 3 right on the first try, and it is highly unlikely that they will all get it wrong in the same way.

I think this is a good path to go down, and I hope other browser developers decide to support this as well. If a client hires me to build a website, I don't want to have to check up on it every few years to make sure it doesn't explode with a new browser version, and I would say that most businesses don't want to hire a developer for that reason either. If browsers can respect older pages, then it gives us developers a firm foundation on which to build.

My only concern is browser bloat, but I would rather see that than webpage bloat which seems to be where we have been heading with CSS hacks, Javascript browser sniffing, and conditional comments.

@Nate - I agree with your assumption on this, it just seems wrong.

@Snook - If I have to do it, looks like I'll be using 'edge'. At least we have that option.

@Snook - the other issue is, just as with other standards, its requires people to be able to set the header to 'edge' if they so wanted. This requires them to have knowledge to change it (not everyone understands), privileges to change it (some might not have access).

So regardless of which way you look at it, it requires the developers to change something. Only now, we are putting more trust and faith in the browsers to implement this consistently. I feel like we have been down this path before.

Honestly, I can't come with a solution - there just seem to be so many barriers to both sides (even web standards). I just don't feel right that this is a 'solution.'

Many angry people are missing the fact here, that IE wants to do this so they can start SUPPORTING STANDARDS more aggressively. Currently they are reluctant to do so because they don't want to break old websites. It could be possible that with IE9, it could be completely on the same level with Firefox and the rest because they aggressively updated the rendering engine etc.

This whole ordeal is quite funny to me considering the top "experts" in the field are supporting it (and partially microsoft) while all the lowly developers are turning their backs. Sort of against the trend for once.

I'm with you on this one, I think it's a great idea, and the drawbacks are nothing major.

More of my thoughts:
http://mattwilcox.net/archive/entry/id/956/

"the other issue is, just as with other standards, its requires people to be able to set the header to 'edge' if they so wanted. This requires them to have knowledge to change it (not everyone understands), privileges to change it (some might not have access)."

If the people do not know about EDGE then they are unlikely to be the people that code with standards, or want that behaviour anyway. As I see it this system is brilliant for ignorant web developers. When they test and build their website they will be viewing it in a DOCTYPE derived mode, so either 'quirks' or 'IE7'. Well, their ignorance won't matter to anyone because their page will always render properly, even if they author crap code but have a valid doctype (say someone developing in Dreamweaver...). And if they want to take advantage of the new-shiny they'll have to learn to code properly.

Other people who are not ignorant of the issue can set EDGE. So they win too.

Win/win/win, everywhere.

"I so called it"

When will you be predicting the NYS Lotto? Please keep me informed of all future predictions.

Thanks.

Jonathan, I definately agree. Something is required to allow future browsers to break free from earlier editions featuring poor standards support. Allowing sites to set the rendering engine that should be used negates the need for later rendering engines to compromise for the sake of supporting older sites. This seems to be a reasonable solution.

its requires people to be able to set the header to 'edge' if they so wanted

But if they don’t, then the worst that will happen is their site, when rendered in Internet Explorer, will be rendered as if it’s Internet Explorer 7. If they don’t have enough control over the mark-up to be able to set a meta element, I doubt IE 7’s rendering will be an issue for them.

It makes zero sense to me that I should have to add a meta element to make Browser X version Y render as itself instead of an earlier version. What on earth??

I think this is really good for the web. Because I think the new default of 'stay as IE7 when no meta tag found' will enhance the uptake of web standards. Because every ignorant developer on earth is now going to be permanently stuck with IE7 rendering and behaviour. They will never get to use any of the new-shiny of IE8 and above if they don't know to include that meta tag. They won't know to include that meta tag until they go away and learn about web standards.

If I could, I'd have every browser on earth fall back to the current DOCTYPE switcher mode, and current render engines, if any part of the page did not validate. That'd stop ignorant developers simply slinging in the meta tag and carrying on producing tag-soup. It would force valid pages if you want to use CSS3 or the new ECMAScript. And all the while leaving the rest of the web totally unbroken.

@pauldwaite and @matt wilcox - I understand what you are both saying. I understand the default behavior (and do not like it). I understand that if people don't know about edge, then they probably aren't building to standards (still a bad argument for those who are just learning standards - maybe even a turn off). This all just seems like major hackery to me. I know we don't live in a perfect world and things will never be perfect, but this 'solution' doesn't seem like much of a solution to me.

Maybe it's my lack of trust in MS, that they now have control over the rendering per a meta tag (or server configuration). As gRegor says, it makes no sense.

Again, all my personal opinion and I have no solution, I just fail to see this as any kind of solution.

How about declaring the standard (eg. HTML4.1 strict; CSS 2.1) which the website creator followed instead of the browser agent? The W3C standards are specific enough. Declaring UA seems crazy - what about mobile devices, what about screen readers, exotic browsers? Why should I care about listing UAs? If I list FF3 and IE7 and forget to list some exotic browser how should it behave? Should all browsers try to imitate the mainstream ones? Why? It's like introducing quirksmode all over again.

What, exactly, is the difference in this compared to conditional comments? As far as I can see, this new feature is just another way of doing what web developers have done for years - writing specific rules for certain versions of IE (lower than 8, or lower than seven).

Will IE8 drop support for conditional comments? In that case, it's nothing left to do but to reinventing the wheel and using this new feature. If not, I do not see the point.

@Snook: I agree. It's just another one-line add to whatever you use as your "base template" upon which you build all your work.

@Tom Sieron: It does seem like there's a lot of ambiguity here. How long will it take for FireFox to support this? What if Safari/WebKit never does? Do browser vendors now need to add a bit extra code to support these old rendering engines? It will be interesting to follow.

So far I have designed to the standards - not to different browser versions.

I'd love to continue that way.

"I'm thinking, take 5 minutes right now, configure your server, and move on. People are spending more time complaining than it would take to solve the problem."

I can think of at least ten people (web designers) who would have no clue how to configure their servers to do this. I could also list off the majority of agencies around me that would have no clue. Honestly, they wouldn't understand one bit. This requirement of 'just update your server' just seems really silly to me. How many times and how many different browser variations will we have for this? One for IE? One for FF? One for Safari? So now - instead of cluttering up our markup with hacks to fix their broken implementations, we now have to clutter up our server config files to send the right HTTP header info. Seriously? How is that a solution to anything?

It all looks like the same pig, just different lipstick to me.

Bizarre that we have to add code to use the latest browser, shouldn't it just detect compatibility, now that would be a superior browser, one that actually knows what to do.

Well people didn't know about doctypes at first either but these were later auto-inserted by html-editors. Don't you think the editors will start adding this as well and what newbie webdesigner wannabe will choose anything but the "edge" setting. This is as doomed as the doctype switch was...

It's only a matter of time before we'll need something new unless we can force the developers of the html-editors to not include the feature... The only way I see is to always force standards mode and have an opt-out instead of this opt-in system.

Why not just use the standard, like HTML5 in the next few years. A standard created by most of the browser maker out there, as far as I know...
I think web developer should be able to tell he browser witch standard they use and their jobs (the browser) is to render it accordingly. I know that I may be dreaming.

Like I said before, I don't believe this is going to work in the long run. The implementation of this backwards compatibility meta thingie will be buggy as hell, and thus useless.

As it stands, we'll only be needing this for IE8 now. Other browsers don't currently need it, and might never need it. But if/when they do: there's a way to do it.

It's like an explicit fallback mechanism. One that you (as a developer) can control, and not one that depends on how a specific implementation renders a hack (which are interspersed in your code -> ugly). This is much cleaner than all the CSS hacks we have now because it's explicit.

What still isn't clear for me is how to specify the latest of every browser.

It's looking distinctly like IE will be the only browser to support the header. Today I've read posts from people representing Mozilla, Apple and Opera saying they can't see the benefit in adopting this header.

I remain unconvinced by this idea. My feeling is the default behaviour is back to front.

A major issue to me is one of education. How are MS going to get the message out to everybody developing websites now, let alone newcomers to the industry? It's bad enough helping people get their heads around the quirks/standards mode switches as they stand today.

@Snook Actually I'm just thinking "great, MS is doing another stupid thing that makes me have to do more to make their browser work correctly."

And as an end user, if Browser X says it can do Y, I want it to do it. It shouldn't have to rely on developers doing something extra. This is both a developer and end-user perspective.

Tom Sieron said it pretty well, I think.

Interesting, well done on another great prediction.
Like other posters, i'd love it if every browser would render html the same. Would make my life 10x easier!

@Snook:

Sorry Snook, but I have to disagree you and agree with Jeremy Keith here in that if you let MS say this is the only way they can support the spec it is letting the tail wag the dog and that's just not right.

Since when does MS have the kind of power to get to dictate standards support to everyone else? Isn't that exactly what they are trying to do here?

Now sure, it’s a five minute job to change the server headers, but why should you have to, especially when at present it’s just for Internet Explorer? Why is IE so damned special? Market share again? If so then isn’t that all the more reason to hold their toes to the fire to support to current spec instead of creating their own like they did for OOXML?

Also, if the content in those HTML 1, 2, and 3.2 pages is that important to preserve then screen scrape it, park in an XML file, and just be done with it. If it’s the graphics you're after then make screen captures till your fingers hurt for all I care and again, convert it and store in an XML file or in a database. Either way the content is preserved in a format that is usable. Until the next time we run into this problem (which should be within the next five years anyway).

You asked if someone earlier if they would pressure the other browser vendors to live up to the spec just like they were advocating MS should, my answer would be “Damn straight!” because the other browser vendors are all trying to do that as we speak, WITHOUT having to use version locking like the IE Team is suggesting.

As to the backward compatibility argument, If the only browser your app will run in is IE 4 then don’t you think its time you upgraded? And you’ll say “But upgrading costs money” Sure it does, but a better, standards compliant browser is a free download and updating that application from Classic ASP to ASP.NET or PHP (or heaven forbid COBOL) can be done relatively painlessly for a modest investment and you're old app can live in place for the time it would take to outsource your upgrade.

My point is I think an awful lot more scholarly debate actually needs to go on among all parties involved before we saddle up this pony riding headlong once more into the breach dear friends and damned be everyone else.

I think that there are a few reasons why people have been so negative about this proposal.

1) I'll start with the obvious first, Microsoft is suggesting it. Now it's all well and good saying that people should give it a chance and that just because Microsoft are suggesting it shouldn't be written off immediately. The problem is that nobody trusts them and for good reason too, they have screwed over their end users and developers time and time again. Every move they have made into the standards world seems to be an attempt to destroy the competition by owning the standard. This may be a completely innocent idea from Microsoft but it is going to be a long time of nothing but good behaviour until people start trusting what they say.

2) For that last few years the mantra has been code for the standards not for a browser, adding in browser specific code has been seen as dirty. When flame wars have built up over whether CSS hacks or conditional comments are the better way to go, can you blame people for being shocked when some of the most prominent standards people turn around backed by Microsoft and say actually it's ok.

3) The way that it was announced seemed to have the traditional Microsoft air of backroom deals and shady dealings. There were explicit references to WaSP that made it seem like they were heavily involved as a group, only for a large number of them to turn around and say actually we've not heard about this before today.

4) For the last few years we have had to hack around IE's deficiencies, make special allowances, compromise the quality of our code and all this time the end users have been oblivious to the state of their favourite browser. Then Microsoft announce that IE8 passes ACID2 and we all start thinking that maybe this time it will be better, we might be able to code once and then not spend the same amount of time again fixing for IE, there is hope. Then all of that is seemingly taken away to be replaced with the rod, is it any wonder that people are pissed.

And with regards to IE8's ACID2 abilities surely they fail the test. As i understand it the test should be taken with default browser settings, and in its current state IE7 fails the test. If the new meta tag is used or the http headers are changed to fit then the test has been changed to suit one browser, which means that it is no longer ACID2. As far as i can see it then if this carries on then IE* will never pass the test as it will always be taken as IE7.

Remember, this isn't about us, the developers, but about the end users who have to visit and use these sites day-to-day. Upgrading their browser shouldn't break the web.

It seems like a lot of people are missing this point. As a developer, I'm trying to deliver an experience to the user and I'll work with the tools I have at my disposal to do so. If that now includes a new <meta> tag, that really doesn't seem like much of an imposition.

Microsoft has to worry about their users too and this seems like a pretty reasonable way for them to progress without alienating their install base.

Lots of people don't really understand the issue. The website that will break with IE8 (or IE9) are the one that are written with standard but assume IE is not Standard compliant and apply fixes to it.

Remember what's happen last year:
http://www.thinkvitamin.com/features/design/internet-explorer-7-were-you-ready

You can think MS has a secret plan to lock people into its products like Silverlight, but I don't see how this meta tag can fit into its evil plans.

Also, with the standards we are using today (HTML4, XHTML1 and CSS 2.1...) that are now stable, clearly, IE is the only one that need this tag. But with HTML5, JavaScript2 and CSS3 coming, other browser might need it in the feature if they start to implement them when they are not finish.

@Snook

I see your point, but still, the way MS handled this whole debacle leads one to believe they haven't learned anything from their earlier mistakes despite what Chris Wilson says. Why must they always do everything so clandestine, blackbag and covert? I know its their option to do so, but its an option that just doesn't make sense.

You think they'd want the development community to know "Hey we're working on a new version and we'd like your help!" After all, just look at how much community support there is for Firefox and Webkit.

I think if they'd be more open and more forthocming with the developer community as a whole I bet that it would go a LONG way to restoring the trust developers now lack in and for MS and IE.

What I hate is its just another level of complexity to deal with, and another level to explain to clients. There are always some hidden costs, that we don't even realise ourselves.

As an example I've been consulting with a large corporate client for several years on a web application. For purely historical reasons it never used a doctype so ran in quirks mode, with a purely IE userbase. To the client adding the doctype was an expense with no payoff, so it never happened. But more recently we discovered that the quirks mode rendering time was 5-6 times slower than standards compliant mode. Their app has been unfairly been perceived as slow as a result for years.

One thing I am dreading seeing "Best Viewed in IE7" I sincerely hope it's not a return the bad old days!

@TomSieron: "How about declaring the standard (eg. HTML4.1 strict; CSS 2.1) which the website creator followed instead of the browser agent?"

Because user agents have bugs in how they implement the standard. Let's say Microsoft claims 100% CSS 2.1 compliance in IE8, but then after IE8 ships they find bugs in it. When IE9 ships with those fixes, this could cause sites targeted at IE8 to now break. This same scenario happens with other browsers today -- it's just that the perception of the breakage depends on the size and type of your user base.

Until every browser is bug free (which, since code is written by humans, is quite a long time), there will always be compliance bug fixes, which all have the potential to cause disruption. Targeting a UA version, not a spec, is required to minimize this disruption.