HTML5 Labs: Prototypen für experimentelle HTML5 Spezifikationen

Gastposting Dariusz Parys , Developer Evangelist für .NET 3.0 Technologie, C++, High Performance Computing, Windows Communication Foundation, Workflow Foundation und Visual Studio Team System bei der Microsoft Deutschland GmbH.

Gestern haben wir die Seite HTML5 Labs veröffentlicht. Ziel der Seite ist es, Prototypen von noch nicht ausgereiften W3C HTML5 Spezifikationen zu implementieren und zu veröffentlichen, um eine Diskussions- und Feedbackgrundlage für Entwickler zur Verfügung zu stellen.

The HTML5 Labs site is the place where Microsoft prototypes early and unstable web standard specifications from standards bodies such as the W3C. Sharing these prototypes helps us have informed discussions with developer communities, and contributes to a better implementation experience with draft specifications.

HTML5 Standardisierungsfortschritt

Solche Prototypimplementierungen helfen Entwicklern, Technologien zu verstehen und geben Ihnen auch Gelegenheit zum Feedback. Es hilft auch den Mitgliedern des W3C Spezifizierungsprozesses, dieses Feedback in die Spezifikation mit einfließen zu lassen und so eine stabilbe Spec zu erarbeiten.

Betrachtet man den HTML5 Standardisierungsfortschritt, so kann man diese in stabile und experimentelle Spezifikationen einordnen. Stabile Spezifikationen finden sich in allen gängigen, modernen Web Browsern - wie auch dem Internet Explorer 9 - wieder. Die stabilen HTML5 Features können demzufolge auch in Webseiten ruhigen Gewissens eingebaut werden. Semantische Tags sind hier ein gutes Beispiel.

Auf der anderen Seite gibt es Spezifikationen die noch nicht so ausgereift sind und die man eben als experimentell bezeichnen kann, wie zum Beispiel WebSockets.

Der Fall der WebSockets

WebSockets im Browser klingt nach einer guten Idee. Direkte Kommunikation aus JavaScript mit dem Server, ohne Plugin. Die Spezifikation wurde schon in einem frühen Stadium von diversen Browser Herstellern implementiert, was zur Folge hat, das Änderungen direkt an die API Schnittstelle für Entwickler durchgereicht werden und somit der geschriebene Code nicht funktioniert und umgestellt werden muss. Zudem ist nicht abzusehen, ob eventuelle Sicherheitsrisiken in sich ändernden Spezifikationen auftun.

Als Beispiel können wir einen Blick auf die Mozilla Entwicklung werfen, die für jedermann einsehbar ist und dort konkret auf Fehler 602028. Hier die Beschreibung des Bugs:

 The -76 implementation of websockets should be prefixed in an experimental<br>namespace for ff 4, while the final websockets protocol is sorted out in the<br>IETF. 

Man möchte die Implementierung in einen experimentellen Namespace überführen, da das Protokoll aussortiert wurde. Daraufhin gab es gleich einen Kommentar, dass man damit eine Inkompatibilität herbeiführt, da andere Browser diesen Namespace nicht haben.

 We most certainly should not. Chrome and Safari have released -76 support<br>unprefixed, and Opera will do the same. Prefixing in Gecko doesn't gain anybody<br>anything, because any new version that wants to see adoption will have to be<br>compatible with the shipped implementations, regardless of what we do. It only<br>hurts us, because "Firefox doesn't implement HTML5". 

Ein weiterer Kommentar bestätigt, dass die Implementierung sich auf jeden Fall ändern wird und verweist auch darauf, das andere Browser Hersteller dieses Feature ebenso in einen Namespace prefixen werden. [Comment 7]

Die Diskussion schreitet voran. Ein weiterer Kommentar schlägt vor, den Prefix mit der Begründung wegzulassen, Entwickler würden wissen, welche der sich in Entwicklung befindlichen Spezifikationen Codeänderungen mit sich bringen. Demzufolge wäre es in Ordnung, wenn der serverseitiger Code nicht mehr funktioniert und wieder und wieder angepasst werden muss. Das Original liest sich einfach besser [Comment 26]:

 As for prefixing with x-, I would prefer not to do that as we would then keep<br>it around forever and probably not migrate. I think the best strategy is to<br>just keep breaking people to force the expectation that this is still a work in<br>progress, and if you're not aware of that you shouldn't be using it... 

Die Diskussion kommt dann an eine entscheidende Stelle [Comment 51], als jemand die Sicherheitsproblematik der WebSockets Spezifikation anspricht, die es theoretisch möglich macht, die Kommunikation zu manipulieren. Kurz: Es gibt ein Sicherheitsproblem.

Das Aus für WebSockets?

Genau das ist der entscheidende Unterschied zwischen stabilen und experimentellen Spezifikationen. Bisher hat Microsoft im Internet Explorer 9 die Implementierung von WebSockets nicht angegangen, denn es bringt dem Entwickler nichts, mit Features produktiv zu gehen, die noch sehr weit weg von Produktionsreife sind. Firefox und Opera haben nun ihre WebSockets-Implementierungen deaktiviert. Vor allem die Sicherheits- und Kompatibilitätsprobleme waren hier ausschlaggebend.

Ist das nun das Aus für WebSockets? Nein, wir sind nach wie vor mit in der Diskussion um die Spezifikation und auch andere Browser Hersteller sind daran beteiligt (draft-montenegro-hybi-upgrade-hello-handshake-00).

HTML5 Labs Prototypes

Auf der anderen Seite möchten aber Entwickler genau mit diesen Features experimentieren und genau hier kommt HTML5 Labs ins Spiel. Wir bieten dort unsere Beispielimplementierungen für diese experimentellen Zweige an. Zwei Prototyp Implementierungen stehen zur Verfügung: Einmal für WebSockets und einmal für IndexedDB.

WebSockets is a technology designed to simplify much of the complexity around bi-directional, full-duplex communications channels, over a single Transmission Control Protocol (TCP) socket . It can be implemented in web browsers , web servers as well as used by any client or server application. The WebSockets API is currently being standardized by the W3C Web Applications Working Group and the protocol is being standardized by IETF Hypertext Bidirectional (HyBi) Working Group.

Link: WebSockets Prototype

IndexedDB is a W3C draft Web specification for the storage of large amounts of structured data in the browser, using indexes that allow for high performance searches on this data. The IndexedDB API is currently being standardized by the W3C Web Applications Working Group . IndexedDB can be used for browser implemented functions like bookmarks, and as a client-side cache for web applications such as email.

Link: IndexedDB Prototype

Letztere Spezifikation hat mehr an Bedeutung gewonnen und ist daher für uns eine Prototyp-Implementierung Wert. Diese Implementierungen müssen gesondert und bewusst installiert werden. Somit ist jedem Entwickler klar, dass es sich um eine experimentelle Implementierung handelt und diese sich natürlich ändern kann.

Wie geht es weiter?

Es gibt noch weitere Spezifikationen, die man als experimentell bezeichnen kann. Hierzu gehören unter anderem die File API und auch WebGL. Wer mit diesen Features experimentiert, muss sich im Klaren sein, dass diese sich auch ändern mit der Zeit. Browser, die diese direkt implementieren, laufen Gefahr, dass heute geschriebener Code in der Zukunft nicht mehr funktioniert und unter Umständen auch Sicherheitslücken entdeckt werden. Eine Spezifikation in der realen Welt zu benutzen ist erst dann sinnvoll, wenn diese die Hürde des W3C genommen hat und mindestens als stabil gekennzeichnet ist.

Anders gesagt: Der Internet Explorer 9 unterstützt den HTML5 Standard und die stabilen Spezifikationen. Der IE9 ist damit bereit, HTML5 fähige Seiten Millionen von Benutzern hardwareunterstützt performant anzuzeigen. IE9 bietet damit Entwicklern eine gute Basis zur HTML5 Webseiten Entwicklung. Wer darüberhinaus mit den experimentellen Spezifikationen arbeiten möchte, kann dies mit den Prototyp Implementierungen der HTML5 Labs  tun.

Daher der Aufruf an alle Webentwickler: Wer noch nicht mit IE9 Beta an Bord gegangen ist, sollte jetzt mit der aktuellen Platform Preview den Zug nicht verpassen!

1. Holt das Beste aus der Unterstützung von Internet Explorer 9 mit HTML5, CSS3, SVG, DOM, ES5 und mehr heraus.
2. Schaut Euch das Entwicklerhandbuch für IE9 an! Vermeidet Browserweichen, die auf Versionsnummern basieren und testet auf die benötigten Funktionen!
3. Testet Eure Seiten in IE9 Standards Mode für die beste Performance und Interoperabilität und nutzt mit nur wenigen Zeilen Code die Vorteile für Eure Webseiten in Windows 7 mit der Integration in die Taskbar und die Nutzung von Sprunglisten!

Auf www.internet-explorer9.de stellt Microsoft eine Produktübersicht zur Verfügung. Weiterführende Informationen rund um den Internet Explorer 9 finden Administratoren auf Microsoft TechNet und Entwickler auf MSDN.