4 ms·

it would be more helpful if you tell us how you remember it

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 ago
  WebCore (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 ago
    People 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.
ZeroGravitas 16y ago
I remember the general consensus being that Gecko, while more functional was convoluted and hard to work with, while KHTML was a cleaner base to work from, but needed work to better deal with the ugly realities of the web. If it was as crappy as suggested then you'd have to ask why Apple would have picked up a LGPL project rather than start from scratch. I also remember them being less than great open source collaborators at first.

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 ago
WebCore (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 ago
  People 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.

ZeroGravitas 16y ago

I remember the general consensus being that Gecko, while more functional was convoluted and hard to work with, while KHTML was a cleaner base to work from, but needed work to better deal with the ugly realities of the web. If it was as crappy as suggested then you'd have to ask why Apple would have picked up a LGPL project rather than start from scratch. I also remember them being less than great open source collaborators at first.