Yes, the differences suck when you are dealing with CSS incompatibility problems, but when you look at the big picture it remains vitally important.
End users who chose not to use Microsoft OS are unlikely to choose Microsoft browser, especially when they have better, native browsers available out of the box.
Porting IE9 to other platforms is a lot of work for a "nice to have" feature for web developers. Such effort is better spent on making IE suck less on its only platform.
Spoon.net goes some of the way, but IE9 won't work on my XP box. So I'll need to reinstall Windows 7. Which means Synergy will stop working again. Blah.
For major releases, like IE9, they could have taken another approach. Like, for example, abstracted many components (css/html engine, js engine, plugins framework, etc.) from the underlying OS and then port just the bridge between those components and underlying OS. It's not easy and there're always many quirks, but we're talking about Microsoft, after all.
Just quick'n'dirty abstraction layer would result in horrible experience that end users don't want to use: slow, not integrated with OS well enough. There are still Mac users who stick with Safari, because Firefox isn't native enough! Opera is still substandard on OS X and Linux compared to Windows, and they've been working on portable layer for a decade.
Such poor browser wouldn't even be good solution for developers, as your OS wouldn't get same fonts with same metrics and rendering as Windows. With abstraction layer you wouldn't get representative performance. You could even get different rendering and behaviour caused by differences in real DX vs emulation, different media frameworks/codecs/plugins, etc.
Without whole OS it's just not "bug-compatible" enough, and bugs are the only thing you need IE for.
2) Firefox & Opera are quite good on all major OSes. Of course Linux/OSX versions may not be on the same level as Windows versions (I really don't know, haven't made any tests recently), but they're still pretty good.
3) I'm not advocating that Microsoft makes feature-by-feature compatible ports (for example, activex comes to my mind), but I would like to see the basic stuff, namely layout and js engine. And that would be much easier if they followed what I've said in 1) paragraph.
4) And no, I don't need IE only to test for bugs. I would happily switch if they made a better browser than Chrome which is my current default browser (Firefox used to be my default browser, but I switched earlier this year).
I would rather parallel IE to various document viewers (.doc viewer, for example) which Microsoft provides free of charge. And which, sadly, also aren't available for other platforms.
And the idea (by extension) that any app that works with standards-based content should be cross-platform is barmy.
They're trying to sell Windows licenses. They have no reason to sweat to make a hardware accelerated IE work on OSX, I'm baffled that people think it'd make sense for them.
So by releasing it on Windows they can (a) gain marketshare so it's taken more seriously, and (b) make sure developers who use Windows will test with it.
As for why they didn't just use Gecko (Firefox's rendering engine), Apple also wants to be certain that websites look great on the iPhone/iPad. And my understanding is that Gecko is an absolute monster to get working well on mobile devices. Plus by having their own rendering engine they get to be certain that there'll be no problems adding features needed for touch-based apps to it.
>>So by releasing it on Windows they can (a) gain marketshare so it's taken more seriously, and (b) make sure developers who use Windows will test with it.
Exactly, and in my opinion, Microsoft should follow this logic for the same reasons.
No-one is going to say "I'm not setting up a Windows machine just to test a niche browser like IE. Screw that".
Tasman supported — in it's own buggy way — properties like display:inline-table that Trident didn't support until IE8.
What do you mean by this? Am genuinely curious, because I've always raged at the lack of browser standardization.
* Mono-cultures are bad security-wise, it's harder to target multiple platforms with different vulnerabilities then one platform (which is one of the reasons IE had such a bad reputation for a long time)
* It prevent people from coding to specific browser bugs/quirks. When there are a lot of platforms it is easier to code to standards (if they are consistently implemented across browsers) then specific platforms. Theoretically at least..
a) Force specifications to written carefully, and exercise the edge cases. It's important the browser authors do this because otherwise web pages authors are forced to find these edge cases (as happened in the IE6 & early IE7 days, when MS had so little competition that they could afford to be careless)
b) Slow down change the core technologies. This sounds like a stupid "advantage", but I'd argue that it has enabled the core HTML/CSS/Javascript trinity to become so well established that any new platform is forced to support it. Ironically, that also means new platforms become viable simply by supporting the web platform.
c) Allow multiple paths for experimenting on new technologies.