Hallo zusammen,

Heute möchte ich eine Kleinigkeit über HTML5, CSS3 und „alte Browser“ schreiben… Es dürfte bekannt sein, das die älteren Browser mit den neuen Features nicht viel anfangen können und deshalb das Web und dessen Entwicklung (mehr oder weniger) einschränken – Aus diesem Grund wird leider häufig auf den „neuen Standard“ verzichtet, um auf möglichst allen Plattformen ein gleichbleibendes Resultat zu ermöglichen.

Nachvollziehbar, aber nicht notwendig!

Ich fürchte viele Entwickler (oder „Entscheider“) wissen gar nicht, das es auch anders laufen kann: Es gibt dutzende Skripte und Fallback-Lösungen für die fehlende Kompatibilität. Okay, zugegeben, nicht alle HTML5 Features (Bzw. Javascript APIs) lassen sich mit Hilfe von nativem Javascript simulieren – Doch die wichtigen Features (vor allem semantischer Natur) lassen sich benutzen.

HTML5 Elemente in alten Browsern

Um HTML5 Elemente wie z.B. nav, section, article, … nutzen und entsprechend stylen zu können benötigen wir ein kleines Skript namens „html5shiv„. Die Nutzung ist sehr einfach:

<!--[if lt IE 9]>
<script src="pfad/zum/javascript/html5shiv.js"></script>
<![endif]-->

Außerdem benötigen wir eine „reset“ CSS Datei, welche sämtlichen HTML5 spezifischen Elementen einen Standard-Style (z.B. „display:block;“) zuweist – Hierzu können wir das 1140 CSS GRID benutzen.

Natürlich gibt es einige Alternativen zu html5shiv, Heute möchte ich mich aber nicht alleine um die HTML5 Semantik beschäftigen, sondern viel mehr auf die weiteren Features und vor allem Fallbacks eingehen. Hier hilft eine Bibliothek ganz besonders…

Prüfen welche Features unterstützt werden

Für diesen Schritt können wir die Bibliothek „Modernizr“ benutzen. Mit Hilfe von modernizr lässt sich prüfen ob ein Browser bestimmte Features unterstützt – Idealerweise führen wir anderen Code aus wenn der Browser keine native Unterstützung mitbringt:

// Nach dem einbinden von Modernizr...

if (Modernizr.touch) {
   // Touch-events einbinden.
} else {
   // Normale click- und mouse*-events einbinden.
}

Außerdem ist Modernizr in der Lage (Javascript oder CSS) Dateien nachzuladen! Dadurch können wir Code für individuelle Fälle zusammenstellen und separat abspeichern. Dies funktioniert mit Hilfe der Implementation von yepnopejs (via „load()“ Methode):

// Prüft ob die 'Geolocation API' verfügbar ist.
Modernizr.load({
   test: Modernizr.geolocation,
   yep : 'geo.js',
   nope: 'geo-fallback.js'
});

Es lassen sich auch mehrere Prüfungen und nachzuladende Dateien gleichzeitig definieren:

Modernizr.load([
   {
      // Prüft ob die CSS3 Features "font-face" und "gradients" (Farbverläufe) verfügbar sind.
      test : Modernizr.fontface && Modernizr.cssgradients,
      nope : ['css3-fallback.js', 'css3-fallback.css']
   },
   {
      // Prüft auf HTML5 Websockets und die JSON Klasse.
      test : Modernizr.websockets && window.JSON,
      nope : 'json-and-websockets-fallback.js',
      both : [ 'scripts.js', 'extra.js' ],
      complete : function () {
         myApp.init();
      }
   },
   'post-analytics.js'
]);

Fallbacks für was…?

Wie Anfangs erläutert gibt es für viele Fälle Fallback Lösungen – Einige davon habe ich bereits in früheren Postings kurz aufgeschnappt! In „Interaktive Diagramme für alle Browser mit jqPlot“ hatte ich bereits von „excanvas“ berichtet. Diese Bibliothek simuliert die Canvas API in älteren Browsern (wie z.B. dem IE7).
Für das Video und Audio Element können wir klassischerweise diverse Flasplayer benutzen, während wir für die Geolocation API auf Ajax Requests und öffentliche APIs ausweichen könne – z.B. der freegeoip web service. Die Daten können mit Hilfe eines einfachen Requests abgerufen werden:

http://freegeoip.net/{format}/{ip_or_hostname}

Das Format kann json, xml oder csv sein… Die IP oder der Hostname – Naja, wie der Name schon sagt eine IP oder ein Hostname 😉

Vor allem aber was das Styling angeht finden wir unmengen von Fallbacks… Unter anderem für Schatten, abgerundete Ecken, Farbverläufe und ich meine sogar für CSS Animationen (die dann einfach nach Javascript „übersetzt“ werden).

Fazit und abschließende Worte

Natürlich sind nicht ALLE Features von HTML5 und CSS3 in den alten Browsern mit Hilfe von Fallbacks machbar… Doch das bedeutet nicht, das wir darauf verzichten sollten. Wenn wir, als Entwickler, auf tolle Features verzichten um eine Webseite auch noch im IE7 -einem mehr als 6 Jahre alten Browser- hübsch darstellen zu können, läuft irgendwas falsch. Ich finde es großartig was Google & Co. machen: Sie ziehen einen sauberen Strich und optimieren ihre Dienste (ganz offiziell) nicht länger für alte Browser – Mitte November 2012 wurde Beispielsweise der Supports für den IE8 beendet.

Ich persönlich achte bei privaten Projekten eigentlich immer nur auf die aktuelle Browser-Generation… Und ich denke alles andere macht bei diesen Statistiken nicht viel Sinn.

In diesem Sinne wünsche ich euch allen Happy Coding und hoffe ihr schau auch nächste Woche wieder rein!

3 comments on “HTML5 und CSS3 in alten Browsern

  • Hallo. Leo,

    du schreibst: Vor allem aber was das Styling angeht finden wir unmengen von Fallbacks… Unter anderem für Schatten, abgerundete Ecken, Farbverläufe und ich meine sogar für CSS Animationen (die dann einfach nach Javascript “übersetzt” werden).

    – Ja, man kann sich viel Mühe machen und unzählige JavaScript-Skripte einbinden, um das Design auch in Uralt-Browsern genauso gut wie in den aktuellen aussehen zu lassen. Und früher war es ja tatsächlich auch oberstes Gebot für Webdesigner, bloß keine Abweichungen des Aussehens der Website je nach Browser zuzulassen.

    Aber ich denke, dass es einfach zu viel Zeit kostet, sich immer noch um alte Browser zu kümmern. Wer sie benutzt, ist es ja im Grunde selber Schuld (von den Fällen mal abgesehen, wo arme Angestellte mit dem in der Firma installierten Uralt-Browser vorlieb nehmen müssen und keinen neueren installieren dürfen). Benutzer mit aktuellen Webbrowsern erleben die Seiten eben etwas schicker, die anderen halt etwas weniger stylish.

    Die semantischen HTML5-Elemente auch alten Browsern anbieten zu können, finde ich allerdings schon eine sinnvolle Sache. Allerdings verlangsamt ja jedes Skript bzw. jede Bibliothek und jede zusätzliche CSS-Datei die Seiten ein bisschen.

    Fazit: leicht hat man es nie als Webdesigner.

    Danke für den interessanten Artikel!
    Torsten

    • Hallo Torsten,

      vielen Dank für deinen Kommentar. Ich stimme dir absolut zu! Ich versuche (privat) eigentlich immer die sogenannten „Evergreen“ Browser zu unterstützen. In anderen Browsern reicht es mir aus, wenn die Seite funktioniert 😉

      Viele Grüße
      Leo

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.