4 ms·
Not the OP, but from what I remember: * Gecko code was a mess and difficult to separate, integrate. KHTML was cleaner, and already intended to be pluggable, ju
by psadauskas 16y ago
Not the OP, but from what I remember:
* Gecko code was a mess and difficult to separate, integrate. KHTML was cleaner, and already intended to be pluggable, just missing some edge-case features.
* KDE/KHTML devs had to fight to get Webkit's source opened, and when they finally did, all they got was code dumps that were impossible to integrate back into KHTML
It's gotten a lot better, and Apple's Webkit devs have become much more open, but from what I understand, it was a huge ordeal to get them to abide by KHTML's GPL.
- tumult 16y agoWebCore (the actual rendering fundamentals itself) was open source before WebKit (the bigger chunk of code that makes up more of a browser's features). When code was released back to KHTML, it came in big chunks with large changes because WebKit development was being taken in a different direction and at a much higher speed than KHTML. Therefore backporting was extremely difficult, and it seems like the WebKit people were not too eager to spend time documenting all of their changes back against existing KHTML code, so they just dumped out big patches and diffs without much commenting. Some features were backported, but you can see today that WebKit is farther ahead than the KHTML fork, and receives a lot more attention.
- philwelch 16y agoPeople criticized Apple for being bad open source contributors, but I don't blame them for choosing to fork over contributing to a project they didn't control. I always thought the "right to fork" was sacred.