What would be the advantages and downsides of standardizing on a single rendering engine such as WebKit?

Does having different rendering engines for Chrome/Safari, Firefox, IE, etc. really add value and stimulate innovation, or does it just lead to a lot of wasted effort and slower development?

This is like wishing for a dictatorship. It could be great if said dictator was fun and friendly, and worked to make everyone's life better. But history has shown us that this was never the case, and that all dictators were jerks.

A monopoly leads to a lack of innovation. A lack of innovation leads to proprietary solutions. Proprietary solutions lead to monopolies.

This is what happend with IE. When IE6 launched in 2001, Microsoft had a 95% market share. They stopped working on IE until IE7 in 2006. 5 years without a single (rendering) update.
And this is what happening right now on the mobile web, where Safari for iOS and Chrome for Android are really lacking behind their desktop counterparts or Firefox for Android.

Please note I said a single rendering engine, not a single browser. What's more, that rendering engine (in this case, WebKit) would be open source, which should theoretically facilitate innovation.

To me, the current situation is a little bit like train lines in Japan. Since Japanese railways are private companies, in Osaka you end up having 3-4 different companies building tracks on roughly the same itineraries, which is not efficient at all.

I believe some monopolies are necessary to enable economies of scale and increase efficiency.

An open-source monopoly might not be such a bad situation. After all even if HTML and CSS are pretty crappy languages, we're still glad we picked standards.

It's worth to note that although WebKit is an open source project, it's not without politics and balance. Take a look at the current reviewers list: trac.webkit.org You will see that the project is dominated by two major players: Apple and Google. It's possible for smaller players to contribute, but it's hard to make a major influence to the project in a short period. With a project this scale and complexity, it's already quite hard to make any groundbreaking innovation without breaking one of the major players' code.

I think arewefastyet.com is a perfect example of having more than one rendering engines stimulates innovation. Had we settled on JSCore 5 years ago, we might never see innovations like v8 and IonMonkey.

My initial argument for having a single rendering engine was going to be less cross-browser debugging, having more people dedicated on one engine would mean faster updates, faster support for the newer technologies, bug fixes would be faster etc.

But after reading some of the comments on here, I've changed my mind, although it's open-source, having just two companies dominate it seems like a terrible idea.

Just because it's open source doesn't mean your patches get in there. Sure, it's open source, but there's forks. On top of forks there's the fact that Google or Apple can choose to accept or put whatever they want in their version of WebKit. All that would happen is you'd have Google WebKit, Apple WebKit, Microsoft WebKit, etc and you'd be back where you started. Hell, even seemingly simple APIs are different in different WebKit versions. Chrome and Safari's take on the HTML5 fullscreen API is totally different for example. I literally have to sniff if it's Safari to fix issues with it.

I don't see any benefit and we shouldn't repeat the past. We should learn from our mistakes.

Let's also not forget (referring to the original tweets) that html and css are regulated by a body that is inherently different (in theory) from the ones that regulate webkit. Apple and Google benefit from the advancement of webkit, while the w3c (again, in theory) doesn't (regarding html/css).

What this means is that the standardization of webkit could be bad if those companies decided to be evil with it, but there's not really a reason for the w3c to do it with html/css, and it really is on the best interest of everyone to evolve it in the best way possible.

That said, the w3c is not without it’s share of criticisms in this regard. en.wikipedia.org