Start Magazin Layout-Engine WebKit

Layout-Engine WebKit

Von den meisten Anwendern unbemerkt, sorgt eine Komponente namens WebKit auf fast allen Mobilgeräten für eine schnelle und korrekte Anzeige von Webseiten. Das bringt Web- und App-Entwicklern zahlreiche Vorteile. Doch die WebKit-Landschaft ist nicht so homogen, wie es auf den ersten Blick scheint.

Bis eine Webseite auf dem Bildschirm erscheint, hat der Browser im Hintergrund bereits zahlreiche Arbeitsschritte erledigt. Er muss die Seite nicht nur aus dem Internet angeln, sondern sie auch wie vom Designer vorgegeben auf dem Bildschirm des Mobilgeräts zeichnen. Den genau dafür zuständigen Programmteil bezeichnet man als Rendering- oder Layout-Engine. Solche Engines gibt es von verschiedenen Entwicklern und freien Projekten als fix und fertige Komponente. Die Browserhersteller müssen im Idealfall nur noch eine hübsche Benutzeroberfläche darum herum stricken und fertig ist der Browser.

Apple und Google verwenden in ihren mobilen Browsern sowie in Safari und Chrome die Layout-Engine WebKit [1]. Seinen ersten öffentlichen Auftritt hatte das auf KHTML basierende WebKit in Apples Browser Safari für Mac OS X (siehe Kasten "Freie Software"). Der schlanke Programmcode der HTML-Engine lässt sich leicht auf andere Systeme portieren, zudem ist WebKit aufgrund einer freien Lizenz vollkommen kostenlos und unterstützt brandaktuelle Web-Techniken.

Freie Software

Die Wurzeln von Webkit reichen bis in die zweite Hälfte der 90er Jahre zurück. Die unter dem freien Betriebssystem Linux laufende Benutzeroberfläche KDE erhielt damals von ihren Entwicklern eine Layout-Engine namens KHTML spendiert. Sie trieb primär den Browser Konqueror an, wurde aber auch eifrig von anderen Internet-affinen Programmen genutzt. Kurze Zeit später kam noch die KDE eigene Java Script Engine in Form der Bibliothek KJS hinzu.

Um 2002 begann Apple mit der Programmierung eines eigenen Browsers für sein brandneues Betriebssystem Mac OS X. Um sich Arbeit zu ersparen, suchten die Entwickler nach einer fertigen Layout-Engine. Sie entschieden sich schließlich für KTHML, das aus ihrer Sicht gegenüber der Konkurrenz kleiner, verständlicher und einfacher zu programmieren war. Apple kündigte eine Zusammenarbeit mit den KHTML-Machern an, portierte KHTML auf Mac OS X, entwickelte dann aber die Layout-Engine in einem eigenen und teilweise geschlossenen Projekt namens WebKit weiter. Die KHTML-Macher waren über dieses Vorgehen alles andere als erfreut und warfen Apple vor, Änderungen nur spärlich und in großen, schlecht dokumentierten Batzen an das KHTML-Projekt zurück zu geben. Der Streit endete erst 2005, als Apple den Programmcode von Webkit komplett öffnete und für jedermann kostenlos zugänglich machte.

Mit dieser Maßnahme trat Webkit seinen Siegeszug in anderen Browsern an: Adobe übernahm die Engine für Adobe AIR und einige Creative Suite-Programme, Google nutzt es in seinem Browser Chrome und BlackBerry setzt ebenfalls auf die freie Engine. Neben vielen unabhängigen Programmierern treiben heute insbesondere Google, Nokia, RIM und Apple die Entwicklung von WebKit voran, also die Firmen, die auch von WebKit besonders profitieren.

Eine Frage der Technik

Der Code von WebKit ist top aktuell. So versteht die Engine einen Großteil der neuen HTML5- und CSS3-Standards, kann Grafiken im SVG-Format anzeigen und verdaut verschiedene XML-Technologien, darunter XPath und XSLT. Obendrauf gibt es eine Unterstützung von WebGL, das hardwarebeschleunigte 3D-Grafiken im Browser erlaubt (genauer gesagt im neuen HTML5-Element canvas). Weitere Funktionen lassen sich über eine Plugin-Schnittstelle im Netscape-Format (NPAPI) nachrüsten. Auf diesem Weg dockt auch der Adobe Flash Player an WebKit-Browser an.

WebKit gehörte zu den ersten Layout-Engines, die den viel beachteten ACID3-Test [2] mit 100 von 100 Punkten bestanden (Abbildung 1 und 2). Dieser Test prüft, wie gut Browser die aktuellen Web-Standards unterstützen. Kein Wunder also, dass sich auch die Hersteller von Mobilgeräten auf WebKit stürzten (siehe Kasten "WebKit inside"), sodass heute eigentlich nur noch Microsoft auf seine Eigenentwicklung Internet Explorer setzt – in allen anderen mobilen Betriebssystemen kommt hingegen WebKit zum Einsatz.

Abbildung 1: Safari mit WebKit-Unterbau erzielt im ACID3-Test 100 von 100 Punkten.
Abbildung 1: Safari mit WebKit-Unterbau erzielt im ACID3-Test 100 von 100 Punkten.

Abbildung 2: Firefox 3.6 bringt es im ACID3-Test nur auf 94 Punkte.
Abbildung 2: Firefox 3.6 bringt es im ACID3-Test nur auf 94 Punkte.

Einige noch nicht endgültig standardisierte Eigenschaften der CSS3-Spezifikation lassen sich in WebKit basierten Browsern allerdings nur dann nutzen, wenn man ihnen jeweils das Kürzel -webkit- voranstellt. Davon betroffen sind unter anderem Animationen, 3D-Transformationen (gemäß CSS 3D Transforms-Standard) und die neuen Eigenschaften für hübschere Rahmen. Letzt genannten verpasst man beispielsweise via -webkit-border-radius abgerundete Ecken. Diese umständlich wirkende Konvention gibt das World Wide Web Consortiums (W3C) absichtlich vor: Dank ihr können Web-Designer und Browser-Hersteller schon mit den neuen Eigenschaften experimentieren, ohne dass noch folgende Änderungen am CSS3-Standard bestehende Seiten zerstören würden.

WebKit inside

WebKit werkelt derzeit im Safari-Browser auf iOS-Geräten, namentlich iPhone, iPod Touch und iPad. Apple Mail greift ebenfalls zur Anzeige von HTML-Mails auf WebKit zurück. Darüber hinaus steckt die Layout-Engine in der mobilen Welt hinter:

  • Google Chrome
  • Android Web-Browser
  • Symbian im S60 Browser (zu finden unter anderem in Geräten von Nokia, Samsung und LG)
  • Palm WebOS
  • Adobes AIR-Plattform
  • Bolt Browser (Android)
  • Iris Browser (Windows Mobile)

Auch Research In Motion setzt in sämtlichen BlackBerry-Geräten ab Version BlackBerry OS 6.0 sowie dem angekündigten PlayBook-Tablet auf einen WebKit-Browser.

Blockbauweise

Webkit selbst ist modular aufgebaut und besteht aus mehreren einzelnen Programmbibliotheken (Abbildung 3). Die zentrale Komponente WebCore baut die Webseiten zusammen und zeichnet das Ergebnis auf den Bildschirm. Ihr zur Seite steht JavaScriptCore, eine Bibliothek, die JavaScript-Programmcode ausführt. In der ersten Version interpretierte sie den Quellcode noch Zeile für Zeile. Um den Ablauf zu beschleunigen, schrieb das WebKit-Projekt die Komponente neu. Heraus kam im Jahr 2008 SquirrelFish. Es überträgt den JavaScript-Code zunächst in eine spezielle Zwischensprache, deren Bytecode sich wesentlich schneller abarbeiten lässt. Kurze Zeit später erschien die Weiterentwicklung SquirrelFish Extreme, kurz SFX. Sie übersetzt den JavaScript-Code in Maschinencode, den der Prozessor direkt verarbeiten kann (Just-in-Time Kompilierung). Trotz der radikalen Kernsanierung unter der Oberfläche hört die JavaScript-Komponente immer noch offiziell auf den alten Namen JavaScriptCore.

Abbildung 3: WebKit besteht aus den Komponenten WebCore und JavaScriptCore.
Abbildung 3: WebKit besteht aus den Komponenten WebCore und JavaScriptCore.

WebCore und JavaScriptCore können Entwickler direkt und einzeln in ihre Programme einbinden. Google setzt beispielsweise in seinen Browsern nur WebCore ein, JavaScript verarbeitet dort eine selbst entwickelte Komponente namens V8. Alternativ lassen sich WebCode und JavaScriptCore über eine gemeinsame, kompakte Schnittstelle ansprechen. Diese Zwischenschicht trägt wiederum den Namen WebKit. Als Programmiersprache stehen dabei standardmäßig C++ und das von Apple favorisierte Objective-C zur Verfügung. WebCode und die JavaScript-Engine selbst sind in C++ geschrieben.

Viele Köche

Beide Kernkomponenten stehen unter der GNU LGPL, die übrigen Elemente unter eine BSD-ähnlichen Lizenz. Diese offenen Lizenzen haben schnell Programmierer angezogen, die WebKit auf verschiedene Betriebssysteme und Geräte portierten, sowie Anbindungen an weitere Programmiersprachen schufen. Das Projekt WebKit.NET verpasst beispielsweise der Layout-Engine eine C#-Schnittstelle für .NET-Anwendungen [3]. WebKit wurde sogar in bestehende andere Bibliotheken und Frameworks aufgenommen. Nokia integrierte WebKit etwa in Qt. Ganz nebenbei fand damit WebKit auch den Weg in Nokias Mobilfunkgeräte.

Durch die zahlreichen Portierungen entstand allerdings auch ein ziemlicher Wildwuchs, fast überall sieht die WebKit-Schnittstelle etwas anders aus. Darüber hinaus bietet nicht jede Portierung alle WebKit-Funktionen. Meist fallen neue HTML5-Elemente, die Plugin-Schnittstelle und die Funktionen des WebInspectors (siehe Kasten "Nebenprodukte") unter den Tisch. Das spüren vor allem Web-Entwickler, wenn sie auf verschiedene Gerätegenerationen treffen. So kennen beispielsweise viele ältere Android-Browser schlichtweg einige neue CSS3-Eigenschaften nicht, die andere WebKit-Browser sehr wohl schon verdauen.

Nebenprodukte

Im Laufe der Zeit entstanden rund um WebKit weitere interessante Projekte. So testet das Benchmark-Programm SunSpider, wie schnell ein Browser JavaScript-Code ausführt. Unter [4] kann man seinen eigenen Browser foltern (Abbildung 4). Zum Redaktionsschluss aktuell war Version 0.9.1 vom April 2010.

Fertige Webseiten nimmt der WebInspector unter die Lupe. Ihn haben viele Web-Entwickler bereits in Safari und Google Chrome schätzengelernt. Er zeigt nicht nur den Quellcode einer Webseite und liefert eine stets aktualisierte Ansicht des DOM-Baums, sondern bietet sogar einen JavaScript-Debugger (Abbildung 5). Letzt genannter war früher übrigens unter dem Namen Drosera als eigenständiges Programm zu haben. Der WebInspector ist Teil des WebKit-Projekts. Welcher Browser ihn mitbringt, entscheidet allerdings der jeweilige Entwickler, auch seine Bedienung hängt vom Browser-Modell ab. Für die Desktop-Versionen von Chrome und Safari findet sich eine Kurzreferenz unter [5]. Um ihn in Safari zu aktivieren, ruft man zunächst die Einstellungen auf, markiert unter Erweitert den Punkt Menü "Entwickler" in der Menüleiste anzeigen und aktiviert dann im neuen Menü Entwickler den Punkt Webinformationen einblenden.

Abbildung 4: Der SunSpider-Benchmark prüft die JavaScript-Leistung des Browsers.
Abbildung 4: Der SunSpider-Benchmark prüft die JavaScript-Leistung des Browsers.

Abbildung 5: Hinter der Leiste am unteren Rand, die man über das Menü Entwickler öffnet, steckt der WebInspector.
Abbildung 5: Hinter der Leiste am unteren Rand, die man über das Menü Entwickler öffnet, steckt der WebInspector.

Auf der offiziellen Homepage des WebKit-Projekts finden Programmierer die stets aktuelle Entwicklerversion. Sie unterstützt von Haus aus nur die großen Desktop-Betriebssysteme Windows, Mac OS X und Linux. Die WebKit-Macher verzichten auf explizit als stabil gekennzeichnete Versionen, wie man sie etwa von herkömmlichen Programmen gewohnt ist. Im Wiki der Projekt-Homepage steht neben Anleitungen zum Compilieren eine umfangreiche technische Dokumentation bereit. Wer sich für den internen Aufbau von WebKit interessiert, sollte sich beispielsweise die sehr guten Blog-Posts von Dave Hyatt ansehen [6].

Da die Programmierschnittstelle von der jeweiligen WebKit-Portierung und Programmiersprache abhängt, findet sich auf der Projekt-Homepage keine allgemeingültige Einführung. Wer WebKit in eigenen Anwendungen nutzen möchte, muss deshalb die Internetauftritte der entsprechenden Portierungen aufsuchen. Für Objective-C respektive iOS-Entwickler bietet die Dokumentation von Apple eine erste Anlaufstelle [7]. WindowsCE-Programmierer starten mit der Seite unter [8].

Webkit = Webkit?

Für Android-Systeme hält die offizielle Android Developers-Seite [9] alle notwendigen Informationen bereit. Wie dort im Dev Guide beschrieben, lässt sich WebKit über die Klassen im Paket android.webkit einbinden. Einen Blick unter die Haube erlaubt Googles frei erhältlicher Android-Quellcode [10], auf dem die einzelnen Gerätehersteller ihr System aufbauen. Dort werkelt in der Version 2.2 und 2.3 ein von Google leicht modifiziertes WebKit 533.1. Insbesondere kamen Funktionen hinzu, mit denen Web-Anwendungen die Bildschirmauflösung und -Ausrichtung auswerten können.

Hardwarehersteller dürfen allerdings gemäß der Android Compatibility Definition eine eigene beziehungsweise selbst angepasste WebKit-Variante nutzen, vorausgesetzt die Programmierschnittstelle verhält sich weiterhin wie von Google vorgeschrieben. Sogar die Zeichenkette, mit der sich WebKit gegenüber Web-Seiten zu erkennen gibt (User-Agent String), dürfen die Gerätehersteller selbst vorgeben. Die in Android verwendete Laufzeitumgebung verwehrt zudem den direkten Zugriff auf die konkret laufende WebKit-Implementierung. Ein Austausch durch eine aktuellere WebKit-Version ist somit nur durch tiefgreifende Änderungen am Android-System oder über einen alternativen Browser möglich.

Bei Systemen die auf Qt aufbauen, wie etwa Maemo, MeeGo oder Symbian, greift man auf die in Qt enthaltene WebKit-Variante zurück. Sie steckt in der Bibliothek QtWebKit, die bei der Versionierung ebenfalls von der offiziellen WebKit-Versionszählung abweicht. So enthält beispielsweise Qt 4.7.0 die Bibliothek QtWebKit 2.0, die wiederum auf einer etwas älteren, nicht näher benannten WebKit-Fassung beruht. In der Entwicklung befindliche Nachfolgeversionen von QtWebKit findet man auf der Qt Port of WebKit Seite [11]. Zum Redaktionsschluss stand beispielsweise QtWebKit 2.1 kurz vor der Veröffentlichung, einen Blick in die Zukunft gewährt die instabile Entwicklerversion QtWebKit 2.2. Zwar kann man diesen Nachfolger gegen die in Qt 4.7.0 mitgelieferte WebKit-Version austauschen, Nokia bietet dafür aber keinen offizielle Support. QtWebKit 2.1 und folgende sind lediglich als Zwischenstadium für die nächste Qt-Version gedacht. Eine umfangreiche Dokumentation zu QtWebKit findet man auf den Qt-Entwicklerseiten unter [11] und [12].

Ausblick

Während sich WebKit auch außerhalb der mobilen Welt langsam zur beliebtesten Layout-Engine mausert, werkeln seine Programmierer bereits an WebKit2. Diese grundlegend überarbeitete Version lagert jede Webseite beziehungsweise Webanwendung in einen eigenen Prozess aus. Stürzt eine Webseite ab, reißt sie damit nicht mehr den gesamten Browser oder gar das Betriebssystem in den Abgrund, sondern lässt sich kontrolliert beenden oder neu starten, wie man das von einigen Browsern bei Plugins schon kennt. Darüber hinaus verpassen die Entwickler WebKit2 eine neue Schnittstelle für die Sprache C, die zumindest auf den meisten Systemen identisch aussehen soll. Andere Sprachen können über einen Wrapper auf die C-Schnittelle zugreifen, Apple plant bereits eine Objective-C- Anbindung. Das aktuelle WebKit bleibt dabei unangetastet, es wird in seiner aktuellen Form auch zukünftig weiterleben.

Kommentiere den Artikel

Please enter your comment!
Please enter your name here