shaver

There’s going to be a lot of talk this week coming out of MIX, about IE8. Early reports are interesting, if still often hidden behind “NOT PUBLISHED” links on MSDN, but the most interesting thing I’ve seen yet is their change in IE8 rendering mode default. The specific change is a good one, but even more than that I think it’s very promising as a matter of process.

The original decision to make IE8 default to matching IE7′s legacy rendering mode was made in secret, secret even from many of the web experts in the organizations linked to from Dean’s post. Once the conversation was opened to input from the rest of the world’s experts on web content compatibility, they were able to get to a much better decision, and happily that’s reflected in the updated plans for IE8. I hope that this case helps Microsoft understand more generally that significant web-compatibility decisions are too important to be left to closed groups: the web is simply too big, with too many stakeholders, for that to be a workable path to success. (Not that simply operating under “a standards body” is sure to avoid such secrecy, as they can also have related damage, but they at least tend to have more diverse viewpoints, which is a half-measure of some value.)

I was also heartened that they were able to make such a change after announcing it. We’ve all heard before that the IE team wasn’t able to talk about their plans until they were very certain, because people build businesses on those plans and will be harmed are made after an announcement. The conspicuous lack of bankruptcies attributable to WinFS being dropped from Vista aside, that they were able to listen to “global” feedback and make a significant change based on that feedback gives me hope that a new, more open process may be beginning here. Bravo and thanks to Microsoft for listening genuinely and making a change that I think will have a very positive effect on standards-based content on the web.

Some of the items listed in the “IE8 Readiness Toolkit” look pretty interesting, and in at least one case (the “XDomainRequest” API) seem pretty close to the subjects of some recent discussions in standards groups and various open projects about solving similar problems. I’m not sure if Microsoft proposed their API or semantics to that group, or shared the design thinking that went into their choices, but I’m permitting myself to hope anew!

(In light of my previous post about compatibility liability, I was also very interested to see this titbit:

[...]we do not believe any current legal requirements would dictate which rendering mode a browser must use[...]

It’s much more likely that they’re referencing the Opera suit than that they’re talking about Microsoft representatives’ previous claims of lawsuit risk stemming from changes in new product versions, but it made me smile nonetheless.)

There are a lot of good posts describing problems with IE8′s version selector feature, so I’ll just leave you to read those for some insight into problems that it creates (and how it pushes the IE-compatibility burden off Microsoft and onto other competing browsers in a very impressive way).

They’ve announced what they’re doing in IE8, and as we know from previous conversations with Chris Wilson, they don’t announce until they’re sure:

[W]e have to be very, very careful to be 100% confident when we announce things like “that’s exactly what we’re doing,” or “that’s the date that we are aiming for.” When we don’t, we tend to get a lot of people upset with us, of course, but it’s not just them being upset with us; it’s actually, it can be damaging their business model if they bet on us releasing something in a given timeframe, or bet on us releasing a given feature, and we don’t ship it

So we’re going to see X-UA-Compatible in IE8, with very high likelihood. It’s positioned as something that other browsers could use — if they wanted to ship multiple rendering engines to make download size a further impediment to competing with Microsoft, say, or totally lock themselves out of the mobile market — and the introductory document has examples like “FF=3″ in it.

And we know from the ES4 discussions that Chris believes in different groups working out proposals together, which is why they didn’t make a specific counter-proposal to the one put forward by TG1, after all:

It’s been pointed out that we haven’t made an alternate proposal – well, I’d kinda hoped we could work it out together. “Open to input” should be the way of the web, should it not?

So that makes me wonder: why were no other browser developers involved in this discussion? I guess that would ruin the protective cloak of secrecy, though I don’t know how else people would work things out together. (If Microsoft knows, they’re not telling, but I guess that shouldn’t be surprising?)

The naming of the header is sort of generic, but unless the next big announcement on the IEBlog is the release of IE8′s source code, “render this like IE8 would” really only helps Microsoft, and I think it works against the promising trend of convergence on open standards.