[giancarlostoro]

The reason IE used to be behind was that at one point Microsoft decided to only publish features which had been standardized, which sounds nice, but the rest of the web wants to be on the bleeding edge with new features.

[gsnedders]

I don't think anybody really believed that. Maybe some manager. Everyone I knew on the IE team at the time wanted to be on the bleeding edge, but they were up against it catching up years of no work on IE—the "Recommendations only" line was as far as one could tell something made up by marketing to justify the fact they were so far behind and what they were implementing as a result. (It's also laughable—for a specification to become a REC at the W3C, post-2001, one practically needs two implementations. Practically it's saying "we're always behind two others!")

[giancarlostoro]

I can't remember where I read it, if on HN or elsewhere, but that was what I heard, it sounded plausible enough. I guess it was likely another excuse. At the very least they're aiming towards the bleeding 'Edge'.

[gsnedders]

It originally comes from the IE Blog in, I think, the IE7 release cycle (my memory of the date could be wrong; it's certainly a while ago!). At the time almost everything there was pretty censored and overly-dressed-up.

[adrianba]

When the time between releases is measured in years you better be sure that new features are somewhat stable before you ship, especially when customers take a long time to upgrade because of the support you offer them. We always have to make a judgement about when things are ready enough but it is much easier now than it was back then. Sometimes we guess wrong but with faster release cycles it is more possible to fix things so we don't have to be _quite_ so conservative. We can also ship things behind flags now (which is how we are experimenting with modules) and we can include things in Insider builds so you can try them without waiting for a full release.

[gsnedders]

To be fair, if I'm not mistaken, those comments dated from a time when most of your efforts were put into fixing ancient bugs and implementing CSS 2.1 and the like (which, uh, was years away from being a REC), rather than anything particularly volatile (well, ignoring things like display: run-in which were ultimately dropped at CR). From everything I heard and the order that was chosen, it ultimately seemed like what was probably the sensible route to catching up, where the order was ultimately aiming at getting an increasing baseline working, and spec stability was just one of many metrics used. I was definitely told that the line was mostly trying to spin things positively, though. Certainly there were plenty of things that weren't implemented as "unstable" were all but done, such as the majority of Selectors Level 3, of which 8/9 only supported a small subset. (Heck, were you even on the IE team that far back?)

There again, I could also poke fun at Flexbox and http://w3cmemes.tumblr.com/post/26637660418/believe-it-or-no..., given we all thought it was stable. :)

Perhaps the "bleeding edge" is a touch too extreme for what ultimately was wanted, but certainly something much closer to other browsers than where IE had been before.