Yeah. More frequently posting on my blog != once a year. I get it. More on that later.
Since I mostly share on twitter, I usually don’t get around to writing out longer posts – it takes time to be interesting and sound coherent when you’re not restricted to 140 characters. But sometimes I want to say something that I just can’t sanely fit into 140-character blocks, no matter how hard I try.
One thing that cropped up in a conversation yesterday was “what happened to IE after IE6″. I was a little aghast at the wild rumors of engineers fleeing the team due to political issues, since that wasn’t what happened, and since I’ve said this publicly before (e.g. my keynote at the Ajax Experience in Boston in 2006), I figured I might as well reiterate.
As we were finishing up the product cycle of IE6, the engineering team was still really excited by the technology and innovation we’d been doing in the web platform. (Newbie, before you go bothering entering random IE-bashing in that comment box, go find someone who was around on the web in 2000. IE6 *WAS* the best. Well, okay, maybe IE5 Mac.) However, we’d been seeing very little adoption of the rich client platform we’d built; it was hard to build rich, sexy applications, and Flash was starting to take off. Outlook Web Access was the “biggest” rich web app around. The dot-com bubble was bursting. There were a few experiments with “Web OS” – that is, building a desktop on top of the web platform – but they were slow and lacked functionality (probably because they also lacked a business model). Finally, we were also getting mired in backwards compatibility – it’s all very well to say you should fix standards bugs, but we kept breaking current pages. People get upset about that – both developers and customers. (As an aside, I’m a big fan of the IE compatibility mode solution we implemented in IE8; I only wish we’d done it in IE7.)
And, of course, we were pretty far ahead of the competitor’s released product at that point, and sadly, Microsoft does seem to work best with strong competition motivating it.
At the same time, Microsoft really needed to invigorate the Windows API. We’d learned a lot of lessons from our experience with the web platform – e.g. that markup is a great tool for developers to use alongside code, and that managed code languages are easier in many cases than C++ – and we wanted to bring those tools to building Windows applications. This led us to start working on the platform re-think that eventually became WPF/XAML/.NET3.0 – and that’s what most of us moved over to work on in that timeframe.
On top of that, that time period was also when Microsoft (and the broader industry, but Microsoft in particular) started getting hammered with security issues, since hackers started realizing they could get PAID for finding ways to insert software into users’ machines. This took a tremendous effort to address, and a sea change in writing secure code; it was quite impressive to see the response to that challenge internally, but that’s a story for a different day.
So, unfortunately, this was a perfect storm that led to the “IE plateau”. Happy it’s over. Glad to see that the web platform isn’t in too much danger of becoming homogenous again any time soon.
-C

kL goes on to say “We can already break law/leech bandwidth by (hot)linking copyrighted images, copyrighted MP3s, etc. Fonts are no different and DRM won’t help here a bit.” You’re quite right, kL, that this will not prevent lawbreaking. However, it DOES give a way to LEGALLY use commercial fonts (those that allow embedding, anyway); directly posting the .TTF or .OTF file on your web server will violate your license for commercial fonts (okay, perhaps there are some fonts out there somewhere that allow this in their EULA, but I’ve never found one.) Linking to raw .TTF/.OTF files WILL, in fact, encourage font piracy, as vastly more commercial fonts will be placed (unadorned) online, where they can be easily pilfered.
Perhaps I should ask Apple how happy they are if I post their fonts on a web server?
[A side note to the inimitable Joe Clark: I'm not actually the head of the browser team. Just some guy with a perverse passion for doing this. And it wasn't just "clean this up and make this validate" - it was more like "Bill, you can't ship this crap that Publisher spit out. Let me show you how you're SUPPOSED to code..." followed by one late night, and then I had to drop it to focus on something else. I'm still hoping to finish the clean recode this week.]
By the way, I don’t particularly care that Acid3 uses direct linking to TTF files; that just goes to show that it is duplicitous to make a “standards test” that tests things that are only Working Drafts of low priority to the working group (as per the CSS WG’s table of priorities). Trying to circumvent the standards process by throwing whatever test you want into a so-called standards test won’t make us implement anything faster.
I’ve been clear on this to the CSS WG, so I suppose I should be here too – we (Microsoft) should NOT support direct TTF/OTF embedding, unless 1) there is some check that the font intended that use to be allowed, which I don’t think there currently is (as it needs to refer to the license agreement), AND 2) other browsers also implement a system that actually ENABLES commercial fonts – those that are allowed to be embedded, but cannot be legally placed directly on a server – to be used.As I also stated to the WG – I don’t personally even care that much if that system is EOT as it is today; I’d be okay with building a new system if the details of EOT were a sticking point. But I want to use commercial fonts on my web pages, I want that to work interoperably across browsers, and I want to not have to violate my license for the fonts I use (and get sued for it) in order to make that happen. A solution that only works for freeware fonts is not a solution.
Is that too much to ask?