KHTML – zarchiwizowany w 2023 roku silnik wyświetlania (renderowania) stron internetowych rozwijany przez społeczność programistów KDE. Udostępniony na licencji wolnego i otwartego oprogramowania.
KHTML – zarchiwizowany w 2023 roku silnik wyświetlania (renderowania) stron internetowych rozwijany przez społeczność programistów KDE. Udostępniony na licencji wolnego i otwartego oprogramowania.
Silnik KHTML stworzony został dla przeglądarki Konqueror, ale był wykorzystywany także w przeglądarkach systemów takich jak AtheOS/Syllable (ABrowse), MorphOS (Sputnik) czy Symbian (MiniMap)[potrzebny przypis].
WebKit, silnik używany między innymi przez Apple w przeglądarce Safari, jest bezpośrednim forkiem KHTML, podobnie jak Blink. Powszechną opinią jest jakoby KHTML był podwaliną powszechnie używanych przeglądarek, takich jak Google Chrome czy Microsoft Edge.
Silnik KHTML został napisany w języku C++ i był rozpowszechniany na warunkach licencji GNU LGPL. Obsługiwał HTML 4, HTML 5, XHTML, CSS 1, 2 i 3, DOM i JavaScript, oraz wtyczki Netscape/Mozilli (Flash, Java itp.). Do silnika KHTML wprowadzono także kilka niestandardowych elementów zwiększających zgodność z Internet Explorerem[potrzebny przypis].
Zgodnie z zapisem dokumentacji technicznej, KHTML był zbudowany jako biblioteka, której podstawowym obiektem był KHTMLPart, odpowiedzialny za przetwarzanie dokumentu i współpracujący z widokiem KHTMLView. Dokumenty HTML były przetwarzane przez tokenizer i parser, które tworzyły drzewo zgodne z modelem DOM, natomiast dokumenty XML wykorzystywały mechanizmy parsowania XML biblioteki Qt. Na podstawie drzewa DOM oraz arkuszy stylów CSS, KHTML tworzył odrębne drzewo renderowania, zawierające obiekty odpowiedzialne za rozmieszczenie i wyświetlanie poszczególnych elementów. Drzewo renderowania mogło różnić się od DOM, m.in. ze względu na tworzenie anonimowych elementów wynikających z zasad formatowania CSS. Za dobór reguł CSS odpowiadał CSSStyleSelector, natomiast mechanizm layoutu obliczał rozmieszczenie elementów w dostępnej przestrzeni, po czym KHTMLView rysował wynik na ekranie. KHTML obsługiwał również ładowanie zewnętrznych zasobów, takich jak obrazy i arkusze stylów, za pomocą mechanizmu Loader pełniącego także funkcję pamięci podręcznej. Proces przetwarzania mógł odbywać się przyrostowo, dzięki czemu tokenizer, budowanie DOM i tworzenie drzewa renderowania częściowo zachodziły równolegle, umożliwiając rozpoczęcie wyświetlania dokumentu przed zakończeniem przetwarzania.
Istnieją głosy w społeczności programistów, jakoby powodem zawieszenia rozwijania KHTML była zbyt duża złożoność projektu.