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.

Ich habe mir die Experten-Workshops gegönnt, welche über den Tag verteilt vier 90-minütige Sessions bereit hielten. Den Start machte Dirk Ginader mit einem sehr guten und mit vielen Details gespickten Vortrag zu Accessible JavaScript. Im Anschluss lieferten Martin Kliehm und Marco Zehe eine beeindruckende Session zu WAI-ARIA (Accessible Rich Internet Applications), die wirklich Lust auf mehr macht. Martin stellte den Entwicklungsstand von ARIA vor, anschließend führte Marco Zehe (Marco ist blind) verschiedene Beispiele live vor. Neben dem Vortragsteil und der Erfahrung, wie schnell Marco mit dem Screenreader arbeitet, blieb auch hier die Zeit für zahlreiche Fragen, Antworten und kleine Diskussionen.

In den Nachmittag startete Tiffany Wyatt mit einer praxisorientierten Session zur Erstellung von barrierefreien PDF-Dokumenten. Zum dritten Mal an diesem Tage empfand ich die 90 Minuten als extrem lehrreich und in diesem Workshop auch erschreckend, wie stiefmütterlich dieses Thema aktuell durch Software wie Acrobat, InDesign oder die zahlreichen Office-Suites unterstützt wird. Man merkt an allen Ecken und Kanten, dass PDF seinen Ursprung im Print hat und die Barrierefreiheit bisher lediglich ein Aufsatz ist, dessen Einbindung in den normalen Workflow noch in den Kinderschuhen steckt.

Zum Abschluss der Veranstaltung lud Ansgar Hein in seiner Session zur Diskussion der aktuellen und zukünftigen Herausforderungen auf dem Gebiet der Barrierefreiheit (Stichworte: Interaktion, Ajax, CMS-Backends usw.). Die Einsteiger-Workshops waren im Übrigen nach Auskunft anderer Teilnehmer nicht weniger hochkarätig, jedoch kann ich leider nicht direkt davon berichten. Pünktlich um 17:00 waren die Workshops beendet und ich konnte noch 2 volle Stunden des gemütlichen Get-Together bei leckerem Essen, einem Bierchen und Gesprächen genießen, ehe mich leider kurz vor 19:30 ein Taxi wieder zum Flieger nach Dresden brachte. Glücklich, müde und hochzufrieden war ich Punkt 22:00 Uhr wieder zuhause.

An dieser Stelle nochmals ein herzliches Dankeschön und Lob an Jörg Morsbach und Ansgar Hein von anatom5 für die Einladung und das überaus gelungene Symposium.

Also habe ich mir vorhin meine aktuelle Liebingsentwicklungsumgebung Aptana Studio gegriffen und mich etwas näher mit den so genannten Snippets beschäftigt. Vom Prinzip her sind das kleine Textbausteine, die über einfache Textvariablen vor dem Einfügen vom Nutzer angepasst werden können. Für etwas mehr Komfort bei der Arbeit mit CSSDoc genau der richtige Ansatz. Also habe ich schnell ein paar Snippets für die wichtigsten Anwendungsfälle erstellt und in einem kleinen Projekt zusammengefasst:

• file comments
• section comments (2 Ebenen)
• bugfix-/workaround-comments
• single line comments

Das sollten aus meiner Erfahrung die am häufigsten benötigten Textbausteine sein und damit die Arbeit mit CSSDoc etwas leichter von der Hand gehen. Dann mal schnell an die Einbindung in Aptana ...

Einbindung in Aptana

Die Einbindung der CSSDoc Snippets ist schnell erledigt. Im ersten Schritt muss das Projekt (Download am Ende des Beitrags) importiert werden. Hierfür bietet sich die Import-Funktion im File-Menü an. Im folgenden Dialog wählt man General -> Existing Projects into Workspace, um das heruntergeladene Projekt vollständig in den eigenen Workspace zu übernehmen.

Im zweiten Dialog des Imports geben Sie das Root-Verzeichnis des zu importierenden Projekts an, anschließend kann man ein oder mehrere Projekte (Verzeichnisse) importieren. Es empfielt es sich, den Haken für “copy projects into workspace” zu setzen, um die Dateien wirklich an Ort und Stelle zu haben. Ist das Projekt in den Workspace eingespielt, sollte es im Projekt-Reiter stehen und geöffnet sein (siehe rechte Box auf dem folgenden Screenshot).

Und das war’s auch schon. Ab sofort sollte im Reiter Snippets ein neuer Listenpunkt CSSDoc Snippets verfügbar sein. Achten Sie darauf, dass das Projekt immer geöffnet ist. Sobald Sie das Projekt schließen, werden die darin enhaltenen Snippets deaktiviert.

Anwendung

Sind die CSSDoc Snippets installiert, ist die Anwendung letztlich ein Kinderspiel. Öffnen Sie eine vorhandene oder neue CSS-Datei (ich hab für das Beispiel eine neue CSS-Datei erstellt) und klicken Sie mit einem Doppelklick auf z.B. das Snippet @file comment.

Daraufhin öffnet Aptana ein kleines Dialogfenster, in welchem Sie einen Titeltext vergeben können, Angaben zu Autor und Version, sowie Angaben zum Copyright einfügen können. Nicht benötigte Angaben lassen Sie einfach aus und löschen die entsprechende leere Zeile nachträglich aus dem eingefügten Textblock (Fallunterscheidungen lassen sich in die Abfragen leider nicht einbauen).

Sind alle Felder ausgefüllt, reicht ein Kick auf “Ok” und ... Voila! ... ein vollständig ausgefüllter section comment steht im Dokument. Beim @file comment Snippet habe ich mir erlaubt, zusätzlich zwei Platzhalter (Revision und Date) für die Arbeit mit Subversion zu ergänzen.

Auf die gleiche Art und Weise können section comments oder auch Kommentare für Bugfixes oder Workarounds erzeugen, in der Form wie ich sie in den Stylesheets (speziell: core/iehacks.css) des YAML Frameworks verwende. Zumindest mir erleichert das die Dokumentation von Bugfixes sehr.

Das einzige kleine Problem, welches ich bisher noch nicht lösen konnte, das erste Leerzeichen in der ersten Zeile des DocBlocks unterschlägt Aptana offenbar, weshalb in dieser Zeile die Einrückung nicht ganz sauber ist. Aber ich glaube, damit kann ich momentan ganz gut leben. Wer weiß, wie man dieses Problem beheben kann, gebe mir bitte ein Zeichen.

Anpassungen und Feedback

Snippets sind in Aptana sehr einfach zu realisieren. Innerhalb des “CSSDoc Snippets” Projekts liegen die einzelnen Snippets im Ordner snippets. Aptana sucht in allen offenen Projekten nach Ordnern mit exakt diesem Namen und sortiert darin befindliche Snippets selbsständig in die Liste der verfügbaren Codebausteine ein. Änderungen in den Dateien werden sofort übernommen. Die Syntax ist verhältnismäßig einfach, die Hilfefunktion von Aptana gibt ebenfalls Auskunft über Aufbau und Funktionsweise.

Die Codeschnipsel sind nichts besonderes, weswegen ich Sie gern zum Download zur Verfügung stelle und auch unter keine spezielle Lizenz stelle. Wenn Sie dem einen oder anderen helfen, mit CSSDoc zu arbeiten, dann ist mir das Lohn und Freude genug. Dennoch würde ich mich in diesem Fall natürlich über Feedback (Hinweise zu Fehlern, Verbesserungsvorschläge usw.) freuen.

Tja, das war’s auch schon als kleine Spielerei zum Samstag Nachmittag.

Nachtrag: Es hat nur ein paar Stunden gedauert, dann hatte Eric Eggert das Thema in seinem Blog ebenfalls aufgegriffen und ein ähnliches Paket für Textmate auf dem Mac geschnürt. Von hier aus ein großes Dankeschön für die Unterstützung.

Download

cssdoc_snippets_v0.1.zip (3 kB)

Chrome soll er heissen und gleich für heute, den 2. September verspricht Google eine erste öffentlich zugängliche Testversion für Windows-Systeme. Wir dürfen also gespannt sein, sobald es Neuigkeiten gibt, werde ich diesen Beitrag updaten.

Wer sich vorab schon etwas über die Intentionen, die zu diesem Schritt führten, schlau machen will, für den haben die Entwickler ein recht umfangreiches Comic aufgelegt. Natürlich im typischen blaß-blauen Ton.

Auch der Spiegel widmet sich bereits heute morgen dem Thema mit einem längeren Beitrag (waren die etwa schneller als Heise?). Es ist nicht unbedingt so, dass die Welt zwingend eine Alternative zu Firefox, Safari, Opera & Co. benötigt. Was man von Chrome zu halten hat, wird sich in den nächsten Wochen zeigen. Ich für meinen Teil hoffe auf frische Ideen und ein frisches Konzept für die Neuentwicklung.

Update: Der Browser steht mittlerweile in einer Betaversion für Windows XP und Vista zum Download zur Verfügung. Dank der Webkit-Engine ist die Rendering-Qualität exzellent, die JavaScript Engine erscheint nach einem kurzen Test relativ schnell zu sein und Dank der Übernahme des Firefox-Nutzerprofils kann man sofort mit den eigenen Bookmarks mit dem Surfen starten. Es sind erst 10 Minuten aber Chrome fühlt sich unter Vista nach dem ersten Eindruck recht knuffig und schnell an. Wir werden sehen, ob das Gefühl anhält ...