Mit leichter Verspätung (was sind heutzutage schon 4 1/2 Monate) gibt es jetzt auch die Folien meines Überblicksvortrags zum aktuellen Stand bei den CSS Frameworks zur WebTech 2009 in Karlsruhe. Thematisch ist es ein kommentierter Überblick, der aktuell in CSS- oder allgemein Layout-Frameworks (wie ich es treffender finde) umgesetzten Gestaltungsansätze.

Die aus meiner Sicht wichtigsten Erkenntis ist eine bessere und einfachere Definition eines Layout-Frameworks, welches folgenden Grundsätzen gerecht werden sollte:

Generisch

Funktionalität ist unabhängig von visueller Gestaltung

Wiederverwendbar

Kombinierbare, nach Funktionen getrennte, standardisierte Bausteine

Robust

Aufrechterhaltung der Funktion unter wechselnden Anwendungszenarien

Darüber hinaus geht meiner Meinung nach der Ansatz der verschiedenen Reset-Stylesheets zu weit. Verglichen habe ich hierbei Eric Meyers Reset-CSS und das Reset von YUI2. In beiden Ansätzen werden Darstellungsunterschiede zwischen verschiedenen Browsern beseitigt, aber quasi als Kolateralschaden dieser Maßnahmen gehen auch zahlreiche sinnvolle Voreinstellungen der Browser verloren. Hier bin ich seit je her anderer Meinung, weshalb der Reset-Baustein von YAML auch etwas anders aussieht. Wie die beigefügten Zitate zeigen, stoßen hier unterschiedliche Philosophien aneinander.

Der Vortrag wurde am 18. November 2009 anlässlich des WebTech Conference 2009 in Karlsruhe gehalten. Die Folien gibts bei SlideShare.

Der wurde am 12. November 2009 anlässlich des World Usability Days gehalten. Die Folien gibts bei SlideShare.

Note: This essay is also available in English.

Inhalt

• Die allgemeine Einschätzung der Webentwickler
• "CSS-Frameworks are never the best solution ..."
  • Frameworks, Codeschnipsel und Webdesign-Praxis
  • Über pragmatische Lösungsansätze und Minimierung von Quellcodes
  • Frameworks dienen der Webentwicklung, nicht der Philosophie
• Zukunftssicheres und wartbares CSS
  • Conditional Comments & Hacks
  • Eine Frage der Praxis: Wohin mit den Hacks?
  • Vorteile Conditional Comments
  • Conditional Comments in YAML
  • Modulare Stylesheets vs. Performance
• Liefern Frameworks unsemantischen Code?
• Nur für Anfänger oder fehlender Lerneffekt?
• Fazit

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.

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

Hinweis: Dieser Essay ist alternativ auch in Deutsch verfügbar.

Table of Content

• Web Developers' General Viewpoint
• "CSS-Frameworks are never the best solution ..."
  • Frameworks, Code Snippets and Web Design Practice
  • About Practical Solutions and the Minimizing of Source Code
  • Frameworks Serve Web Development, not Philosophy
• Futureproof and Maintainable CSS
  • Conditional Comments & Hacks
  • A Question of Practice: Where to Put the Hacks?
  • The Advantages of Conditional Comments
  • Conditional Comments in YAML
  • Modular Stylesheets vs. Performance
• Do Frameworks Create Non-Semantic Code?
• Only for Beginners / No Learning Effect?
• Summary

Web Developers' General Viewpoint

HTML and CSS are interpreted on the client side. Code should therefore be kept as streamlined as possible for any individual project. CSS frameworks, however, are project-independent modular systems, built with the goal of presenting the most universal solutions for the greatest variety of layouts. How do these seemingly incompatible approaches fit together?

A fair comparison of the more than twenty online projects calling themselves “CSS frameworks” is extremely difficult: their quality and documentation as well as their intended uses and even the basic concepts behind the layout concepts simply vary too much. Even worse, there is no clear and generally accepted definition of what really qualifies as a “CSS framework”. Almost encouragingly, so many people want to know what makes a framework that many people have published perfunctory and superficial surveys. The typical argumentation when discussing the pros and cons of CSS frameworks generally looks like this:

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

As the developer of the (X)HTML/CSS Framework YAML, I constantly use these arguments / stereotypes to keep the further development of my project on course. In this essay, I would like to clarify my position on the most common criticisms of frameworks, using my definition of a CSS framework (german article) as the standard.

CSS frameworks are powerful development environments for website creation and are generally oriented towards professional web developers. They provide universal layout building blocks and define a set of rules and parameters within which the developer can move freely.

Important here is the affirmation that CSS frameworks are tools for professionals. A project like YAML might – at first glance – look like a complete set of building blocks with finished layouts and samples, but all the templates and examples are merely demonstrations of how flexibly this environment can be used in professional web development practice.

In this discussion, I will repeatedly refer to Jens Meiert's articles, as he is one of the best-known German web developers and an energetic advocate of streamlined and standard-conforming code. I do not intend to personally attack Jens. On the contrary: I greatly appreciate his articles, as he is one of the few critics who does not merely complain, but can back up his arguments. His articles are thus a good basis for a thorough technical discussion.

"CSS frameworks are never the best solution ..."

The following will examine the truth of the purported disadvantages listed above. For various reasons, the fact is: CSS frameworks are not for everyone. Jens Meiert tries to name several reasons for this:

"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

This seems reasonable enough at first glance. A framework can be based upon web standards and best practices, but can never duplicate the particular methods of an individual developer or an agency with 100% accuracy. This is why working with a CSS framework requires a certain learning phase for the code and its working principles. This demands that individual developers adjust their work methods to the conceptual basis of that CSS framework.

Jens Meiert concludes, however, purely on the basis of the foreign code, that CSS frameworks always and necessarily bring an overhead of markup and too many CSS rules. This results from the assumption that frameworks would neither allow individual working procedures nor permit any possibilities of optimizing the final code. This assumption is the actual basis of his criticism. The mistake in his logic is, however, to assume that either individual working procedures or the concrete demands of any project determine the basis of professional web development – rather than working according to current web standards. This set of rules is not only the basis of all professional web development, it is also the basis of widely varied and highly individual working habits. YAML, currently the most complete and fully developed CSS framework, is also based on these web standards: this results in a foundation of transparent source code, a clear separation of content and layout, and semantically appropriate markup within the HTML page structure.

Let us examine current web development practice: in spite of all the variations in the millions of websites, their structure is basically similar. There is usually a header, a navigation, a clearly defined content area, perhaps a sidebar and finally a footer: these sections are often named directly in the source code, and have by now nearly become an informal convention. There may be several columns and perhaps teasers or small variations of the layout. Yet: websites are less different from each other than houses are, which – as unique as they may be – still all consist of a foundation, a living area, and a roof.

Frameworks, Code Snippets and Web Design Practice

Many fear that the use of a CSS framework with a set structure and predetermined class and ID names will unnecessarily hinder the designer's particular freedom. We note that the restrictions of the immutable HTML structure of the CSS Zen Garden have not kept designers from producing countless unique designs for the site.

The practice of the individual hand-coding of a website does not necessarily mean that developers invent their structure from a blank slate. A developer is precisely not an artist, kissed by the Muse to give the Web a new masterpiece of her creative fantasy. Web development is a trade and every developer uses trusted tools (code snippets) for every new site – even those who code by hand. And even if a developer swears that she uses no prefab copy & pasted lines of HTML or CSS, it is her expert knowledge that leads her to type her code according to the principles of a particular system. Web professionals have uncountable tried-and-true code snippets in their heads, just like architects remember countless possible variations on a house. And CSS frameworks are basically nothing more than a collection of tested, practice-oriented code snippets which work together and are subordinated to one general concept.

Often cited along with the arguments of too much markup and too many CSS rules is the allegedly poor quality of the code itself. Here, however, it is important to discuss the fundamentally different goals of various framework concepts. Most web developers understand the term "CSS framework" to refer not only to YAML, but also to YUI Grids, Blueprint CSS, 960 Grid System and various derivatives of latter two. It is easy to lose sight of the fact that unlike YAML, the sleek YUI-Grids do not contain the complete IE patches, the building blocks for forms, or comprehensive documentation. Blueprint CSS and 960.gs implement the design of a classic column grid as their conceptual foundation for the entire framework, and are thus much closer to the purely visually oriented table layout than to the implementation of web standards. As a framework in practice, YUI-Grids can be a bit tricky when designing complex elements, while the visually oriented frameworks with their precisely defined columnar layout cannot clearly separate content and design, which is certainly justified grounds for criticism.

About Practical Solutions and the Minimizing of Source Code

Professional CSS frameworks cannot fullfill the dream of always providing the absolute minimum code. Naturally, such an extreme can always only be reached for exactly one specific case and requires integration of the pages' final content. The goal of a good CSS framework can thus only be to develop building blocks with a relative minimum of markup and CSS rules and the greatest possible potential for reusability, and to use those to create a robust and efficiently usable layout system independent of content.

The difference between the absolute code minimum of a perfect individual creation and the relative minimum of the framework code is inherently variable, dependent upon various influences:

1. The more the layout planning can take the functional principles of the framework being used into account, the smaller the resulting overhead and the faster and simpler the implementation.
2. HTML and CSS almost always offer various ways to solve a problem, and hand coding is not guaranteed to find the ideal solution and implement it faultlessly. Expert knowledge comes into play here.
3. The absolute minimum is a theoretical value. In reality, CSS bugs and the varying CSS implementations of the different browser generations require constant compromises in markup and in the formulation of CSS rules.
4. CSS frameworks are tools for layout development. Only in the hands of an experienced developer does the final layout appear, precisely because optimization is determined by the requirements of the particular project. A certain overhead on the part of the framework is thus required to allow this flexibility.

CSS frameworks do not provide that perfect made-to-measure suit, but a compromise – and with good reason. YAML does not claim to deliver the best possible (in the sense: a made-to-measure suit = absolute minimum code) out of the box. Instead, I aim to provide the best possible code basis (in terms of efficiency and flexibility) for the developer. YAML's basic markup, the flexible grid building blocks (Subtemplates) and the three CSS Core Stylesheets (base.css, iehacks.css and print_base.css) are robust, reusable construction units, which have all gone through an optimization process in the course of developing the framework, and especially in the area of flexible layouts, this code basis is extremely streamlined in spite of its flexibility.

The objection of too much markup and rules is of course not answered by merely offering an empty folder for content along with a reset-css and a couple lines of basic CSS as a basis for coding – that cannot really be called a "framework". It is certainly streamlined, but will not save any more than a couple minutes in development time.

Frameworks Serve Web Development, not Philosophy

Another look at the practice: the desired minimum of code is also in hand-coded form only reachable in the extremely rare case of a customer who gives a developer free rein from the initial conception up to the launch – without any change requests in the middle. The reality of front end development is rather different. New changes are often demanded after clearance and even after the launch, which at that stage often mean additional markup. The minimum can only be determined at the end of the life of the project, and only as a best case scenario.

Jens Meiert is not the only one who misses the point of a CSS framework, as he compares a theoretically highly-optimized custom solution to the out of the box result of a CSS framework – in order to argue against the necessary overhead of the CSS frameworks. This argument first neglects the fact that only those professionals with the necessary expertise can and should optimize the basic project setup of any framework. Second, the advantages of working with a CSS framework are not in the area of final code optimization, but in all the previous stages of development, in which things change due to more factors than just through discussions with the customer. The growing complexity of large and challenging projects with several teams and diverse groups of decisionmakers does not allow for immediate optimization and finalization of code. YAML's concept offers a practice-oriented solution: robust in all the major browsers, designed for complex demands of web development, and ready for the vagaries of dealing with customers. That six of the recent Biene Awards for particularly accessible websites were awarded to YAML-based sites demonstrates what this framework can do in professional practice.

Futureproof and Maintainable CSS

Even in the area of CSS itself, there are many varied opinions on the utility of splitting up stylesheets according to modules, using hacks to tame Internet Explorer, and the use of conditional comments. YAML uses all these techniques with good reason.

Conditional Comments & Hacks

I quote Jens Meiert on conditional comments, as he is absolutely uncompromising on the use of Conditional Comments and a Reset-CSS.

"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 are indeed a special case, as they are a proprietary development from Microsoft and accordingly they don't quite behave like regular HTML comments do. Yet this does not necessarily cause problems. The same is the case for Internet Explorer's no-less idiosyncratic understanding of CSS properties, some of which are simply wrong (CSS bugs), and others are just not interpreted. Of course CSS bugs are not only evident in Internet Explorer, but Microsoft has led the browser market for many years. By now, we can solve all of Internet Explorer's presentational problems more or less easily, by avoiding particular markup / CSS constellations or by using CSS hacks.

A Question of Practice: Where to Put the Hacks?

For the hacks, there are two methods: either – as Jens Meiert recommends – do without the use of CCs and keep all bugfixes in the regular stylesheets. For the maintainer's search for particular CSS rules described above, this method may be advantageous. However, this does not avoid feeding useless CSS ballast to all the modern browsers (Firefox, Safari, etc.) which do not need it, yet thus load the pages more slowly. In addition, many bugfixes use parser hacks to address particular IE versions. But precisely these sometimes hard-to-read constructs will generally not validate, and they are not always ignored by other browsers – which certainly does not make this method less problematic regarding "weird layout problems".

Or, one can separate standard CSS and the IE adjustments completely, put all the CSS hacks into their own special stylesheet, and link it in the layout with a conditional comment. The advantages of this method are convincing and more than compensate for the possible disadvantage of slightly higher maintenance effort.

The Advantages of Conditional Comments

1. The standard CSS remains free of cryptic parser hacks for correcting IE bugs.
2. The bugfixes for Internet Explorer cannot accidentally disrupt the presentation in modern browsers.
3. The number of CSS adjustments for Internet Explorer is usually manageable. Such a stylesheet can generally be kept quite short.
4. The website gains on performance in modern browsers as they need not even parse through the bugfixes for Internet Explorer.

That was the general claim for the sensible use of conditional comments. Within YAML itself, it was possible to formulate bugfixes for most of the IE CSS bugs universally enough so that they engage without any work from the developer: they can be used preventively, thanks to the framework's set markup structure. This concept, which is currently exclusively used in YAML, leads on one hand to some slight CSS overhead, and yet on the other hand also provides many advantages.

Conditional Comments in YAML

1. Developers can concentrate on layout development for the standard-conform browsers, as YAML takes care of most of the adjustments for IE 5.x - 7.0 automatically. The amount of time spent correcting the general layout as well as forms etc. sinks dramatically.

2. Customers need not accept incompatibility with certain browsers, as the CSS framework inherently includes support for older IE-versions.
3. End users are freer in their choice of browser as the CSS framework supports more of them.

And finally, should Internet Explorer 8 completely conform to the standards and drive the older versions from the market, the only update necessary for a site to deactivate support for the old browsers is to delete the stylesheet from the server and remove the special comments from the layout. Can those who oppose conditional comments merely because they are proprietary or because the arbitrarily defined “maintenance problem” is too great really present an effective alternative to YAML's bugfixing concept, one which provides at least the same advantages for developers, customers, and end users?

Modular Stylesheets vs. Performance

CSS frameworks are development tools with a modular structure. They contain a variety of reusable building blocks (resetting CSS, screen layout, navigational elements, print version, etc.), which are integrated into the CSS layout and adjusted, depending on the requirements of any particular project. The principle of reusability is critical to the speed of the design process. Simultaneously, the use of tested components keeps maintenance and testing to a necessary minimum. Contrary to the development process, running a live site requires more speed than anything else. As every CSS file must be individually requested from the server and every request results in lag time and slows the loading of the page, it is a standard recommendation that a live site combine its stylesheets into as few as possible. A similar process is used for graphics (see CSS-Sprites). Still, these are two entirely independent phases of a project, which should not be arbitrarily mixed together in our discussion.

The CSS of a website is only interpreted by the user's client, and must first be downloaded from the server. Performance on a live site thus requires the smallest possible files for fast loading times. Tools like the YUI Compressor or minify can efficiently compress stylesheets. CSS comments and unnecessary whitespace (space characters, tabs, line breaks) are removed to shrink the file. However, compressed files are not suitable for development: they are not so easily readable by humans. Anyone coding layout by hand will always ensure that the CSS rules are legible and well-organized and will comment on particular passages to increase maintainability and to document design decisions for other members of the team. A division of stylesheets into logical parts thus lends itself to the care and maintenance of complex projects.

Developing with a CSS framework is not much different. The framework provides a new code basis which must be understood before one can trust it and work efficiently with it. To assist new developers, YAML's CSS building blocks are thoroughly documented using CSSDOC and the stylesheets are divided into consistent modules according to their function. CSS comments, meaningful names for layout elements, files, and folders is a basic requirement of professional web development and cannot be considered to be exclusive to either hand coding or to CSS frameworks. In either case, the development process has different requirements than does the live environment. A modular structure of stylesheets while in development is not an argument against CSS frameworks. The decision to optimize stylesheet performance for the live environment is entirely independent of any hand coding or framework use, and is always a sign of professional work.

Do Frameworks Create Non-Semantic Code?

A rather exasperating topic: CSS frameworks purportedly provide non-semantic code or even use non-semantic class names.

"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

This is nonsense. CSS layouts are typically based on DIV elements, which are intended to have no semantic meaning: they are merely structural elements which allow us to divide content neatly into useful sections (header, navigation, content, footer, etc.) and to display it independently of that content. Of course there are certainly various approaches to the extensive or restrained use of DIV elements, but that is really a separate issue and has nothing to do with semantics, and is really a matter of personal taste and of keeping your code as short as possible.

Now to address those evil non-semantic IDs and class names in many CSS frameworks: they are completely irrelevant. Class and ID names add no semantic information to a website, nor does the actual content itself become less semantic when the source code is enriched by CSS frameworks class names. Class and ID names are intended purely to match CSS selectors to HTML elements: nothing more. Or let us ask: what changes in the semantics of a German technical article if the class names of the layout elements surrounding the content are in English? Or in Spanish? Class names must be carefully chosen purely for the easy maintenance and readability of the source code, and indeed, we must give the known CSS frameworks credit for a sophisticated and consistent naming system.

Developers' misunderstandings stem more often from the fact that the system cannot be to everyone's individual taste. Purely grid-based frameworks (Blueprint CSS or 960 Grid System) are strongly visually oriented. This results in a markup structure that strongly resembles the old table layouts and names the CSS classes accordingly, which are oriented to the grid matrix. Jens Grochtdreis's (german article) and Adam Bard's criticism is fully justified, as they point out how little this layout technique can separate form from content and how difficult changes are. However, this valid point relates specifically to the technique employed by Blueprint CSS and its many clones and modifications. YAML, on the other hand, allows a great variety of designs implemented in pure CSS, without any changes in the basic markup. YAML's layout concept is particularly efficient in combination with Content Management Systems, as templating is generally relatively complicated. The limitless design possibilities of such templates using CSS increase their potential reusability.

Only for Beginners / No Learning Effect?

Finally, two further typical arguments against CSS frameworks: they are allegedly useful only to beginners, as real professionals need no such help. It is certainly a good deal easier to learn how to use a framework than to build up expert knowledge of CSS.

“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

But how far does a beginner really get without learning? No framework in the world can save users from the responsibility of positioning individual layout elements correctly and labeling their content semantically correctly. Anyone who requires quality will require expertise. Learning cannot be avoided. Beginners are only spared the frustration that any web developer faces when confronted with the not-so-standardized browser reality.

Professional developers will not gain a lasting learning effect by using HTML and CSS daily – they should already know how it works. As mentioned in the introduction, using a CSS framework does require a certain willingness to learn in order to work efficiently with it. And the timesavings are of course much greater in professional webdesign, as the development time is shortened for each additional project that uses the system. This time can then be used for investigating new developments like HTML 5, WCAG 2.0 or WAI-ARIA.

In contrast, it is certainly understandable that hobby designers prefer to focus on the fun and choose to code everything by hand, as efficiency in a hobby is generally neither required nor desired.

Summary

It's quite noticeable that damning criticisms of CSS frameworks or of YAML come from professionals who have clearly never worked with YAML. One can only speculate on the reasons: if, even more important than a basically healthy distrust, a general fear of losing control to an instant third-party solution plays a larger role. I have to wonder if the critics are simply afraid to be at the mercy of a foreign concept and constricted in their creative freedom, which is certainly not the case for those with enough expertise. Jeff Croft noticed that quite a while ago. It's true, you have to trust and work with YAML's concept, and you have to take time to understand the structure of the framework. But that is true of any CMS too, as they all have their own rules and are certainly only manageable after a much longer time spent learning than a CSS framework requires. The argument “I just don't want to” can certainly be an honest and legitimate objection – I can live with that. Such a very personal decision in favor of a particular way of doing things, however, does not mean that CSS frameworks are obsolete or cannot compete with one's own code quality.

It is undeniable that the current number of projects and their starkly varied complement of functions, as well as their various approaches to layouts make a thorough comparison of their qualities almost impossible. Even more aggravating, many online projects gladly assume the buzzword “framework” as part of their name in an attempt to gain in popularity, yet their quality leaves much to be desired for the professional designer. This certainly makes sweeping criticism simple, if not justified. A few copycats will certainly not detract from the many advantages that working with CSS frameworks offers in the long term. YAML and YUI Grids both give us an idea today of what the future holds for web development.

This essay was developed in close cooperation by Dirk Jesse and Nils Pooker. The as always excellent English translation provided Genevieve Cory.

In regelmäßigen Abständen rufen deshalb seit ein paar Jahren Webentwickler zur aktiven Sterbehilfe für den Internet Explorer 6 auf, aktuelles Beispiel: Skandinavien. Die norwegische Webseite Finn.no ging kürzlich in die Offensive und rät ihren Besuchern aktiv und unverblümt zum Umstieg. Ähnliches wünscht sich das Projekt IE Death March – in beiden Fällen gefeiert von einer Vielzahl an Webentwicklern.

Das Dilemma wird noch deutlicher, denn wie Ingo Chao im XING Blog zielsicher den Finger in die Wunde legt, waren es die Webentwickler selbst, die mit ihrer erfolgreichen Suche nach Workarounds und CSS-Hacks sowie deren Sammlung und Veröffentlichung erst dafür gesorgt haben, dass sich dieser Browser bis heute über Wasser halten konnte.

Isn’t it ironic that we, as web developers, have made this nonsense possible? It is our documentations and analyses of browser bugs. We, not the vendors, did that. We found workarounds for today’s complex pages in IE, or, if this failed, we reverse engineered its bugs for standards-compliant browsers so they act like IE. So we made this trap for ourselves, conscious of the consequences or not.

Ebenso Recht hat natürlich auch Jens Grochtdreis mit seinem Hinweis, dass die Webentwickler seinerzeit gar keine andere Wahl hatten, als sich mit dem IE6 zu arrangieren. Von Microsoft war aufgrund fehlender Konkurrenz keine Aktivität zu erwarten.

Fakt ist aber auch: Die Bugs des IE6 sind bereits seit einem halben Jahrzehnt im Netz bestens dokumentiert, einschließlich passender Fixes und Workarounds. Und der überwiegende Teil lässt sich auf relativ einfache Art und Weise fixen. Zu einem offensichtlichen Problem wurde diese Situation erst mit dem rasanten Aufstieg des Firefox und der Wiederaufnahme der Entwicklungsarbeit bei Microsoft, die Ende 2007 in der Veröffentlichung des IE7 mündete, ohne jedoch den IE6 zu ersetzen. Seither ist richtig Bewegung im Browsermarkt, genauso wie in der Entwicklung neuer Webstandards (CSS3, HTML 5 samt Canvas, WAI-ARIA, RDFa, SVG).

Was war zu erst da, die Henne oder das Ei?

Also, wie kommen wir raus aus diesem Dilemma? Meinungen dazu gibt es viele, Antworten aber leider nicht. Denn wenn sich das Problem Internet Explorer 6 mit Unterschriftenaktionen, in Webseiten eingeblendeten Textboxen mit Wechselempfehlungen oder gar der Verweigerung von CSS-Styles für den IE6 tatsächlich lösen ließe, dann hätte das schon 2007 funktionieren müssen. Dummerweise haben wir jetzt 2009 und sind keinen Schritt weiter. Zwar ist der Marktanteil des IE6 bereits stark gesunken und wird weiter fallen (vermutlich aber langsamer), doch es will niemand mehr so lange warten, bis er von selbst in der Bedeutungslosigkeit untergeht.

Die große Chance, die Herzen aller Webentwickler dieser Welt zu rühren, hatte Microsoft erstmals beim Release des Internet Explorer 7 - und ließ sie ungenutzt. Man unterstützte nur Windows XP, ließ ältere Betriebssysteme außen vor und machte die Installation nicht zur Pflicht – aus Angst vor massiven Problemen mit alten Webseiten sowie Unternehmenssoftware vieler großer Firmen, die speziell auf den IE6 abgestimmt waren (und es vermutlich vielerorts auch heute noch sind). Den zweiten Matchball hat Mircosoft mit dem IE8 gerade in der Hand. Doch auch jetzt sieht es nicht so aus, als bringe Microsoft den notwendigen Mut auf, einen klaren Schnitt zu machen.

So motivierend oder eindringlich öffentliche Kampagnen auch sein mögen – sie bleiben lokale Strohfeuer. Nur Microsoft erreicht weltweit die kritische Masse und könnte mit einem Zwangsupdate auf den Internet Explorer 8 in Verbindung mit einer konsequenten Ausrichtung auf Webstandards (ohne Kompatibitätsmodus und IE7 Emulation) für unmittelbare und nachhaltige Reduktion der IE6-Installationen sorgen, so dass wir das Problem nicht weiter aussitzen müssen. Doch das wird nicht geschehen und so werden die bestehenden IE6-Installationen nur gemächlich weniger werden.

Was also tun?

Der Internet Explorer 6 ist seit nunmehr 8 Jahren ein fester Bestandteil des Internets und hat die Weiterentwicklung der Standards nicht behindert. Genauso wenig darf seine Anwesenheit den Einsatz neuer Techniken behindern. Genau das tut er jedoch – vorrangig in den Köpfen vieler Webentwickler.

Aufklärung!

Jens Grochtdreis wird nicht müde, immer wieder auf die einzigartigen Stärken des Mediums Internet zu verweisen ...

Der Kernpunkt zur Lösung des Problems ist ein anderer. Wir müssen uns von der irrigen Annahme verabschieden, wir könnten Pixelperfektion in allen Browsern garantieren. Wir müssen uns von der Annahme verabschieden, Pixelperfektion sei ein sinnvoller Wert. Vor allem Kunden und Grafiker müssen in meinen Augen lernen, dass Pixelperfektion nur im Bildbearbeitungsprogramm sinnvoll ist, aber nicht in unterschiedlichen Browsern.

... und weiter ...

Alle, die professionell für das Internet arbeiten, sollten wirklich begreifen, dass das Geniale des Internet seine Flexibilität ist.

...

Wenn diese Flexibilität aber die große Stärke des Internet ist, warum versuchen dann so viele Beteiligte, sie einzuschränken?

Das Verständnis für die Einzigartigkeit des Mediums muss erst einmal in die Köpfe der Webentwickler und Grafiker und zur eigenen Überzeugung reifen. Ist es da angekommen, wird es auch einfacher, Kunden besser zu beraten. Es geht um das Grundverständnis, dass kein Webdesigner oder Grafiker die Kontrolle über die Darstellung seiner Webseite im Browser des Nutzers hat.

Doch halt: So wichtig Aufklärung über die Vorteile von Webstandards und die Nachteile eines veralteten Browsers für und unter Webentwicklern auch ist, so sehr kann sie bei Kunden und Usern aufdringlich und bevormundend herüberkommen. Ein erhobener Zeigefinger hat meiner Meinung nach wenig Überzeugungskraft, denn gleichzeitig wissen wir (und auch die User), das der IE6 auch mit aktuellen CSS-Layouts durchaus klarkommt. Zigtausende Seiten beweisen es. Wo liegt also für den User der Nutzen eines solchen Wechsels? Um uns Webdesigner zufrieden zu stellen? Wohl kaum.

Viel einfacher lassen sich User zu einem Browserwechsel bewegen, wenn der Einsatz neuer Webtechniken (ohne dass sie sich selbst dessen bewusst sein müssen) zu einem besseren Nutzererlebnis führt. Jüngstes Beispiel: Die Vorstellung von Bespin, Mozillas Texteditor auf Canvas Basis. Eine derartige Applikation verlangt für die Anwendung selbstverständlich einen aktuellen Browser. Und niemand erwartet ernsthaft, den aktuellen Stand der Technik auf einem technisch veralteten Browser zum Laufen zu bekommen. Die Applikation ist das Zugpferd, in dessen Windschatten sich Anwender gern einen neuen Browser installieren. Und genau dann ist die konsequente Anwendung aktueller und neuer Standards legitim und zugleich förderlich für die Weiterentwicklung des Webs. Genau solche Projekte brauchen wir – und sie werden kommen, ohne Zweifel.

Nutzt Frameworks!

Ob ihr es hören wollt oder nicht: Nutzt Layout-Frameworks!  YAML, YUI grids, 960gs oder Blueprint CSS befreien vom permanenten Kampf mit Browserinkompatibilitäten und niemand muss heute das Rad ein zweites Mal erfinden. Natürlich geht auch dann nicht jedes Projekt völlig ohne Stress mit dem Internet Explorer über die Bühne. Doch die Probleme sind zumindest mit YAML so gering und überschaubar,  dass das Aussitzen eines langsamen Aussterbens des IE6 kaum einen YAML-Anwender ernsthaft Sorgen bereitet. Die weiteren genannten Frameworks mögen geringere Fähigkeiten im Bereich der Bugprävention haben, für die jeweilige Kernfunktionalität ist die Sicherheit aber dennoch gegeben und führt somit in jedem Fall nachhaltig zu kürzeren Entwicklungszeiten.

Zweifelsohne notwendige Einarbeitungszeiten sind als Argument gegen CSS Frameworks eher schwach bis untauglich, denn diesem einmaligen Aufwand steht eine nachhaltige Zeiteinsparung bei korrekter Anwendung gegenüber. Und mal ehrlich: Weiterbildung und das ständige Erlernen neuer Techniken sind Grundlagen professioneller Arbeit, denn das Web erfindet sich alle paar Jahre neu.

Es zeugt jedoch nicht von Professionalität, öffentlich lautstark auf den verbuggten Internet Explorer 6 zu schimpfen und gleichzeitig   zeitsparende Weiterentwicklungen im Bereich CSS zu ignorieren. Denn gleichermaßen gilt: Seit vielen Jahren bereits gibt es für fast ausnahmslos alle CSS-Probleme des Internet Explorer 6 sinnvolle CSS-Hacks oder Workarounds. Weiterhin existieren zahlreiche Methoden, diese Anpassungen so zu integrieren, dass sie die Pflege und Weiterentwicklung eines Layouts nicht behindern. Wer sich der rein manuellen Layoutentwicklung aus eigenem sportlichem Ehrgeiz stellt und Handkodierung bevorzugt, der kommt mit Ausdauer und fundiertem Fachwissen mit Sicherheit ebenso zum Ziel. Aber schon heute würde er das Ziel nicht mehr als erster überqueren. "Working in the now" ... wer mir nicht glauben mag, der lasse sich von Chris Heilmann überzeugen.

In jedem Fall kann ein Kunde erwarten, dass wir als professionelle Webentwickler mit dem Internet Explorer 6 umzugehen wissen und er darf ebenfalls erwarten, dass heute die Unterstützung des IE6 bei der Erstellung eines Screenlayouts nicht zu spürbaren Mehrkosten führt, denn was mit Framework-Einsatz machbar ist, sollte auch bei professioneller Handkodierung ohne Extrakosten realisierbar sein.

Anders sieht der Fall für Einsteiger und Hobbybastler aus. Hier kann ich die Flüche auf den IE6 durchaus verstehen, denn er macht das Erlernen von HTML & CSS unnötig schwer durch seinen zahlreichen Darstellungsfehler. Und es wahrlich nicht einfach, die Vorteile von Webstandards lieben zu lernen, wenn der lokale Testbrowser des Weltmarktführers sich nicht an diese hält.

Funktionale- anstatt visueller Anpassungen

Wenn es darum geht, sich die Arbeit mit dem Internet Explorer 6 zu erleichtern, ist es doch in den seltensten Fällen legitim, ihn ganz außen vor zu lassen. Auf privaten Webseiten ist es sicherlich vorstellbar, im öffentlichen und geschäftlichen Leben ist ein Ausschluss des Internet Explorers jedoch heute und in naher Zukunft ein absolutes Unding. Demzufolge kann es nur in kleinen Schritten vorwärts gehen. Auch hierzu finde ich Ingo Chaos Ansatz ausgesprochen sinnvolll ...

The web is about information, networking, and interaction. This means,  a page simply has to work. As I see it, disgraceful degradation would abandon the attitude of everything-is-possible. Functional hacking should supersede the obsolete presentational hacking now, or we keep being trapped in a costly, mutual mistake of the web developers and the web consumers.

Eine Webseite muss in erster Linie benutzbar sein und ihre Aufgabe erfüllen. Die überwiegende Mehrheit der IE6-Nutzer surft eben nicht parallel mit Safari oder Firefox und wird sich deshalb auch an visuellen Abweichungen/Einschränkungen des Layouts nicht stören. Deshalb sollte man die Eingriffe auf notwendige funktionelle Anpassungen beschränken und nicht versuchen, per halbtransparenten Screenshot-Vergleich visuelle Deckungsgleichheit zwischen Browsern zu erzielen, zwischen denen gleich mehrere Evolutionsstufen liegen. Ob via Progressive Enhancement, Graceful Degradation oder doch ein härterer Schnitt, wird immer projektabhängig zu entscheiden sein. Es sollte jedoch jedem Kunden im Beratungsgespräch überzeugend klarzumachen sein, dass Pixelperfektion in dieser Situation nicht das erstrebenswerte Ziel sein kann. Genauso wie ein 8 Jahre alter Röhrenfernseher nicht mehr die visuelle Brillianz aktueller Plasma-TVs erreicht.

Umgang mit neuen Webtechnologien

Auch wenn es vermutlich noch Jahre dauern wird, bis alle Module von CSS3 Recommendation Status erhalten, so unterstützen dennoch bereits jetzt Firefox, Safari und Opera einige interessante neue Eigenschaften:

• erweiterte Gestaltungsmöglichkeiten für Rahmen (Border-Radius, Border-Image)
• Mehrfache Hintergrundgrafiken
• Nachladbare Schriften mit @font-face
• Schatteneffekte (Box- und Text-Shadow)
• Alphatransparente RGB-Kanäle (RGBa)
• Verläufe (Gradients)
• Animation und Übergänge (Transitions)
• usw.

Auch für die modernen Browser ist das momentan die Speerspitze, denn selbst Firefox 3 und Opera 9 unterstützen momentan noch nicht alle diese Features (beim Safari 4 bin ich mich mir nicht ganz sicher) und so wird einen Teil dieser Eigenschaften momentan noch sehr zurückhaltend einsetzen. Runde Ecken via border-radius können sie hingegen alle und es ist ein hervorragendes Beispiel, wie CSS3 die zahllosen, teils recht markupintensiven Rounded-Corner Lösungen obsolete macht.

Keine dieser Eigenschaften wird der IE6 jemals verstehen, der Internet Explorer 8 übrigens auch nicht – sollen wir deshalb sie deshalb einfach links liegen lassen? Ganz klar, Nein. Dennoch sollte klar sein, dass wir uns hier am anderen Ende des Entwicklungszweiges befinden, am vorderen. Demzufolge ist momentan nur die neueste Browsergeneration (z.T. sogar nur Betaversionen) überhaupt dazu in der Lage,fehlerfrei mit diesen neuen Möglichkeiten darzustellen. Der Einsatz muss daher immer mit Bedacht erfolgen.

Erst vor einem Monat veröffentlichte Peter Kröner eine ausführliche Zusammenstellung der aktuellen Browserunterstützung von HTML 5, verbunden mit einer Einschätzung für eine Nutzung schon heute. Wie bei CSS3 gilt: Wir befinden uns an der Spitze dessen, was gute aktuelle Browser leisten können. Aus meiner Sicht macht es deshalb heute noch keinen Sinn, HTML 5 als Grundlage für die Layoutentwicklung zu nutzen. Viel zu lückenhaft ist da noch die Browserunterstützung. Dennoch lassen sich, wie Peter Kröner zeigt, die neuen Formulartypen durchaus bereits verwenden und können Nutzern moderner Browser bereits heute das Leben erleichtern. Doch auch das ist momentan nur Profis zu empfehlen, denn ein Formularfeld vom Typ "date" liefert nur im Opera 9 gesichert auch einen validierenden Datumsstring, in anderen Browsern muss diese Validierung auch weiterhin beispielsweise per JavaScript erfolgen. Daher sind Fallback-Lösungen zwingend gefragt.

Fazit

Der Internet Explorer 6 wird nicht über Nacht verschwinden, das sollte jedem klar sein. Das ist auch gar nicht so wichtig, denn die Probleme sind nicht neu und die Lösungen seit Jahren bekannt. Die Ursache für die plötzliche Aufruhr muss ihren Ursprung also woanders haben. Nämlich in der Tatsache, dass wir mehr und mehr in Konflikte kommen mit aktuellen Technologien, die wir nicht einsetzen können, solange wir uns Pixelperfektion und identische Optik in allen Browsern (seien sie auch noch so alt) selbst verordnen. Solange wir dieses Dogma nicht aufgeben, befinden wir uns in einer Endlosschleife, passend zum Titel dieses Essays.

Gerade im Bezug auf den Einsatz neuer Technologien stellt sich letztlich nämlich die Frage, ob der Internet Explorer 6 hier wirklich die einzige Bremse ist? Auch die Versionen 7 und 8 des Internet Explorers hängen dem Stand der Technik um Jahre hinterher, werden uns aber noch weitaus länger begleiten als der IE6. Die eigentliche Frage müsste daher lauten: Wie gehen wir heute und in Zukunft mit einem Internet Explorer um, der in jeder Version dem aktuellen Stand der Technik um zwei bis drei Jahre hinterher hinkt? Denn machen wir uns nichts vor. Wenn wir diese Frage keine Antwort finden, reiben wir uns in zwei Jahren die Augen weil wir exakt an der gleichen Stelle stehen werden wie heute, nur dass aus der Zahl 6 eine 7 geworden ist. Auch Tomas Caspers, drüben bei Einfach für Alle sieht das übrigens so.

Der Internet Explorer 6 wurde am 21. August 2001 von Microsoft veröffentlicht und hatte in bis zum Erscheinen des Internet Explorers 7 einen weltweiten Marktanteil zw. 80 und 90 Prozent.

Aktuell steht die Version 8 des Internet Explorers in den Startlöchern, welche von Microsoft mit dem Anspruch entwickelt wird, erstmals einen Browser mit fehlerfreier Unterstützung für CSS 2.1 auszuliefern.

Einer der wichtigsten Punkte beim Vergleich und der Arbeit mit Layout-Frameworks ist die klare Trennung zwischen anwendungsorientierten Grid-Frameworks und entwicklungsorientierten CSS-Frameworks, da beide Typen vollkommen unterschiedliche Zielsetzungen verfolgen. Anhand der unterschiedlichen Konzepte und verschiedener Beispielprojekte werden Funktionsumfang, gestalterischen Möglichkeiten und auch die grundsätzlichen konzeptionellen Grenzen beider Framework-Typen erläutert.

Auf den Punkt gebracht lassen sich die beiden Typen wie folgt beschreiben:

• Sinn und Zweck von Grid-Frameworks sind schnelle Ergebnisse in der Anwendung.
• Sinn und Zweck eines CSS-Frameworks ist die Bereitstellung einer möglichst leistungsfähigen Entwicklungsumgebung.

Dank der hervorragenden Organisation des Kongresses kann ich an dieser Stelle nun nicht nur die Folien meines Vortrags zur Verfügung stellen (bei Slideshare auch als PDF zum Download), sondern es steht sogar einen Livemitschnitt des gesamten Vortrags im MP3-Format bereit (Download-Link in der Infobox). Ich bitte, den etwas holprigen Start des Vortrags zu entschuldigen - ich musste nach meiner Virusgrippe zunächst vorsichtig meine Stimme testen.

Hinweis: In der PDF-Fassung der Folien sind alle von mir vorgestellten Projekte verlinkt und können somit direkt angeklickt und die jeweiligen Webseiten besucht werden.

Der wurde am 4. September 2008 beim Webkongress Erlangen (Direktlink) gehalten.

• Kongress-Homepage
• Vortrag im MP3-Format (42.1 MB)
• Folien im PDF-Format (1.7 MB)

Konzept

Das erfrischende Konzept heißt Workshops und soll Einsteigern die Essenz von CSS nahebringen, ohne sie zu zwingen, die 458 Seiten von vorn nach hinten durchackern zu müssen. In insgesamt 30 Workshops mit einem Umfang von jeweils 10-20 Seiten werden dabei zahlreiche Themen des Webdesigns behandelt. Jeder Themenkreis umfasst drei bis vier in sich geschlossene Workshops. Sie starten jeweils mit einer kurzen Beschreibung des Arbeitsziels, gefolgt von der Entwicklung des HTML-Quellcodes und der Gestaltung der Elemente per CSS.

Der Schwerpunkt des Buches liegt ganz klar auf dem Designaspekt, weshalb das durchweg farbige Layout zu gefallen weiß und einen hervorragenden optischen Eindruck hinterlässt.
Unterbrochen werden die Workshops in regelmäßigen Abständen durch insgesamt 4 Exkurse, in denen kompakt CSS-Grundlagenwissen vermittelt wird. Die Zielgruppe sind – wie es der Titel bereits verrät – Einsteiger. Sie sollen CSS nicht aufgrund grauer Theorie, sondern anhand von ausgewählten Best-Practice-Lösungen erlernen, die ein breites Spektrum an Alltagsaufgaben abdecken.

Inhalt

Die Themenwahl des Buches ist ausgewogen. In den ersten Workshops geht es um die Gestaltung von Überschriften mit CSS und Image-Replacement-Techniken, dem Zusammenspiel von Text und Bild sowie listenbasierten Navigationen. Später steigt der Anspruch. So werden Bildergalerien mit CSS gestaltet und mittels JavaScript zum Leben erweckt, dann geht ans Eingemachte bei der Gestaltung von Formularen und Tabellen.  Die letzten drei Themenkreise umfassen den kreativen Umgang mit Hintergrundgrafiken, einen Einblick in die Erstellung fixer, elastischer und flexibler Layouts sowie einem abschließenden Special zu Diagrammen und Mikroformaten. Die neun Themenkreise sind abwechslungsreich und bieten für Einsteiger augenscheinlich einen umfassenden Überblick, wobei sich innerhalb der Themenbereiche einfache und anspruchsvollere Beispiele durchaus abwechseln.

Heiko Stiegert schreibt flüssig und nicht zu kompliziert, sodass man seinen Gedanken immer folgen kann. Alle Beispiele funktionieren fehlerfrei auf aktuellen Browsern sowie im IE6 und sind vollständig auf der Buch-DVD enthalten. Diese enthält übrigens neben zahlreichen Demoversionen verschiedenster HTML-Editoren noch vier zusätzliche Workshops im PDF-Format (natürlich ebenfalls im schicken, farbigen Layout des Buches), die nicht mehr im Buch untergebracht werden konnten.

Alles in allem eine runde Sache – möchte man meinen, dennoch ist das Buch nichts für Einsteiger, was im Folgenden auch begründet werden soll.

Kritik

Das Buch startet ohne jede Einleitung direkt mit dem Exkurs “Was sind Cascading Style Sheets”, was auch gleich im ersten Satz erklärt wird: “Cascading Style Sheets, oder kurz CSS, ist eine deklarative Auszeichnungssprache zur Definition von Formateigenschaften einzelner (X)HTML-Elemente.” Alles klar?

Im Anschluss werden die Möglichkeiten zur Einbindung von CSS in HTML vorgestellt, wobei von der Einbindung per STYLE-Element und STYLE-Attribut strikt (und ohne Ausnahmen) abgeraten wird. Dass diese Optionen in der namensgebenden “Kaskade” sehr wohl ihre Berechtigung haben, wird verschwiegen. Dafür werden im Schnellverfahren die Einbindung externer Stylesheets per LINK-Element, per @import-Regel und Conditional Comments für den Internet Explorer eingeführt, was Einsteiger mit Sicherheit überfordern dürfte.

Teilweise konstruierte Beispiele

Eigentlich sollten die Workshops Best-Practice-Lösungen anbieten, doch viele der Beispiele wirken konstruiert. Gleich im ersten Workshop “Überschriften per CSS gestalten” soll eine Überschrift zweizeilig dargestellt und gestaltet werden. Dazu wird der hintere Teil der Überschrift mit einem SPAN-Element umschlossen, welches für den Umbruch in die zweite Zeile sorgt. Ohne jede Erklärung sehen sich Einsteiger in diesem Workshop mit der Kurzschreibweise der font-Eigenschaft konfrontiert, einschließlich relativer Schriftgröße und Zeilenabstand. Dann wird plötzlich auch noch der Selektor :first-line eingeführt, um der ersten Zeile der Überschrift eine andere Farbe zuzuweisen. Egal welchen Teil der Überschrift man mit dem SPAN umschließt, mit h1 { ... } und h1 span { ... } lassen sich beide Teile vollständig gestalten, :first-line ist hier absolut unnötig und bläht das CSS nutzlos auf.

Ein weiteres Beispiel folgt im Workshop “Sind Gutenbergs Grundlagen auch auf das WWW übertragbar”. Hierbei geht es um die Positionierung nebeneinander liegender Textblöcke. Für viele Einsteiger ist das der Punkt, wo sie aus purer Verzweiflung zu Tabellen greifen, daher sind Lösungsvorschläge bei Einsteigern in höchstem Maße willkommen. Heiko Stiegerts Angebot basiert auf dem Multi-Column-Modul, welches vielleicht in CSS3 enthalten sein wird. Der Ansatz ist wunderbar einfach, logisch und leicht nachzuvollziehen. Dumm nur, dass weder das Multi-Column-Modul noch CSS3 praxisrelevant sind, unter anderem weil der Internet Explorer (IE5.x – 8.0) nichts dergleichen darstellen kann. Darauf weist der Autor am Ende des Workshops in der Marginalspalte auch hin, nur leider ohne Alternativen aufzuzeigen – oder per Querverweis auf den Workshop “Infoboxen in mehrspaltigem Layout”, ca. 150 Seiten weiter hinten im Buch zu verweisen, der zumindest einen gangbaren Lösungsweg aufzeigt.

Auch in den späteren Workshops wiederholt sich der Eindruck, konstruierter Beispiele. So wird beispielsweise im Workshop “Kooperation in Text und Bild” dem IE6 mühsam mittels JS-Hack die korrekte Darstellung alphatransparente PNG-Grafiken beigebracht, obwohl in dem konkreten Fall ein transparentes GIF vollkommen ausreichend gewesen wäre, was selbst der IE5.x problemfrei darstellt. Eine Übersicht darüber, wann welches Grafikformat (GIF, PNG 8-/24-bit, JPEG) sinnvoll ist, hätte ich mir hingegen in einem designorientierten Buch gewünscht.

Fachbegriffe, interne und externe Querverweise

Die Idee von in sich stimmig gestalteten Workshops ist ausgezeichnet, allerdings übertreibt man es hier mit der Abgrenzung. Das Buch enthält so gut wie keine Querverweise. Die Handvoll existierender Verweise in der Form “siehe Kapitel 2” sind weitgehend nutzlos, da die Workshops nicht nummeriert sind.

Auch auf Fachbegriffe und externe Verweise (Links zu Webseiten) wird verzichtet. Im Workshop Image-Replacment verwendet Heiko Stiegert die Phark-Methode, ohne sie beim Namen zu nennen. Gleichzeitig wird zur Wachsamkeit ermahnt: “... denn manche der Image-Replacement-Methoden setzen display:none ein”. Ist das wirklich der Fall? Jens Meierts Übersichts-Artikel (eigentlich ein Pflichtlink) erläutert 16 anerkannte Image-Replacement-Methoden (natürlich auch Phark) – und keine der vorgestellten Methoden verwendet display:none, was in der Tat der falsche Weg wäre. Einsteiger werden hier verunsichert, obwohl es im Internet gute Informationsquellen gibt, die zeigen, dass es dafür gar keinen Grund gibt.

Im ersten Navigations-Workshop wird eine horizontale Navigation erstellt, wobei die “Sliding-Doors”-Technik zum Einsatz kommt, ohne die Bezeichnung zu nennen. Einsteiger mögen zunächst begeistert sein, doch das Thema ist nichts Neues und Google weiß zu diesem Begriff eine Menge zu berichten. Ohne den Fachbegriff bleibt die Tür zu diesen Informationen allerdings verschlossen.

Aufgrund des anwendungsorientierten Workshop-Charakters sind Einsteiger zwangsläufig auf zusätzliche Lektüre angewiesen. Da ist es ungünstig, dass in mehreren Workshops SPAN- oder A-Elemente (beides klassische Inline-Elemente) zu Block-Elementen umdefiniert werden. Ein Hinweis auf das dahinterstehende Prinzip, mindestens aber die Erwähnung der Fachbegriffe, wären mehr als nur wünschenswert.

Am meisten gestört hat mich die Wahl des Markups im Workshop “Ein barrierefreies Formular”. Heiko Stiegert verwendet darin ohne Begründung Definitionslisten zur Gliederung der Input-Elemente und Labels, was mit Sicherheit diskussionswürdig ist. Das Formular bleibt weitgehend ungestylt, die Elemente werden lediglich horizontal ausgerichtet. Im darauffolgenden Workshop “Ein attraktives Formular” (Workshop-Titel auf der DVD) wird im Markup hingegen plötzlich eine unsortierte Liste verwendet und auch die optische Gestaltung des Formulars macht deutlich mehr her. Der im Vorwort definierte Anspruch des Buches “Ein Design muss unter Berücksichtigung von Accessibility und Usability schon lange kein fades und langweiliges oder einfach nur schmückendes Beiwerk sein.” wird in den Formularbeispielen aus der Sicht des Lesers ad absurdum geführt, denn das barrierefreie Formular verwendet streitbares Markup und sieht hässlich aus. Das “attraktive” Formular hingegen verwendet ein anderes Markup, was die Vermutung aufkommen lässt, nicht mehr barrierefrei zu sein bzw. das Barrierefreiheit und schöne Optik halt doch nicht zusammen passen. Einsteiger werden sich mangels Verweisen auf weiterführendes Infomaterial (beispielsweise der Beitrag “Reine Formsache” bei Einfach-fuer-Alle.de) zwangsläufig falsch orientieren.

Das Fehlen eines einleitenden Kapitels zur Beschreibung einiger wichtiger Arbeitsgrundlagen, sowie der vollständige Verzicht auf Querverweise führt beispielsweise dazu, dass der Leser die Berechnungsvorschrift einer relativen Schriftgröße als Prozentwert (Zielgröße / Schriftgröße des Elternelements = Eingabewert in Prozent) über 100 Mal in der Marginalspalte wiederfindet, teilweise bis zu drei Mal auf einer Doppelseite. Beim Lesen des Buches stören die endlosen Wiederholungen schnell und es ist schade um den Platz, der für andere Informationen hätte genutzt werden könnten.

Auch einige grobe Fehler finden sich im Buch. So wird auf Seite 358 dem Internet Explorer 6 fälschlicher Weise nachgesagt, das Box-Modell generell fehlerhaft zu interpretieren. Diese Aussage ist schlicht weg falsch. Im Standard Mode interpretiert der IE6 das Box-Modell korrekt. Der Box-Modell-Bug (bekannt vom IE5.x) ist lediglich im Quirks Mode aktiv und sollte damit bei standardkonformen Webseiten und in den Workshops (die alle auf XHTML 1.0 Strict basieren) keine Rolle spielen.

Was uns gefiel

Die ausführliche Beschreibung der einzelnen Kritikpunkte soll nicht den Eindruck erwecken, das Buch sei generell unbrauchbar. Deswegen möchten wir nach all den kritischen Anmerkungen ein Lob für die zahlreichen gelungenen Workshops nicht unterschlagen.

So wird beispielsweise im dritten Workshop die Implementation des Flash Replacements (sIFR) sehr gut nachvollziehbar erklärt. Der Workshop zur Gestaltung von Zitaten unter Einbeziehung einiger typographischer Rafinessen gefällt ebenso wie die drei Tutorials zur Gestaltung von Tabellen mit CSS, wobei der gestalterische Anspruch schrittweise gesteigert wird. In zwei weiteren Workshops zeigt Heiko Stiegert, wie man mit HTML und CSS eine kleine Bildergalerie zaubert. Der zweite Workshop geht noch einen Schritt weiter und bringt JavaScript mit ins Spiel. Beide Workshops dürften auch Einsteigern helfen, bei komplexeren Aufgaben sicher ans Ziel zu kommen. Natürlich geht das JavaScript-Beispiel im Rahmen des Workshops nicht sonderlich in die Tiefe, aber es zeigt das grundlegende Konzept, JavaScript unaufdringlich als Präsentationslayer über HTML und CSS einzubinden.

Einen schönen Abschluss des Buches bilden die fünf Specials, in denen weniger Alltägliches aber nicht weniger interessante Lösungen für die Erstellung einfacher Balkendiagramme, Sitemaps sowie für die Gestaltung der wichtigsten Mikroformate (hCard, hCalendar, hReview) vorgestellt werden.

Fazit

CSS-Design ist ein interessantes Buch mit vielen praktischen Detaillösungen, jedoch für Einsteiger nicht zu empfehlen. An vielen Stellen werden Entscheidungen nicht begründet. Die Workshops suggerieren Best-Practice-Lösungen, wie sie erfahrene Webdesigner verwenden würden. Diesem Anspruch werden sie jedoch häufig nicht gerecht.

Hat man als Leser hingegen schon einige Erfahrungen im Umgang mit CSS gesammelt, bietet das Buch zahlreiche Anregungen für die tägliche Arbeit. Es zeigt, wie Heiko Stiegert sich den verschiedenen Aufgaben nähert und es ist für fast jeden Webdesigner etwas Interessantes, Neues und Nützliches dabei. Vermutlich waren Einsteiger auch während des Schreibens nicht die eigentliche Zielgruppe, denn im Vorwort spricht Heiko Stiegert selbst noch vom Arbeitstitel “CSS-Design. Tutorials für moderne Webseiten”, was dem Inhalt bei weitem näher kommt und viele der angesprochenen Kritikpunkte weniger kritisch erscheinen lassen würde. Grundlegende Fachbegriffe (Inline-/Block-Elemente, Float-Clearing usw.) werden im Buch mehrfach umschrieben, aber nicht klar definiert. In einem Design-Buch müssen keinesfalls die Grundlagen von HTML und CSS erläutert werden, auch wenn es sich an Einsteiger richtet. Aber man sollte die Dinge zumindest beim Namen nennen, sodass der Leser sich in ergänzender Fachliteratur informieren kann. Der weitgehende Verzicht auf externe Quellen wiegt speziell bei der anvisierten Zielgruppe “Einsteiger” schwer.

Zusammenfassend geben wir diesem Buch 3 bis 3,5 von 5 Sternen (wir konnten uns nicht entscheiden). Der Großteil der Kritik bezieht sich dabei auf die verfehlte Zielgruppe, wofür Heiko Stiegert vermutlich am wenigsten kann, wie es der Arbeitstitel im Vorwort vermuten lässt. Der zweite Schwachpunkt betrifft die fehlenden internen und externen Querverweise sowie die z.T. konstruierten Beispiele, die nicht als Best-Practice-Lösungen zu empfehlen sind.

Trotz aller notwendiger Kritik hat der Workshop-Charakter unbestreitbar seinen Reiz und die Umsetzung gefällt, zudem betritt der Verlag mit dem Konzept Neuland. Schon deshalb haben Buch und Autor eine zweite Auflage verdient.

• Gebundene Ausgabe: 458 Seiten
• Verlag: Galileo Press; Auflage: 1 (Juni 2008)
• Aufmachung: Gebunden komplett in Farbe + DVD
• Sprache: Deutsch
• ISBN-10: 3836211556
• ISBN-13: 978-3836211550
• Webseite zum Buch

Über den Autor

Heiko Stiegert arbeitet als Webentwickler und –designer in einer Berliner Agentur und Betreiber des Webstandards Blog.

In der Tat ist es so, dass die überwiegende Mehrzahl der im Netz befindlichen Webseiten ein fixes Layout hat. Die Standardtreue der Browser hat sich in den letzten Jahren jodoch stark verbessert, zusätzlich erleichtern CSS Frameworks wie YAML oder YUI die Erstellung flexibler Layouts. Was bleibt sind die grafischen Zwänge, die in einigen Fällen eine fixe Lösung quasi erzwingen. Im Zuge der Veröffentlichung des Firefox 3 fanden sich jedoch in der weltweiten Blogosphäre vermehrt Stimmen, die mit der großflächigen Verfügbarkeit des “Seitenzooms” (IE7, Firefox 3, Opera 9) gar das generelle Ende der flexiblen Layouts vorhersagten. Als Hauptargument wird angeführ, dass sich fortan jedes fixe Layout über den Seitenzoom skalieren lässt.

Ich habe mir diesbezüglich vor einiger Zeit in meinem Weblog Gedanken gemacht und den Beitrag später in einer überarbeiteten Fassung als Essay veröffentlicht, der dankenswerter Weise bei Dr. Web und im Smashing Magazine veröffentlicht wurde. Der Essay ist daher hier nicht im Volltext verfügbar, die Infobox enthält jedoch die Direktlinks zur deutschen und englischen Fassung.

Der Essay wurde am 12. Juni 2008 bei Dr. Web (Direktlink) und am 26. Juni 2008 in englischer Übersetzung im Smashing Magazine (Direktlink) veröffentlicht.

| View | Upload your own

Die Folien des Vortrages stehen ab sofort bei SlideShare unter Creative Commons Lizenz bereit.

Der Vortrag wurde am 3. Mai 2008 auf dem Leipziger Barcamp 2008 gehalten.

Für kleinerer Webauftritte, z.B. Weblogs, ist das meist ausreichend. Bei größeren Projekten oder der Verwendung von Content-Management-Systemen verliert man jedoch schnell die Übersicht. Für den produktiven Betrieb kann es durchaus sinnvoll sein, Stylesheets gezielt zu optimieren. Die Entwicklerfassung sollte jedoch immer möglichst gut dokumentiert sein.

CSSDOC – Ein Ansatz für einen Standard

Kein gewissenhafter Programmierer lässt seinen Code undokumentiert. Jenseits des CSS-Tellerrandes existieren daher Lösungen wie Javadoc oder Scriptdoc. Beide Standards verwenden spezielle Kommentare, um Programmcode möglichst effektiv zu dokumentieren bzw. sie ermöglichen die automatische Erstellung von Modul-/Programmdokumentationen. CSSDOC wird von Tom Klingenberg, Timo Derstappen und Dirk Jesse entwickelt und ist ein Ansatz, die Vorteile dieser Lösungen auch für die Arbeit mit CSS nutzbar zu machen.

Grundlagen

Ein Kommentar wird in CSSDOC als DocBlock  bezeichnet und folgt einer speziellen Schreibweise. Zu unterscheiden sind dabei DocBlocks für einzelne Abschnitte (section comments) und Dateikommentare (file comments), die den Inhalt einer Datei beschreiben.

Jeder DocBlock wird von der Zeichenkette /** eingeleitet und mit */ beendet. Beide Zeichenketten stehen separat in einer Zeile. Dazwischen befinden sich die eigentlichen Informationen, wodurch das Format für Maschinen lesbar wird.

 /**
  * Ein einfacher DocBlock
  *
  * Gelegentlich ist etwas mehr zu sagen. Dann  koennen sich
  * Kommentare auch schonmal ueber mehrere  Zeilen erstrecken.
  */

Das Salz in der Suppe - Tags

Durch spezielle Tags kann der Informationsgehalt eines DocBlocks entscheidend gesteigert werden. Tags können Strukturinformationen, Autoren- und Copyrightinformationen, Information zur Browserkompatibilität usw. enthalten. Ein Tag beginnt immer mit dem Zeichen ‘@’.  Beispiel 2 enthält einen Abschnittsbeginn (@section)  sowie einen Querverweise (@see).

 /**
  * @section browser reset
  * @see     http://www.yaml.de/documentation/...
  *
  * Reset any browser specific CSS ...
  */

Auch Bugfixes werden durch CSSDOC besser verständlich.

 /**
  * Doubled Float-Margin Bug
  * @see   http://...
  *
  * @bugfix
  * @affected   IE 5.x/Win, IE6
  * @css-for    all browsers
  * @valid      yes
  */

  .float_left { float:left; display: inline }

Die Anzahl der Tags ist relativ hoch, daher erfordert ihre Anwendung zweifellos etwas Übung. Du wirst jedoch mit der Zeit feststellen, dass du dank CSSDOC auch nach längeren Bearbeitungspausen schneller Zugang zu Ihrem eigenen oder auch CSS-Code anderer Entwickler finden wirst.

Der Beitrag wurde am 3. Dezember 2007 erstmals im Rahmen des Beitragsserie “Adventskalender 2007” bei den Webkrauts veröffentlicht (Direktlink).