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.

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.

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.

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.

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.

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.