the 200ok weblog

A while back, Microsoft stunned the standards world by responding to developer objections and agreeing to have IE8 render like IE8 by default (and yes there are many things in that sentence that should be wrong, but aren't).

Nobody could quite believe that Microsoft would really do something that genuinely supported web standards, especially when they were reluctant to do it.

Sadly the disbelief was justified - Microsoft have now done a backflip on their backflip. IE8 won't always default to rendering in standards mode after all, interoperability principles notwithstanding.

The latest idea is that IE8 will render in IE8/standards mode by default for general web pages; put a "broken page" icon on the toolbar when in IE8/standards mode; default to IE7 mode for intranets; and let the user change the defaults if they want to.

Because that's so much simpler than having IE8 render like IE8 unless explicitly told to do otherwise.

A couple of links if you hadn't heard:

• IEBlog : Introducing Compatibility View, which is an odd mix of technical detail and rampant marketing spin. Watch out for the term "IE7 capable", which I think means "breaks in IE8".
• Comment: Microsoft breaks IE8 interoperability promise | The Register where Opera's CTO rakes them over the coals for marking standards-compliant pages with a 'broken page' icon.

broken page icon?

OK, so technically the broken page icon means "go into compatibility view". It replaces the more accurately-named "Emulate IE7" button from the previous beta. But that's not really what it looks like:

That looks like "broken page" to me. Which is particularly annoying as it will only be shown when the page is being rendered in standards mode; and it will be placed in the address bar rather than somewhere like the "Tools" menu.

it's all about the intranets

Obviously I am not surprised by this development in the saga. I said last time around that X-UA-Compatible is all about 'not breaking bad web apps' and this just confirms my suspicions.

The only sites that will render in IE7 mode by default are those accessed by local URLs like http://intranet/. Of course if you can access your intranet using both http://intranet/ and http://www.intranet.real.domain/ then you're going to see it in two different rendering modes.

So I guess you're going to have to forward one to the other or set the meta tag/HTTP header with the correct rendering mode. Which begs the question why this change was useful in the first place, if intranet developers still end up having to modify settings somewhere along the line. Why not leave things as they were - get intranet developers to just set X-UA-Compatible and be done with it?

But instead Microsoft decided to modify IE8's rendering mode selection process again.

Ok, so it's just intranets. This isn't so bad, right?

Not quite.

the defaults aren't

The nasty little rider in this latest announcement is the fact that users can now 'apply compatibility view' for all websites:

That user choice (and display of the broken page icon) can be overridden by developers using the meta tag or HTTP header. That makes sense, since the developer should know for sure if their site will work in IE8 or not.

But... think that through for a moment, and you'll realise we're back to square one. We now have to modify all our sites, all the time, since users can override our chosen rendering mode if we chose the default rendering (that is, we wanted IE8 to render as IE8 like Microsoft promised last time around).

If we build a site that works in IE8 and then leave things to the default, IE8 users with 'display all websites in Compatibility View' selected will see the site rendered like IE7.

Awesome, isn't it?

confusing for users

I really do wonder what the average user is going to make of this.

I can't fathom why Microsoft thinks the average user is going to know when to click the busted browser button. It's essentially asking the user to understand the finer points of standards compliance and rendering modes, when most users still seem barely aware that the blue e icon on their desktop is not actually "the internet".

Average users shouldn't need to select rendering modes! They should be able to just browse, letting developers and browser makers sort out the details.

But if the user is presented with the option at some point I can them going for the "safe" sounding option of enabling "compability view" for all websites. After all... it sounds kind of like a good thing, right? Compatibility is good, yeah?

so where does this leave developers?

Well, we have two options if we want to build sites that work in IE8, in IE8 rendering mode:

1. Leave things to the defaults, and ignore users who've set IE7 mode to be on all the time.
2. Explicitly set our sites to render in IE8 mode, even though we did the right thing and shouldn't have to fart around with X-UA-Compatible.

Logically I think most of us will go with Option 2, since you don't want a user to think your site is broken because they're seeing the "broken site" icon; or worse still have the page actually break because the user is applying the wrong rendering mode.

no real surprises

We are back to what Microsoft wanted to do in the first place. We have to specifically choose a rendering mode for IE8, since there's no reliable default under this new model.

But Microsoft can still say that by default an internet page will render in IE8 mode. They can still pay lip service to interoperability, even if they're not really getting into the spirit of the thing.

It's not a hard equation really: Microsoft makes money off intranets, but doesn't make money off web standards. So, they're always going to protect their intranet interests over web standards considerations.

It's a little sad, since for a while there it looked like Microsoft was actually responding to developer feedback. But it's not surprising to find out that you can't trust a multinational corporation to keep a promise it didn't want to make in the first place.

Labels: ie8, microsoft, X-UA-Compatible

It's rare that I'm amazed at Microsoft* in a good way. It's more or less unheard of when web standards are involved.

Yet the news is in, MS has announced it drank the interoperability kool-aid and reversed its previous decision to have IE8 default to rendering like IE7:

IEBlog : Microsoft's Interoperability Principles and IE8: We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can. This decision is a change from what we’ve posted previously.

This is great news. It changes X-UA-Compatible from being spam to being a safety net for big, bad web applications.

The idea of maintaining and including multiple rendering engines still isn't ideal, but really it's not a bad compromise. My biggest objection was the default behaviour, so I'm really happy to see this turn of events.

Do I think it shows MS to be a good member of the standards community from here on out? Oh hell no. I really wouldn't be surprised if this is a random act rather than a new habit. Microsoft, as a corporate entity, has no real interest in standards - otherwise it'd get MS Office to support ODF, rather than trying to get open source projects to adopt .doc (just as a for instance). Much of its profit relies on (or benefits from) leveraging its monopolies to turn their proprietary solutions into "standards".

Of course I'd love to be proved wrong here. It'd be great if MS did embrace standards, open formats and so on. But on that, only time and actions will tell.

In the meantime, we can certainly give MS credit for taking the pain away from people who do the right thing. Only people who have a site that actually breaks in IE8 need implement the X-UA-Compatible fix. For them, the investment of time is entirely reasonable; since they have a real reason to do it.

IE8 can now be a step forward for standards, instead of the huge step backwards it was going to be. Bravo!

* Note that I mean "Microsoft-the-company" and not any individual within that bohemoth.

Labels: backflip, ie8, microsoft, web standards, X-UA-Compatible

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

So. There's been an idea. IE8 is going to pretend to be IE7 unless you explicitly ask it to be IE8. Sure, that makes... absolutely no sense.

[Update 2008.03.05 - Microsoft has now reversed this decision. See the 200ok weblog: IE8 to default to IE8 after all, hell chilly.]

You probably already know what I'm talking about. Let's do the run-down:

• First we have A List Apart: Articles: Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8 where Aaron Gustafson explains that IE8 will look for a <meta> tag or HTTP header defining the browser version a site was "built for". It will then apply one of several rendering modes to try to keep sites built for old versions of IE from breaking when a newer version of IE is used.
• Then Eric Meyer describes his process of coming to accept the idea, even if he has some fairly obvious reservations: A List Apart: Articles: From Switches to Targets: A Standardista's Journey
• It is important to note that only some members of WaSP were involved in the decision, others were emphatically not: Microsoft’s Version Targeting Proposal - The Web Standards Project
• IE Platform Architect, Chris Wilson, posts details and reasons at the IEBlog: IEBlog : Compatibility and IE8. It's important to note that Chris is also taking the time to respond to comments, including one comment where he says I'm open-minded, and I'm listening. I didn't like the concept when it was first suggested; however, the evidence has proven to me that it's necessary...
• Jeremy Keith's position is clear: it's a bad idea as proposed due to the opt-out requirement - Adactio: Journal—Broken
• Anne Van Kesteren suggests we simply ignore the whole thing by setting our servers to IE=edge: The Internet Explorer lock-in - Anne’s Weblog
• Mozilla hacker Robert O'Callahan suggests that the Firefox crew will be unlikely to enter into the massive bloatware and maintenance overhead of maintaining old rendering engines: Well, I'm Back: <META HTTP-EQUIV="X-BALL-CHAIN">
• Opera's Chief Web Opener, David Storey, briefly observes that paves the way to opt-out of responsibility: The great opt-out - Slightly ajar - by David Storey

So I've been trying to work out what to make of this whole situation.

almost but not quite

The short version is this: I'm not wild about it, but I think it would be acceptable if the method was opt-in. That is, you should have to intentionally invoke the older rendering engine.

But that's not what's happening. What's being proposed is that to get IE8 to render your site in standards mode, you now have to put in a DOCTYPE and a new meta tag asking the browser to actually render in the mode specified by the DOCTYPE.

So I think this is a bad idea.

If the system was opt-in then it wouldn't be too bad. But instead it's opt-out (you know, like all those emails you never asked for). If a developer takes no action their site will initiate the old rendering mode in IE. So all those disinterested developers who only built for IE6 in the first place get rewarded for inaction.

Meanwhile those developers who build to standards have to cruft up their pages (or dick around with their server settings) just to get IE8 to render pages in IE8 mode. This is crap.

version targets are spam

IE8 version switching is like spam! Sure, let people have the option, if they're into that sort of thing. But don't force it on people who never asked for it.

we should not reward ignorance

Chris Wilson mentions on the IEBlog that this is all based on trying to keep badly written pages from breaking in newer, more standards-compliant versions of IE. While I understand it's been hard for MS to weather the storm as thousands of developers the world over discover their sites suck, that doesn't make those developers "right".

Chris says There's no easy answer, because it is impossible for us to tell whether the author wrote their content to standards or to IE's previous behavior.

But there is a way to tell! If they've included a DOCTYPE, they've declared they want to render to standards. If they did that in ignorance, it's time they started earning their money instead of letting Dreamweaver do their jobs.

Alternatively, MS can just throw them a bone and tell them how to bail out. People who didn't actually want that DOCTYPE are free to go and remove it from their pages and wear their Tag Soup badges as proudly as they like.

Or, more likely, just let them opt-in to the version target system. It'll still be less work for them than learning how to build to standards.

Yes, IE6 has created a legacy. But freezing half the world in IE7 isn't going to help move forward. It'll just keep things from progressing. People too disinterested to know what a DOCTYPE is aren't going to engage with this process. They're not going to learn anything or opt in to standards behavior on their own schedule.

once more with feeling...

If we're going to have a proprietary hack, or a new "standard" then for the love of Mike why can't we have an intentional selector hack?

Forget conditional comments or <meta> tags in every single document you maintain. Give us a legitimate version of * html to scope our tweaks to the browsers that need it. Something like ua[ie6] { } would be just dandy.

Sure, this will only suit those of us who know how to create pages that only need a few tweaks across browsers. But we've worked hard to get to that stage. Why shouldn't we get the love? :)

but basically...

Regardless of how many people support the version target idea - and regardless of just how scary-smart some of them are - right now I think it hurts the web to give bad developers a free pass like this. I think it will lead to many years of lazy developers keeping the web closed. Why bother building to standards? Why bother building for anything except IE7? They can just build in IE7, whack in a meta tag saying that's all they tested, then they can piss off back to the pub.

That's not the intention of version targets, you say? Sure, but that's how plenty of people out there will take it. The whole situation legitimises the approach of building for a restricted platform.

A cynical person might suggest that Microsoft is intentionally trying to lock the world down to IE; or try to get the other browser makers to bleed resources by trying to maintain legacy rendering engines. I have no doubt that individuals at MS do not want this result. But MS the company just might.

just make version targeting opt-in

IE8 should default to IE8, not IE7. I mean really, should I even have to say that?

So much of this situation hinges on the default behaviour. If there's a DOCTYPE and no meta tag, the browser should default to standards mode. It has received no instructions to contradict the W3C specifications, so why should it go ahead and load up a non-standards-compliant rendering engine?

Having a browser arbitrarily pick a rendering mode against the definition of the document makes a mockery of standards. Allowing a developer to specifically ask for the old rendering mode is a soft option, but it at least the document would contain an explicit instruction to override the DOCTYPE.

If version targeting became an opt-in system, for all that it'd feel like a dirty little secret it would be an acceptable tool. If version targeting remains opt-out, it's spam.

...ready or not!

But sadly it's not really something that's open to discussion. As Lachlan has already observed, Microsoft doesn’t tell you it’s going to do something of this scale unless it means it.

Microsoft is clearly going to go ahead with this idea. After all the blue monster isn't going to backflip into a higher level of standards purity. The announcement came through A List Apart and apparently they have more articles to come on the subject. Eric Meyer was enlisted to comment on the announcement. Passionate, smart people with serious NDAs were involved in the internal discussions at Microsoft and we still got this result (can you imagine the options that got rejected?).

So it's spam time.

Labels: ie8, version targeting, X-UA-Compatible