Der Artikel ist nicht gerade kurz geraten, hat aber gerade deswegen nach all den CSS- und Framework-Diskussionen der letzten Zeit besonders viel Spaß gemacht.

Doch wie einst Saurons “einer Ring” den Verstand von Gollum vergiftete, so hatte auch dieses YAML-Ding scheinbar eine vergleichbare magische Anziehungskraft auf Herrn K. und wenn man ganz leise war, konnte man bereits das Flüstern hören: “Mein Schatzzzzzzzzz ...”. Unaufhaltsam getrieben von einer inneren Stimme begann Herr K. die Urheberrechtsangaben in den YAML-Dateien umzuschreiben. Erst ersetzte er nur den Namen des Autors, später folgte die Projekt-URL – doch die Stimme wollte mehr und flüsterte ihm immer wieder vier Buchstaben zu. Und so ersetzte er auch noch den Schriftzug YAML durch “wxyz” (Anmerkung des Erzählers: Name zufällig entfallen). Und zum ersten Mal nach langer Zeit – so spürte Herr K. – fühlte sich dieses ehemals-YAML-jetzt-WXYZ-Ding gut an. Er hatte etwas Eigenes geschaffen – dachte er.

Doch die Stimme gab keine Ruhe – sie hatte weit Größeres mit ihm vor. Und so begab es sich, dass Herr K. zu digitaler Feder und Tinte griff, um über ein ganz besonderes Template zu bloggen, an welchem er gerade arbeite und welches er bald der Welt präsentieren werde. Ein gar wundersames Ding sei das, welches Einsteigern die Welt der robusten, flexiblen CSS-Layouts näher bringen könne. Doch noch war viel zu tun.

Die kalten, dunklen Winterabende verstrichen – wir schreiben mittlerweile das Jahr 2008 – und es wurde Frühling in Deutschland. Mit den ersten warmen Sonnenstrahlen um den 30. Tag des Monat März fühlte sich Herr K. bereit, der Welt die Früchte seines Schaffens zu präsentieren. Volle drei Monate – so schreibt er stolz in seinem Blog – habe ihn die Entwicklung gekostet, zuzüglich einer einmonatigen Beta-Phase, in welcher Herr K. die sagenhafte Zahl von 138 Bugs aus dem Projekt entfernte und es letztlich zur Reife führte (Anmerkung des Erzählers: Woher diese Bugs gekommen sein mögen, ist leider nicht überliefert). In den frostigen Nächten des Winters 2007 hatte Herr K. seine Copy-Paste-Delete-Technik weiter verfeinert und das Ex-YAML-Ding weiter nach seinen Vorstellungen umgeformt. So sezierte er das Projekt und entfernte jeden noch so kleinen Hinweis auf die ehemals vorhandenen englischsprachigen Kommentare in den diversen CSS-Dateien. Nur deutsche Kommentare durften erhalten bleiben. HTML & CSS-Code, Dateinamen etc. ... blieben hingegen jungfräulich unberührt, um den strahlenden Glanz des Ringes ... ähm des Projektes ... nicht verblassen zu lassen oder aus Unwissenheit gar etwas kaputt zu machen. Mit beispiellosem Heldenmut traf K. dann aber zumindest doch noch eine eigenständige Entscheidung: Er ersetzte die ID-Bezeichnung “col” durch “column” – projektweit versteht sich, denn wahre Helden ziehen sowas durch. Damit war das unschaffbar geglaubte Ziel erreicht. “wxyz” strahlte die selbe technische Brillianz und Reife aus – wie es das YAML-Ding tut – doch in den Augen von Herrn K. ist es seins, sein Eigen, ... sein Schatzzzzzz ... und Erfinder K. fühlte eine zuvor ungekannte Zufriedenheit eines ganz großen Entwicklers.

Und so hatte die innere Stimme auch diesmal leichtes Spiel, als sie ihn dazu überredete, auch den letzten konsequenten Schritt zu gehen. Denn was innen wie YAML aussieht, muss natürlich auch nach außen wie YAML glänzen. Meister K. mag keine Wühltischromantik, er mag Qualität. Und so ist es nur konsequent, dass er das Screenlayout von YAML.de vollständig auf seine Webseite übernimmt, um damit sein “wxyz” Framework in einem würdigen Rahmen präsentieren zu können. Und natürlich übernahm er auch vollständig und wortwörtlich die beiden Lizenzmodelle (Creative Commons und das kommerzielle Lizenzmodell) sowie die zugehörigen Informationstexte von YAML. Einen rebellischen Hauch von Individualität gönnte er sich, indem er in seinem kommerziellen Lizenzmodell auf eine “generelle Lizenz” verzichtete und dafür Preisangabe für eine Projektlizenz auf 25,00 EUR halbierte – vielleicht verkauft es sich ja so besser. Jetzt endlich wurde die Stimme spürbar leiser und nachdem Herr K. auch noch einen Account bei Google Code einrichtete und dort die Veröffentlichung des Framework-Code unter der GPL-Lizenz ankündigt hatte, verstummte die Stimme endgültig. Die große Tat war vollbracht.

Noch heute erzählen die Leute in Kleve beim Abendessen von den unglaublichen Heldentaten des Herrn K. Und wenn er nicht gestorben ist, lebt er noch immer als glücklicher und zufriedener Framework-Entwickler in dem kleinen Örtchen nahe der deutsch/holländischen Grenze.

Kommentar des Erzählers

Märchen sind etwas Wunderbares und mit Sicherheit werde ich meinem 9 Monate alten Töchterchen auch bald die ersten Gute-Nacht-Geschichte vorlesen. Doch diese Geschichte wird nicht dabei sein, denn wir leben nicht im Glücksbärchiland und am Happy-End melde ich berechtigte Zweifel an. Als ich vor knapp vier Wochen durch eine Email erstmals auf die Webseite von Herrn K. und seine Aktivitäten aufmerksam wurde, blieb mir minutenlang der Mund offen stehen. Dass jemand hier in Deutschland eine derartige Dreistigkeit an den Tag legen würde, konnte ich mir bis zu diesem Zeitpunkt nicht vorstellen. Da klaut jemand meine Arbeit, schreibt seinen Namen drüber, feiert sich als grandioser Entwicker und sinniert in seinem Blog über mögliche Verbesserungen in zukünftigen Versionen. Und als wäre das noch nicht genug, übernimmt er sogar 1:1 meine Lizenzmodelle und bietet meine Arbeit unter seinem Namen interessierten Nutzern zum halben Preis zum Kauf an.

Mehrfach habe ich versucht, mit Herrn K. persönlich in Kontakt zu treten. Mehr als eine automatische Bandansage des Anrufbeantworters habe ich jedoch nie zu hören bekommen. Am vergangenen Wochenende ist dann ein anwaltliches Schreiben bei Herrn K. eingegangen, welches Herrn K. sanft mit der realen Welt konfrontierte und ihn mittlerweile dazu bewogen hat, das Projekt – wie er es formuliert – “auf vorerst unbestimmte Zeit vollständig” einzustellen. Für die wünschenswerte Selbsterkenntnis, dass er, Herr K, eben nicht der Framework-Entwickler ist, hat es indes offenbar nicht gereicht. Denn Herr K. spricht in seinem Blog weiter davon, dass die aktuelle und zukünftige Versionen von ihm “nicht weiter entwickel und betreubar” [Rechtschreibfehler im Originalzustand belassen] seien. Kein Wort über den offensichtlich aufgeflogenen Projektklau oder gar ein Einsehen. Und so schafft es Herr K. auch nach langer und intensiver Beschäftigung mit YAML nicht, in dem eingeforderten Link auf das YAML-Framework meinen Namen korrekt zu schreiben. Vermutlich war der aber in seinem Projekt auch nicht mehr auffindbar, denn Löschen und Ersetzen von Texten kann Herr K. perfekt. Nur mit dem Merken, das muss noch besser werden.

Da ich weder ein gesteigertes Interesse verspüre, Herrn K. mehr öffentliche Aufmerksamkeit als zwingend nötig zukommen zu lassen, noch dass ich meinen Lesern die katastrophale Rechtschreibung auf den Seiten des Herrn K. zumuten möchte, verzichte ich hier auf jegliche Verlinkung und bitte die geneigte Leserschaft, dies auch in eventuellen Kommentaren hier im Blog zu respektieren.

Dass die Zeit wie im Fluge verging, war dabei maßgeblich Nils zu verdanken. Denn David ist kein YAML-Anwender und so hätte ich nur aus meiner Sicht als Entwickler über das Framework erzählen können. Nils hingegen ist seit vielen Jahren selbstständiger Webentwickler und arbeitet tagtäglich mit YAML. Er hat seine eigenen Erfahrungen mit dem CSS-Framework gemacht und bringt als erfahrener Anwender eine Sicht der Dinge in Spiel, die ich nicht bieten kann. Und achtet mal drauf, wie leidenschaftlich er beim Thema IE6 wird.

Zum Glück hatten wir die Sendung thematisch gut vorbereitet, sonst wären wir wahrscheinlich bei einigen Themen noch viel länger hängen geblieben. Und trotz der Vorbereitung sind natürlich auch Dinge auf der Strecke geblieben, die man im Nachhinein noch hätte ansprechen wollen aber das Thema ist einfach unendlich. Daher freue ich mich auch einfach über die gelungene Sendung, die wir am letzten Mittwoch nach kleinen Startschwierigkeiten annähernd reibungslos über Skype aufgenommen haben. Und ganz besonders danken möchte ich auch nochmals allen Kommentatoren und Forenusern, die uns ihre Fragen zur Beantwortung in die Sendung mitgegeben haben. Ich hoffe, wir konnten alles zufriedenstellend beantworten.

Nachtrag: Hinweis an mich. Unbedingt Headset besorgen, damit Stimme nicht mehr so verrauscht ist.

Fast eineinhalb Jahre sind seit dem ersten Public Draft vergangen, in der wir zahlreiche Erfahrungen sammeln und einiges positives Feedback ernten konnten. Bereits seit YAML 3.0 (Juli 2007) kommt das CSSDOC Regelwerk in meinem CSS-Framework zum Einsatz und hat bestens bewehrt.

Die klare und verständliche “Sprache” der Tags erleichtert professionellen Anwendern wie auch Einsteigern den Umgang mit dem Framework. Umso mehr lag es uns allen am Herzen, die vor langer Zeit begonnenen Arbeiten an der Spezifikation weiterzuführen und das Regelwerk zu vervollständigen. Am letzten Wochenende war dieses Ziel mit dem Einflegen der letzten Korrekturen erreicht und den aktuellen Stand in Form eines zweiten öffentlichen Drafts veröffentlicht.

Das Dokument steht als PDF-Datei zum Download bereit und wir bitten jeden CSSDOC-Interessierten ausdrücklich um Feedback über die öffentliche CSSDOC-Mailingliste.

Nachtrag: Dass das Projekt mittlerweile einiges an Ansehen für sich verbuchen kann, äußert sich auch darin, dass beispielsweise die offizielle Drupal-Dokumentation das Regelwerk im Rahmen des Drupal Coding Standard zur Kommentierung von Cascading Stylesheets empfielt.

Und hast Du nicht gesehen, schon überschlägt man sich hier, da und dort mit Artikeln, die vom Beginn einer neuen Webdesign-Ära sprechen, in der die ach so komplizierten Layoutkrücken, welche noch auf Floats oder absoluter Positionierung basieren, nur noch ein Schattendasein fristen werden.

Licht und Schatten

Rein gefühlsmäßig entspringt der Hype maßgeblich der Tatsache, dass es mit CSS-Tabellen endlich relativ problemlos möglich sein sollte, CSS Layouts mit gleichlangen Spalten zu erzeugen. Vor zwei, drei Jahren - wo es fast ausschließlich einfache CSS-Spaltenlayouts gab, fand ich diese Idee auch toll. Doch seither hat sich im Webdesign doch einiges getan. Alle Welt baut Grids, Techniken für gleichlange Spalten gibt es zu Hauf, sowohl als Fake-Lösungen (faux columns) als auch ganz real per CSS (siehe hier und da). Sicher, sie haben ihre Nachteile — aber im Grunde erfüllen sie ihren Zweck, wenn man die Funktionalität benötigt. CSS-Tabellen können hier Webdesignern in Zukunft das Leben wirklich noch etwas einfacher machen, den Status eines Erlösers bekommen sie deswegen jedoch sicher nicht. Denn das Gute an all den bisher verwendeten Workarounds ist, dass sie weitestgehend auch mit älteren Browsergenerationen funktionieren. Bei CSS-Tabellen sieht das anders aus. Zwar hinkt auch hier in erster Linie der Internet Explorer hinterher, jedoch sind auch Firefox, Safari & Opera bis heute nicht 100%-ig einer Meinung, was die Detail der Darstellung eines Containers mit der Eigenschaft display:table betrifft.

Ein weiterer, schwerwiegender Nachteil ist, dass es bei Tabellen (und ebenso bei CSS-Tabellen) keine Möglichkeit gibt, die Reihenfolge in der Spalten in der Bildschirmausgabe per CSS zu beeinflussen. Die Codereihenfolge wird streng und unverändert in die Präsentation übernommen. Bei Tabellendaten ist das auch nicht notwendig, bei der Layoutgestaltung führt es jedoch zu massiven Einschränkungen gegenüber den aktuellen Float-Lösungen. Dabei will ich garnicht von den SEO-Fanatikern sprechen, sondern vielmehr den Blick auf Screenreader und Textbrowser lenken. Mit CSS-Tabellen verlieren wir die Möglichkeit, die einzelnen Layoutelemente im Code und in der Präsentation unabhängig zu platzieren. Ich halte diesen Punkt für weitaus wichtiger als die native Unterstützung gleichlanger Spalten, weshalb für mich Floats weiterhin das Maß der Dinge bleiben.

Und nicht zuletzt sind da die beiden Veteranen, Internet Explorer 6 & 7, die vermutlich auch in den nächsten Jahren noch maßgebliche Marktanteile verbuchen werden. Wie bringt man diesen Browsergeneration die CSS-Tabellen nahe? Da fangen wir dann also doch wieder an zu basteln und zu hacken. Denn um auch Nutzer dieser Browser wenigstens in den Genuss der Mehrspaltigkeit kommen zu lassen, müssten die Tabellenspalten speziell für die alten IE’s wieder in floatende Container zurückverwandelt werden.

Gefühlte 5 Jahre zu spät

Ich mag mich natürlich irren, aber ich denke, CSS-Tabellen kommen einfach zu spät. Die Technik hat unbestritten ihren Reiz, doch ist es nunmal so, dass CSS2 schon ein paar Jahre existiert und die Welt während dieser Zeit nicht regungslos auf die Ankunft der CSS-Tabellen gewartet hat. Es gibt eine Vielzahl ausgereifter Layouttechniken, die sich relativ problemlos selbst im veralteten IE5.x fehlerfrei anwenden lassen. Und genau da können CSS-Tabellen nicht punkten, denn nur die kommende IE-Generation wird damit umgehen können.

CSS-Tabellen werden ihren Platz im Webdesign-Alltag finden, da bin ich mir sicher. In einfachen Grid-Frameworks wie 960.gs könnten sie die bisher verwendeten Floats durchaus ablösen. Bei Verwendung dieses Frameworks stimmen Code- und Präsentationsreihenfolge auch jetzt schon zwingend überein, weshalb in diesem Fall technischen Einschränkungen der CSS-Tabellen nicht spürbar werden, die gleichhohen Spalten aber sogar einen echten Mehrwert bieten. Schon bei Blueprint CSS sieht es u.U. anders aus, denn Blueprint stellt Klassen zum Verschieben von Elementen innerhalb des Grids zur Verfügung (mittels positiver/negativer Margins), was in Verbindung mit Floats wunderbar funktioniert, mit CSS-Tabellen aber vermutlich schwierig werden würde.

Eine Revolution oder auch einen signifikanten Entwicklungsschub in Sachen CSS-Layouts sind CSS-Tabellen in meinen Augen daher nicht. Sie bringen zu große Probleme mit (Spaltenreihenfolge in Code und Präsentation), die mit den herkömmlichen Bordmitteln (Floats) seit Jahren getrost als gelöst bezeichnet werden dürfen, zudem ist die Browserunterstützung nur in der aktuellsten Generation gewährleistet. Sie sind aber eine willkommene Alternative in dem einen oder anderen konkreten Anwendungsfall.

Für den Firefox gibt es den Netzwerk-Reiter in der Firebug-Extension (v1.2.1), welche eben diese Auskünfte liefert. In einem Balkendiagramm werden vertikal die einzelnen Objekte entsprechend der Reihenfolge ihrer Anforderung beim Server aufgelistet, horizontal verläuft die Zeitachse, welche Aufschluss über den Start des Requests und die Zeit bis zum erfolgreichen Abschluss des Ladevorgangs gibt. Nach dem erfolgreichen Seitenaufruf lassen sich für jedes geladene Element Detailinformationen ausgeben, wie etwa den Cache-Status des Objektes, Lebensdauer im Cache ect. abrufen. Kleiner Nachteil: Firebug stellt den Zeitraum zwischen der Serveranfrage und dem erfolgreichen Abschluss des Ladevorgangs undifferenziert dar und gibt keine Auskunft über Latenzzeiten und effektive Ladezeiten.

Für den Safari 3.x übernimmt die Netzwerk-Timeline des Web Inspectors (dem im Safari eingebauten Developer-Tool) diese Aufgabe und unterscheidet farblich zwischen Stylesheets, Grafiken und JavaScript-Dateien. Die Anzeige differenziert aktuell jedoch auch noch nicht zwischen Warte- und effektiven Ladezeiten (Die akutellen Nighty-Builds der Webkit-Engine sind wohl hier schon besser). Wie auch beim Firefox bringt ein Klick auf das jeweilige Objekt weitere Detailinformationen hervor.

CSSTidy steht aktuell in der Version 1.3 als PHP-Script und als Kommandozeilenversion für Windows zur Verfügung. Die einfache und übersichtliche Benutzeroberfläche erlaubt im Textfeld auf der linken Seite die Übergabe der CSS-Daten per copy/paste oder alternativ den Import von CSS-Dateien über eine URL.

Auf der rechten Seite finden sich einige Optionen, um die Arbeitsweise des Tools zu beeinflussen. Leider führen die standardmäßigen Voreinstellungen schnell zu unbrauchbarem CSS.

Squeeze me ...

Komprimierung (Code Layout) Über diese Auswahlbox wird der Umgang mit Leerzeichen, Tabulatoren und Zeilenumbrüchen bestimmt. Die Einstellungen haben daher vorrangig Einfluss auf die Les- und Wartbarkeit des optimierten Codes. In der Einstellung “Standard” bleiben Zeilenumbrüche weitgehend erhalten, unnötige Leerzeilen werden hingegen bereits entfernt, genauso wie Einrückungen am Zeilenanfang. Auf Stufe “Hoch” werden sämtliche Selektoren zeilenweise notiert, ihre Eigenschaften folgen innerhalb der Zeile. Ich empfehle diese Einstellung als guten Kompromiss, denn das CSS ist noch lesbar (wenn auch nicht mehr übersichtlich) und erlaubt eine schnelle Fehlerkontrolle. In der höchsten Stufe werden auch die letzten Zeilenümbrüche entfernt und somit der gesamte Inhalt wie an einer Perlenschnur aufgefädelt. Die Lesbarkeit ist hier stark eingeschränkt, dem CSS-Parser des Browsers ist das jedoch egal - es entstehen minimale Dateigrößen.

Etwas mißverständlich ist die letzte Option “Benutzerdefiniert (unten eingeben)”. Damit ist NICHT gemeint, dass die darunter befindlichen Optionen bei den vier oberen Einstellungen keine Bedeutung hätten. Oftmals werden die Komprimierungseinstellungen irrtümlich mit den weiter unten festzulegenden Optimierungseinstellungen gleichgesetzt - CSS-Probleme sind dann vorprogrammiert. Hierbei geht es wirklich nur um das Code-Layout, für welches eine benutzerdefinierte Vorlage verwendet werden kann. 

CSS-Optimierungen, Teil 1

Der oberste Optionsschalter ist auch gleich der wichtigste, denn hier passieren die meisten Fehler. Zu dieser Checkbox gehören nämlich auch die vier nachfolgenden Optionen, die meist mehr Chaos im Code anrichten als Nutzen bringen.

Selektoren sortieren Diese Option sollte man tunlichst ausgeschaltet lassen, denn die Selektoren werden strikt alphabetisch aufsteigend sortiert, was die CSS-Kaskade innerhalb des Stylesheets gehörig durcheinander würfeln kann. Zudem gewinnt man durch Umsortieren kein einziges Byte - daher Finger weg.

Eigenschaften sortieren Das alphabetische Sortieren der Eigenschaften innerhalb eines Selektors ist ebenfalls in erster Linie eine Geschmacksfrage. Knifflig wird es erst, wenn Sie in ihren Stylesheets mit Parser-Hacks für den Internet Explorer arbeiten (z.B. Tantek-Hack), deren Funktion von der richtigen Abfolge der Eigenschaften anhängt sind. Da auch hier kein echtes Einsparpotential in Bezug auf die Dateigröße besteht - lieber ausgeschaltet lassen.

Selektoren umgruppieren Jetzt wirds richtig heftig. Per Default steht diese Option auf “Selektoren mit gleichen Eigenschaften zusammenfassen”. Dummerweise überließt man diesen viel zu langen Text in der schmalen Box zu leicht und wundert sich im Anschluss stundenlang über offenbar fehlerhaftes CSS. Denn auch diese Option sortiert Selektoren innerhalb der Datei um und greift somit willkürlich in die Kaskade ein. Daher: Unbedingt umstellen auf “Nichts ändern”.

Shorthands optimieren Das ist in meinen Augen die sinnvolle Option, denn damit werden CSS-Eigenschaften - wo möglich - in die Kurzschreibweise (shorthand) überführt. Allerdings empfehle ich hier - es bei der in diesem Fall sinnvoll gewählte Voreinstellung “Sichere Optimierungen” zu belassen. 

CSS-Optimierungen, Teil 2

Farben komprimieren Dieser Schalter ist standardmäßig aktiviert und kann es im Regelfall auch bleiben. Hierbei geht es um die Optimierung von Stringlängen. Farbcodes in hexadezimaler Schreibweise (#ff0000) oder RGB-Codes (rgb(255,0,0)) werden ggf. gegen Kurzbezeichnungen (red) ausgetauscht, um das eine oder andere Byte zu sparen.

Font-weight komprimieren Auch hier versucht CSS-Tidy kürzere Strings in den Code einzufügen. So wird der 4-Byte lange String bold gegen den 3-Byte langen Ersatzstring 700 ausgetauscht. Auch diese Optimierung ist in der Regel harmlos, da so ziemlich alle aktuell am Markt befindlichen Browser mit beiden Werten klarkommen.

Selektoren in Kleinbuchstaben Wieder eine Option, die mir Vorsicht zu genießen ist. Sie ist zum Glück standardmäßig deaktiviert. HTML-Klassen und ID’s sind zum Teil case-sensitive (Wussten Sie das schon?), weshalb die Änderung der Schreibweise dazu führen kann, dass dessen Eigenschaften nicht mehr berücksichtigt werden. Ich werde hier jetzt jedoch nicht in die Abgründe der Standards abtauchen. Wer mehr darüber wissen will, hier gibts mehr zum Thema. Ende vom Lied: Finger weg - Checkbox deaktiviert lassen.

Groß-/Kleinschreibung für Eigenschaften Diese Option ist harmlos und dient der Lesbarkeit, indem es die Schreibweise der CSS-Eigenschaften vereinheitlicht. Auf Datei- und Verzeichnisnamen (die durchaus case-sensitiv sein können) wird dabei Rücksicht genommen. Daher gibts hier keine Bedenken.

Unnötige Backslashes entfernen Diese Option ist per Default aktiviert, doch leider auch hier - Vorsicht! Nicht alles, was unnötig zu sein scheint, ist es auch - Stichwort IE-Parserbugs. Backslashes lassen sich ganz hervorragend dazu nutzen, IE5.x und IE6 auseinander zu halten, bzw. gezielt anzusprechen, wobei dabei nicht zwingend invalides CSS entsteht. Daher ist auch ein Validitätscheck eines unbekannten Stylesheets kein Garant dafür, dass keine auf Backslashes aufbauenden Parser-Hacks für den IE im Stylesheet enthalten sind. Wenn Sie sich also unsicher sind - unbedingt ausschalten.

Letztes ; entfernen Und mal wieder eine nützliche Option, vor allem bei größeren Stylesheets. Jeder einzelne Selektor liefert ein Byte Optimierungspotential. Das summiert sich zum Teil ganz ordentlich.

Ungültige Eigenschaften entfernen Für die meisten Anwender ist das eine weitgehend sinnlose Option. Ausnahme: Validitäts-Fetischisten. Der CSS-Standard ist so angelegt, dass Browser unbekannte Eigenschaften und Selektoren einfach ignorieren. Es gibt also keinen Grund, solche Dinge bei der Optimierung aus dem Stylesheet zu werfen. Lediglich einige CSS-Validatoren kreiden sowas u.U. als Warnung an, was ich aber ebenfalls für unsinnig halte.

Zusammenfassung

Wie die Erläuterungen zu den einzelnen Optionen bereits deutlich machen, sind viele Schalter mit Vorsicht zu geniessen. Das Schrumpfpotential bei der Dateigröße von CSS-Dateien rührt in erster Linie aus dem Entfernen von Kommentaren, Einrückungen und Zeilenumbrüchen her. Wenn Sie sich über den Inhalt einer CSS-Datei nicht im Klaren ist, sollte man es dabei auch belassen. Die zusätzlich von CSSTidy angebotenen Optimierungen sind vielfach nicht ohne Weiteres zu empfehlen und führen schnell zu Komplikationen. Vor allem vor der Umsortierung von Selektoren sollte man einen großen Bogen machen.

Beachtet man die oben genannten Hinweise, so ist CSSTidy eine sehr wertvolle Hilfe bei der Performance-Optimierung. Die Ausgabe erfolgt entweder in Dateiform oder als ASCII-Text unterhalb der Konfiguration. Arbeitet man in der Entwicklungsphase des Projektes mit mehreren, ggf. sogar verschachtelten Stylesheets, so empfielt es sich für den Produktivbetrieb, Stylesheets weitgehend zusammenzufassen, um HTTP-Requests und damit indirekt Wartezeiten beim Aufruf der Webseite zu reduzieren.

Weiterhin habe ich auch eine jQuery-Session geplant, in welcher live ein kleines Plugin entstehen wird. Wer von Euch Lesern sich also ebenfalls am WE auf dem Barcamp herumtreibt und Fragen hat, sprecht mich an. Ich freu mich drauf.

Unter den Layout-Frameworks gehört YAML damit zu den Urgesteinen und ist dennoch kein bisschen angestaubt. Verständlicherweise sind die Update-Zyklen mittlerweile etwas größer als noch 2006, doch das liegt im Reifegrad des Frameworks begründet, der nur noch wenige Eingriffe und vor allem eine behutsame und bedachte Weiterentwicklung erfordert. In diesem Zusammenhang fand ich es spannend, Jens Grochtdreis Worte aus seinem damaligen Release-Beitrag in seinem Blog noch einmal zu zitieren:

Dirk erklärt interessant und ausführlich sein Layout, das man auch kompakt herunterladen kann. Sein Layout ist interessant aufgebaut und geht sowohl mit fixen Spaltenbreiten als auch mit flexiblen Spaltenbreiten um. Es bietet sowohl Header als auch Footer, die man auch ausschalten kann. Die Flexibilität seines Layouts ist Programm,  denn Dirk wollte sich eine Basis für künftige Projekte schaffen.

Floats sind interessant und obwohl sie viele Fussangeln aufweisen, layoute ich derzeit nie anders.

Schon in der ersten Version stand der Grundsatz der größtmöglichen Flexibilität – und damit meine ich die Gestaltungsfreiheit bei der Positionierung von Elementen und der Verwendung und Kombination beliebiger Maßeinheiten – an erster Stelle. An der technischen Umsetzung dieser Idee hat sich im Verlauf der 3 Jahre nichts Wesentliches verändert. Die Idee eines grobusten und wiederverwendbaren Layoutkonzepts war damals jedoch weitgehend neu und hat mir einige Diskussionen beschert. Und das macht mich rückblickend schon ein wenig stolz, denn Layout-Frameworks waren 2005 noch weitgehend Neuland. Auch ich musste erst einmal lernen, wie man das Layoutkonzept und das "TOP-DOWN" Prinzip in der Dokumentation verständlich erklärt.

Heute sieht die Welt etwas anders aus. Layout-Frameworks sind in aller Munde und die Verwendung des Begriffs steigt nahezu inflationär. Die pure Anzahl und die unterschiedlichen Konzepte verdeutlichen einerseits das allgemeine Interesse an universellen Lösungen. Auf der anderen Seite gehen Nutzeransprüche und die Qualität der Umsetzung der Frameworks zum Teil noch sehr weit auseinander. Auch die Diskussionen um den Nutzen für private Bastler und professionelle Entwickler reisst nicht ab. Leider plätschert diese Diskussion – und das ist meine persönliche Meinung – bei vielen geschätzten, professionellen Webdesignern und Bloggerkollegen zu sehr an der Oberfläche. Allzu oft werden Projekte mit unterschiedlichsten Ansätzen und Entwicklungsständen über einen Kamm geschert. Beim diesjährigen Webkongress in Erlangen habe ich deshalb in meinem Vortrag die Flut der Layout-Frameworks etwas tiefgründiger beleuchtet und die zwei grundlegenden Ansätze Grid-Frameworks und CSS-Frameworks anhand der unterschiedlichen Konzepte, Ziele, sowie Vor- und Nachteile umrissen.

Und was kommt jetzt?

Die Entwickung bleibt nicht stehen, weder in der Browserwelt, noch bei YAML. Aktuell arbeite ich an der Version 3.1, die einige spannende Neuerungen und Verbesserungen mitbringen wird. Intern wird es einige kleinere Änderungen geben, wodurch sich neue Gestaltungsmöglichkeiten mit YAML ergeben. Weiterhin werden einige neue Features in Form von Add-ons in das Download-Paket integriert werden, sodass hier in Zukunft sinnvolle Bausteine für die tägliche Entwicklungsarbeit mitgeliefert werden können. Ich werde dabei auhc darauf achten, das Projekt nicht unnötig zu überfrachten - der Auswahlprozess ist noch im Gange. In jedem Fall wird die Zahl der Anwendungsbeispiele weiter steigen.

Auch beim YAML Builder stehen die Räder nicht still. Das ehemals kleine Online-Tool hat sich in der Version 1.0 zu einer recht stattlichen JavaScript-Applikation entwickelt. Im letzten halben Jahr habe ich viel Feedback eingesammelt und meine eigenen Vorstellungen und Ideen für die weitere Entwicklung geordnet. Was sich nun so langsam als Featureliste für die nächste Generation des Builders verdichtet, verspricht sehr spannend zu werden. Mehr gibts auch hier momentan noch nicht an Details, denn ich habe mit der Programmiererei erst vor wenigen Wochen begonnen.