I'm somewhat confused. I'm not into the whole webdevelopment thing, but what is so terrible about all browsers sharing a common implementation of at least the basic features that pertain to the alignment, orientation and sizing etc. of elements on a page?
Browsers can still differentiate themselves through a faster JS interpreter or new fancy teleconferencing APIs all they want.
> I'm somewhat confused. I'm not into the whole webdevelopment thing, but what is so terrible about all browsers sharing a common implementation of at least the basic features that pertain to the alignment, orientation and sizing etc. of elements on a page?
If everyone shares the same underlying implementation, then standards are meaningless: The standards body can say whatever they want, but in practice all that will matter is what actually runs on the single implementation.
If there is a bug in that implementation, everyone will code around that bug. If there is more than one way to implement a feature in the standard, people will code for the way in the single implementation. And if there are extra non-standardized features in the single implementation, people will use those.
So the standard will be meaningless. Does that matter? In the short term perhaps not. But the only reason WebKit could achieve what it achieved was that there was a strong standard. IE's dominance was broken and multiple browsers existed, and WebKit could render the same pages by supporting the same standard.
It was hard to break IE's dominance, and if WebKit becomes the new single implementation, it will be similarly hard to make it possible for a new browser to show up.
Does that matter? Well, when there is a standard, you can write a better codebase that renders the same content. WebKit, like all other current browsers, is written in C++. That language is less secure and parallel processing friendly than other languages. If someone wants a better browser than WebKit by using another language, that will only be possible if there are standards for web content - otherwise, it will be a chase after WebKit specific bugs and features. Bug parity/bug-for-bug compatibility is extremely difficult to achieve, and becomes harder as the web includes more and more content. So it will be harder to break a WebKit dominance than an IE one.
> If everyone shares the same underlying implementation, then standards are meaningless: The standards body can say whatever they want, but in practice all that will matter is what actually runs on the single implementation.
How is that different from the case today? The web is moving much faster than the Standards and their inaction has lead to their dwindling importance. The W3C hasn't even ratified HTML5 yet (their hoping to do so in 2014!).
Within the time frame of the W3C discussing HTML5 Google started Chrome and has shipped 24 versions. Not only that, but they aren't waiting around for the W3C to vote and have shipped a ton of emerging tech: WebGL, WebRTC, NaCL, Web Speech, Web Intents, etc etc etc.
How is this bad? We're building stuff now instead of waiting around for a decade.
> WebGL, WebRTC, NaCL, Web Speech, Web Intents, etc etc etc.
The difference is that all these APIs, with the exception of Native Client (which is unlikely to ever take off beyond Chrome), either are standardized already or have standard drafts being worked on. Mozilla does not have go to hunting around in WebKit code to figure out how to implement them.
> have shipped a ton of emerging tech: WebGL, WebRTC, NaCL, Web Speech, Web Intents, etc etc
Except for NaCl, those are standardized technologies, and almost all have multiple implementations (generally at least Chrome and Firefox). It is easy for other browsers to implement them because there is a spec for each, and the multiple implementations of it have hashed out ambiguities and issues in the specs.
If there was just WebKit, that wouldn't be the case.
At least as far as I'm concerned, it's that that implementation is (a) written in a very unsafe language (C++); (b) is not particularly amenable to multicore CPUs without major rewriting.
Having a common implementation is extremely important, for instance a common implementation of HTML.
The problem arises with regards specifically to control and who has it. As others have mentioned if one entity has complete control then standards committees will be beholden to the controlling organization, effectively making them meaningless.
I don't think that even faster JS engines would improve overall performance of web apps significantly. DOM performance seems to be the bottleneck currently and another arms race in this area would be beneficial for the web.
Browsers can still differentiate themselves through a faster JS interpreter or new fancy teleconferencing APIs all they want.