Im ersten Teil der HTML5-Serie konnten Sie alles über neue Präsentationsformen im multimedialen Bereich lesen. Im zweiten Teil beschäftigen wir uns mit den neuen Möglichkeiten zur Datenaufbereitung sowie zur Verknüpfung von Online-Diensten und lokalen Anwendungen.
Foto: W3C
Von allen Spezifikationen, die das World Wide Web Consortium W3C in seinen HTML5-Entwürfen vorlegt, ist die Möglichkeit, Online-Daten auf dem heimischen Rechner abzulegen, die wohl technisch spannendste. Zu Beginn der Browser-Ära waren diese Zugriffsprogramme lediglich als Client gedacht, die nur das umsetzten und anzeigten, was Sie vom Server vorgegeben bekamen. Recht schnell erkannten die Programmiere die Limitation dieser Idee und führten kleine Datenschnipsel ein, die Websites ihren Besuchern ungefragt auf den Rechner überspielten und später zurück an den Server sendeten. Diese "Cookies" sind nichts anderes als winzige Textdateien, die Informationen über den Surfer enthalten, die beim erneuten Besuch einer bestimmten Website vom Browser ausgelesen werden können. Schnell bildete sich Widerstand gegen das Ausspähen der Surfgewohnheiten: Cookies wurden zunehmend häufiger gelöscht oder gleich ganz gesperrt. Die Möglichkeiten der Entwickler waren also weiterhin stark eingeschränkt.
Um das Problem zu lösen und Browser-basierter Software zum Durchbruch zu verhelfen, dürfen JavaScript-Programmierer laut neuer HTML-Spezifikation nun angemessene Datenmengen auf einem lokalen Rechner ablegen. Damit entsteht zum einen ein größerer Zwischenspeicher für Informationen über den Benutzer, auf den Websites zugreifen können. Zum anderen können Anwender Web-Seiten lokal ablegen und damit installierbare Desktop-Software überflüssig machen. Denn hat der Browser erst einmal vollen Lese- und Schreibzugriff auf die Festplatte, gibt es wenig Grund, eigenständige Desktop-Applikationen zu installieren - es ist schließlich so gut wie alles im Web verfügbar.
Webspeicher
Die einfachste Form des Webspeichers legt Daten der aktuellen Session ab - aber nur solange, wie der Browser geöffnet ist. Jedes neue Dokument bekommt ein sessionStorage-Objekt zugewiesen, das ein paar grundlegende Funktionen wie "setItem", "getItem" und "clear" beherrscht. Diese Items bestehen aus Schlüssel-Wert-Paaren - vergleichbar mit assoziativen Arrays.
Lokaler Speicher
Die richtigen Vorteile bringt das neue localStorage-Objekt, das zwar fast genauso wie das SessionStorage-Objekt aussieht, aber gänzlich anders arbeitet. Dort, wo sessionStorage vergisst, kann sich localStorage erinnern. Daten bleiben erhalten, obwohl der Browser geschlossen und der Rechner heruntergefahren wird. Mehr noch: Ist eine Website in zwei Fenstern gleichzeitig aktiv, werden die lokal gespeicherten Daten gemeinsam genutzt. Ändert sich der Code, auf den das eine Fenster gerade zugreift, ändern sich auch die Daten des anderen. Die HTML5-Spezifikation legt fest, dass ein Ereignis "storageChange" in einem Fenster sich sofort auf alle Fenster auswirkt. Einige Browser unterstützen dieses Vorgehen schon länger - manche von ihnen nur beim Tabbed Browsing, manche auch über verschiedene Fenster hinweg. Da es noch keine verbindlichen Standards gibt, ist die Implementierung aber noch längst nicht abgeschlossen.
Lesen Sie auf der folgenden Seite, was durch die neuen Storage-Objekte für Komplikationen drohen könnten.
Beschränkt und doch gefährlich
Ob und wie stark das storageChange-Objekt in seiner Wirkung eingeschränkt wird, wird noch diskutiert. So können derzeit nur Skripte mit derselben Funktion sowie von derselben Domain und Port aus das Objekt verwenden. Diese engen Grenzen lassen Probleme mit beliebten Skripten oder einem Wechsel zwischen HTTP- und HTTPS-Verbindungen gar nicht erst aufkommen.
Auch wenn sich die neuen Möglichkeiten für Webentwickler wie ein Traum anhören mögen, könnten sie schnell zum Albtraum werden: Dann nämlich, wenn zwei Fenster auf dieselben Dateien zugreifen und einen Wettlauf darum starten, wer die Daten als erstes korrumpiert (kritischer Wettlauf). Experten streiten deshalb darüber, um das Objekt um einen "Mutex"-Algorithmus (mutual exclusion), der dieses schädliche Ansinnen auf beiden Seiten - Server wie Client - einschränkt, ergänzt werden müsse.
Einer der jüngsten Entwürfe der HTML5-Spezifikation sieht einen Mutex eher als potenzielle Geschwindigkeitsbremse und gibt die Empfehlung ab, mögliche Datenbeschädigungen unter diesen Umständen zuzulassen. Weiter heißt es: "Alternativen, die ohne ein Skript-Lock auf Client-Seite auskommen, werden dringend gesucht."
Derartige Alternativen sind auch notwendig, könnte es andernfalls doch zu bizarren Auswüchsen kommen, wenn mehrere Browserfenster gleichzeitig geöffnet sind. Dann liefen zwar verschiedene Instanzen eines Codes parallel, jeder Prozess hätte aber nur Zugriff auf einem einzigen unveränderlichen lokalen Datenbestand.
In der Spezifikation heißt es: "Verschiedene Website-Betreiber, die sich einen Host teilen - beispielsweise mehrere Blogger auf Wordpress.com (Anm. d. Red.) - teilen sich ein localStorage-Objekt. Es gibt kein Feature, den Objektzugriff pfadabhängig zu beschränken." Wieviel Speicherplatz bekommt also jeder einzelne? Lässt sich DNS-Spoofing verhindern? localStorage beantwortet zwar viele Fragen, wirft aber mindestens genauso viele neue auf.
SQL-Datenbank und IndexedDB
Die Schlüssel-Wert-Paare im localStorage-Objekt sind in der Regel mächtig genug, um viele Grundfunktionen auszuführen - sie sind jedoch keineswegs mit relationalen Datenbanken vergleichbar, die Daten in indexierten Tabellen speichern. Für diese Anforderung bietet der HTML5-Standard zwei neue Optionen.
Die erste ist der Standard Web SQL Database, der bereits vor längerer Zeit entworfen und implementiert worden ist, bevor er zugunsten einer abstrakteren Variante etwas aus dem Blickfeld geriet. WebKit- und Opera-Anwender können mit der in dem Standard beschriebenen abgespeckten Datenbank-Engie SQLite Tabellen erstellen und Wertereihen speichern - SQL-Grundwissen vorausgesetzt. Weil das W3C aber entschied, Web SQL Database nicht weiterzuentwickeln, ist der Standard heute nur noch für experimentierfreudige Tekkies geeignet - er wird trotz allem weiterhin von vielen Browsern unterstützt.
An seine Stelle trat die Indexed Database - sie ist vollkommen SQL-frei und enthält massenweise Schlüssel-Wert-Paare, analog zum localStorage-Objekt. Der Unterschied: Dank ihres Indexes lassen sich benötigte Daten schneller finden. Browser speichern jede Tabelle in einem B-Baum, um die Ergebnisrecherche zu beschleunigen und den Programmieren die Möglichkeit einzuräumen, die eingegebenen Daten zu sortieren. Der indexierte Speicher schließt kritische Wettläufe, die im localStorage noch möglich sind, dadurch aus, dass er alle Änderungen im Code als Transaktionen ausführt. Datenbankadministratoren mögen das gut finden, ausreichende Praxiserfahrungen mit IndexedDB liegen jedoch noch nicht vor. So enthält die aktuelle Version des HTML5-Entwurfs die Anmerkung, dass noch entschieden werden müssen, was geschehe, wenn eine dynamische Transaktionen ein Datenbankobjekt sperren wolle - das betroffene Objekt aber bereits von einer anderen Transaktion gesperrt sei. Also noch viel zu tun…
Lesen Sie auf der folgenden Seite alles über neue Möglichkeiten zum Offline-Browsen und potenzielle Eingriffe in die lokale Festplatte…
FileAPI: FileReader
FileReader- und FileWriter-Objekte greifen über die Browser-Sandbox hinaus auf die lokale Festplatte zu. Es ist schließlich ein Unterschied, ob sie nur die Möglichkeit haben, pro Session Daten abzulegen oder ob sie darüber hinaus Funktionen wie readAsBinaryString verwenden dürfen. Die FileAPI ist noch nicht weit verbreitet, schickt sich aber an, die Grenzen zwischen "persönlichem" (Festplatte) und "öffentlichem" (Internet) Teil des PCs einzureißen. Es existieren bereits Ansätze, in den Browser eingegeben URIs wie file://C: mehr wie Websites aufzulösen. JavaScript soll durch einheitliche XML-http-Request-Anfragen weniger stark zwischen lokalen und serverseitigen Daten unterscheiden.
Die API-Details sind noch nicht ausgearbeitet. Die Spezifikation ist voll von nützlichen Vorschlägen, wie dem, dass systemrelevante Dateien (wie /usr/bin-Verzeichnisse, Passwortdateien, EXE-Files) diesem Zugriff entzogen bleiben sollten. Wichtig ist dabei das Wort "sollten" - es wird in der Tat im Konjunktiv verwendet. Der W3C-Vorschlag geht dahin, dass der Browser bei Zugriffsversuchen auf derartige Dateien einen "Security Error" ausgibt. Bis es aber einen FileReader-Standard gibt, wird es noch dauern.
FileAPI: FileWriter
FileWriter ist das Gegenstück zum FileReader - die API könnte unter anderem die Installation neuer Software stark vereinfachen. Zunächst wird ein Block mehrerer Bytes erstellt (Blob) und in ein FileWriter-Objekt umgewandelt. Anschließen können Rechte wie "append" oder "write" vergeben werden, die es dem Objekt erlauben, auf der Festplatte der Anwender zu wildern. Ein Paradies für Virendesigner - die sogar noch wählen dürfen, wie sich Ihre Werke installieren sollen.
Natürlich muss es nicht soweit kommen, und wenn die Modelle so arbeiten wie vorgesehen, wird es das auch nicht. Momentan sieht es danach aus, dass der Anwender vom Browser vor jedem Schreibzugriff gefragt wird, wo Daten abgelegt werden sollen - sensible Festplattenbereiche werden dabei wohl von vornherein kategorisch ausgeschlossen. Doch schützt das vor Schäden? Die größte Gefahr sitzt schließlich vor dem Rechner.
Offline-Web-Anwendungen: AppCaching
Indem Web-Seiten Dateien lokal speichern dürfen, kann sich der Netztraffic erheblich reduzieren - weil AJAX-Abrufe und anderes zwischengespeichert werden. Das Caching der Website selbst ist davon aber kaum beeinflusst. Die AppCaching-Entwicklungsumgebung sorgt deshalb dafür, dass Teile der Seite lokal zwischengespeichert werden. So werden zum einen die notwendigen Reloads minimiert und sind zum anderen Sites möglich, die auch ohne aktive Internet-Verbindung weiterarbeiten. Auch jetzt schon können HTML-Seiten mit Header-Tags ausgestattet werden, die ein solches Caching möglich machen - JavaScript- und CSS-Erweiterungen (Cascading Style Sheets) sind davon jedoch nicht erfasst. Die AppCaching-API erzeugt deshalb für jede Seite ein eigenes Ladeverzeichnis, in dem alle wichtigen Seitenteile aufgelistet sind, und gibt es an den Browser zum Auslesen weiter. Voraussetzung ist folgender Eintrag im Header Code:
<html manifest="page.manifest">
Der Browser schaut sich daraufhin das Ladeverzeichnis an und behandelt alle erfassten Dateien zusammen als eine Einheit. Sobald sich das Ladeverzeichnis ändert, lädt der Browser die gesamte Website neu.
Die API behandelt die Elemente unterschiedlich: So können Abrufe von serverseitigen CGI-Funktionen beispielsweise in einen separaten Teil des Verzeichnisses ausgelagert werden, um ihr Caching zu verhindern. Auch gibt es eine allgemeine Fallback-Sektion, in der Anweisungen für den Fall aufgeführt sind, dass bestimmte Teile nicht zwischengespeichert werden können. So lassen sich dort beispielsweise Alternativ-Icons für nicht verfügbare Bilder angeben.
Auf der folgenden Seite finden Sie Näheres zu den noch nicht weiter ausgearbeiteten Plänen über versteckte Dateien im HTML-Baum und neue maschinenlesbare Metainformationen...
Unsichtbare Daten einbinden
Eine weitere Neuerung ist die Möglichkeit, Daten im DOM (Document Object Model) zu verstecken. Das JQuery-Framework, eine freie JavaScript-Klassenbibliothek, bringt die Methode "data" mit, die beliebige Objekte an Teile des DOM-Baums anhängt. So können Daten in einem nichtsichtbaren Bildschirmbereich abgelegt werden - anstatt wie bislang gesondert gespeichert werden zu müssen. Das erleichtert "Drag and drop"-Vorgänge. Die Funktion ist noch nicht gut ausgearbeitet - einige HTML5-Entwickler unterstützen aber das Vorhaben, das Feature zu standardisieren.
HTML5 Microdata
Hinter der Microdata-Spezifikation steckt die Idee, eine neue Klasse maschinenlesbarer Meta-Tags zu erstellen, die die Website den sichtbaren Informationen hinzufügt. Anstatt beispielsweise Daten in Form von "1. Januar 2011" oder "Neujahr" als Text auf die Website zu schreiben, ergänzt der Programmierer im Code folgendes:
<time itemprop="birthday" datetime="2011-01-01">Neujahr</time>
Webcrawler wie Suchmaschinenroboter verstehen sofort, dass hier eine Datumsangabe vorliegt und müssen nicht erst den gesamten Text der Seite parsen. So könnte die Microdata-API nach dem Willen des W3C ein erster großer Schritt auf dem Weg zum semantischen Web sein: Je mehr Websites ihre Inhalte auf diese Art ausgeben, desto semantischer wird das Web werden - Suchmaschinen können Informationen besser sortieren und den Anwendern intelligente Auskünfte erteilen, ohne all zu komplexe Suchanfragen gestellt bekommen zu müssen.
In den meisten Webbrowsern ist Microdata noch nicht implementiert. Solange der konkrete Nutzen für einzelne Website-Betreiber und -Besucher unklar ist, wird sich daran nichts ändern. Natürlich wäre es beispielsweise nett, <time>-Tags mit regionalen oder überregionalen Kalendern verknüpfen zu können, um Besucher dem Anlass entsprechende Informationen auszugeben - aber selbst diese simple Anforderung wird von der API derzeit noch nicht unterstützt.
Fazit
Die Verknüpfung von Web und lokalen Clients steht noch am Anfang. Viele Anforderungen, gerade unter dem Aspekt der Datensicherheit, der Datenmenge und der Lebensdauer der Daten, sind noch nicht diskutiert worden. SessionStorage- und localStorage-Objekte werden schon jetzt von allen führenden Browsern (Chrome, Firefox, IE, Opera, Safari) bis zu einem bestimmten Punkt unterstützt. Die anderen vorgestellten APIs sind zum größten Teil nur Arbeitsentwürfe. FileReader ist in Google Chrome und Mozilla Firefox schon integriert - AppCaching funktioniert in allen Browsern mit Ausnahme des Internet Explorers (auch in Version 9 wird sich das nicht ändern). IndexedDB und FileWriter wird bisher noch von keinem Programm unterstützt. Wer seinen Browser testen möchte, kann dies hier tun: http://www.wayner.org/node/75 (siehe Bild).
Darüber hinaus betreffen alle Spezifikationen fast ausschließlich JavaScript-Programmierer. Den Endanwender interessieren sie herzlich wenig - er entscheidet in seinem lokalen Browser mit einem Mausklick, ob beispielsweise AJAX-Dateien dauerhaft auf dem lokalen Rechner behalten werden dürfen oder nicht. Tiefergehende Entscheidungsmöglichkeiten stehen ihm derzeit nicht zu. Welche Features werden also wirklich benötigt? Wo ist der goldene Mittelweg zwischen der nötigen Privatsphäre und der Flexibilität, die fortschrittliche Web-Angebote benötigen? Das sind offene Fragen, die noch einigen Diskurs benötigen.
Der Artikel stammt von Peter Wayner von unserer US-Schwesterpublikation InfoWorld. Die HTML5-Reihe wird fortgesetzt. (sh)