>The rounded corners issue I talked about wasn't a mark-up issue, it was a basic rendering bug. It took several attempts to fix, over a period of months.

You're going to have to point to a bug report, because I don't know what you're referring to. Webkit had poor rendering of border-radius with a varying radius (the edge would be discontinuous), it had an issue where box-shadow would break with rounded corners, and it had an issue where the element background color would show show up slightly outside of any border color. All were bugs, but none were regressions, as far as I know.

> Moreover, as long as Google and Mozilla keep releasing "experimental" CSS features with syntax and capabilities that aren't yet standardised, they are on a path where the only options are supporting alternative, non-standard functionality indefinitely or breaking existing web sites that were written using the experimental features at some unspecified point in the future. That's starting to sound like IE vs. Netscape all over again.

That's just the reality of web development. We should have had a stable foundation for content, styling, and scripting for a decade now, but the standards are now finally being advanced at a decent rate. In order to do this, we need both experimental and working implementations. You'll note that Opera has -o- prefixed css properties and Microsoft has -ms- prefixed properties. That's how it works...implementations are built while specs are being written, but nothing is standardized until interoperable implementations exist. For more: http://www.alistapart.com/articles/prefix-or-posthack/

> Google dropped support for H.264 in the Chrome development builds some time ago, and the change is scheduled to be pushed to users of the official release imminently.

You're making me second guess myself, but AFAIK, they didn't and it isn't. The announcement was that they will sometime soon, but that was to give people time to switch. I was just able to play h264 videos in dev and canary builds on my windows and mac machines.

> If you've got a full ad-blocker for Chrome, I'd love a link. I've never found one anything close to as capable as things like Ad Block Pro in Firefox.

There's "AdBlock" and "AdBlock Plus." I think the second is made by the same guy that makes AdBlock Pro, but I don't really keep up with it. I have click to play enabled for plugins and that'sufficient blocking of annoying things for me.

No idea what's up with applets, but the irony of bringing up the font rendering change in Firefox 4 is that Firefox 4 was a long in development, monolithic release. Whether the style of font rendering is a regression or not is up for debate (there were also tradeoffs that had to be made working with GDI and directx), but really it's just a change people don't like, which has nothing to do with changes in release rates. UI and UX regressions happen all the time; that's why it's great to have a choices.

Finally, there are two points here:
1) Only use experimental features if you're willing to be a participant in the process, even if that just means keeping up with implementation changes
2) Point (1) would only prevent quick release cycles from advancing the state of the web if implementations didn't converge and specs weren't finalized at a rate faster that e.g. IE's release rate. They do, and since HTML5 and CSS3 have moved to a more modular spec format (rather than the decade long process for CSS 2.1), we are going to see the effect of a lagging IE10 over the next two years.

All that said, legacy browsers will have a worse effect, so it's really not that bad. I'm not saying that Microsoft is bad (although required browser updates after, say, 3 years with only an opt-out option would make me a happier camper), I just think that the faster release cycles are better for the web (for developers, users, and advancing web standards), and that the growing pains we've experienced have actually been quite minor.