Skip to main content

CSS (R)Evolution

So aufregend die schöne neue Welt von CSS3 auch ist, so sehr steckt sie noch in den Kinderschuhen. Inkompatibilitäten, freizügige Interpretation des Wortes Standard seitens der Browserhersteller und ein undurchdringlicher Dschungel von Vendor Prefixes machen den Entwicklern das Leben schwer. In diesem Artikel möchten ich auf die Strategie eingehen, mit der Zensations versucht der Situation Herr zu werden.

Progressive Enhancement

... ist ein Buzzword das Adaptive Design in Popularität bei Bullshit-Bingo Jongleuren kaum nachsteht. Im großen und ganzen bedeutet es nur dass der Entwickler seinen Job ernst nimmt. Bei der unheimlichen Bandbreite an Browsern und Endgeräten ist es weder möglich noch sinnvoll Designs überall Pixelgenau gleich darzustellen. Stattdessen wird eine Basisversion des Layouts erzeugt, das auf allen Plattformen die nötigsten Ansprüche erfüllt ohne übertrieben mit unnötigen Bildern oder Javascript-Shims zu arbeiten, die sich negativ auf die Lade- und Ausführungszeit auswirken. Erst in einem zweiten Schritt werden dann abhängig von Unterstützungsgrad des Browsers weitere Effekte und Dekorationen hinzugefügt.

An dieser Stellen weiten sich die Augen von Kunden, Projektmanagern und Grafikern meist vor Schrecken. "Aber das heißt die runden Ecken und Verläufe oder beliebiger anderer Word-Art-Effekt sind in Internet Explorer gar nicht so hübsch?"

Die meiner Meinung nach völlig korrekte Antwort darauf lautet: ! Leute, die mit IE surfen sind gewohnt dass das Internet sch****** aussieht!

Zum Glück gibt es auch eine business-taugliche Variante davon. Prinzipiell sei gesagt dass es mit Hilfe von Grafiken und Fallback-Skripten durchaus möglich ist jeden Mist all die hübschen Dinge umzusetzen die ein Grafiker sich so einfallen lässt. Das hat jedoch negative Auswirkungen:

  • Bounce Rate: Besucher sind ungeduldig. Und zwar viel ungeduldiger als man gerne glauben will. Jeder Sekundenbruchteil den die Seite braucht, um zu laden und sich darzustellen, kostet Kunden. Und Grafiken für Verläufe, runde Ecken, Schatten und ähnliches kosten sehr viel Zeit.
  • Suchmaschinen: Siehe Punkt 1. Auch Google weiß, dass schnellere Seiten zufriedenere Besucher bedeuten und bezieht die Ladezeit deswegen in das Ranking mit ein.
  • Kosten: Ja, Programmierer leben nicht von Bits und Bytes, sondern brauchen etwas zu essen. Und browserübergreifend pixelgenaue Designs umzusetzen ist ein signifikanter Mehraufwand, den leider kaum jemand in Rechnung stellt. An dieser Stelle möchte ich auf einen Beitrag von Lea Verou verweisen, in dem eigentlich alles gesagt wird.

Ja, und jetzt?

Die Gründe warum wir auf Progressive Enhancement setzen wurde denke ich zur Genüge ausgeführt, die Frage bleibt jetzt noch, wie wir das tun. Primär setzen wir dabei auf zwei kleine aber feine Open Source-Tools.

Modernizr

Modernizr ist eine Javascript-Anwendung, die mit der Website mit ausgeliefert wird und das Body-Tag der Website mit Klassen markiert. Diese geben Auskunft darüber, welche Features der Browser unterstützt. So könnte man zum Beispiel einer Box einen einfachen schwarzen Rand verpassen, in echten modernen Browsern wird dieser dann durch einen Schlagschatten und runde Ecken ersetzt:

.box {
  border: 2px solid black;
}

.borderradius .box {
  border-radius: 5px;
}

.boxshadow .box {
  border: none;
  box-shadow: 1px 1px 4px black;
}

Prefixfree

In dem oben genannten Beispiel fällt auf dass nur border-radius und box-shadow deklariert wurde, jedoch verlangen die meisten Browser noch sogenannte Vendor Prefixes für erweiterte CSS-Befehle. Für Safari und Chrome wäre das zum Beispiel -webkit-border-radius, für Firefox -ms-border-radius, für Opera -o-border-radius und Internet Explorer interpretiert ab Version 9 -ms-border-radius. Jeder Entwickler, dem beim Gedanken all diese Befehle extra zu notieren kein kalter Schauer über den Rücken läuft, sollte sich fragen ob er den richtigen Beruf gewählt hat. Das mag jetzt nach Faulheit klingen, Dry or Die ist aber vor allem ein Prinzip, das Kosten spart.

Zum Glück hat sich die in diesem Artikel schon einmal genannte Lea Verou (eine bemerkenswerte junge Dame) des Problems angenommen und das Projekt -prefix-free ins Leben gerufen. Dabei handelt es sich ähnlich wie bei Modernizr um eine einzelne Javascript Datei die nur in die Website eingebunden werden muss. Zur Laufzeit werden dann die Stylesheets nach CSS Befehlen durchsucht und vollautomatisch an die Bedürfnisse des jeweiligen Browsers angepasst.

Pro & Contra

Sowohl Modernizr als auch -prefix-free werden beim Client ausgeführt und sind damit von Javascript abhängig. Das mag auf den ersten Blick ein Problem sein, ein Browser der Javascript nicht ausführt wird jedoch ohnehin keine CSS3-Effekte kennen und die Seite verhält sich gemäß Progressive Enhancement ganz normal.

Das ernstzunehmendere Problem ist der sogenannte FOUC - Flash of unstyled content. Wenn die Seite fertig geladen ist stellt der Browser sie dar bevor die beiden Tools ihre Arbeit verrichten konnten. Je nach Ausführungsgeschwindigkeit kann es dabei vorkommen, dass für einen Sekundenbruchteil die abgespeckte Version des Designs angezeigt wird, und dann erst die erweiterten CSS Regeln in Kraft treten. Aber auch hier handelt es sich um ein primär theoretisches Problem. Moderne Browser sind mit derart schnellen Javascript-Engines ausgestattet dass der beschriebene Effekt auch mit geschultem Auge kaum wahrzunehmen ist. Jemandem der nicht danach sucht fällt es gar nicht erst auf. Und ältere Browser arbeiten nur mit der Basisvariante die sich dann auch nicht mehr ändert. Abgesehen davon wäre die einzige Alternative statt CSS-Effekten Bilder zu verwenden, die auch erst nachgeladen werden müssen und nicht sofort dargestellt werden.

Less but not least

LESS CSS ist ein weiteres Tool das zwar nicht unmittelbar notwendig, aber gerade für den Einsatz mit Modernizr unheimlich praktisch ist. LESS ist eine Art erweiterter Dialekt von CSS der eine Reihe von Zusatzfeatures wie Nested Rules, Variablen, Mixins und Rechenoperationen zur Verfügung stellt und vom zugehörigen LESS-Compiler in standardkonformes CSS übersetzt wird. Das spart Unmengen an Codezeilen und erhöht die Übersichtlichkeit und Wartbarkeit drastisch. Es gibt genug Stimmen, die sich gegen CSS-Preprocessors aussprechen und auch aus guten Gründen. Unbedachte Nutzung von Verschachtelungen und Mixins kann zu übergroßen Stylesheets und undurchsichtiger Selektorspezifizität führen. Große Macht bringt große Verantwortung oder frei nach Bjarne Stroustrup:

! In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg.

Wird nicht veröffentlicht