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?

HTML5 entpuppt sich langsam als ein würdiger Nachfolger des Ajax-Hypes. Das mag zwar von Produkten wie dem iPhone und iPad beeinflusst worden sein, hauptsächlich aber natürlich die fortschreitende Entwicklungen der Browserengines Gecko und WebKit. In gewisser Weise natürlich auch Opera, und — das wird die Zukunft zeigen — wohl auch Trident von Microsoft.

Obwohl CSS technisch gesehen nichts mit HTML zu tun hat, erfahren die CSS3-Features derzeit in der HTML5-Welle eine außergewöhnliche Bedeutung.

Da CSS3 noch nicht endgültig verabschiedet wurde (wenngleich es da auch wahrscheinlich keine größeren Überraschungen geben wird), gibt es leider nicht für alle CSS3-Eigenschaften eine breite Basis — sprich: Gleichheit. So konnte man lange Zeit in Mozilla Browsern nur mit der Eigenschaft -moz-opacity: 0.9 einen Alphawert von 90 für ein Element definieren. Und WebKit hatte natürlich -webkit-opacity: 0.9. Und Opera mit -o-opacity: 0.9. Mittlerweile ist das glücklicherweise einfacher: Die CSS2-Eigenschaft� opacity: 0.9 wird von beiden unterstützt, wie auch allen anderen Browsern mit CSS2-Unterstützung.

siehe http://girliemac.com/blog/2009/04/30/css3-gradients-no-image-aqua-button/

Das gleiche Spielchen können wir jetzt auch beobachten, allerdings mit Eigenschaften, welche um einiges komplexer und umfangreicher als die Alphawert-Steuerung sind.

Auf CSS3 Please! kann man beispielsweise auf einem Blick ein paar ausgewählte CSS3-Eigenschaften� in Action sehen — inkl. deren vorläufigen Browserengine-Implementierungen. Dabei sind die Auswahlen nicht zufällig (und deshalb auch dieser Artikel). Sie sind allesamt sehr nützlich für Webdesigner, weil sie bisher notwendige Grafikbearbeitungen unnötig machen:

• Farbverläufe
• runde Ecken (sic!)
• Rotationen
• Schatten

Der Teufel steck im Detail, denn es sind einige Dinge zu beachten, um bereits jetzt Photoshop in die Tonne zu hauen.

Unterschiedliche Namen der vorläufigen Eigenschaften…

Wie bereits erwähnt war das Spiel bei opacity relativ einfach: jeweils den Prefix des Supports (moz, o, webkit) anfügen und gut war.

.alpha { /* Regel mit Unterstützung für Browser ohne endgültigen/vollständigen CSS2-Support */
-moz-opacity: 0.9;
-o-opacity: 0.9;
-webkit-opacity: 0.9;
opacity: 0.9;
}

Man könnte also denken, das die Umstellungen relativ einfach sind — und daher schnell den Rückschluss ziehen, dass der Hersteller doch direkt “opacity” hätte nehmen können. Klar, heute sind wir schlauer.

Sehen wir uns mal an, wie die Namen der Regeln für border-radius aussehen; diese Eigenschaft steuert den Radius der Ecken (“runde Ecken”).

.roundedBox {
-moz-border-radius: 10px; /* jeder Firefox */
-webkit-border-radius: 10px; /* alle aktuelle WebKit basierte Browser */
border-radius 10px; /* CSS3 */
}

Sauber. Allerdings gibt es neben der CSS3-Eigenschaft border-radius auch die detaillierten Eigenschaften border-top-left-radius, border-top-right-radius, border-bottom-left-radius und border-bottom-right-radius. Während WebKit das gleiche Namensschema hat (immer mit dem Präfix -webkit), hat Mozilla ein eigenes: -moz-border-radius-topright, -moz-border-radius-topleft u.ä. Umpf.

Anmerkung: Die Spezifikation der Regel als solches sagt nichts darüber hinaus, wie sie auch in der Browserengine implementiert wurde. Da gibt es einen lesenswerten Beitrag über border-radius vom IE9-Team (!!).

… unterschiedliche Konfigurationsmöglichkeiten…

Anderes Beispiel, gleiche Problematik: Gradienten oder Farbverläufe. Während Mozilla dies über die CSS-Background-Eigenschaft -moz-linear-gradient ab Geck 1.9.2 (=Firefox 3.6) vorläufig implementiert hat, heißt es bei WebKit/Safari -webkit-gradient.

Übrigens: Es ist auch nicht verwunderlich, dass hier Apple genannt wird. Einige Module der CSS3-Spezifikation (etwa Animationen und Transformationen!) werden von Apple-Entwicklern beim W3C angeführt — und werden bereits erfolgreich in den bereits genannten Produkten produktiv genutzt.

So sind folgende zwei Zeilen an für sich im jeweiligen Browser gleich bedeutend:

background-image: -moz-linear-gradient(top, #444444, #999999); /* FF3.6 */
background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0, #444444),color-stop(1, #999999)); /* Saf4+, Chrome */

oder, alternatives Konfigurationsmuster:

background: -moz-linear-gradient(0 0, #000, #fff);
background: -webkit-gradient(linear, 0 0, 0 100%, from(#000), to(#fff));

Hinweis: Während Mozilla eine zweite Eigenschaft -moz-radial-gradient für radiale Gradienten — Kreise — eingeführt hat, wird dies bei WebKit über den ersten Parameter gesteuert.

Hat noch jemand Einwände, dass die Browserengines vorläufige Implementierungen auch als solche explizit einführen? Nicht wirklich, oder?

… und der Internet Explorer?

Traditionell braucht der Internet Explorer natürlich eine Extrawurst. Das wiegt jedoch nur unschwer als die Lösungen der anderen. Naja, fast. Alle Lösungen sind aus technischer Sicht des CSS-Standards auch nur proprietäre Lösungen.

Microsoft hat seit Jahren ihre eigenen Lösungen unter dem Sammelcontainer filter abgelegt. So heißt das Pendant zu dem oberen Verlauf:

filter: � progid:DXImageTransform.Microsoft.gradient(startColorStr='#444444', EndColorStr='#999999');

Nun ja, dies galt zu mindestens für Internet Explorer 6 und 7. Bei 8 hat sich Microsoft dem Schema der anderen Entwickler genähert, und die proprietäre Eigenschaft filter als solche gekennzeichnet: -ms-filter und Eigenschaften in Anführungszeichen. Ignoriert man bei einer Überprüfung der CSS-Eigenschaften die proprietären Eigenschaften (die mit einem Strich beginnend), so kann man jetzt in der Theorie ein valides CSS erhalten. So weit in der Theorie.

-ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorStr='#444444', EndColorStr='#999999')";

Leider hat Microsoft zeitgleich für manche Eigenschaften die Variante über filter deaktiviert. Daher gilt: Ab sofort muss man beide Anweisungen im Doppelpack mitangeben um IE6, 7 und 8 ansprechen zu können. Oder wahlweise die Anweisungen in die entsprechenden Conditional Comments packen. Ich wünsche viel Spass beim Chaos.

Schatten

Die Anwendung der Schatten ist ähnlich einfach wie bei den Gradienten, abgesehen von folgenden Problematiken im Internet Explorer:

• Die Konfiguration eines Schattens kann zu einer wahren Try-and-Error-Orgie führen, weil man selten die Box mit allen 8 Richtungen im Kopf hat (bzw. daran denkt).
• Der Internet Explorer hat das typische hasLayout-Problem (Lösung: zoom: 1).
• Sobald ein Element nicht static ist (etwa relative) wird der Schatten unbrauchbar.

Beispiel für umfangreiche vollständigen Schatten in allen Browsern.

Werkzeuge

Als “Nachschlage-Werk” kann man sicherlich die simple Seite CSS3 Please! nutzen. Ein spezieller CSS Gradient-Generator ist vorhanden, aber ohne IE-Support.

Prinzipiell unschlagbar ist das Script ie-css3.htc — es liest die CSS3-Eigenschaften border-radius, box-shadow und text-shadow und erstellt dynamisch die proprietären Microsoft-filter-Eigenschaften. Die HTML Components sind im Grunde kleine Javascripts zur Erweiterung des Internet Explorers.

Eine Erweiterung für Gradienten wäre wünschenswert, falls jemand sich spontan dazu veranlasst sieht.. bitte Der Autor hat sich leider bisher auf meine Mail nicht gemeldet.

Ein kleiner Schönheitsfehler, der scheinbar mit HTCs selber zu tun hat: Die Angabe im CSS muss mit absoluten Pfad gesehen. Das ist unschön und für Webanwendungen mit dynamischen Kontexten schlicht unbrauchbar.

Die Vergessenen

Bei aller Liebe zu den technischen Neuerungen, man sollte nur eines nicht vergessen: Viele Nutzer haben aus verschiedenen Gründen noch einen Firefox 3.5 oder gar 3.0 am Laufen. Und auch Opera-Nutzer sind erst in den neueren Versionen in den Genuß von einigen, aber nicht allen, Eigenschaften gekommen. Bei den WebKit-Benutzern hat wohl die Mehrzahl eine aktuelle Version, sei es durch den automatischen Google-Chrome-Updater oder die starke Verbreitung der 4er-Version von Safari. (Notorische Update-Verweigerer sind selbst für ihr Dilemma verantwortlich.)

• Gradient: Eine Fallback-Lösung kann man unter Umständen über die Eigenschaft background-image erstellen.
• Border-Radius: Nicht ohne HTML-Markup-Änderungen.
• Shadow: Schwer bis unmöglich.

Mit anderen Worten heißt das: Sofern border-radius und box-shadow nur nice-to-have Features sind oder es vernachlässig ist, wenn ältere Browser die Seite unvollständig anzeigen, stehen dem Einsatz keine Grenzen mehr!

Nützliches

• W3C Standards & Drafts: CSS
• Mit-diesem-Link-kann-dein-WebKit-Browser-die-aktuelle-Seite-zur-Seite-kippen.