Safari and KHTML again

I just wish to weigh in on debacle to clear up some mistakes. First of all I would like to say I agree with Zack. The annoying part is not that Apple don't cooperate as much as they could. They are actually helpfull in answering questions and _tries_ at least to separate OS X specific features in the code (allthough they fail miserably at it). No, our problem are users who think Apple does more and underestimate the effort it takes for us to implement patches from WebCore. We are doing this for free and for fun, all we really want is appreciation for our effort.

In December 2004 I "ported" the CSS text-shadow property from WebCore. I put ported in quotes because the only thing ported was the code to parse the property. In the rendering Apple had created an extension to KWQ (their Qt) that used an OS X call to draw the shadow. This meant that to "port" it I had to write the shadow drawing myself. Not that I mind, it was pretty fun work. I was just saddened to see afterwards that many people assumed I had just merged a WebCore patch. The advantage of the reimplementation though is that we can apply any number of shadows like the standard requires, while Safari can only apply the one OS X supports.

The situation was even more extreme with the white-space patch. The goal was to make "white-space: pre" work like it did in WebCore. But the actual patch I merged from WebCore was exactly _one_ line of code. On top of that I had to merge the right 3 or 4 other changes that it broke, write several hundred lines of code myself and spend several weeks hunting corner case regressions. So the port of white-space: pre was one line of code from WebCore and several hundred written by myself and many weeks work. Yet it is treated as something I "ported" from WebCore. No wonder Zack is bitter if he has experienced the same. Of course the advantage again is that by redeveloping I could do it better than Apple, and thus KHTML supports both white-space: pre-wrap and pre-line from CSS 2.1 that Safari does not.

For those interested in the Acid2 patches I can say that I have merged three of them now and just need to fix a few new regressions. For small simple patches like these it takes 1 or 2 hours to merge them. It is still somewhat easier than to redevelop which would take at least a few hours more. Don't expect all of the patches. First of all the Acid2 test is complete crap. It doesn't really test any important features and the only thing it caught we couldn't do was min/max on positioned elements, the rest of the test are just obscure corner cases of error fall-back. Second of all some the patches by Dave are written in ObjC and is a joke to publish as KHTML patches. And lastly I believe correctly parsing SGML comments should be considered a bug.


It is highly appreciated by me :-) I already changed some of my sites to use the nice text-shadow property :-)

By Wilbert Berendsen at Sat, 04/30/2005 - 14:49

just want to say me too - i fully rely on khtml, as i don't have gecko (nor any gtk libs) on my system... and of course no windows :D

By superstoned at Sun, 05/01/2005 - 12:32

I thought you just grabbed shadow code from WebCore and it seems this is truly wrong. Maybe you guys should say something like "Add foo support with some bits from WebCore" because "Merge foo support from WebCore" is truly misleading.

But even if the case was simply copying WebCore code you would still deserve appreciation because its open source and developers deserve respect and appreciation.

Just my 0.02€

By ismail at Sat, 04/30/2005 - 15:18

I know that the "merge" from webcore is a hard and annoying job. This is the reason why I really appreciate your work on khtml.
Thanks, guys! What would be khtml without you? :-)

By Dario Massarin at Sat, 04/30/2005 - 16:51

First of all the Acid2 test is complete crap. It doesn’t really test any important features and the only thing it caught we couldn’t do was min/max on positioned elements, the rest of the test are just obscure corner cases of error fall-back.

For all that Acid2 may not have caught any real/significant/important bugs except for that one, couldn't that just mean that KTHML already does a good job with CSS? With zero patches, KHTML (and Gecko for that matter) are a whole lot better than IE. I was under the impression that the test is designed to expose a lot of IE-specific bugs, and a few bugs in the real browsers.

By eon at Sun, 05/01/2005 - 06:47

ooh, still the same issue ... i dont like that :(

- any person devoting itself to a taks such as this one owns my respect - AND its great what has already been achieved.
- not so amusing then again when i assume you have an my-work-is-hard-and-important-syndrome. still - also see my first note just above this ;)
- other coders just post interesting stuff, or development stories, they're bare, most most often not a slight offence to anyone — but here, i always see flames about the company Apple... (yeeees don't like corporate feudalism as well, but the the way some blog entries sound, your not that far aways either)

So to the bottom line i think YES you have more work to do AND you also always have to run after the changes. At least you can always look at a piece of code and see how that bad company did it, then you end up with your own implementation quite quicker than trying to code it all from the start *hint hint*

.. just wondering what your problem is actually, other than being pissed for always walking a step behind

By anunnaki at Mon, 05/02/2005 - 12:34

Okay I was being polite and got misunderstood. When I said "all we want is appreciation" I didn't mean "Look at me, I am so good.". I was hinting at users who are down right rude.
Look at bugs.kde.org and you can find many Konqueror bugs where the users are telling us how incredible lazy and lame we are because we don't just copy all the shit Apple is doing "for us".

By Allan Sandfeld at Mon, 05/02/2005 - 14:47