Balancing customer needs against forward motion: IE8

I’ve watched the debate with interest but not posted anything until now. The news of Internet Explorer 8 keeping it’s new rendering engine to itself unless you tell it otherwise caused a strong outpouring of opinion around the web.

I must admit, my initial reaction mirrored that of many others – that it’s just plain wrong (although my good friend Nick’s posting took some concentration to ascertain his thoughts!). Why hold back on improved support for CSS; why hide the fact that the engine now passes ACID2?

Then I thought for a bit, and tempered my view with the knowledge that the coming of IE7 caused much angst amongst companies because what worked in IE6 failed in IE7. Perhaps an additional switch to toggle this new rendering marvel on and off was a good idea. But surely, you’d want it to default to the shiny new engine… wouldn’t you?

I have now changed my mind. Why? Because at a recent event, after presenting for a while on upcoming Microsoft technologies including IE8, one of the attendees came up to chat. He worked for major financial organisation and was pressing for more information on the new browser. Would it really keep the rendering behaviour as previous versions by default? If so, that was great! Why? Because he was faced with many different divisions within his organisation, all of which had web-based applications and all of which cried foul over IE7 breaking their systems. This was still giving headaches with the rollout of IE7, and he was very keen on being able to convince his stakeholders that if they would just shoulder the pain of the version 6 to 7 transition, he could guarantee that there would be no more pain with future upgrades. This would mean that the IT department could push out the newer, more secure browsers without the battle.

There are many large organisations like that around the globe. Their strength in terms of buying power and opinion is what has led Microsoft to the solution we now see with IE8. Whilst purists may hate it, the truth is that IT Managers around the planet are smiling.

Which would you rather see – massive companies sticking to insecure browsers on their desktops because the investment in internal systems would be too large to allow movement, or a steady push forward in versions safe in the knowledge that there will be zero impact on existing investment?

If you’ve managed to avoid this issue entirely thus far, the ever thoughtful and tactful Eric Meyer has some excellent posts discussing the matter.

3 Replies to “Balancing customer needs against forward motion: IE8”

  1. Your new tempered thoughtful view is skewed by only thinking about WHAT happened, not WHY it happened. IE7 broke websites because it was still a browser with a host of rendering bugs. The IE team fixed SOME, but not ALL of the bugs, while at the same time removing the parsing bugs, that developers used to get around the rendering issues of IE6. Some of these rendering issues remained in IE7, and there was no clear way, early on, to fix them. Since IE7 was not as compliant as other browsers some bugs remained, with no way to fix them. If Ie7 had been released and was as standards compliant as the other available browsers (or better!), nothing would have broke. IE7 could have followed the standards compliant code that all the other browsers followed. But alas, that didn’t happen. The IE team released ANOTHER buggy browser into the wild, and when sites broke, they asked developers to change the way they code (conditional comments). They didn’t say they’d fix they’re browser…they asked the DEVELOPERS to change their code! Now they are doing it again. Instead of ensuring that IE8 is the most standards compliant browser on the market, and ensuring that all rendering bugs have been fixed, they are going to release another browser (potentially still buggy but better), and instead of dealing with the backlash of releasing ANOTHER buggy browser, they are AGAIN asking developers to change the way they code. This is a frightened IE Team. They’ve been burned. They may be under a mandate to get another version out the door, or they may have other reasons for doing this, but by NOT developing the most standards compliant browser available, MS and the IE team are only showing that they cannot compete in the browser market. And their marketshare downslide will continue.

  2. That’s a contentious point of view, Michael. Whe IE7 was released a great many rednering bugs were fixed and the rendering behaviour of IE7 was brought into line with other browsers, which is why hacks (for that is what they were) such as * html ceased to function. The problem is not that IE7 is buggy, at least in terms of the reistance to deployment in the corporate environment. Rather it is the fact that it fixes the extremely errant behaviour of IE6 without giving any way to get that behaviour back. Many web applications have the correct doctype to trigger standards mode but actually rely on the odd way IE6 renders and therefore fail in anythng else. Now, this situation is not the fault of IE7, but rather IE6. The IE team now is a very different beast to the one that developed IE6. They really do want to build the best browser. IE7 was feature capped because of time and the complexity of doing some of the things they wanted to because of the way the rendering engine worked. IE8 has resulted in a great many changes under the hood and is better for it. Be careful not to confuse anti-Microsoftism with genuine criticism. You make some valid points but tey are mostly lost in the vitriol. Big corporations that invest millions in systems don’t care about purism – they want to be able to upgrade systems with the least amount of investment and effort, and they are the people that have made Microsoft the organisation it is today.

  3. It’s not about purism and there was no vitriol in my post. Yes, as even “I” stated, IE7 fixed some bugs, but not all. And that was the problem. The *html hack (and other parsing bug hacks) failed in those instances where IE7 STILL didn’t follow the standard and didn’t display properly. If it did, there wouldn’t have been a problem with IE7 ignoring all the parsing bugs used as hacks. Firefox, Opera, Safari all ignore these same parsing bugs and follow the correctly coded CSS and display as expected. IE7 was a better browser than IE6 – agreed. Was it completely free of the rendering bugs that plagued IE6? No it was not. Hence the problem. Yes, there were some developers ONLY developing for IE, and perhaps they didn’t have appropriate fallback CSS for compliant browsers, but I would hesitate and ask, then why would they be using the *html hack? If all I’m developing for is IE why do I need parsing bug hacks? The parsing bug hacks were mainly used by knowledgeable developers to overcome the failings of IE5/6, while still supplying correct CSS to all other browsers. So when IE7 still couldn’t follow the proper CSS, and was no longer able to be hacked by using parsing bugs, it failed to render properly. In effect, IE7 broke websites. A standards compliant IE7 would have been a boon to developers everywhere, and would likely have broken very few websites. And of those sites that might have been rendered incorrectly, all could have been blamed on the developer. But the IE Team seem to want to blame the developers for the mess that they are in now, AND they want the developers to help clean it up. I grant you that the problems caused by IE6 may not be the current IE Team’s fault (and I understand that they are working towards compliance), but they have been charged with cleaning it up, not me. They should NOT release IE8 until it is at least as compliant as its peers (if not more so). And this stupid META tag is only being forced upon us out of the IE Team’s fear of getting blasted again. A fully compliant (or as good as its peers) IE8 wouldn’t break a thing, it would be a help and a breath of fresh air. Anything less is a waste of time.

Leave a Reply

Your email address will not be published. Required fields are marked *