I don't see why WebKit-everywhere would be different. If they become lazy and slow at implementing features, what's going to make them get their act together other than a competing engine that's beating them in some regard?
The thing I'd be most worried about with a single engine is lack of compliance with the standard. If multiple people are implementing the standard independently, there are bound to be some differences (for example, if an SVG line is rendered at 0px, with a 1px stroke width and crispEdges, do you snap to [-1px, 0px], or [0px, 1px]?) People run into these issues in practice, and report them; it causes clarifications in the standard to be made, and ensures there is an accepted standard of behavior for pages. This ensures we don't end up in a situation like Ruby, where Specs ran on the official compiler dictate language rules. It means that WebKit is allowed to change its implementation details without anyone crying foul when the maintainers change undefined behavior.
Just because it's open source doesn't mean that the gatekeepers of WebKit will accept your patch.
And while we are on the subject it seems like people are talking past each other in this debate.
1a. Web standards are good because they provide a baseline of combatibility for browsers.
1b. Webkit forks on all browsers could be good because it would provide a baseline of compatibility for all browsers.
2a. Web standards could be good because they prevent any one browser from setting defacto proprietary standards that lock other browsers out of the market.
2b. Webkit on all browsers could be good because it would prevent any browser from setting defacto proprietary standards that lock other browsers out of the market.
3a. Having webkit on all browsers would hurt standards by becoming a defacto standard providing a baseline of compatibility between browsers and still allowing competition.
3b. Having webkit on all browsers would provide a real baseline of compatibility between browsers while still allowing competition.
It's a little bit funny to watch actually.
You don't think it had anything to do with the introduction of Safari and Webkit, more than a year earlier?
Also, the last version of Internet Explorer for Mac was v5.2, which by 2004 was getting pretty long in the tooth. Many Mac users had already switched from IE to other browsers by the time Firefox was released (let alone when it was halfway decent).
Safari was utterly irrelevant until the late 2000s, where it only gained relevance through the iOS devices. It did nothing to spur movement. Further from a history perspective, while Safari might have preceded the coining of the Firefox brand, Firefox was an offshoot of the Mozilla Suite (effectively splitting the browser out of the suite) with a history going back to 1998.
This comment I felt gave a good practical example of the more handwavey 'competition is good' argument
"Doing this would mean being forever stuck in single-threaded land for rendering (e.g. nothing like Mozilla's Servo project could ever happen).
People have tried to parallelize WebKit and failed: too entangled, too much code making too many assumptions... Parallelism is one of those things that's just incredibly hard to bolt on after the fact.
So if you want browsers to never really scale well to large number of cores, by all means try to get them to all switch to WebKit."
Unfortunately, due to memory limitations of some of these devices, they don't really score well on automated compliance tests as "nice-to-have" features are trimmed in an effort to get a workable browser on constrained devices. Have a look at http://console.maban.co.uk/ about the capabilities of these devices. Remember, there are more game consoles and handhelds than iphones and Android device.
Surely we've learned from IE6 why a defacto standard is worse than an open and implementable standard?
Monoculture is a terrible price to pay. Don't forget South Korea's 99%+ IE6 dominance. http://blog.mozilla.org/gen/2012/11/15/2012-update-to-the-20... -- such a lock-in that it becomes a political topic: http://blogs.wsj.com/korearealtime/2012/11/13/ahn-pledges-to...
2. If people don't code to the standards, it's much more difficult to make new and better browser engines.
1, expanded: All browsers have quirks, or bug, or specific ways of handling ambiguous situations. IE6 has more than most, but even modern browsers do have their edge cases and unsupported features and whatnot. If there's only one browser, people will code to the quirks, not the browser. Historically, the single largest category of implementation-dependent behavior that people rely on is how an implementation handles erroneous input. That's why malformed HTML is now standardized.
No, not you of course, but all those other web developers. Look, standards are nice, but to many developers (especially hobbyists), and to most suits, it's just a bunch of hot air. And the hard part is, they're right, at least in the short term. Coding to standards costs time, and coding to browsers produces a pixel-perfect functional site.
Multiple, disagreeing browsers are what make standards practical. Coding to standards is a best-practice, low-cost way of dealing with the real problem of divergent browser implementations. If that problem becomes theoretical, but the cost does not, then the sensible path is to code write pages that work in Webkit, standards be damned.
2, expanded: The more that existing code relies in the quirks of one implementation, the harder it is for a new implementation to arise. The surface area of features they have to match is expanded. Furthermore, these new "features" are more constraining to match because they are undesigned, not always consistent, and often closer to the metal.
Not only does this make it harder to write a new engine, it constrains the ways in which new engines can be better. The easiest example is how having to match another implementation's order-of-evaluation can limit the benefits of concurrency.
So the sum of this is that Webkit wins now, it will be incredibly difficult to get anything better than Webkit in the future (note that this applies equally to forks of Webkit--they're still limited in how much they can differ). Not that Webkit's bad or anything, but I think it's myopic to say that we won't ever want anything more.
Servo, of course, is right now the most concrete example of something that we might want in the future, with its promise of a fundamentally concurrent architecture. But even aside from that, the future has a way of surprising us, and I wouldn't like the be stuck with outdated tech in 2018 because webdevs in 2013 got a bee in their bonnet about webkit vs gecko.
To anyone who says "you can fork it": If you aren't using the same features as everyone else, how is the situation then different to what we have now?
He is also assuming that because every major browser is using the same engine, everyone will suddenly magically agree with one another on how to do stuff. Chrome and Safari uses different versions of WebKit, and trust me, it won't be long before Opera will use its own version of WebKit as well.
What I'm trying to say is that while it is much easier than it was to create a branch and merge all or some of the modifications back into master, the concept of a fork, where development diverges because different parties want to do different things with the project, which can't easily coexist in the same codebase, is still relevant.
So it's as fragmented as on the desktop.
> It seems a smidgen complex,
The thing about Rust is that it seems that way, but that's because things that are library features in other languages are language features in Rust. For example, C++ has one kind of pointer. Unless you count smart_ptr<> and friends, in which case it has just as many as Rust does.
That's a tentative "final" though. No guarantees until 1.0.
For more information, I would recommend to read the article from Dan Geer about diversity and security - Monopoly Considered Harmful:
Nothing could cause such pain without a lot of hard work.
The web's strongest feature is that it's not tied to one particular implementation: that's why it's been able to grow, change, and sustain itself for so long.
In an ideal world the split would be even throughout all major browsers. I feel uneasy seeing Chrome so high. Even makes me a bit melancholic to see Firefox at a measly 17%. (again: for MY websites)
What? There top 5 browsers are IE, Firefox, Chrome, Safari and Opera. Chrome and Safari already use WebKit, so how would Opera moving to WebKit be "an Opera first"?
I also doubt that Microsoft will move after heavily investing in IE9 and IE10 standard compliance (apart from that it wouldn't be MS style).
And basically that's end of "everyone should move" topic. The other top browser apart from Firefox and IE already are Webkit (or will become, as Opera announced).