Losing Mac IE 6

You may be taken to celebration. Perhaps you stopped using Mac IE long ago (or, like me, never used it much in the first place). You may even view this as a rare instance of Microsoft "losing", something to hold up in triumph.

I can assure you everyone loses here.

• HTML authors lose because there will be one less web browser to test your code against. Mac IE has routinely enlightened me to where edge-case HTML code will fail. I write better code because of it.
• HTML authors and Users lose because Mac IE5 is very standards-compliant (by then-current standards). More standards-compliant than Safari, to be sure.
• Microsoft and Users lose because the smart guys who were working on the next-gen Mac IE will never get to ship their work.
• Users lose because there will be less competition in the browser market. You may think we have too many browsers on Mac OS X anyway. One browser out of nine goes away¹. But I care less about the number of clients, than I care about the number of rendering engines. And that number, along with OmniWeb moving to WebKit, goes from seven² to five.

  Even when Apple publishes WebKit, while the number of clients will likely increase, the number of rendering engines will remain constant. Largely, I'm concerned the rendering engine market will only end up supporting a Gecko/KHTML duopoly.

• Apple & the KHTML team loses because Mac IE presented another example on the inevitable tradeoffs of rendering engine design, and another reference point to compare their rendering against.
• Mac programmers lose because Apple has less pressure to publish the undocumented APIs Safari uses to great advantage. And yes, Safari does use at least one undocumented API -- Microsoft is telling the truth here.
• Mac users lose because clueless webmasters who say their site is "IE only" will now say "Wintel only", once Mac IE goes away. In reality, they were quick to dismiss Macs anyway, but at least it was something.

The only real upside is a reduction of confusion in the browser marketplace (slight) and another rendering engine (with its own unique set of bugs and work-arounds) eventually won't need to be supported.

¹ Current Mac OS X browsers: Camino, Firebird, iCab, IE5, Lynx, Mozilla, OmniWeb, Opera and Safari.

² Current Mac OS X rendering engines: Gecko, iCab, KHTML (Safari/WebKit), Lynx, OmniWeb, Opera and Tailsman Tasman [thanks, Ned!] (Mac IE5). Pathetically weak engines such as Carbon's HTMLRendering and Cocoa's NSTextView specifically not mentioned, as they unleash unspeakable rage.

Update: Chris Kaminski and Mark Gardner remind me that Tasman lives on in MSN for Mac OS X. Well, kind-of. It turns out Mac MSN actually uses a variant of the rendering engine set to ship in Mac IE6. This engine has better standards support, exceptional ligature support, draws aqua buttons where possible, is generally faster and stomps a number of bugs. The kind-of qualifier stems from the fact that chunks of Tasman live on in Mac MSN. Case in point: Mac MSN will draw standard Aqua buttons unless you use a CSS style that Mac OS X can't draw (for example, setting a border). Then, it will fallback on Tasman's Platinum-style button drawing code, which does support such styles.

Sunday, June 15, 2003
12:00 AM