Comment by michael_miller | Hacker News Reader

Comment by michael_miller | Hacker News Reader

Parent Full thread

The reason that WebKit is different from Trident (IE's rendering engine) is that WebKit is open source. If a company comes along and says "hey, it would be really cool if we had an NFC API for the web", they're not stuck in a rut. They can hire some developers and submit a patch. So I'm not worried about lack of feature development.

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.

You're working on the assumption that one of the biggest fallacies of open source software, which is that anyone can make any change they like and it'll be rolled back into the main branch.

Just because it's open source doesn't mean that the gatekeepers of WebKit will accept your patch.

True enough, but it's always possible to fork the project, given it's GPL status -- heck, this is what Apple did to the KHTML project.

Webkit gatekeepers may not accept your patch but they can't stop you from forking it. If you maintain a fork and you're feature becomes popular then eventually your fork will get merged into mainline webkit. If it doesn't become popular then it probably didn't need to get merged into webkit. This is how open source works and it's a good thing. It allows ideas to compete.

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.

Reply on news.ycombinator.com