未來 Konqueror 將導入 WebKit 做為預設渲染引擎

　　其實去年底就有聽到這樣的風聲了， KDE 工作團隊打算將自家開發的渲染引擎 KHTML 併入 KHTML 的分支— WebKit (WebKit 是蘋果專為 Safari 所設計的渲染引擎)。在 Konqueror 第四版出來後， KDE 的工作團隊也開始著手將 WebKit 導入 Konqueror 4 ，截至目前為止已經初具雛型了，不過由於原本的 KHTML 工作團隊分成兩派人馬，一是傾向於轉向 WebKit 開發，另外則是死守 KHTML 的開發者，所以基本上 KHTML 在短期內應該還不至於消失。

　　就我個人的看法而言，依照 Konqueror 和 Safari 的軟體能見度來說， Safari 當然是遠大於 Konqueror ，因此 WebKit 受網頁設計師支援以及重視的程度也當然就會比 KHTML 大很多(更何況使用 WebKit 的瀏覽器並不止 Safari)，所以就通行度而言，引入 WebKit 對於 Konqueror 來說的確是件好事。

　　但是 KHTML 是 KDE 自己專為 Konqueror 而量身打造的渲染引擎，不但是Konqueror 的渲染引擎，更是整個 KDE 的渲染引擎， KHTML 對於 Konqueror 來說，意義非凡，若是沒了 KHTML ，就我個人的觀點認為，那 Konqueror 恐怕就只剩外殼了(就像 KKBOX 和 Galeon 那樣，是沒有自己核心的瀏覽器)。所以我認為 KHTML 不應被 KDE 團隊所忽視。

　　但就情勢來說， KHTML 現在應該算弱勢，未來所剩的 KHTML 開發者也有可能因為感到大勢已去而紛紛轉向 WebKit 開發，直至 KHTML 消失為止。

　　雖然我贊同 Konqueror 導入 WebKit ，但我還是傾向於使用 KHTML 做為預設的排版引擎，讓我們可以在必要時切換到 WebKit 就好，我不贊成將 WebKit 做為預設渲染引擎，尤其不贊成 KHTML 開發者轉而開發 WebKit ，原因很簡單，因為我認為 KHTML 對於 Konqueror 甚至是整個 KDE 來說是意義非凡。