X-UA-Compatible: let sleeping intranets lie?
The longer I think about X-UA-Compatible, the more I think it's not really about "not breaking the web". I think it's about "not breaking big bad web apps".
While it's possible that Microsoft wants to be friends with standardistas, or at least make us shut up, they really don't want to be enemies with a much larger group - large web application vendors and administrators.
Think of the children lemurs big vendors
The big application vendors could seriously kill innovation in IE. People like IBM, PeopleSoft/Oracle, BlackBoard and indeed Microsoft themselves... basically any company that sells web applications with lots of zeros in the figure. There are a lot of them out there and a lot of them dominate an entire industry.
Why can't MS afford to piss them off? Well their products drive a lot of really big sites and intranets that only work properly in IE6 or IE7, because they were built for a bad but stable platform. If IE8 comes out and renders like Firefox, Opera or Safari, those sites might break.
That's one reason IE7 is still blocked in many corporate environments - they have systems that only work in IE6. Remember it only takes one critical system to stop the new browser being rolled out. Admins have no choice but to lock down to old versions of the browser or switch their users to a competitor (if they have that option).
So Microsoft faces a scenario where their new products are not adopted; or they start losing thousands of users at a time as corporate clients switch to competitor products; or they have to keep releasing browsers that never update the rendering engine.
Otherwise they could have large vendors banging on the door with pitchforks, torches and lawyers, demanding to know why Microsoft has sabotaged their products after years of providing a stable platform.
stability?
IE6 sucked, but it didn't change for years. That's stability, to the corporate mind. So they just built for IE, or if you're really lucky they built for Netscape as well and eventually grudgingly added Firefox to the list. Safari? Opera? Konqueror? Not a chance. In fact "alternative" browsers may even be blocked entirely.
The big vendors don't want new browsers. New browsers are a pain because they require huge amounts of testing, bug fixing and patches. So they want their supported browser list to be as small as possible and they'd be quite happy if no new browser was ever released.
why are these apps so bad?
Based on my observations the bigger the company and the more expensive the product, the worse the product's frontend code will be. The bigger the application the harder it is to change any of it, too.
Why is that? My speculation is that the really big enterprise applications are mostly running on old code bases. They may have been through several releases, with an ever-expanding list of dependencies, patches and plugins. Some didn't even start life as a web app. Some began as desktop applications and at some point had a web interface tacked on.
I'd also guess that the web interfaces are often built by software engineers, who were never trained as web developers and really don't care about frontend code - much less standards compliance or accessibility.
So anyway, these applications are not agile. They are big, slow and heavy. They cannot change direction. They cannot seriously deviate from the way they work. They cannot be easily fixed if their environment changes.
...and that's the new version
Keep in mind that the systems in production out there might also be running and old version of the product. When it costs hundreds of thousands of dollars just to do a dot-point upgrade, staying current loses some of its gloss.
Clients might be holding on to an old install because they don't have the money, time or inclination to upgrade it. There are plenty of systems out there being kept alive well after their use-by date.
think of the large clients
At even greater risk than the vendors in all this is the people who bought the big applications. We're talking about big businesses, universities and government departments who've invested anything from hundreds of thousands to many millions of dollars implementing an off-the-shelf web application.
Why do I say they're at risk if they could afford the system? Well many of these clients cannot afford to do much more than maintain the application. They spent their money, they got a system and now they wait out the years on a support plan, until their next shot at a big capital expenditure.
what about roll-your-own?
Major operations tend not to roll their own web applications. I'll skip the rant about the wisdom of this approach; but the decision makers believe that big organisations have to buy big products. They believe that only a big vendor can provide proper support; they believe they need an ecosystem of consultants set up to help with your implementation; and they need to feel sure the vendor will still be releasing patches in five years time.
The applications are critical to ongoing operations. People need financial systems to get paid, students need to get enrolled, government departments need to publish information for the public. These are not systems that can be replaced by something hacked together over the weekend, no matter how much of a big, tough Rails Haxx0r you are.
even if they do roll their own...
In some cases, big organisations will actually get a system built specifically for them. But when they do that, they still tend to base it on some large vendor's technology. They also tend to hire really expensive companies to do the build; and those companies often convince them to set up "a controlled environment" since they have the same mentality as the big vendors anyway.
Which means they just build for IE, or if you're really lucky they build for Firefox as well.... and you know where that leads.
then there are the disinterested developers
It's true that even the big vendors probably aren't the only issue. Yes, there are a lot of developers out there who aren't packing a major web application, yet they have the same build habits as the vendors. IE's the most common browser, so that's what they build in. End of story.
No matter what standardistas think of them, we're outnumbered by the people who learned tables and font tags back in 1997 and haven't changed a thing since.
Yes, these people just might scream at Microsoft if IE8 suddenly "breaks" their sites. While I personally would be happy to see these hacks get a harsh lesson, I can understand why Microsoft might not want to stir up that trouble.
so where does this leave the IE team?
Let's assume that the IE team do want to build a standards-compliant browser, even if Microsoft the company doesn't give a shit. It's also rational to think they want to keep their market share; and we know they don't want 10,000 more screaming emails.
So the IE team can't release something which breaks all those intranets and web applications. Forget "breaking the web" - the web can heal itself (mob rules and all...).
But imagine what happens if you break a bank's intranet? Breaking a hospital's patient file records database? Breaking a government's welfare payment system? These are scenarios I think are entirely plausible and would cause serious trouble. Breaking an entire product line of some major vendor? That's unlikely to bode well for the IE team either.
So version targeting is a way out. They can build a better UI, a more secure browser and still keep the old rendering engine for those systems that won't render in standards mode.
If that same solution can be set up to keep the lazy developers happy and quiet, so much the better (for Microsoft).
where does that leave standards?
Standardistas get caught in the crossfire. We have to do more work because we build the "right way". But we're motivated enough to go and fix our sites, or set up a version target, or deal with it some other way. We'll live.
Being able to specify browser support probably means that a lot of existing sites and web applications will never progress. They'll freeze at IE7 either through choice or inaction.
Huge numbers of people will opt out of web standards and opt-in to IE, because it gives them the illusion of stability and control. Is this a big loss? Perhaps not - they probably weren't ever going to be willing or able to make the switch to standards anyway.
So essentially Microsoft is giving up on a huge number of developers. They're giving them a free pass to mediocrity - making it easier to just do nothing rather than build to standards. There is no way this won't lead to more crappy, non-compliant, non-accessible and inefficient web sites and applications. So it's bad for standards on that count.
But, the flip side is that all those crappy sites can sit and stagnate without stopping the rest of us building to standards. Plus I gather from some of the comments I've seen, the alternatives were all worse.
Maybe the whole issue will be a turning point. Perhaps standards-based development becomes a niche industry, like tailor-made suits compared with cheap off-the-rack suits from budget stores. People might recognise the quality, but they'll only pay for it on special occasions.
standards 0, business 1
While it's disturbing how well lemurs can illustrate the issue as it might play out for small companies (X-UA-Lemur-Compatible, if you haven't seen it), I don't think that's what ultimately drove Microsoft's decision. I think the most telling battles were probably fought on the major application front.
Standards lost. Business won. But IE8 may live to fight another day and with it, maybe standards will ultimately come out on top.
I still think X-UA-Compatible should have been an opt-in system, putting the burden onto the people who caused the problem in the first place. It would have been far better for web standards if all those lazy developers out there had to explain why they needed to roll out another patch. Maybe a few questions would have been asked.
But that's not how it's going to play out. Microsoft is making web standards an opt-in game. In some ways the game hasn't truly changed... we still have to convince people to opt-in to standards, it's just going to be a little harder now.
I hope the big bad web applications appreciate it.
Labels: browsers, enterprise applications, ie8, intranets, microsoft, web standards, X-UA-Compatible
Ben. That is the best explaination out there. I think we know this is the answer, but we pretend to ignore it. I wanted to articulate this but got to mixed up in both sides of the argument. Well done.
Ben this is the post I wanted to write because browser version switching is all about intranets and their applications and nothing about the internet.
I understand the logic of why it is being done, I just do not agree with the implementation.
It would be better if IE8 had all those features turn on, and in a corporate environment the system could be set to which sites must be treated like IE7 (much like what sites bypassing proxy settings). If MS wanted better uptake of IE8 then an option to treat like IE6 would be a big selling point. A large number of corporate environments like our office are still IE6 because of payroll and finace systems (they do not work in IE7).
IE8 or later should not default to IE7 if that meta tag is not present, because that is a security risk to users. Suppose a flaw/exploit of IE7 is found, it can be fix in the IE8 or IE9 engine, but you can't fix the IE7 engine because it will break IE7 intranets (history lesson, improved security features of IE7 are one reason many places are still with IE6).
So all IE8+ users will be put at risk, because any web page without a specific meta tag, will behave like IE7 and have all it's security problems.
A better way would be let users or IT departments decide which sites be treated with the old school, lower security version and everything else gets the high tech, high security version. Who cares if it is a few pixels out on rendering as long as it works and is secure.
Good article, Ben. It helps explain to me the dogged persistance of IE6 - even with forced IE7 upgraded through Windows Update. Anything that has had so much money invested in is going to die a slow death indeed, much to our own pain and suffering.
The AOL client is another example. It is essentially IE dressed in drag. Cross-browser development was never necessary: "Oh it works in IE5.5" was enough.
As for banks, they're usually driven by security concerns anyway so I'd hazard a guess in that they would be dropping IE6 support like a hot piece of dog poo in the near future. If they're not, they should.
Probably the best post I've read so far about the rationale behind the new meta tag. The upshot of it all might just be that this will be remembered as the moment IE shot itself in the foot. This is, after all, an industry in which innovations come at a rapid pace, so freezing IE's rendering engine at IE7 for all those not in the know could have a seriously adverse effect on IE's market share. One can only hope :)
I don't think it's the code legacy in the back-end, I do think it's the software engineers who still use tables for layout, because this is all they know. And they live by he rule: If it's not broken, don't fix it (until it's too late, or even then they don't know it is broken). Did any one ever saw a SAP portal? The horror... :)
I understand what you are saying, but the fact is (as you said) that most Corporates have stuck with IE6, and it doesn't look like this will allow them to move on to IE8. The damage has already been done, and if IE cannot support current standards then Microsoft should be the one who has to take the pain, not us.
100% agree with you and came to a similar conclusion myself.
Except that I would say that brings the total score to standards: 0 vs. business:1,500,000.
I remember when I first started learning and using web standards, I did so because I thought that this was the right way to make web sites, the general feeling was that if you had pride in what you did, you would develop/design to the standards.
Years later, I'm really starting to wonder if this was the right move, when time after time we are forced to take a slap in the face for the good of some corporate bottom line.
I'm starting to wonder if I should go back to tables and font tags, if I did, it seems that my laziness will be generously rewarded by the powers that be in the years to come, if the past is any indication.
I care not what any of the experts say about the statistically higher number of developers who do not use standards vs. those who do, this system should have been opt-in.
I still think it should be opt-in and even for large sites, the worst that should need to occur is to add a custom HTTP header. For IIS this is trivial to add in the Default Web Site Properties, it's not like every page needs have the meta-tag added. Instead of making this a no-brainer stop-gap MS has once again turned a large portion of the development community against them. They may not have shot themselves in the foot but they've certainly stepped on a nail.
It's certainly true what you say about software engineers and how they code. There is also an attitudinal problem there, where they consider HTML/CSS to be simple and beneath their contempt. Afterall, they program using the really really hard stuff, yanno, and HTML is for the birds.
I recently told a programmer that I was reluctant to insert his code (for an app) into one of our library site pages because his was written in XHTML transitional, and mine was in HTML strict. It didn't seem right to me. He thought I was being idiotic. "Who cares? If it renders, that's all that matters!".
/me sighs
"The damage has already been done, and if IE cannot support current standards then Microsoft should be the one who has to take the pain, not us."
There it is... There is no better way to put it than that. There is no argument that can change the simple fact - MS made a promise, now they can't deliver on it, if they were drug dealers they'd be found in a gutter somewhere with one in the head when IE8 is launched in "super standards mode" by default - why is this our fault? We weren't involved in the back ally deals they made...
Its time MS stood on its own 2 feet for once...
Post a comment
Got something to say? Leave a comment! Please add your name. If you don't have a Blogger or OpenID account, you can still choose "Other" to include your name & URL.
→ Post a Comment