Dienstag,
22. Mai 2012

Die Bewertung von fremdem Programmcode hinsichtlich Qualität, Flexibilität und Robustheit der gebotenen Features ist immer wieder knifflig, schließlich braucht es gute Kenntnisse, um sich in die fremden Quelltexte hineinzudenken und ggf. Schwachstellen zu erkennen. Das gilt für PHP oder JavaScript genauso wie für CSS (auch wenn hier nicht wirklich programmiert wird).

Ich schreibe dies auf, weil ich durch meine Arbeit an YAML und die eigene Analyse von weit über 50 CSS-Frameworks einen gewissen Blick für die Details gewonnen habe und ich mich schon mehrfach über die oberflächliche Vorstellung von CSS-Frameworks oder Vergleiche verschiedener Projekte in der Fachpresse geärgert habe. Zu oft werden ganze Scharen von CSS-Frameworks (und Dinge, die gar keine CSS-Frameworks sind) nur mit herauskopierten Textschnipseln aus deren Projekthomepages vorgestellt und viel zu selten erfolgen Empfehlungen und Bewertungen der Projekte auf der Grundlage eines wenigstens grundlegenden Code-Reviews.

Deshalb will ich heute ein paar Hinweise geben, die ich zur Evaluierung von CSS-Frameworks nutze. Ich stelle einige Kritieren vor, nach denen ich mir einen ersten Eindruck über neue Projekte verschaffe und eine Bewertung vornehme. Ich nenne in diesem Beitrag bewusst keine Beispiele, denn ich will nicht mit dem Finger auf andere Projekte zeigen, sondern aus meiner Erfahrung heraus Hilfestellung bei zur Evaluation von CSS-Frameworks geben.

Update 25.5.2012: Ich habe soeben den Kriterienkatalog gerade noch um zwei wichtige Punkte (Barrierefreiheit und “Wider den Hype”) erweitert.

Browserkompatibilität

Als erstes stellt sich die Frage, welche Browser unterstützt werden und noch wichtiger: Welche nicht? Die Frage zielt in erster Linie auf die alten IE-Versionen, aber nicht nur auf den IE, denn auch Firefox und Co. sind nicht bugfrei. Der Hintergrund ist folgender: Mit den zahlreichen neuen Möglichkeiten von CSS3 lässt sich Selektoren sehr viel schlanker schreiben. Während in CSS2-Zeiten viele separate Klassen definiert werden mussten, um bestimmte Eigenschaften einzelnen Elementen an einer ganz bestimmten Stelle im Quelltext zuzuweisen, bietet CSS3 mit seinen Struktur-Pseudoklassen, z.B.: E:nth-child(n) oder E:nth-of-type(n), elegante Wege, ohne zusätzliches Markup in Form von Klassen auszukommen.

Diese Entwicklung ist grundsätzlich gut, allerdings steigt bei einer derartigen Codebasis schnell der manuelle Aufwand, falls der IE8 oder der IE7 zu unterstützen sind. JS-basierte Polyfills sind in der Regel hier keine wirkliche Hilfe, denn sie fressen bei den heute üblichen flexiblen (responsive) Layouts viel Performance auf den schon ohnehin langsamen JS-Engines dieser veralteten Browser. Ein CSS-Framework auf Klassen aufzubauen, ist unabhängig davon auch weiterhin sinnvoll, denn auf diesem Wege erreicht man den höchsten Grad der Unahängigkeit vom Markup und damit sehr große Flexibilität in der Anwendung.

Es gibt aktuell erste Projekte, die ein klassenloses Konzept bieten mit dem Argument, Markup zu sparen. Diese Projekte basieren auf CSS-Präprozessoren, womit die Eigenschaften, die üblicherweise in wiederverwendbaren Klassen zusammengefasst werden, direkt den betreffenden Elementen zugewiesen werden. Bei Layouts niedriger Komplexität ist dieser Weg nicht unattraktiv. Bei komplexeren Layouts allerdings führt er schnell zu einer Vervielfachung des Codeumfangs, weil einzelne Eigenschaften wieder und wieder an Elementselektoren gebunden werden müssen, anstatt sie in Klassen zusammenzufassen.  Die Entscheidung darüber, welcher Weg der bessere ist, hängt deshalb stark vom eigenen Workflow und der Komplexität des Layouts ab.

Deshalb: Das Framework sollte klare Aussagen machen zu den unterstützten, bzw. nicht-unterstützten Browsern. Klären Sie für sich, wie aufwändig es für Sie wäre, im Bedarfsfall die fehlende Unterstützung für einen nicht-unterstützten Browser zu eigenständig ergänzen? Denn dieser Aufgabe müssen Sie sich stellen, wenn es Ihr Auftraggeber wünscht.

Grid-Funktionalität

Die überwiegende Masse der CSS-Frameworks stellt in erster Linie Layout-Komponenten bereit und dies in aller Regel in Form von Grids. Die Anforderungen hierfür haben sich mit dem Trend zu Responsive Designs grundlegend verändert, was vielen Anwendern, aber leider auch vielen Framework-Entwicklern offensichtlich noch nicht bewusst ist.

Der Anwender muss wissen, in welcher Maßeinheit (px, em oder Prozent) die Grid-Spalten und insbesondere die Zwischenabstände definiert sind. Ob ein Grid aus 5,8,12,16 oder 24 Spalten aufgebaut wird, ist wichtig für die Robustheit des Layouts. Flexible Grids basierten auf Breitenangaben in Prozentwerten und sind daher beim Rendering des Browsers Rundungsfehlern unterworfen. Je feingliedriger das Grid, desto mehr wirken sich diese Rundungsfehler optisch aus. Elliot Jay Stocks hat dazu im Januar einen interessanten Beitrag verfasst, zu dem ich mir auf Google+ auch schon einige Gedanken gemacht habe.

Das Grundproblem bei Grids mit Prozentbreiten ist, dass sich die Rundungsfehler innerhalb einer Reihe von Grid-Spalten aufaddieren und in Browsern mit schlechtem oder nicht vorhandenem Subpixelrendering durch Abrunden auf ganze Pixel zu einem hässlichen, sichtbaren Versatz führen und in den älteren IEs durch deren grundsätzliches Aufrunden zu Float-Drops und damit zu massiven Layoutproblemen führen. Das simple Konzept fixer Gridbausteine lässt sich nicht durch einfaches Ändern der Basiseinheit auf Flexibilität trimmen.

Ein wirksames Mittel zur Erhöhung der Robustheit flexibler Grids ist das Kleinhalten der gleichrangingen Gridspalten in einer Hierarchieebene. Um dennoch die notwendige Flexibilität in der Anwendung zu gewährleisten, muss das Verschachteln von Grids möglich sein, um beispielsweise eine 66 Prozent breiten Inhaltsbereich für einzelne Elemente nochmals in zwei oder drei Segmente zu teilen. Was auf den ersten Blick so einfach klingt, ist bei vielen CSS-Frameworks, die flexible Grids anbieten, aber gar nicht möglich, weil in diesen Projekten die Zwischenabstände als Prozent-Werte in Form von Margins oder Paddings dem gleichen Element zugewiesen werden, welches auch die Breiteninformation trägt.

Hier ein vereinfachtes Beispiel für einen Grid mit 5 Spalten (jede Spalte 20% breit):

.col {
  float: left;
  width: 19%; /* column width */
  margin-right: 1%; /* gutter */
}

Das Problem: Bei der Schachtelung eines so aufgebauten Grids berechnet sich dieser Randabstand nach der Größe des Elternelementes und damit schrumpft der Rasterabstand und das Gridraster wird zerstört. Leider begehen diesen Fehler zahlreiche Framework-Entwickler, weil sie px-basierte Grids 1:1 auf Prozent-Angaben umstellen, ohne sich dieser Problematik bewusst zu sein. Mit dem Aufkommen des Responsive Design sind eine ganze Reihe neuer CSS-Frameworks veröffentlicht worden, die flexible Grids anbieten. Leider ist aus meinen Erfahrungen hier viel Blendwerk und technisch unausgereifte Lösungnen dabei, die keine robusten, komplexen flexiblen Layouts ermöglichen.

Deshalb: Den technischen Aufbau eines Grids sollte man sich in jedem Fall genauestens ansehen und verstehen. Testen Sie Demoseiten eines CSS-Frameworks nicht nur in modernen Browsern sondern ganz bewusst in älteren Versionen (IE6-8, Firefox 3.6, Opera 10/11). Dort trennt sich meist schnell die Spreu vom Weizen.

Synthetische vs. Real World Beispiele

Die eben erläuterten Anforderungen an flexible Grids zeigen, wie wichtig es zur Einschätzung der Robustheit eines Frameworks ist, gute Demos/Beispielseiten zur Verfügung zu stellen. Hierbei sind sowohl synthetische Beispiele sinvoll, allein auf die Präsentation eines speziellen Features abzielen (z.B. die Darstellung aller vordefinierten Teilungen eines Grids), aber aber – und das ist nicht zu unterschätzen – relatitätsnahe Anwendungsbeispiele, denn erst in Verbindung mit den Inhalten (Texten, Bildern, Tabellen, Formularen) zeigt sich, ob eine Framework-Komponente wirklich robust ist (also mit unterschiedlichsten Inhalten und in unterschiedlichsten Anwendungsszenarien) einsetzbar ist.

Ein weiteres Beispiel hierfür sind Formularbausteine. Nicht wenige CSS-Frameworks liefern neben den Layoutkomponenten auch Bausteine zum einfacheren Erstellen von Formularen an. Hier sollten sie sich frühzeitig anschauen, welche Freiheiten Ihnen diese Bausteine bieten. Greifen die Formularregeln des Frameworks global oder werden sie erst durch eine Klasse aktiv? Das ist schon deshalb wichtig, weil viele Content Management Systeme eigene Formulargeneratoren mitbringen, die sich nicht ohne weiteres im Markup an die Vorgaben des Frameworks anpassen lassen. Es sollte also immer eine Opt-In Lösung sein, um unnötige Konflikte zu vermeiden.

Deshalb: Testen Sie CSS-Frameworks in Real-World-Szenarien. Wenn es nur synthetische Demos gibt, kopieren Sie selbst Bilder, Tabellen oder Formulare in den Code und loten sie die Grenzen aus. Grenzen gibt es immer, und es ist gut, sie von vornherein zu kennen.

Modularität, Funktionalität und Design

Mit dem Funktionsumfang eines Frameworks steigt nicht nur die Komplexität, sondern auch die Verantwortung des Framework-Entwicklers für die notwendige Modulariät des Projekts zu sorgen. Eine Grundregel ist, dass Features, soweit sinnvoll, modular gestaltet werden sollten, sodass der Anwender Entscheidungsmöglichkeiten hat, nicht benötigte Funktionen leicht aus dem Code zu nehmen, bzw. gar nicht erst einbinden zu müssen. Die Möglichkeiten hierfür sind sehr vielseitig und abhängig vom geplanten Workflow. Eine Modularisierung kann auf Dateibasis erfolgen. Basiert das Framework auf Präprozessoren wie SASS oder LESS, so kommen weitere Möglichkeiten hinzu. Die meisten mir bekannten CSS-Frameworks bieten hier sinnvolle Lösungen an, sodass dies eher selten ein Ausschlusskriterium ist.

Problematischer sehe ich die Trennung von Funktionalität und Design, bzw. die fehlende Trennung bei vielen Projekten. Ein CSS-Framework soll in verschiedensten Anwendungszenarien einsetzbar sein. Bei den Layoutkomponenten ist das meist auch gegeben, wobei speziell bei Gridlayouts das Screendesign idealerweise schon in der Enstehung darauf abgestimmt werden sollte. Besondere Bedeutung kommt der Trennung von Funktion und Design bei Navigations- oder Formularbausteinen zu, oder bei der Typographie.

Der Einsatz eines CSS-Frameworks ist nur dann wirklich effizient, wenn die Umsetzung eines indiviudellen Designs leicht möglicht ist und kein (bzw. möglichst wenig) unnötiger Ballast zurückbleibt. In der Regel bleiben die Dateien eines CSS-Frameworks vom Anwender unberührt. Änderungen werden unter Ausnutzung der CSS-Kaskade in den eigenen CSS-Dateien vorgenommen. Dieses Vorgehen ist durchaus sinnvoll und empfehlenswert, denn es erleichtert dem Anwender das Einspielen von Bugfixes, nimmt aber den Framework-Entwickler in die Pflicht, für ein geringstmögliches Maß an Redundanz im Code zu sorgen.

Das bedeutet: Umfangreiche Typografievorgaben, Formular- und Button-Stile haben in den Core-Dateien eines Frameworks nichts verloren. All dies sind Dinge, die in aller Regel auf Projektbasis umfassend verändert oder erweitert werden müssen. CSS3 bietet zahlreiche neue Gestaltungsmöglichkeiten (Runde Ecken, Verläufe, usw.). Allerdings sind diese Eigenschaften aufgrund der Vendor-Präfix-Problematik häufig auch mit einem großen Codeumfang verbunden, den man nicht unnütz mit sich herumschleppen mag.

Deshalb: Überprüfen Sie, wie unabhängig Sie bei Typographie, Formularen und Navigationsbausteinen sind? Welche Vorgaben macht das Framework? Wo haben Sie einfache Anpassungsmöglichkeiten, welche Regeln lassen sich nur über die CSS-Kaskade anpassen?

Dokumentation & Versionsgeschichte

Die Dokumentation ist bei fast jedem Entwickler ein ungeliebtes Kind, denn meist macht sie mehr Arbeit als das Schreiben des eigentlichen Codes. Aus Anwendersicht ist die Doku jedoch ungemein wichtig, denn sie ist nicht nur dafür da, die Funktionalität in blumigem Werbeslang zu verkaufen, sondern um die Funktionalität und deren Anwendungsgrenzen möglichst klar zu beschreiben. Gerade letzteres vermisse ich bei vielen Projekten, doch gerade hier liegt für den Anwender der Schlüssel zur Effizienz beim Einsatz eines Frameworks. Als Framework-Entwickler kennt man die Grenzen der einzelnen Features und es ist kein Zeichen von Schwäche, sie dem Anwender mitzuteilen, sondern ein großer Vorteil. Denn fast immer lässt sich ein Problem auf mehreren Wegen lösen, aber nur wenn man von vornherein die eingesetzte Technik auch voll im Griff hat, lässt sich die Umsetzung vorab sinnvoll planen.

Gleiches gilt für die Versionsgeschichte und die Dokumentation von Bugfixes und Erweiterungen. Egal wie diese kommuniziert werden, wichtig ist, dass es überhaupt in einer nachvollziehbaren Art und Weise geschieht. Ganz nebenbei ist dies auch ein Zeichen dafür, dass ein Projekt einer gewissen Pflege unterliegt und notfalls ein Ansprechpartner bereitsteht.

Deshalb: Lesen Sie die Dokumentation sorgfältig. Wird die Anwendung lückenlos beschrieben? Werden bestehende Konfigurationsmöglichkeiten erläutert und werden die Anwendungsgrenzen umrissen? Natürlich können Sie all das mit genügend Zeit und Motivation selbst herausfinden, aber dann wird aus einem Werkzeug zum effizienten Arbeiten eher ein Liebhaberstück.

Barrierefreiheit

Barrieren im Web sind keine Fügung der Natur. Viele Zugänglichkeitsprobleme entstehen erst durch die unbedachte oder durch Unwissenheit verursachte falsche Anwendung von HTML-Elementen, CSS oder JavaScript. Demzufolge sollte man, wenn man auf eine fremde Codebasis aufbaut, tunlichst darauf achten, sich keine Probleme an Land zu ziehen, die man ohne das CSS-Framework gar nicht hätte.

Ein seit Jahren bekanntes Problem, welches ich dennoch immer wieder in CSS-Frameworks entdecke, ist :focus { outline: 0; }, meist in Verbindung mit dem Reset-CSS-Baustein von Eric Meyer. Tastaturnutzern wird durch diese Eigenschaft der sichtbare Bezug auf den aktuell anvisierten Link genommen. Ich habe darüber vor schon 2009 auf der Webtech Conference gesprochen. Und aus meiner Erfahrung ist es eher die Ausnahme als die Regel, dass dieses Problem vom Entwickler während der Seitenerstellung gefixt wird.

Ähnliches gilt für Formularbausteine und komplexere UI-Komponenten, die einige Projekte mitliefern. Wenn sich ein Framework “HTML5” auf die Fahnen schreibt und in diesem Atemzug im empfohlenen Markup für Formulare <label> Elemente “zugunsten” von placeholder-Attributen weglässt, erweist es unbedarften Nutzern einen echten Bärendienst. Für JavaScript-basierte Features gilt die gleiche Sorgfaltspflicht bei der Evaluierung. So schön schlanke jQuery-Plugins für Dropdown-Menüs, Tabreiter, Accordions oder individuell gestaltete Formularelemente (Comboboxen, gestylte Radio- und Checkboxen) sind, so wichtig ist es, diese auf ihre Zugänglichkeit zu prüfen – oder von jemandem prüfen zu lassen.

Deshalb: Analysieren Sie CSS- und JavaScript-Code auf offensichtliche Schwächen, wie die hier genannten. Testen Sie die mitgelieferten Layoutbeispiele hinsichtlich Tastaturnavigation, der Zugänglichkeit versteckter Inhalte in Screenreadern und prüfen Sie, wie sich dynamische Layoutelemente (z.B. Tabreiter) verhalten, wenn JavaScript im Browser ausgeschaltet ist. Auch dann sollten Anwender noch eine sinnvolle Struktur vorfinden und alle Inhalte erreichen können.

Wider den Hype

Seit zwei Jahren sind zwei Begriffe aus der Frontendentwicklung kaum wegzudenken: HTML5 und Responsive Design. Und demzufolge sind in dieser Zeit auch zahlreiche neue Projekte entstanden, die aber keine CSS Frameworks mehr sein wollen, sondern “HTML5 Frameworks” oder “Responsive Frameworks”. Nur was bedeutet das für den Anwender? Wie aufwändig ist der Support von HTML5 auf CSS-Seite wirklich, als dass es dafür den Umstieg auf ein neues CSS Framework notwendig macht? Und wie hilfreich sind die gebotenen Features in Sachen “Responsive Design”?

Was HTML5 angeht, so findet man mittlerweile in fast allen Projekten die grundlegenden CSS-Eigenschaften im Reset- oder Normalisierungsbaustein, um z.B. aus <header> und <footer> Blockelemente zu machen.

article,aside,details,figcaption,figure,
footer,header,hgroup,nav,section {
  display:block;
}

Aber schon darüber hinaus beginnen die Unterschiede, wieviel HTML5-orientiertes CSS wirklich noch in den Projekten steckt. Die echten Hürden bei der Unterstützung von HTML5 in älteren Browsern werden nämlich nicht durch CSS beseitigt, sondern durch JavaScript-Polyfills das wie HTML5 Shim oder Modernizr (für HTML5 Elemente im statischen Markup) und beispielsweise das in jQuery 1.7 eingeflossene innerShiv, welches erst die dynamische Generierung von HTML5-Elementen per JavaScript wirklich ermöglicht. Fehlenden die Bausteine, so ist es mit dem HTML5-Support nicht weit her.

Noch heikler ist die Situation beim Hypethema “Responsive Design” hinsichtlich der Frage, was ein Responsive Framework gegenüber einem vielleicht schon etwas älteren CSS Framework voraus hat? Die Basis von Responsive Design ist die Arbeit mit CSS3 Media Queries. Doch gibt es zahlreiche Projekte, die nicht mehr viel mitbringen als ein paar vordefinierte Media-Query-Hüllen, ohne jeglichen Inhalt.

/* #Media Queries
================================================== */

  /* Smaller than standard 960 (devices and browsers) */
  @media only screen and (max-width: 959px) {}

  /* Tablet Portrait size to standard 960 (devices and browsers) */
  @media only screen and (min-width: 768px) and (max-width: 959px) {}

  /* All Mobile Sizes (devices and browser) */
  @media only screen and (max-width: 767px) {}

  /* Mobile Landscape Size to Tablet Portrait (devices and browsers) */
  @media only screen and (min-width: 480px) and (max-width: 767px) {}

  /* Mobile Portrait Size to Mobile Landscape Size (devices and browsers) */
  @media only screen and (max-width: 479px) {}

Es ist sicherlich nicht ratsam bei der Evaluation den Schwerpunkt auf dieses Detail zu legen, oder? Diese Zeilen sind leicht in jedes x-beliebige Projekt kopiert oder von Hand geschrieben. Ein echter Nutzen aus dem Framework-Charakter ergibt sich in einer solchen Situation sicherlich nicht.

Da die meisten CSS Frameworks eine Gridkomponente mit an Bord haben, ist bei den Vertretern der Responsive Frameworks immer auch ein Weg zu deren Linearisierung auf kleinen Bildschirmen vorgesehen. Hier sollten Sie klären, nach welchem Schema diese erfolgt, und welche Anpassungsmöglichkeiten Sie hier gegebenenfalls haben. Denn auch wenn die Linearisierung in vielen Fällen unverzichtbar ist, um das Desktoplayout für kleine Bildschirme nutzbar zu machen, ist es nicht ausgeschlossen, dass es auch im Layout für Mobilgeräte vorteilhaft sein kann, Elemente über ein Grid zu gliedern. Denken Sie nur an eine kleine Bildergalerie. Hilft Ihnen das Framework auch in dieser Situation noch oder sind Sie aufgrund einer Zwangslinearisierung des mitgelieferten Grids auf sich gestellt?

Deshalb: Lassen Sie sich von wohlklingenden Bezeichnungen und dem Hype nicht blenden. Die Herausforderungen bei Responive Designs sind sehr viel größer und komplexer (Organisation der Inhalte im Markup, Responsive Images, usw.), als dass sie allein durch ein paar Zeilen CSS gelöst werden. Sie sollten deshalb darauf achten, dass Ihnen das Framework nicht unverhofft im Wege steht, statt Ihnen unter die Arme zu greifen. Gleiches gilt beim Thema HTML5. Legen Sie den Schwerpunkt Ihrer Evaluation deshalb eher auf die zuvor genannten Kritikern und sehen Sie Features, die Ihnen such CSS Frameworks in diesem Bereich geboten werden, eher als Bonus, solange sie nicht 100%-ig auf Ihre Anwendung zugeschnitten sind.


Du kannst die Kommentare zu diesen Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.

Dieser Eintrag kann nicht mehr kommentiert werden.