accessCast

Dirk Jesse, Entwickler des YAML CSS-Frameworks hatte sich vor einiger Zeit öffentliche Gedanken zum Pro und Contra von Frameworks gemacht und uns freundlicherweise erlaubt, diesen Text als Basis für unseren heutigen Podcast zu nehmen. Am Mikro wie immer Manfred Heinze und die Links gibt's wie immer in der Mitschrift.

Ein CSS-Framework – was ist das eigentlich?

Ein CSS-Framework ist zunächst einmal nur eine Sammlung von Routinen und Modulen mit gängigen Code-Konstruktionen. Diese kann man als Basis für die weitere Entwicklung eines Web-Auftrittes nehmen und sich damit eine Menge immer wiederkehrender Tipparbeiten für Dinge ersparen, die bei jedem Web-Projekt annähernd gleich sind.

Die einfacheren Frameworks bestehen nur aus ein Grundgerüst, mit dem die wichtigsten Darstellungsunterschiede in den gängigen Browsern auf eine gemeinsame Basis gesetzt werden. Darauf bauen dann üblicherweise einige simple Layout-Varianten auf (einspaltig, zweispaltig, dreispaltig und so weiter) und ab da beginnt dann die eigentliche Arbeit des Webdesigners. Streng genommen hat man ja schon ein Framework, wenn man im HTML- und CSS-Editor ständig wiederkehrende Codeschnipsel ablegt und per Knopfdruck einfügt.

Komplexere CSS-Frameworks wie YAML oder YUI Grids gehen noch einige Schritte weiter und geben dem Webdesigner weitergehende, komplexe Formatierungsmöglichkeiten an die Hand. Gute Frameworks decken schon von sich aus die weitaus meisten Anwendungsfälle ab. Man kann sich mit ihnen beliebige Layouts zusammenstellen und muss nicht immer wieder bei Null anfangen. Wobei hier die Einschränkung auf reines CSS schon falsch ist - diese Frameworks sind ja streng genommen bereits (X)HTML- und CSS-Frameworks, weil sie das benötigte HTML-Gerüst schon mitbringen.

Und genau hier setzen viele Kritiker an. Des Web-Entwicklers liebste Linkschleuder, das Smashing Magazine hat den Überblick über aktuelle CSS-Frameworks und die Diskussionen um diese prägnant zusammengefasst:

Deutliche Vorteile sind demnach …

• das Vermeiden von alltäglichen Fehlern,
• eine einheitliche Code-Basis,
• ein verbesserter Workflow in Teams und damit
• eine Steigerung der Produktivität.

Dem gegenüber stehen die Nachteile …

• das Erlernen der Arbeitsweise eines Frameworks kostet Zeit,
• das Verstehen der Code-Architektur kostet Zeit,
• Fehler in der Codebasis werden unerkannt mitgeschleift,
• man vertaut dem Framework und nicht seinen eigenen CSS-Kenntnissen,
• Frameworks erzeugen zu viel unnötigen Code.

Nun sind wir hier bei Einfach für Alle keine Außenstehenden, denn das Layout dieser Seiten basiert ebenfalls auf einem Framework – einer älteren Version von YAML. Damit wäre auch klar, warum wir den genannten Vorteilen vorbehaltlos zustimmen. Zu den genannten Nachteilen möchten wir jedoch etwas anmerken. Nicht, um sie weg zu diskutieren, sondern weil wir denken, dass die Ursachen dafür woanders zu suchen sind.

Das Kennenlernen ist schwierig

Jeder Mensch hat seine persönliche Handschrift. Das gilt auch für die Erstellung von HTML- und CSS-Code sowie die Art und Weise, in der der eigene Code dokumentiert und weiterentwickelt wird. Der Einsatz eines CSS-Frameworks erfordert das Arbeiten mit fremdem Code und vorgegebenen Strukturen. Das Verstehen und der Umgang mit einer fremden Codebasis kosten den Programierer verständlicherweise Zeit.

Innerhalb einer professionellen Webagentur sollte dieser Prozess allerdings zum Alltag gehören. Die Zusammenarbeit mehrerer Abteilungen oder externer Firmen und damit auch mehrerer Webdesigner ist dort die Regel. Der mögliche Vorteil eines Frameworks: die Einarbeitung in die Arbeitsweise ist ein einmaliger Aufwand - anschließend kommt der Vorteil einer einheitlichen Codebasis und einer einheitlichen Sprache bei der Umsetzung von Projekten zum tragen. Speziell bei Teamarbeit kann Arbeit und Pflege damit einfacher und leichter werden.

Es ergeben sich damit keine ungewollten Zwänge. Ansätze mit einer willkürlichen Struktur werden auf Dauer kaum Bestand haben. Logische und praxisorientierte Strukturen in die eigene Arbeit zu übernehmen, fällt hingegen leicht. Den meisten Webseiten liegen solche allgemeinen Stukturen zu Grunde. Je universeller und logischer diese durch das Framework abgebildet werden, desto einfacher lässt sich damit arbeiten.

Der oft geäußerte Aussage »Das bekommt man (i.d.R gemeint: der Autor selbst) selbst schneller und mit weniger Code hin!« kann man so pauschal nichts entgegnen. Allerdings ist dies eine rein subjektive Einschätzung der eigenen Fähigkeiten und Ansprüche an den erzeugten Code, sodass es als objektives Kriterium pro oder contra Frameworks nicht taugt, denn sie basiert nicht auf einem konkreten Anwendungsfall, sondern auf verallgemeinerten Regeln. Frameworks wie YUI Grids, Blueprint oder YAML setzen jeweils unterschiedliche Schwerpunkte. YUI Grids ist klar auf starre Layouts und die Zusammenarbeit mit den JavaScript-Bibliotheken von Yahoo! ausgelegt. Blueprint verfolgt ein streng visuelles Konzept und kombiniert ein pixelbasiertes Gestaltungsraster mit typographischen Vorgaben. YAML hingegen setzt auf flexible Layouts und Gestaltungfreiheit für den Entwickler. Sie haben also alle ihre individuelle Stärken und Schwächen.

Die Bedenken, Fehler in der Codebasis unerkannt mitzuschleifen, sind nachvollziehbar. Die Chance auf bugfreien Code stehen jedoch für den Anwender sehr gut, denn Fehler in der Codebasis werden von der Community meist schnell entdeckt gemeldet und repariert. Dies ist also keine Kritik an Frameworks sondern an der teilweise mangelnden Dokumentation. Wie jede Software müssen sich auch CSS-Frameworks ihre Reputation in der Community zunächst verdienen. Und das kann nur über fehlerfreien Code und eine entsprechende Dokumentation erfolgen. Es ist ein Unterschied, ob man eine Codebasis verwendet, ohne sie zu verstehen und dem Ergebnis blindlings vertraut oder ob man alltäglich wiederkehrende Arbeitsschritte automatisiert und doch genau weiß, was dabei passiert. Wer keine Browsertest mit fremdem Code macht, macht vermutlich auch keine mit dem eigenen Code.

Zum Thema »unnötig großer Code« kann man sagen, dass der durch ein Framework generierte Wasserkopf verhältnismäßig gering ist und bei anspruchsvolleren CSS-Layouts praktisch nicht Gewicht fällt. Wenn Ladezeiten und Traffic wirklich systemkritisch sind, bestehen sowohl bei CSS-Frameworks als auch bei indivuellem Code ähnliche Optimierungspotentiale, denn auch die Erstellung von Hand führt nicht im automatisch zur optimalen Lösung. Und ob eine CSS-Datei nun 21 oder 11 Kilobyte groß ist spielt spätestens dann keine Rolle mehr, wenn ein Redakteur ein 120 Kilobyte großes Bild in einen Artikel einpflegt – die wirklichen Optimierungspotenziale liegen also meist woanders.

Es geht noch besser

Sind Frameworks der Heilige Gral der Web-Entwicklung? Vielleicht werden sie es eines Tages, wer weiß? Derzeit sind sie es jedoch sicherlich noch nicht – zumal niemand bisher so richtig weiß, wie dieser Gral aussehen könnte. Ungeachtet dessen sind sie schon heute eine enorme Arbeitserleichterung für gestresste Web-Entwickler.

Was man durchaus als Nachteil vieler aktueller Frameworks empfinden kann – und was die angesprochenen Kritikpunkte durchaus verständlich macht – ist die mangelhafte Dokumentation. So hat man oftmals den Eindruck, im luftleeren Raum zu arbeiten. Gerade bei YUI Grids erinnert die Arbeit manchmal an Voodoo – man piekst irgendwo rein, es passiert was, aber warum etwas passiert ist nicht nachvollziehbar. Diese Tatsache ist für den produktiven Einsatz nicht gerade vertrauensbildend und führt zu den geäußerten Bedenken. Hier sind die Framework-Entwickler gefragt, Ihre Lösungen vollständig und für Anwender verständlich zu dokumentieren.

Gerade bei den heutigen Anforderungen in Sachen Usability, Zugänglichkeit und den Anforderungen an modernes Webdesign sollten der inhaltliche Schwerpunkt professioneller Arbeit nicht mehr im mühsamen Erstellen von validem Markup und dem Umschiffen von Browser-Bugs liegen. CSS-Frameworks greifen dem Webdesigner in genau diesem Punkt unter die Schultern, damit der Blick wieder frei wird für das Wesentliche der Arbeit.

Warum also diese Aversion gegen Frameworks?

Könnte es sich dabei in Wahrheit nicht um eine Aversion gegen strukturiertes und methodisches Arbeiten handeln? Sicher, künstlerisch anspruchsvolle Websites sind so höchstindividuell, dass sie wahrscheinlich in kein Framework-Gerüst passen. Und sicher gibt es auch Kolleginnen und Kollegen, die das Anordnen von spitzen und geschweiften Klammern selbst schon als künstlerische Ausdrucksform sehen. Aber seien wir doch mal ehrlich: wie viele Brot- und Butter-Webseiten eines Webdesigners sind künstlerisch anspruchsvoll?

Vielleicht liegt die verbreitete Ablehnung aber auch nur daran, dass das ganze Konzept, die Idee hinter Frameworks für viele CSS-Schreiber einfach unbekannt und neu ist. In der Programmierung richtiger Applikationen werden schon seit Jahrzehnten externe Code-Bibliotheken verwendet und niemand käme auf die Idee, jedesmal wieder ganz unten bei Maschinencode anzufangen. JavaScript-Bibliotheken verfolgen dasselbe Konzept und in der Entwicklung von Web-basierten Aplikationen sind Frameworks wie Ruby on Rails oder CakePHP nicht mehr wegzudenken. Ehrlicherweise muss man aber anmerken, dass es auch bei »richtigen« Programmierern die gleichen Diskussionen um die Verwendung von Frameworks gibt – im Sinne des Kunden und seiner Nutzer kann das aber alles nicht sein.

Und was hat das überhaupt mit dem Thema Barrierefreiheit zu tun? Oberflächlich betrachtet zunächst einmal nicht viel. Die BITV schreibt den Gebrauch von CSS vor; woher dies kommt ist der Verordnung egal, geregelt wird nur die Art der Verwendung. Wir sind aber der festen Überzeugung, dass Frameworks bei sachgemäßem Gebrauch wichtige Ressourcen freisetzen können, die eher in eine wirkliche Verbesserung der Inhalte gesteckt werden sollten. Schließlich kommen die weitaus meisten Besucher einer Website nicht wegen der hübschen geschweiften und spitzen Klammern im Quelltext, sondern wegen der eigentlichen Inhalte und Funktionen des Angebots.

Wo Nutzer und gerade Menschen mit Behinderungen jedoch einen echten Vorteil aus Frameworks ziehen können ist, wenn diese halb-automatisch für die Verbreitung von Accessibility-Features sorgen. Die zunehmende Verbreitung solcher Frameworks als Basis für Layouts von verbreiteten Weblog- und Content Management-Systemen sorgt quasi durch die Hintertür für eine bessere Zugänglichkeit, wenn Frameworks diese Merkmale bereits eingebaut haben und Autoren sich somit nicht mehr darum kümmern müssen. Ein praktisches Beispiel hierfür findet sich im YAML-Framework bei den bereits ab Werk eingebauten Methoden zur Sprungnavigation für Tastatur-Nutzer.

So, das war die neueste Ausgabe unseres Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags CSS und Design. Bis zum nächsten Mal.