[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.