> I'd say we already see the benefits of having so many people work together on WebKit.
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.
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.