Ich erwähnte bereits gestern, dass der aktuelle HTML5-Hype kaum zu bremsen ist. Man begegnet ihm in Form von Video, aber auch in “HTML5-Tutorials” oder CSS3-Survival-Kits. Okay, gerade letztes habe ich ja indirekt auch angesprochen. Womit wir wieder am Anfang dieses Absatzes wäre (Achtung: Rekursionswitz).

Oft wird in Diskussionen oder Artikel über den Themenpool “Apple, Adobe, Flash, HTML5, Video” gesagt, dass HTML5 das Adobe Flash Format oder den Player abschafft. Dann sagen Kritiker wieder: Nein, Flash ist viel besser. Einfacher. Performanter. Verbreiteter. Bekannter. Leistungsfähiger.

In meinen Augen wird sich die Entwicklung ähnlich wie bereits in der Vergangenheit fortführen: das sukzessive Replacement von alten in neue, bewährte Techniken.

Wenn nicht jetzt…

Früher gab es eine Zeit, in der konnte man Rolloverbuttons entweder gar nicht oder nur über Umwege in allen Browsern lösen – die Techniken waren damals Javascript. Heute in der Regel ausschließlich CSS (seitdem der IE das auch kann). Daher lösten einige gewitzte Designer das Problem mit Mini-Flashbuttons. Heute jedoch sind solche Buttons sowie komplette Navigationsmenüs technisch gesehen “out”; und wer so etwas immer noch abliefert, muss sich die Frage gefallen lassen: “Warum…?”.

Auch dynamische Aktivitäten ließen sich eine Zeit lang einfacher in Flash lösen (gepaart mit entsprechenden Effekten) – bis ein paar Menschen herausfanden, dass man nur ein Modewort braucht, um alternative Techniken sich zu nutze machen zu können. Heute gibt es kaum eine Seite, die kein Ajax in irgendeiner Form braucht.

Kennt noch jemand die “coolen” Flash-Chat-Apps? Sie waren damals schon ein Graus und stammten aus einer Zeit, als Ajax bei Google nur Suchergebnisse für einen Fußballverein oder einen Haushaltsreiniger ergaben. Heute wird sowas in Ajax (und offenen Verbindungen serverseitig) gelöst. Man stelle sich das mal vor: Goggle Mail oder Facebook mit einem Flash, welches sich jedes mal neu lädt. (Okay, schlimmer wäre nur noch eine komplette Fullpage-Anwendung.)

Ebenfalls nahezu erfolgreich wurden die Fotoalben verdrängt, die lange Zeit auf Flash basierten. Während Flickr hierbei ein schlechtes Beispiel wäre, zeigen etwa Googles Picasa Webalben schon seit Jahren, was möglich ist. Oder Apples .mac, jetzt MobileMe. Und auch jeder zweite Internetseite nutzt irgendeine Form von Javascript-Plugin, welche eine Art “Lightbox” (manchmal mit automatischer Skalierung, FadeIn, FadeOut) zaubert.

Es gab schon immer die Early Adopters – und eben diejenigen, die entweder auf Nummer sicher gehen wollen. Naja, oder die einfach zu faul umstellen sind. Letzteres ist bei HTML5 o.ä. weniger der Fall, da es tatsächlich noch kein (bindender) Standard ist. Es schadet jedoch nicht, die bereits vorhandenen Möglichkeiten anzuschauen und ggf. zu nutzen.

Seitdem Webseitenbetreiber gemerkt haben, dass man auch mittels Ajax auch Werbung in eine Klickserie einbinden kann – *seufz* – wird es meiner Meinung auch verstärkt genutzt. Irgendwo muss ja auch der bekannte Wermutstropfen bei der Sache bleiben.

…wann dann?

In den letzten Wochen, und sicherlich auch noch in den nächsten Monaten, erleben wir das gleiche eben mit neuen technischen Komponenten von Webseiten. Wichtig für eine Akzeptanz ist, dass es während der Umstellung nicht zu inversiv ist. Gleichzeitig kann die Umstellung aber nur richtig funktionieren, wenn alle an einem Strang ziehen. Ein bisschen wie das Henne-Ei-Problem, jedoch machen derzeit ohne Ausnahme alle Browserengine-Hersteller gute Fortschritte.

Folgende Komponenten haben gute Chancen, in den nächsten Monaten und Jahren für moderne Browser von der Bildfläche zu verschwinden.

  • Musikplayer sind bisher als Flash gelöst, weil nicht jeder Browser einen MP3-Link im Browser abspielt – viele bieten dann einen Download an. Beides ist jedoch nicht “embeddable”.. Sicherlich, wir werden bei dem Audio-Tag mit einer HTML5-OGG/MP3/Flash-Weichenkonstellation ein paar Jahre leben müssen. But who cares?
  • Videoplayer sind ebenfalls als Flash gelöst; aus den gleichen Gründen wie Musik. Der Flashcontainer wurde aus der Not gewählt, mangels Alternative. Tatsächlich sind aber Werbeeinblendungen und Editorfunktionalitäten noch in keinem HTML5-Player implementiert (wenn doch, bitte ich um eine Anmerkung). Aber für die einfachen “only play a video”-Fälle reicht das Videotag aus. Genau wie bei Audio wird es auch hier auf eine Weiche hinauslaufen. But who cares? Flash wird auch stets auf zwei Arten eingebunden, dafür gibt es Frameworks.
  • Schriften sind eins der Themen, wieso man bisher immer Grafiken oder sogar Flashs verwendet hat. Grafiken sind statisch und müssen beim Design angelegt werden, Flash ist dynamisch (etwa wichtig für die I18n). Es lassen sich mit CSS3 gute Fallbacks mit Text+Hintergrundgrafik erzeugen. Im Endeffekt haben schriftlastige Seiten und alte Clients dann mehr Traffic als neuere Clients, aber das macht die Natur der Technik ja auch so gut.

Weniger schnell werden sich jedoch andere gute HTML5-Features verbreiten:

  • Offline-Features für Offline-Sitzungen (inkl. einer Datenbank) sind bisher eine technische Barriere gewesen, weshalb man ein Internetbrowserplugin brauchte. Allerdings kann man hier nicht mit Weichen arbeiten sondern muss tatsächlich zwei parallele Versionen (HTML5, Flash) anbieten. Auch wenn dies “nur” Aufwand für die GUI ist, so ist das Mehraufwand, der abschrecken kann. Da ist es egal, wenn HTML5 auch simple Datenbankstrukturen aufweisen kann – man muss ja eine Alternativlösung für ältere Browser haben.
  • Animationen und Transformationen stecken auch im Moment noch in der Entwicklung – tatsächlich kann man sie auch hauptsächlich im WebKit und in Apples MobileSafari (nicht 100% synchron mit WebKit oder gar Safari4) erleben. Hier ist eine Fallbacklösung ebenfalls schwierig und bedarf tiefer Einschnitte ins HTML-Markup als das sich da jemand darauf – vorerst – einlassen wird. Zu mindestens für einfache Dinge wie “sliden” kann man jedoch eine JS-Api nutzen, und damit quasi von hinten herum das Feld der unsupported Browser aufräumen. Das wird sich aber zeigen.

Interessant wird es beim Thema Werbung. Prinzipiell scheint mir die Branche aufgeschlossen zu sein, auch neue Techniken (Stichwort: Damals & das “DHTML”) zu nutzen. Ich würde sogar soweit gehen, dass sie es besser steuern könnten, in dem der Adserver einfach nach dem Useragent das passende Codefragment ausgibt. Zur Zeit könnte etwa die etwas ungelöste Frage, wie man HTML5-Werbung vernünftig blockt, für die Branche interessant sein. Vielleicht analysieren die Adblocker von Morgen die Koordinaten und Größenangaben von HTML-Elementen, um Blöcke von Standard-Werbeformaten zu erkennen?