Montag,
23. März 2009

Layout-Frameworks werden immer beliebter und sind auf gutem Weg, sich als fester Bestandteil der Webentwicklung zu etablieren. Nun ist jedoch der Begriff des «Frameworks» vorrangig aus dem Bereich der Softwareentwicklung bekannt und weder HTML noch CSS können als Programmiersprache bezeichnet werden, weshalb die Übernahme der Bezeichnung in den Bereich von HTML/CSS nicht unumstritten und oft verwirrend ist. Ähnlich verhält es sich mit dem gedanklichen Ansatz eines CSS-Frameworks an sich, denn eben weil es sich nicht um Programmierung handelt, besteht trotz der Widrigkeiten des Alltags insbesondere unter professionellen Entwicklern die Überzeugung, Markup und CSS-Regeln vollständig von Hand schreiben zu müssen, um sauberen und schlanken Code zu erhalten. Zum Teil rührt dieses Vorurteil aus den Erfahrungen, die wahrscheinlich jeder Entwickler aus seinen Anfangszeiten mit automatischen Codegeneratoren wie Frontpage, GoLive oder Dreamweaver als einprägsame Negativbeispiele für sein Leben mit sich trägt.

Note: This essay is also available in English.

Inhalt

Die allgemeine Einschätzung der Webentwickler

HTML und CSS werden clientseitig interpretiert. Ein möglichst schlanker Code für individuelle Projekte sollte daher vorrangiges Ziel jeder Layoutentwicklung sein. CSS-Frameworks sind hingegen projektunabhängige Baukastensysteme, deren Ziel ein möglichst universeller Lösungsansatz für unterschiedlichste Layouts darstellt. Wie passen diese offensichtlich gegensätzlichen Anforderungen also zusammen?

Eine Vielzahl von Projekten (mittlerweile über 20) finden sich im Netz unter der Bezeichnung «CSS-Framework». Dabei streuen Qualität der Umsetzung und Dokumentation ebenso wie der Anspruch an Funktionsumfang und die zugrunde liegenden Layoutkonzepte derartig stark, dass ein objektiver Vergleich untereinander extrem schwierig ist. Hinzu kommt, dass es bisher keine klare und allgemein anerkannte Definition gibt, was ein CSS-Framework wirklich ausmacht. Gleichzeitig besteht jedoch genau in diesem Bereich ein großes Informationsbedürfnis, was leider zu zahlreichen undifferenzierten und oberflächlichen Betrachtungen führt. Die typische Argumentation bei Diskussionen Pro & Contra CSS-Frameworks sieht folgendermaßen aus:

Advantages of CSS Frameworks

  • You increase your productivity and avoid common mistakes.
  • You normalize your code/class base.
  • You have a better workflow within a team.
  • You gain an optimal browser-compatibility.
  • You have a clean, well-structured and complete code.

Disadvantages of CSS Frameworks

  • You need time to fully understand the framework.
  • You need a close familiarity with your code’s architecture.
  • You might inherit someone’s bugs or mistakes.
  • You develop sites upon a framework, not upon the solid knowledge of CSS
  • You get a bloated source code.
  • CSS can not be framed semantically.
  • Ignoring the uniqueness of your project.
CSS Frameworks + CSS Reset: Design From Scratch, Smashing Magazine

Als Entwickler des (X)HTML/CSS-Frameworks YAML muss ich mich permanent diesen Argumenten stellen, um das Projekt bei der Weiterentwicklung auf Kurs zu halten. Daher möchte ich in diesem Essay meinen Standpunkt zu den am häufigsten geäußerten Kritikpunkten an CSS-Frameworks darlegen, wobei ich hierfür meine Definition eines CSS-Frameworks als Maßstab ansetze.

CSS-Frameworks sind leistungsfähige Entwicklungsumgebungen für die Erstellung von Webseiten und richten sich vorrangig an professionelle Webentwickler. Sie stellen universelle Layoutbausteine bereit und definieren ein Regelwerk, im Rahmen dessen der Entwickler sich frei bewegen kann.

Wichtig ist hier die Feststellung, dass CSS-Frameworks Werkzeuge für Profis sind. Ein Projekt wie YAML mag vielleicht auf den ersten Blick wie ein Fertigbaukastensystem mit Layoutvorlagen und fertigen Beispielen erscheinen, aber sämtliche Vorlagen und Beispiele dienen nur der Anschauung, wie flexibel diese Umgebung in der Praxis professioneller Webentwicklung genutzt werden kann.

Ich werde mich in der Diskussion an verschiedenen Stellen auf Fachartikel von Jens Meiert stützen, einem der bekanntesten deutschsprachigen Webentwickler und energischen Vertreter von standardkonformem und schlankem Code. Dabei habe ich nicht die Absicht Jens persönlich anzugreifen. Vielmehr schätze ich seine Beiträge sehr hoch, denn er ist einer der wenigen Kritiker, die ihren Standpunkt nicht nur einfach in den Raum stellen, sondern mit stichhaltigen Argumenten hinterlegen. Seine Artikel sind daher eine gute Grundlage für eine ansprechende Fachdiskussion.

"CSS-Frameworks are never the best solution ..."

Ob die oben zitierten Nachteile tatsächlich zutreffen, soll im Folgenden überprüft werden. Tatsache ist aber, dass CSS-Frameworks aus verschiedensten Gründen nicht jedermanns Sache sind. Jens Meiert versucht dafür auch mehrere Gründe zu benennen:

"Public, or open, HTML/CSS “frameworks” are never the best solution, and oftentimes not even a good solution for any site. [...] So why stating that frameworks aren’t a good solution? Because people outside your company or outside your apartment just cannot know your needs, and this implicit ignorance results in way too much markup in your documents and way too many rules in your style sheets, making any framework-based solution inferior to something tailored."

A few words on HTML/CSS-Frameworks, Jens Meiert

Auf den ersten Blick erscheint das verständlich. Ein Framework kann sich auf Webstandards und Best-Practice-Methoden stützen, unmöglich aber die individuellen Arbeitsweisen eines einzelnen Entwicklers oder einer Agentur zu 100 Prozent abbilden. Deshalb verlangt die Arbeit mit einem CSS-Framework nach einer gewissen Einarbeitungszeit in den Code und seine Funktionsprinzipien. Dazu gehört auch, dass der Entwickler seine individuelle Arbeitsweise entsprechend den konzeptionellen Ansätzen des CSS-Frameworks angleichen muss.

Jens Meiert folgert jedoch allein aus der Tatsache des fremden Codes, dass CSS-Frameworks immer mit einem Overhead an Markup und zu vielen CSS-Regeln einhergehen. Dahinter steht die Annahme, Frameworks würden erstens keine individuelle Arbeitsweise und zweitens keine Möglichkeiten der finalen Code-Optimierung zulassen. Diese Annahme ist der eigentliche Aufhänger seiner Kritik. Der Denkfehler in Meierts Argumentation besteht darin, dass nicht individuelle Arbeitsweisen oder konkrete Projektanforderungen die Basis professioneller Webentwicklung darstellen, sondern die Arbeit nach geltenden Webstandards. Dieses Regelwerk ist nicht nur die Grundlage jeder professionellen Webentwicklung, es ist ebenso die Grundlage unterschiedlicher und individueller Arbeitsweisen. YAML als das aktuell umfangreichste und ausgereifteste CSS-Framework basiert ebenfalls auf diesen Webstandards, es gibt also ein Fundament, das aus Transparenz des Quellcodes, klarer Trennung von Inhalt und Layout und semantisch korrekten Auszeichnungen innerhalb der HTML-Seitenstruktur besteht.

Betrachten wir die Praxis der Webentwicklung: Trotz aller Unterschiedlichkeit der Millionen von Websites ist deren struktureller Aufbau grundsätzlich ähnlich. Meistens gibt es einen ein Header, eine Navigation, einen klar eingegrenzten Inhaltsbereich (content), eventuell eine Sidebar und abschließend ein Footer, wobei sich auch diese Art der Benennung schon fast als Konvention durchgesetzt hat. Vielleicht gibt es mehrere Spalten und vielleicht gibt es auf ausgewählten Seiten einen Teaser oder kleine Variationen des Layouts. Dennoch unterscheiden sich Websites nicht mehr voneinander als ein Haus, das auch bei individueller Ausführung und größter Unterschiedlichkeit zu allen anderen Häusern über ein Fundament, eine Wohnebene und ein Dach verfügt.

Frameworks, Codeschnipsel und Webdesign-Praxis

Zum Thema Gestaltungsfreiheit wird immer wieder der Vorbehalt geäußert, ein CSS-Framework würde durch vorgegebenen Aufbau und festgelegter Benennung von Klassen und IDs die individuelle Umsetzung einer Website unnötig einschränken. Dazu sei nur bemerkt, dass der CSS Zen Garden trotz festgelegter HTML-Struktur der Vorlage die Webdesigner offensichtlich nicht davon abgehalten hat, zahllose individuelle Lösungen zu entwickeln.

Die Praxis der individuellen Handcodierung einer Website bedeutet deshalb nicht, dass der Entwickler aus dem Nichts heraus beginnt, eine Struktur zu erfinden. Der Webentwickler ist eben nicht der Künstler, der von der Muse geküsst wird und dank seiner Kreativität und Schöpferkraft dem Web ein neues Meisterwerk schenkt. Webentwicklung ist ein Handwerk und jeder Entwickler greift auf bewährte Werkzeuge (Codeschnipsel) zurück, auch der per Hand codierende. Und selbst wenn ein Entwickler schwören könnte, keine vorgefertigten Zeilen HTML- oder CSS-Code per copy & paste zu verwenden, ist es eben sein Fachwissen, das bei der Handcodierung den Prinzipien eines bestimmten Systems folgt. Unzählige bewährte Codeschnipsel hat der Webdesign-Profi in seinem Kopf, so wie der Architekt unzählige bewährte Varianten für die Planung eines Hauses kennt. Und CSS-Frameworks sind grundsätzlich nichts anderes als eine Sammlung erprobter, praxisorientierter Codeschnipsel, die reibungslos zusammenarbeiten und sich einem übergeordneten Konzept unterordnen.

Zusammen mit dem Argument von zu viel Markup und zu vielen CSS-Regeln wird oft die angeblich schlechte Qualität des Codes ins Feld der Kritik geführt. Hier ist es jedoch wichtig, auf die grundsätzlich unterschiedlichen Ansätze verschiedener Framework-Konzepte hinzuweisen. In der allgemeinen Wahrnehmung verstehen die meisten Webdesigner unter dem Begriff «CSS-Framework» nicht nur YAML, sondern daneben auch YUI Grids, Blueprint CSS, 960 Grid System und entsprechender Derivate der beiden letztgenannten. Dabei wird schnell übersehen, dass im Vergleich zu YAML dem schlanken YUI Grids beispielsweise die umfangreichen IE-Patches, der Formularbaukasten und eine ausführliche Dokumentation fehlen und dass Blueprint CSS, bzw. 960.gs die Gestaltung in klassischen Spaltenrastern zur konzeptionellen Grundlage des gesamten Frameworks gemacht haben und damit dem rein visuell orientierten Tabellenlayout näher stehen als dem Konzept der Webstandards. Als Framework in der Praxis ist YUI Grids deshalb gelegentlich etwas dünnhäutig bei komplexen Aufgabenstellungen, während die visuell orientierten Frameworks durch das detailliert ausgearbeitete Spaltenkonzept an vielen Stellen die klare Trennung von Inhalt und Design vermissen lassen, was zurecht Anlass zur Kritik gibt.

Über pragmatische Lösungsansätze und Minimierung von Quellcodes

Professionelle CSS-Frameworks können nicht dem Anspruch gerecht werden, immer das absolute Minimum an Code zu liefern. Naturgemäß kann ein solcher Extremwert nur für jeweils genau einen speziellen Anwendungsfall erreicht werden und bedingt zwingend die Einbeziehung der Seiteninhalte. Das Ziel eines guten CSS-Frameworks besteht vielmehr darin, mit einem relativen Minimum an Markup und CSS-Regeln Bausteine mit einem größtmöglichen Potential zur Wiederverwendbarkeit zu entwickeln und darauf aufbauend inhaltsunabhängig ein robustes und effizient einsetzbares Layoutgerüst bereitzustellen.

Die Differenz zwischen dem absoluten Minimum an Code einer perfekten Individuallösung und dem relativen Minimum des Framework-Codes ist naturgemäß keine konstante Größe, sondern abhängig von verschiedenen Einflussfaktoren:

  1. Je besser die Planung für die Umsetzung eines Layouts die Funktionsprinzipien des verwendeten Frameworks berücksichtigt, desto geringer ist der entstehende Overhead und desto schneller und einfacher ist auch die Realisierung.
  2. HTML und CSS bieten fast immer mehrere Lösungswege für eine Aufgabe und Handcodierung ist kein Garant dafür, auf Anhieb die Ideallösung zu finden und fehlerfrei zu implementieren, hierfür zählt allein Fachwissen.
  3. Das absolute Minimum ist ein theoretischer Wert. In der Realität bedingen CSS-Bugs und variierende CSS-Fähigkeiten verschiedener Browsergenerationen immer wieder Kompromisse im Markup und bei der Formulierung von CSS-Regeln.
  4. CSS-Frameworks sind Werkzeuge zur Layoutentwicklung. Erst in den Händen des Entwicklers entsteht damit das fertige Layout, eben weil erst mit Kenntnis der Randbedingungen des konkreten Projektes eine Optimierung sinnvoll möglich ist. Demzufolge ist ein gewisser Overhead auf der Seite des Frameworks unerlässlich, um diese Vielseitigkeit zu ermöglichen.

CSS-Frameworks liefern daher keine Maßanzüge, sondern Kompromisslösungen – und das aus gutem Grund. YAML hat nicht den Anspruch, out-of-the-box die bestmögliche (im Sinne: Maßanzug = absolutes Minimum an Code) zu liefern. Stattdessen nehme ich für YAML in Anspruch, die bestmögliche Codebasis (im Sinne von Effizienz und Vielseitigkeit) für den Entwickler bereitzustellen. Das Basismarkup von YAML, die flexiblen Gridbausteine (Subtemplates) sowie die drei CSS-Core-Stylesheets (base.css, iehacks.css und print_base.css) sind robuste, wiederverwendbare Bausteine, die ihrerseits ein Optimierungsprozess in der Frameworkentwicklung durchlaufen haben und speziell im Bereich der flexiblen Layouts ist diese Codebasis trotz ihrer Vielseitigkeit extrem schlank.

Das immer wieder vorgebrachte Argument des Übermaßes an Markup und Regeln wird natürlich auch nicht dadurch gelöst, indem man einen leeren Ordner für Inhalte anlegt und lediglich ein Reset-CSS und ein paar Zeilen Basis-CSS als Grundlage zur Codierung anbietet und das dann «Framework» nennt. Das ist zwar schlank, bringt aber außer ein paar Minuten Zeitersparnis keine Entlastung in der Praxis der Webentwicklung.

Frameworks dienen der Webentwicklung, nicht der Philosophie

Noch ein Blick in die Praxis: Das gewünschte Minimum an Code ist auch in der von Hand codierten Form im Projekt-Workflow nur dem äußerst seltenen Idealfall vorbehalten, dass der Auftraggeber dem Entwickler von der Planung bis zum Launch völlig freie Hand gibt und nicht die geringsten Änderungswünsche formuliert. Die Realität der Frontend-Entwicklung sieht jedoch anders aus. Nicht selten werden noch nach Abnahme und Launch der Website von Kunden oder Entscheidern umfassende Änderungen gewünscht, die oft auch zusätzliches Markup bedeuten. Das Minimum kann also frühestens am Ende des Projektablaufs stehen, und auch da nur als best-case-Variante.

Nicht nur Jens Meiert verfehlt daher in seiner Argumentation gänzlich den Sinn und Zweck eines CSS-Frameworks, denn er stellt eine theoretisch hochoptimierte Individuallösung dem out of the box Ergebnis eines CSS-Frameworks gegenüber, um mit dem zwangsläufig vorhandenen Overhead gegen CSS-Frameworks argumentieren zu können. Bei dieser Argumentation wird erstens vergessen, dass gerade Profis mit hinreichendem Fachwissen auch das projektbezogene Grundgerüst eines Frameworks optimieren können und sollten. Zweitens liegen die Vorteile der Arbeit mit einem CSS-Framework nicht im Bereich der finalen Codeoptimierung, sondern in den davor gelagerten Entwicklungsphasen, die nicht nur durch die beschriebene Abstimmung mit dem Auftraggeber zahlreiche Änderungen erfahren können. Die zunehmende Komplexität anspruchsvoller Großprojekte mit der Arbeit in Teams und heterogenen Entscheidergruppen lässt eine auf Anhieb optimierte und finalisierte Codierung überhaupt nicht zu. Hier bietet das Konzept von YAML eine praxisnahe Lösung: für alle gängigen Browser robust, für komplexe Anforderungen in der Webentwicklung umfassend und für die Untiefen in der Kundenabstimmung flexibel. Dass beim eben vergebenen BIENE-Award für besonders zugängliche Webseiten insgesamt sechs Gewinner-Websites mit YAML umgesetzt wurden, zeigt, was dieses Framework in der professionellen Praxis leisten kann.

Zukunftssicheres und wartbares CSS

Auch im Bereich von CSS gibt es viele unterschiedliche Meinungen, was die Aufsplittung von Stylesheets in Module, den Einsatz von Hacks zur Zähmung des Internet Explorers oder auch der Verwendung von Conditional Comments betrifft. YAML macht von all diesen Dingen intensiven Gebrauch und muss sich demnach natürlich auch der Kritik stellen.

Conditional Comments & Hacks

Bezüglich Conditional Comments zitiere ich Jens Meiert einleitend, denn er vertritt in Bezug auf Conditional Comments und Reset-CSS eine sehr kompromisslose Ansicht.

"The core problem with Conditional Comments is its impact on maintainability. By their very definition you have to link at least one additional style sheet from your HTML, unless, even worse, CSS rules are added within the document. And just as we avoid using font elements as they are presentational and usually mean HTML changes once we want to change the layout (which means a maintenance problem), we should avoid Conditional Comments as once we want to change (or even keep) the layout when a new version of Internet Explorer ships or an old version goes, we face a good likelihood to change the HTML, which translates to an unnecessary maintenance issue as well. [...]

There are implications for collaboration as well, and you can observe these problems in practice: Since CC style sheets don’t necessarily use different selectors than the “regular” style sheets, developers either have to look for the same selector in at least two style sheets, which slows them down (even or especially in comparison to “hacks” which are usually close to all other rules), or they overlook them, implement another solution, eventually run into “weird” layout problems (because the CC style sheet overrides something or says something different), and maybe even add code that is unnecessary."

To Be Clear (on Conditional Comments and Resets), Jens Meiert

Conditional Comments fallen zwar in der Tat etwas aus der Rolle, denn es handelt sich um eine proprietäre Erweiterung von Microsoft und sie verhalten demzufolge auch sich nicht ganz so, wie es einfache HTML-Kommentare tun sollten. Doch ein Problem ergibt sich daraus nicht. Gleiches trifft nämlich auch auf das nicht weniger eigentümliche Verständnis des Internet Explorers bezüglich vieler CSS-Eigenschaften zu, die entweder falsch (CSS-Bugs) oder gar nicht interpretiert werden. Zwar sind CSS-Bugs kein Alleinstellungsmerkmal des Internet Explorers, jedoch beansprucht Microsoft seit vielen Jahren die Marktführerschaft. Nun lassen sich aber all diese Darstellungsprobleme des Internet Explorers mehr oder weniger einfach beheben, sei es durch Vermeidung bestimmter Markup/CSS-Konstellationen oder durch CSS-Hacks.

Eine Frage der Praxis: Wohin mit den Hacks?

Für die Hacks gibt es zwei Wege: Entweder – wie Jens Meiert empfiehlt – verzichtet man auf den Einsatz von CCs und verwaltet sämtliche Bugfixes in den regulären Stylesheets. Für die skizzierte Suche nach bestimmten CSS-Regeln im Wartungsfall mag dieses Vorgehen vorteilhaft sein. Das hat aber leider den Nachteil, dass wir sämtlichen modernen Browsern diesen nutzlosen CSS-Ballast der Bugfixes aufbürden und somit die Ladezeiten in Firefox, Safari & Co. unnötig verlängern. Zudem benötigen viele Bugfixes Parser-Hacks, um einzelne IE-Versionen direkt ansprechen zu können. Doch genau diese meist invaliden und schwer lesbaren Konstrukte werden nicht zwingend von anderen Browsern ignoriert, was diesen Weg nicht weniger problematisch in Bezug auf "weird layout problems" macht.

Oder man trennt Standard-CSS und die IE-Anpassungen sauber voneinander, fasst sämtliche CSS-Hacks in einem gesonderten Stylesheet zusammen und bindet dieses über einen Conditional Comment ins Layout ein. Die Vorteile dieses Weges klingen überzeugend und wiegen den möglichen Nachteil eines leicht erhöhten Pflegeaufwands mehr als auf.

Vorteile Conditional Comments

  1. Das Standard-CSS bleibt frei von kryptischen Parser-Hacks zur Korrektur von IE-Bugs.
  2. Die Bugfixes für den Internet Explorer können nicht versehentlich die Darstellung modernen Browsern stören.
  3. Der Umfang der CSS-Anpassungen für den Internet Explorer hält sich zumeist in übersichtlichen Grenzen. Ein solches Stylesheet bleibt daher meist übersichtlich klein.
  4. Die Webseite gewinnt an Performance in modernen Browsern, da Bugfixes für den Internet Explorer auch nur diesem zugänglich gemacht werden.

Soweit der allgemeine Teil zum sinnvollen Umgang mit Conditional Comments. Innerhalb von YAML ist es zudem möglich, Bugfixes für den überwiegenden Teil der CSS-Bugs Internet Explorers so universell zu formulieren, dass sie ohne Zutun des Entwicklers greifen und deshalb präventiv eingesetzt werden können, dank der vom CSS-Framework vorgegebenen Struktur des Markups. Dieses Konzept, das bisher ausschließlich in YAML umgesetzt wurde, führt zu einerseits zu geringfügigem CSS-Overhead, bringt aber im Gegenzug nachhaltige Vorteile mit sich.

Conditional Comments in YAML

  1. Entwickler können sich bei der Layoutentwicklung auf standardkonforme Browser konzentrieren, der überwiegende Teil der Anpassungen für IE 5.x - 7.0 erfolgt automatisch durch YAML. Der Korrekturaufwand für Darstellungsprobleme des Layouts, von Formularen und sonstigen Inhalten sinkt drastisch.
  2. Auftraggeber müssen keine Einschränkungen in der Browserunterstützung hinnehmen, denn das CSS-Framework liefert die Unterstützung älterer IE-Versionen frei Haus.
  3. Endanwender werden hinsichtlich des gewählten oder gezwungenermaßen verwendeten Browsers weniger bevormundet aufgrund der weitreichenden Browserunterstützung des CSS-Frameworks.

Und letztlich, sollte der Internet Explorer 8 vollständig standardkonform rendern und die älteren IE-Versionen verdrängen, so beschränkt sich der Wartungsaufwand zur Deaktivierung der Unterstützung dieser veralteten Browser für den Webentwickler auf das einfache Löschen eines Stylesheets auf dem Server, bzw. die Entfernung dieses speziellen HTML-Kommentars aus dem Layout. Wer daher Conditional Comments allein aufgrund ihrer proprietären Herkunft oder einem willkürlich heraufbeschworenen Wartungsproblem ablehnt, muss sich die Frage nach einer vergleichbar effektiven Alternative zu dem in YAML umgesetzten Bugfix-Konzept gefallen lassen, welche die genannten Vorteile für Entwickler, Auftraggeber und Endanwender gleichermaßen abdeckt.

Modulare Stylesheets vs. Performance

CSS-Frameworks sind Entwicklerwerkzeuge mit einem modularen Aufbau. Sie beinhalten eine Vielzahl an wiederverwendbaren Bausteinen (Reset-CSS, Screenlayout, Navigationselemente, Druckausgabe, ect.), die in Abhängigkeit der jeweiligen Anforderungen in das CSS-Layout integriert und ggf. angepasst werden. Die Möglichkeit der Wiederverwendung ist dabei entscheidend für die Beschleunigung des Entwurfsprozesses. Gleichzeitig wird durch die Verwendung erprobter Bausteine der Pflege- und Testaufwand auf ein notwendiges Minimum zu reduziert. Im Gegensatz zur Layoutentwicklung verlangt der Produktivbetrieb der Webseite in erster Linie nach Geschwindigkeit. Jeder CSS-Baustein muss einzeln per HTTP-Request beim Server angefordert werden. Jeder Request bedingt Latenzzeiten und verlangsamt somit die Darstellung der Webseite. Im Produktivbetrieb ist es daher sinnvoll, die Anzahl der einzelnen Stylesheets durch Zusammenfassen so weit wie möglich zu reduzieren. Ähnliche Vorgehensweisen wendet man bei Grafiken an, Stichwort: CSS-Sprites. Dennoch handelt es sich hier um zwei gänzlich von einander unabhängige Phasen der Projektentwicklung, die in der Diskussion nicht willkürlich miteinander vermischt werden sollten.

Das CSS einer Webseite wird erst im User Client interpretiert und muss dazu zunächst vom Server heruntergeladen werden. Performance im Produktivbetrieb verlangt deshalb nach möglichst kleinen Dateigrößen für kurze Ladezeiten. Erreicht wird dieses Ziel durch die Komprimierung von Stylesheets mit Werkzeugen wie dem YUI Compressor oder dem PHP-Tools wie minify. Dabei werden CSS-Kommentare und unnötige White-Spaces (Leerzeichen, Tabulatoren, Zeilenumbrüche) aus den Stylesheets entfernt, um die Dateigröße zu reduzieren. Ebenso ist es jedoch nachvollziehbar, dass sich in einer derart komprimierten Form nicht vernünftig entwickeln lässt. Wer sein Layout von Hand codiert, wird gleichermaßen darauf achten, CSS-Regeln lesbar und übersichtlich zu halten und wird einzelne Passagen kommentieren, um die Wartbarkeit des Codes und das Nachvollziehen von Designentscheidungen für andere Teammitglieder zu dokumentieren. Die Wartbarkeit und Pflege komplexer Projekte lässt eine Unterteilung von Stylesheets in logische Teile ebenfalls sinnvoll erscheinen.

Bei der Entwicklung eines CSS-Frameworks ist es nicht viel anders. Das Framework stellt für den Anwender zunächst eine fremde Codebasis dar, die verstanden sein will, um Vertrauen in den Code zu gewinnen und um effektiv damit arbeiten zu können. Aus diesem Grund sind die CSS-Bausteine bei YAML auf Basis von CSSDOC sehr ausführlich dokumentiert und die modulare Aufteilung der Stylesheets in aufgabenspezifische CSS-Bausteine wird konsequent verfolgt. Das Kommentieren von CSS, die bedeutungsvolle Benennung von Layoutelementen, Dateien und Ordnern ist eine Grundvoraussetzung für professionelle Webentwicklung und kann somit nicht exklusiv für die Handcodierung oder den Einsatz von CSS-Frameworks gelten. In beiden Fällen unterliegt der Entwicklungsprozess anderen Kriterien als der Livebetrieb der fertigen Website. Der modulare Aufbau der Stylesheets während der Layoutentwicklung ist daher kein Argument gegen CSS-Frameworks. Unabhängig von Handcodierung oder Framework-Einsatz ist die Entscheidung hinsichtlich einer Performanceoptimierung der Stylesheets für den Livebetrieb ein Zeichen dafür, ob man sich einer professionellen Arbeitsweise stellt oder nicht.

Liefern Frameworks unsemantischen Code?

Ein ausgesprochen leidiges Diskussionsthema betrifft den immer wieder zu hörenden Vorwurf, CSS-Frameworks würden unsemantischen Code produzieren oder gar unsemantische Klassennamen verwenden.

"A CSS framework passively removes a great majority of semantic value from the markup of a document and, in my opinion, should be avoided."

Please Do Not Use CSS Frameworks, Jonathan Christopher

Diese Aussagen sind ganz und gar Unfug. CSS-Layouts basieren typischerweise auf DIV-Elementen. Und diese Elemente haben in der Tat per Definition keine festgelegte semantische Bedeutung. Es sind strukturgebende Elemente, die uns erlauben, Inhalte sinnvoll innerhalb eines HTML-Dokumentes zu gliedern (Header, Navigation, Content, Footer, ect.) und mit CSS inhaltsunabhängig zu gestalten. Jetzt gibt es natürlich durchaus unterschiedliche Ansichten, wie und in welchem Umfang mit DIV-Elementen umgegangen werden soll. Doch diese Fragestellung hat wiederum nichts mit Semantik zu tun, sondern ist dem persönlichen Geschmack, bzw. dem zuvor diskutierten Thema um möglichst schlanken Code zuzuordnen.

Dann wären da noch bösen unsemantischen IDs und Klassennamen in vielen CSS-Frameworks. Das ist schlicht und ergreifend Unsinn. Klassen- und ID-Bezeichnungen fügen einer Webseite weder irgendeine semantische Information hinzu, noch geht den Seiteninhalten Semantik verloren, wenn der Quelltext mit Klassennamen eines CSS-Frameworks angereichert wird. Klassen- und ID-Bezeichnungen dienen der Zuordnung von CSS-Selektoren zu HTML-Elementen, mehr nicht. Oder als Frage formuliert: Was ändert sich wohl an der Semantik eines deutschsprachigen Fachtextes, wenn das ihn umgebende CSS-Layout englische oder gar spanische Klassennamen verwendet? Natürlich sollten Klassennamen stets sinnvoll gewählt werden, um die Les- und Wartbarkeit des Quellcodes zu erleichtern. Doch man muss den bekannten CSS-Frameworks zweifelsfrei eine durchdachte Systematik bei der Namensvergabe bescheinigen.

Verständnisprobleme bei Entwicklern rühren eher daher, dass die verwendete Systematik der Benennung nicht den Geschmack eines jeden Webdesigners trifft. Reine Gridbasierte Frameworks (Blueprint CSS oder 960 Grid System) sind sehr stark visuell orientiert. Das äußert sich zum einen in einem, dem früheren Tabellenlayout ähnlichen Aufbau des Markups und eben auch in der Bezeichnung der CSS-Klassen, die sich am Gridraster orientiert. Die Kritik von Jens Grochtdreis und Adam Bard ist in der Tat angebracht, denn sie macht deutlich, wie wenig bei diesem Layoutansatz von der Trennung von Inhalt und Layout noch übrig geblieben ist und wie aufwändig Änderungen werden können. Doch dieser berechtigte Kritikpunkt bezieht sich konkret auf den Layoutansatz von Blueprint CSS und dessen zahlreicher Clones und Modifikationen. Bei YAML hingegen ist eine Vielzahl an Gestaltungsmöglichkeiten vollständig per CSS realisierbar, ohne dass das Basismarkup verändert werden muss. Das Layoutkonzept von YAML ist deshalb gerade in Verbindung mit Content-Management-Systemen effektiv, denn die Templateerstellung ist üblicherweise relativ aufwändig. Weitreichende Gestaltungsmöglichkeiten eines solchen Templates per CSS ermöglichen auch hier eine Wiederverwendung.

Nur für Anfänger oder fehlender Lerneffekt?

Zum Abschluss noch zwei weitere typische Argumente aus der Diskussion contra CSS-Frameworks: So seien Frameworks in erster Linie für Einsteiger sinnvoll, während Profis keine derartigen Hilfen bräuchten. Sicherlich ist es für Einsteiger eine geringere Hürde, die Anwendung eines Frameworks zu erlernen, als echtes Fachwissen über CSS aufzubauen.

“A big problem with frameworks is when up and coming developers attach themselves to a framework as opposed to the underlying code itself. The knowledge gained in this case surrounds a specific framework, which severely limits the developer.”

Please Do Not Use CSS Frameworks, Jonathan Christopher

Doch wie weit kommt denn ein Einsteiger ohne Fachwissen wirklich? Kein Framework dieser Welt nimmt seinem Nutzer die Eigenverantwortung ab, individuelle Layoutelemente fehlerfrei zu positionieren und Inhalte semantisch korrekt auszuzeichnen. Wer Qualität will, kommt um Fachwissen nicht umhin. In jedem Fall bleibt der Lerneffekt also erhalten. Erspart bleibt dem Einsteiger lediglich der Frust, den Webentwickler jeder Qualifikation erleben, wenn sie sich der nicht ganz so standardkonformen Browserrealität stellen.

Für professionelle Entwickler dürfte wohl kaum ein nachhaltiger Lerneffekt aus der alltäglichen Anwendung von HTML & CSS zur Layout erwachsen, denn sie sollten dieses Fachwissen bereits besitzen. Wie einleitend erwähnt wurde, verlangt jedoch auch die Nutzung eines CSS-Frameworks eine gewisse Lernbereitschaft, um damit effizient arbeiten zu können. Und speziell im professionellen Bereich wirkt sich das zeitliche Einsparpotential erst richtig aus, denn die Einsparungen multiplizieren sich mit der Anzahl der Projekte. Die eingesparte Zeit lässt sich indes hervorragend zur Weiterbildung in Sachen HTML 5, WCAG 2.0 oder WAI-ARIA nutzen.

Im Gegensatz dazu ist es durchaus nachvollziehbar wenn Hobbybastler vorrangig den Spaß an der Freude schätzen und sich deshalb bewusst für die Handcodierung entscheiden, denn Effizienz ist in diesem Fall wahrscheinlich weder maßgebend noch erwünscht.

Fazit

Auffällig ist die Tatsache, dass massive Kritik an CSS-Frameworks, bzw. an YAML, von Profis kommt, die selbst offensichtlich noch nie mit YAML gearbeitet haben. Man kann darüber spekulieren, ob neben dem grundsätzlich verständlichen Misstrauen vor allem die Furcht vor fehlender Kontrolle über eine Instant-Lösung von dritter Seite eine große Rolle spielt. Man wird das Gefühl nicht los, als ob die Kritiker Angst hätten, dem für sie fremden Konzept ausgeliefert und in ihrer Arbeitsweise eingeschränkt zu sein, was jedoch bei hinreichender Fachkompetenz nicht der Fall ist. Jeff Croft bemerkte das schon vor einer ganzen Weile. Es stimmt, man muss sich auf das Konzept von YAML einlassen, und man muss Zeit investieren, um den Aufbau des Frameworks zu verstehen. Aber das gilt ebenso für jedes CMS, das ebenfalls nach eigenen Regeln funktioniert und erst nach weitaus längerer Einarbeitungszeit beherrscht werden kann als ein CSS-Framework. Die Argumentation "Ich will nicht" wäre deshalb eine ehrliche und völlig legitime Aussage, mit der ich als Entwickler von YAML gut leben kann. Eine solche, zutiefst persönliche Entscheidung für eine individuelle Arbeitsweise, bedeutet im Umkehrschluss jedoch nicht, dass CSS-Frameworks obsolet sind oder mit der eigenen Codequalität nicht konkurrieren könnten.

Es ist unbestritten, dass die aktuelle Vielzahl an Projekten und deren stark variierender Funktionsumfang, sowie die verschiedenen Layoutansätze eine qualitative Einschätzung ohne tiefgründige Recherchen fast unmöglich manchen. Zudem heften sich zahlreiche Projekte das offensichtliche Buzzword «Framework» gern ans Revers auf der Suche nach etwas Ruhm in Netz, scheitern bei genauerer Betrachtung jedoch den Ansprüchen, die an derartige Hilfsmittel für Webentwickler gestellt werden. Und nur aus diesem Grund ist Pauschalkritik momentan noch so einfach, wenn auch nicht gerechtfertigt. Denn einzelne Trittbrettfahrer schmälern langfristig nicht die zahlreichen Vorzüge, die aus der Arbeit mit CSS-Frameworks erwachsen können. YAML und auch YUI Grids lassen heute bereits erahnen, wohin die Reise für Webentwickler in den nächsten Jahren gehen wird.

Informationen

Dieses Essay entstand in enger Zusammenarbeit von Dirk Jesse und Nils Pooker. Die wie immer hervorragende englische Übersetzung lieferte Genevieve Cory.


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.