snapshot1

KHTML-based Konqueror is not compliance to ACID2 test

網絡暴民的Blog指出

不過,大家都知道 Safari 的核心是 KHTML,可是 Apple 的做法卻引起 KDE 的開發團不滿,因為其改變過的 Source code 並沒有 CVS History,KHTML 開發者不能夠知道他們改了什麼,而要 KHTML Engline[sic] 支持 ACID2 則似乎要 KHTML 開發者再自行努力了。

另其中一句是

Apple 飲水要思源啊…

這篇文應是回應Slashdot一篇報道,指KHTML部份開發者指他們不能因為Safari能夠pass ACID2 test而有任何得益。
我先要聲明,我不是一個Web developer,只是一條粉皮,電腦方面我特別地屎。
此文有最少一點值得商榷。而那一句是「大家都知道 Safari 的核心是 KHTML」。我不屬於這句話的「大家」,因為我不知道Safari的核心是KHTML,我只知道Safari的「核心」是Cocoa Architecture,其Layout engine是WebCore和JavaScriptCore。這兩個Core分別用了一部份來自K Desktop Environment的KHTML和KJS的Source Code。同情地理解,「Safari 的核心是 KHTML」部份成立,但香港Blogosphere最近流行判準主義,這句說話,無異於說出「人其實是由一對腳組成」。WebCore和JavaScriptCore都已經嚴重地OS dependent了,因為他們已經經過OS優化,和Quartz Engine等等Mac OS X專用的架構整合好。最致命的是,WebCore和JavaScriptCore使用了一個叫KWQ的技術,令來自KHTML的東西不再需要使用KDE的Qt toolkit。這是KHTML不能使用WebCore的Source Code的主因。Safari能夠pass ACID2,其實Dave Hyatt及其隊員除了要修改WebCore/JavaScriptCore,也要令Safari正確地運用Mac OS X的功能。我可以說,WebCore是差不多不可能找出KHTML能夠直接使用的Source Code。如果有看Dave Hyatt的Blog,他不是未嘗試過給KHTML開發團供應ACID2的程式碼,就是那文所指的所謂「飲水思源」,只是KHTML的開發團發現來自WebCore的程式碼太過OS dependent,根本不能用。
再者,蘋果已經根據KHTML的GPL使用執照將WebCore和JavaScriptCore的原程式碼經GPL公開,已經有好些軟件因此受益(如Shiira, Omniweb),我覺得蘋果沒有做出任何對不住KHTML的事。甚至比GPL條文所說的做得更多。
在這件事上,我不明白為何要將茅頭指向Apple。網絡暴民在回應說道

Apple 當然沒有義務,但他們可以做的或許可以更多?

就算Safari的首席開發師,也即Camino的前首席開發師Dave Hyatt也在其blog問大家,WebCore和KHTML有如此大的分野之下,Apple可以怎樣做。(What do you think Apple Could be doing better here?)就連怎樣做也不知道,他們如何「可以做的或許可以更多」呢?
注意:內文純切磋,無意引發任何Flamewar,如有任何冒犯,請多多見諒。