But we already see problems today from WebKit's dominance on mobile. Non-WebKit browsers have trouble rendering the mobile web which was designed with only WebKit in mind. It got so bad that Opera just gave up and adopted Chromium (not even just WebKit).
The remaining non-WebKit browsers, IE and Firefox, are left with an even bigger problem and it is even harder for them to disrupt the WebKit mobile web. And it would be even harder for a completely new engine.
So general arguments about cycles and all that might sound good, but we already see the damaging effects of WebKit monoculture (you argue it's a loaded word, but it fits).
Yes, over-use of vendor prefixes in CSS and other browser-specific features is bad. But that's an authoring issue as much as it's a WebKit issue. Having -moz-, -o-, and -webkit-* plus JavaScript shims to hide the differences in multiple browsers is a great argument for standards, but not a great argument for a larger variety of independently developed and maintained web rendering engines.
Of course, as I already agreed before. There are benefits to centralization.
It's a question of degree, not absolutes. As I said, 10 or 100 might be too many rendering engines, while 1 is too few. 2 or 3 seems, to me, to be optimal, but again this is a matter of degree so others may prefer a little more or less.
> Yes, over-use of vendor prefixes in CSS and other browser-specific features is bad. But that's an authoring issue as much as it's a WebKit issue. Having -moz-, -o-, and -webkit-* plus JavaScript shims to hide the differences in multiple browsers is a great argument for standards, but not a great argument for a larger variety of independently developed and maintained web rendering engines.
Agreed, this is not just a WebKit monoculture issue - plenty of other problems in that area as well, as you say.
"Monoculture" is a loaded word. The differing priorities that might manifest in completely separate web rendering engines still have plenty of room to manifest when multiple big players are working on WebKit, with nothing stopping any of them from forking if the differences get too large.
(And anyway, Gecko does still exist, after all…)