Stylesheets dokumentieren mit CSSDOC Technikwürze 97

Herzlich willkommen zu Technikbitze siebenundneunzig. Heute geht es um CSS Doc, nicht um den Arzt. Mit mir dabei in der Sendung, sind Dirk Jesse.

Hallo.

Und der Tom Klingberg.

Hallo.

So, die Hörer kennen den Dirk schon aus einigen vergangenen Sendungen. Neu mit dabei zum ersten Mal ist heute der Tom. Stell dich doch mal vor.

Ja, mein Name ist Tom. Ich komme aus Mainz und ich mache seit einigen Jahren unter anderem auch mit, Webdesign und auch Stylesheets rum und CSS rum und möchte heute ein bisschen was zum CSS Doc erzählen.

Genau, CSS Doc ist ja von euch beiden, aber ihr seid nicht ganz alleine, ne?

Mh, wir haben noch einen Mitstreiter, das ist der Timo. Der stammt aus Köln.

Dann Dirk, erklär uns doch mal, was CSS Doc jetzt ist.

Ja. CSS Doc ist, sagen wir so ein Stil, eine gute Schreibweise sozusagen, wie, Stylesheets vernünftig kommentiert werden, sodass sie nicht nur für die eigene Arbeit, nach ein paar Monaten wiederverwendbar sind und man dann noch weiß, was man da getan hat, sondern dass sie, bevorzugt auch für andere oder für Dritte lesbar werden, inklusive für Maschinen, sodass man also sich auch die Arbeit in der Entwicklungsumgebung entsprechend etwas erleichtern kann.

Also bisher hatten wir ja einiges abverlangt von den HTML-Machern und Webentwicklern, nämlich dass wir gesagt haben: „Nutzt doch endlich mal Webstandards." Jetzt haben sie das das erste Mal gemacht und haben wir gesagt: „Nutzt doch bitte CSS." Und jetzt haben sie sich so langsam an CSS gewöhnt und nu kommen wir drauf und sagen: „Macht das doch bitte sauber, organisiert und strukturiert und am besten nach den Regeln des CSS Doc."

Ja. Es ist nicht ganz so dogmatisch, glaube ich. Es ist einfach nur, wenn man anfängt, etwas größere Projekte zu stricken, dann fällt einem irgendwann auf die Füße, dass CSS nicht wirklich, eine Programmiersprache ist, in der man, eine Art Gliederung anlegen kann, sondern mehr oder weniger schreibt man seine Regeln, mehr oder weniger hintereinander. Das Einzige, was man aufpassen muss, ist einfach nur die Kaskade.

Und bei kleinen Seiten, wenn man so eine einfache Webseite baut, sind das unglaublich nicht allzu viele Regeln, dann passt das alles sehr schön ineinander. Bei größeren Projekten kann man dann anfangen, die Stylesheets zu zerlegen in einzelne Dateien und sie so zum Beispiel themenweise zu gliedern.

Aber innerhalb, einer CSS-Datei ist eigentlich, kaum möglich, sind kaum Möglichkeiten da, die irgendwie zu strukturieren oder sinnvolle Hinweise zu hinterlassen nach irgendeiner Form, die auch, die andere auch sofort wieder verstehen und erkennen können.

Tom, wieso sollte der normale Webentwickler überhaupt Ordnung und Struktur in seinen CSS-Code bringen?

Ja, gute Frage. Ich meine, solange man am Projekt ist und das entwickelt, kennt man sich auch noch gut aus.

Wenn man dann mal zwei, drei Wochen vergehen lässt oder auch nach 'nem halben Jahr oder so was wieder in ein Projekt reinmuss und man macht seine Dateien auf und denkt sich: „Ich könnte sie eigentlich gerade neu schreiben", dann ist eigentlich so der, sage ich mal, so dieser Test, den man durchführen kann, wo man sagt: „Okay, hier macht das einfach Sinn." Also wenn ich meine Dateien aufmache und ich gucke rein und ich habe das Gefühl, ich blicke sofort wieder, wo oben und unten ist, wo vorne und hinten ist, dann denke ich, habe ich eine Datei ganz gut geschrieben.

Dann macht es mir auch Spaß, damit zu arbeiten. Ja, und da ist ja auch eine, ein Ansatzpunkt von CSS Doc, eben dort ein paar Sachen für eine gut aussehende Struktur, wie ich auch finde, vorzugeben und auch die Orientierung zu erleichtern. Wie Dirk ja auch sagte, das ist gar nicht unbedingt so dogmatisch. Es gibt ein paar Regeln, an denen man sich halten kann.

Es gibt ein paar Notationsregeln auch, wie man was hinschreibt, wie man so einen Kommentar dann eben auch schreibt, diesen Doc-Block-Kommentar. Und ich finde, der sieht auch ganz gut aus und der schafft auch Ordnung. Manche Leute denken, es ist vielleicht platzverschwenderisch, aber ich finde es einfach ganz nett so.

Also ich finde es auch unabdingbar, dass man seinen, ich nenne es jetzt mal Code, auch wenn es keine Programmiersprache ist, dass man seinen Code in CSS auch sauber schreiben sollte, gerade wenn man im Team arbeitet oder das, was du auch sagst, gerade wenn man mal ein bisschen Zeit verlaufen lässt, dazwischen, also dass man sich die Datei mal wieder anschaut und die sind dann noch gewachsen bei größeren Projekten, dann merkt man es sehr schnell, dass man eigentlich um eine Dokumentation nicht drumherum kommt, wenn man jetzt schnell was ändern möchte.

Ja klar. Also wenn ich unterbrechen darf für Arbeiten im Team, ist das, ist das definitiv noch viel schneller der Fall. Wenn andere Leute was mit einfügen. Da passieren ja auch Sachen hinter meinem Rücken, wo ich die Prozesse vielleicht nicht ganz genauso verfolge oder da mit drinstecke.

Und dann ist es natürlich umso besser, wenn ich sehe, okay, hier ist jetzt wirklich ein Kommentar und da hat sich jemand auch was zu überlegt, was er dazu reinschreibt, wenn er eine neue Sektion in einem Dokument zum Beispiel aufmacht.

Also bei Sevenload machen wir es derzeit genauso, dass wir alles dokumentieren und vor allen Dingen setzen wir uns selbst Coding-Standards auf in Englisch, die sagen, so wird programmiert in PHP, so schreiben wir HTML, so schreiben wir CSS, damit andere, die in, in, ins Entwicklerteam hineinstoßen, sofort mitarbeiten können und produktiv sein können, ohne dass sie sich tagelang, dumm und dämlich suchen. Und genau darum geht's ja.

Und gerade in Sachen PHP, da kenne ich das ja, gibt es ja das PHP Doc, die Dokumentation, indem man bestimmte Kommentare, über seine Funktion oder Klassen setzt. Und, wenn ich das ganze Ding durch PHP später durchparsen lasse, dann kommt am Ergebnis eine automatisierte Dokumentation dabei raus. Und das ist ja auch die Richtung, mit der ihr ins CSS Doc gehen wollt, wenn ich das richtig sehe, oder?

Das ist ein gutes Stichwort, vor allen Dingen jetzt der Hinweis auf PHP Doc. Also das ist, CSS Doc ist da keine Neuerfindung. Also wenn man den Blick über den Tellerrand mal rausnimmt, aus CSS, dann sieht man eben schon, dass bei PHP mit PHP Doc, bei Java-Programmierung Java Doc beziehungsweise Script Doc, schon diese Art und Weise der, der, der Dokumentation vorhanden ist.

Hauptsächlich eben dazu oder dafür gedacht bei PHP eben, dass im Idealfall automatisch aus dem Code gleich noch eine Dokumentation generiert werden kann. Java Doc ist, hat denselben Ansatz. Bei CSS Doc wird es im Prinzip alles aufgenommen, diese Infos. Weniger, um jetzt aus dem, aus dem Wunsch da eine komplette Dokumentation rausz-zuwerfen am Ende, sondern aber zumindest diese Übersichtlichkeit zu erreichen, ne.

Wenn man sich mal vorstellt, größere Projekte, also vielleicht jetzt nicht mein eigenes Weblog, aber wenn ich mir vorstelle, ein größeres Unternehmen, wo da ein komplettes CI umgesetzt wird, wo das komplette Backend, das Frontend nachher gestaltet wird mit zig Vorgaben für das Online-Editieren, für das, das Layout, was nach draußen geht, für ein Printlayout.

Also da kommen eine ganze Menge Sachen zusammen- -die da irgendwo ineinandergreifen müssen, wo es Querverweise gibt, wo welche Sachen herkommen.

Das lässt sich eben, soll sich möglichst alles in diesem einen Dokument, zusammenfassen lassen, dass man quasi wirklich seine Entwicklerfassung von CSS einmalig schreibt, einmalig dokumentiert und dann, für den eigentlichen Auftritt, für die Live-Version, einfach daraus eine Fassung extrahiert, die irgendwie auf den Server legt, die eben von mir aus diese Kommentare nicht hat, damit eben die Dateigröße, hier kein Problem wird.

Aber dass man eine Arbeitsfassung hat, wo man wirklich alles zusammen bündelt und die man auch jederzeit weitergeben kann.

Also ich glaube auch, was wir nicht entstehen lassen sollten, sind die Gedanken: Meine Güte, jetzt machen sich wieder irgendwelche Köppe heiße Gedanken und meinen, sie müssten irgendwas reglementieren. Typisch deutsch vielleicht. So ist es nicht. Also einen praktischen Nutzen, gerade bei PHP Doc, sehe ich darin, wenn sehr viele Leute am, am skalierten Projekt, also an sehr großem Projekt arbeiten, dann kann nicht jeder zu jeder Zeit jede Funktion auswendig, kennen.

Wenn ich aber gerade eine Funktion suche und ich fange an, diese Funktion, ich weiß noch, Mensch, die hieß ungefähr irgendwas mit, Papipapo, dann gebe ich, fange ich an, Papipapo anzuschreiben und, per, also meine, meine Entwicklungsumgebung, das ist in meinem Fall Zend, findet automatisch diese Funktion, schlägt mir die vor: Meintest du etwa das? Und wenn ich dann sage: „Ja, diese Funktion meine ich“, beim Schreiben sagt er mir auch gleich, welche Variablen ich übergeben muss.

Und das passiert automatisch, weil ich ein PHP Doc oben drüber habe. Ist das auch vielleicht irgendwann eine Zukunfts, vision für CSS Doc, dass das irgendwann mal in den I, IDEs integriert werden kann?

Das ist definitiv, ist das eine Perspektive, die das Projekt hat und auch eine Möglichkeit, allein durch die Maschinenlesbarkeit, die dadurch, die, die ermöglicht das ja quasi. Dadurch kann ja ein Editor das CSS parsen und kann dann zum Beispiel so was wie Gruppen oder Sektionen auswerten. Und wenn du Zend benutzt oder diese Eclipse-basierten Sachen, die haben zum Beispiel die Outline, dass man dann auch eine Outline hat für größere CSS-Dokumente, und zwar nach der eigenen Dokumentation.

Jetzt nicht nur: Okay, jetzt habe ich für alle meine Klassen oder meine Selektoren das oder für die Ad-Media-Selektoren vielleicht noch mal in der Staffelung, sondern auch wirklich nach dem: Hier ist eine Sektion der Reset-Block, da ist eine Sektion des Layout, dass man diese Sachen dann quasi auch als Sektion anwählen kann und da schnell hinspringen kann. Für eine Wiederauffindbarkeit, denke ich, ganz gut. Das sind so Sachen, die man recht simpel, ja, implementieren könnte.

Ich habe das mal jetzt beim eigenen Editor gemacht, der da so eine Funktion bietet, um halt besonders schnell so Sprungpunkte zu definieren. Das hat sehr gut geklappt in dem ersten Test. Das sind schon so Sachen. Wir haben halt im Vergleich zu den Programmiersprachen doch ein etwas anderes Terrain auch.

Die Programmiersprachen sind, ja, sind sehr klar definiert und haben auch eine klare eigene Struktur, was weiß ich, eine Klasse, ein Objekt, einen Funktionsblock et cetera pp., was eben so eine IDE auch ganz prima abbilden kann oder wozu man auch mit dem PHP Doc, um jetzt zum Beispiel mit PHP zu bleiben, immer eine Definition noch dazupacken kann. So genaue Möglichkeiten haben wir im CSS nicht. Deswegen ist das auch per se schon mal nicht so dogmatisch in Anführungszeichen.

Also PHP Doc kann mir sagen, wenn ich eine undokumentierte Funktion habe. Diese Möglichkeit, die wird es bei CSS Doc nie geben, weil, weil es da so was wie CSS-Funktionen gibt es einfach nicht.

Ja, es ist, es ist ja kein Programmteil, der da jetzt ausgerufen wird, sondern es sind ja eigentlich nur Style-Definitionen. Von daher wird es auch nicht so wichtig sein, ob ich diesem Definitionsblock jetzt noch eine Farbe gebe oder so, sonst irgendwas, ne.

Ja, genau. Aber Ziel soll natürlich schon sein, dass eine IDE das gut unterstützt, ja. Wenn man-- Also wir haben auch so Sachen überlegt mit Querverweisen. Wenn man jetzt von einer Datei in eine andere Datei verweist, das wäre natürlich super schön in der IDE, wenn ich da draufklicken kann wie auf einen Hyperlink. Und dann, gehe ich in die nächste Datei rein. Ja, so was.

Oder ich mache eine, eine Referenz in eine andere Sektion, dass man sagt, was weiß ich, mein globales Layout und dann habe ich so, so Sublayouts vielleicht da drin. Dann habe ich da einen Add-C-Tag drin und dann steht dort Verweis auf, auf die andere Sektion. Da klicke ich drauf und dann springt der da hin. Das wären natürlich so Komfortoptionen, sage ich mal, die die Arbeit angenehm machen und die man dadurch machen könnte. Vielleicht kann ich da noch gleich einspringen.

• Der Vorschlag dazu kam, aufm Barcamp im April vom Timo und vom Tom. Die sind da beide damals an mich rangetreten, als ich, damals die neue Version von YAML vorgestellt hab und meinten da, wie sinnvoll das doch wäre, mit CSS Docs,, in die Richtung mal zu denken. Und, der Tom hat dann letzten Endes angefangen, so 'ne, so 'nen ersten Draft mal zusammenzustellen.

Ich hatte mich dann, glaub ich, im Mai oder im, im, im Juni relativ kurzfristig dazu entschlossen, die neue YAML-Version drei mal komplett mit CSS Docs, auszustatten. Und das hat natürlich ein bisschen Arbeit gemacht, weil wenn man sich das in YAML mal ansieht, das ist natürlich, die Dateien sind extrem Kommentar, mit Kommentaren angereichert. Aber was sich sehr schnell, ergeben hat, waren eine ganze Menge Vorteile, die dieses Ganze eben code lesbarer gemacht haben.

Das beste Beispiel, find ich eigentlich, ist die Dokumentation beispielsweise von Bugfixes. Ne? Wer mit CSS regelmäßig Umgang hat, der wird das kennen, dass, CSS normal recht einfach lesbar ist. Sobald man aber irgendwie einen Hack vorgesetzt kriegt oder für irgendeinen Bug, wenn man nicht täglich drinsteckt und nicht genau weiß, was da passiert, dann verliert man sehr schnell die Übersicht.

Und das ist einer der großen Vorteile, die ich eben sehe, wenn ich mit, Standardtext beispielsweise, wie sie bei CSS Docs jetzt definiert sind, arbeiten kann, dass ich sehr einfach beschreiben kann und für jeden verständlich: Was ist es für ein Bugfix? Welche Browser werden davon, welche Browser sind davon betroffen?

Welche Browser werden von dem Hack, den ich hier verwende, angesprochen, sodass ich auch gucken kann, wenn's irgendwo Fehler gibt: Kann das hier davon kommen?, dass ich das einfach dokumentieren kann, auch ob der Bug, der, der Bugfix valide ist, dass ich mir also dafür, mir umschauen kann, wo platziere ich ihn in meinem Quellcode. Das sind alles Sachen, wie gesagt, die machen das unheimlich übersichtlich, und verbessern wirklich extrem die Lesbarkeit.

Vor allen Dingen bei so Projekten wie eben bei YAML, wo ich doch auf eine ganze Menge Sachen rückgriffe, die im täglichen Leben nicht unbedingt an jeder Stelle gebraucht werden. Bugs können eben, durch die verschiedenen Layoutmöglichkeiten, die es da gibt, mal auftreten und mal nicht.

Und da halt eben sehr wichtig, dass man im Hintergrund eine Dokumentation hat, die man sehr schnell überfliegen kann und wo man sehr schnell immer wieder reinkommt, egal wie lange man jetzt, das Ganze nicht angepasst hat, um rauszubekommen, wo könnt's denn klemmen, wo kommt denn dieses her und wofür ist jene Regel da.

Es dient natürlich auch der Verständlichkeit, grade wenn du sagst, wir setzen CSS-Hacks ein. Grade wir Profis gehen ja mehr in die Richtung, dass wir versuchen, unseren, unseren Quelltext, zu minimieren, immer weniger zu schreiben, trotzdem mit den gleichen Effekten und was auch immer auszukommen.

Aber trotzdem gibt es ja diverse Sachen, die in Browsern gesetzt werden müssen, hide von ein Prozent oder, oder clear floating oder wa-was auch immer, die einfach drin sein müssen, damit sie, damit diese Website browserkompatibel ist. Also ich kann mich grade jetzt noch, bei Sevenload haben wir die BMW Web TV gemacht und benutzen als, JavaScript-Framework jQuery und da gab es bei den Effekten-- Also alles spielt sich auf einer Seite ab und muss sehr schnell funktionieren.

Also wenn ich irgendwo draufklicke, dann muss sofort ein Ajax-Effekt passieren. Da muss irgendwas sofort passieren ohne Wartezeit.

Und dann gibt es ein paar gewisse Sachen in jQuery-Effekte, die waren eben sehr langsam oder auch ein bisschen buggy, die wir sonst eingesetzt haben und an der einen oder anderen Stelle haben wir dann im Code eben gesagt: „Nein, hierfür nutzen wir einen anderen Effekt, der vielleicht nicht, so richtig toll aussieht, aber super zuverlässig funktioniert." Und dann haben wir den alten noch drin gelassen und haben drübergeschrieben: „Den nicht, weil buggy", oder sonst irgendwie was.

Und das ist auch eine Richtung, die in CSS natürlich auch sehr wichtig ist. Nicht, dass wir sagen: „Okay, wir fangen jetzt mit 'nem weißen Blatt Papier an", natürlich schon, und, und machen sehr wenig, aber nein, da müssen auch gewisse Bugfixes oder was auch immer rein, die wir dann dokumentieren, um zu sagen: „, nein, das Ding muss unbedingt drinbleiben, weil dieser und dieser Browser mit dem, was wir da jetzt publiziert haben, Probleme hat", ne.

Genau. Also geht's mir im Prinzip auch, weil, sagen wir so an YAML beispielsweise, das ist nun mal das Projekt, wo ich jetzt schon wirklich Stück für Stück über zwei Jahre daran arbeite, kontinuierlich. Und das geht eben los damit, dass ich Browser unterstütze, ab dem Explorer fünf null, und schon der fünf, fünf fünf, die sechs. Alles alte Dinger, die aber jeder irgendwo anders, geregt und gepflegt werden wollen, wenn man sie denn noch irgendwie unterstützen möchte.

Und da sind einfach, Sachen, wenn man sich da, wenn man da das ein oder andere Detail gefunden hat und dann irgendwann mal gelöst hat, und dann soll man sich nach einem Jahr, soll man noch aussagefähig sein, ob das für dieses oder jenes Problem, was aktuell grad auftritt, verantwortlich sein kann, dann ist es eben-- Dann, dann kommt der Vorteil auf einmal noch hervor.

Und jetzt ist es ein gutes Stichwort eigentlich, was du erwähnt hast. Jetzt ist es natürlich wichtig, wenn ihr euch entschließen solltet oder du dich bei YAML, dass du sagst, in 'nem halben Jahr oder in einem Jahr, wenn's YAML drei Punkt fünf gibt oder was auch immer die Zukunft sagt, und du unterstützt dann eben nicht mehr, Internet Explorer fünf auf dem Mac oder auf dem PC, weil's einfach zu viel Aufwand ist und das Ding eh keiner mehr nutzt.

Dann ist es natürlich von Vorteil, wenn du A, diese Hacks oder was auch immer gruppiert hast für diesen Browser beziehungsweise im Kontext hast und nicht überall in tausend Dateien alles verschoben hast und musst die einzeln raussuchen, sondern kannst das dann, durch die Dokumentation eben leicht aufspüren und dann entfernen. Was gibt es denn sonst noch für Vorteile von CSS Doc oder generell der Dokumentation der Funktion von CSS? Nicht der Funktion, sondern der Deklaration.

Komm, willst du?

Ich, ich kann mal mit so ein paar allgemeinen Sachen anfangen. Ich denk, das kennt jeder, der ernsthaft irgendwie anfängt, ja, Dokumente zu schreiben. Das, das ist ja die Versionierung zum Beispiel oder einfach den Autor festzuhalten. Wer hat zum Beispiel, wer hat an dieser Datei denn mal gearbeitet?

Wer hat das verbrochen?

Wer hat das verbrochen, genau. Oder auch aus urheberrechtlichen Gründen. Da gibt's ja die verschiedenen Sinnigkeiten, warum man irgendwie den Autor festhält. Da haben wir, sage ich mal, einen @author-Tag. Das kennt man auch aus vom-- Wenn man PHP Doc kennt, dann kennt man das auch.

Also wir haben, der Dirk hat es ja schon gesagt, wir haben eigentlich nicht so viel jetzt neu erfunden, sondern wir haben bewährtes Prinzip genommen und haben das übertragen eben auf CSS und versucht, ja, die guten Sachen, die wir halt davon kennen, dahin zu übertragen, weil's da halt noch nichts gab.

Also noch mal ganz kurz eingegriffen: Die Basis generell für diejenigen, die jetzt auch PHP Doc nicht kennen. Wenn ich in PHP eine Funktion oder eine Deklaration jetzt oder was auch immer ein Block in CSS habe, dann setze ich direkt da drüber einen Kommentar, wo eine Funktionsbeschreibung oder, oder eine generelle Beschreibung reinkommt, worum es sich im nachfolgenden Block handelt. Und dann kann man mit einem @ jetzt noch den Autor hinzufügen oder das Datum oder sonstige Sachen.

Da gehen wir später in die Sendung noch drauf ein, was ihr euch da überlegt habt. Aber ganz generell kann man dort auch den Autor anlegen und dann sagen, das war der und der mit Datum so und so zur Revision so und so und, dann weiß ich ganz genau: Ach nee, da hat der und der doch eine neue Version gemacht und die müssen wir jetzt an dieser Stelle einfügen.

Zum Beispiel.

Entschuldigung.

Oder ja, oder ich, oder ich weiß einfach, wer, wer das verbrochen hat- -wie du eben sagtest und, kann den einfach ansprechen und sagen: „Hier, was ist denn mit deinem Reset-Block los? Du machst irgendwie einen Reset auf alle Input-Elemente und nimmst irgendwie den Border da raus. Das führt aber bei den, Input-Hidden-Elementen im Opera 5 zu Problemen, weil der auf einmal dann den Null-Border drum setzt und die als Block-Elemente rendert oder so was, obwohl die eigentlich hidden sein müssen.

Was weiß ich. Also da gibt es ja wirklich die, die obskursten Sachen, die auch passieren können. Und da ist das wirklich sehr hilfreich, ja.

Das ist eine Form der Anwendung, dass man halt diese Metadaten dazu packt oder eben auch ganz einfach, indem man sagt: „So, das ist jetzt hier mein Reset-Block." Ja, in den ersten Tests, die ich gemacht hab, war das zum Beispiel so: Ja, hier war jetzt der Reset-Block von, das war eine Theme von, von unserer Usergruppen-Seite in Frankfurt, von der PHP User Group.

Da setzen wir so ein Blogsystem ein, WordPress, das ist recht bekannt und da gibt's halt verschiedene Themes zu und wir haben unsere natürlich angepasst, um uns ein eigenes Design zu geben und ein Teil von so einer Theme ist eben auch eine, CSS-Datei.

Und da gab's dann auch am Anfang einen Reset-Block und dann wurde halt dokumentiert und dann gab's auch irgendwie einen Verweis von dem ursprünglichen Designer, der halt nach, ich glaub, Meyer war das oder so, diesen CSS-Reset durchgeführt hat und dann konnte man sich, wenn man das nicht kannte, ganz schnell dazu informieren, weil halt noch der Hyperlink dazu hinterlegt war unter einem @c-Tag, also diese Sache mit dem @ und dann eine kurze Beschreibung.

Das sind halt die sogenannten Tags für die, die es nicht kennen. Und wenn man dann eben halt genau weiß, was diese Stichwörter oder diese Tags heißen und dann weiß man auch, was man davon zu halten hat, sozusagen. Das ist eben diese Konvention, auf die man sich auch einigt. Oder darüber kann man auch einfach ganz frei schreiben, kann sagen: „Das ist jetzt der Reset-Block nach Meyer.

Ich hab den angewendet und bin prima zufrieden damit." Das wär jetzt schon sehr ausführlich, aber da kann man auch normalen Text noch reinschreiben in diese Kommentarblöcke.

Ich denke mal, ich denke mal, wir schieben die Nachteile, es gibt ja eventuell ein paar, die schieben wir ans Ende der Sendung. Gehen wir noch ein bisschen auf die Grundlagen ein. Also welche Notationen habt ihr euch noch überlegt, um gewisse Blöcke zu gestalten oder gewisse Blöcke zu dokumentieren?

Da würde ich, also was einen-- Es gibt so generelle Geschichten, das ist die generell die Struktur, die man anlegen möchte. So die Grundstruktur, da gibt's erst mal diesen File Comment, also den Datei-Kommentar quasi, der steht am Anfang. Der steht da halt auch immer am Anfang. Der kann einmal pro Datei auftauchen, wo eben so Grunddaten pro Datei rein gehören.

Und dann gibt's eben halt die Sektionskommentare, Section Comments nennen wir die von den Blöcken her, wo man pro Sektion, also Unterteilung, die der Autor selber trifft, wie Reset, Layout oder so was.

Tabellenformatierung, Formulare et cetera.

Tabellen, genau. So was Typografie oder so. Manche machen ja einen, einen Block für die, für die Grundschriften und so. Das, -

Ich bekenne mich schuldig.

Wo der selber-- Hä?

Ich bekenne mich schuldig.

Wo, wo man das halt selber mit dann markiert und somit natürlich damit auch, ja, für sich selber auch schon mal Ordnung schafft, ja, in diesem Dokument oder natürlich dann auch für andere. Das sind so, sage ich mal, ist das im Groben. Und dann gibt's halt so ein paar Spezial-Tags. Da würde ich auch gerne an den Dirk abgeben, zum Beispiel eben für diese Bugfixes und Workarounds von den CSS-Hacks.

Da haben wir auch schon sehr viel Gehirnschmalz reingepackt und der Dirk hat das ja, es klang ja eben schon mit an, hat er auch sehr viel Erfahrung durch sein YAML, dass wir dort schon eine sehr, ja, sage ich mal, weit entwickelte Notation in diesem Bereich haben, die Dirk gerne auch mal kurz vorstellen kann.

Ja. Also zur Schreibweise, wenn wir uns das angucken, normaler Kommentar, CSS-Kommentar, geht immer irgendwo mit einem Slash und einem Stern los, endet wieder mit einem Stern und, und einem Backslash. Ein CSS Doc Kommentar oder so ein Doc Block, wie es dann sozusagen heißt, startet im Unterschied dazu mit einem Slash und zwei Sternen. Das ist die übliche Schreibweise.

Danach, beginnt jede weitere Zeile innerhalb so eines Doc Blocks einfach mit einem eingerückten Stern und dahinter ist man also einfach frei zu kommentieren. Wenn ich nur eine Zeile zu schreiben habe, dann ist natürlich ein ganz normaler CSS Kommentar nach wie vor das Sinnvollste. Wenn es aber wirklich jetzt darum geht, bestimmte Sachen etwas näher zu beschreiben, dann kommt eigentlich CSS Doc zu, kommt dann durch und man hat seine Vorteile.

Dann kommen eigentlich die Tags ins Spiel und die sind das eigentliche Salz in der Suppe, dass man eben anfängt. Wir fangen mal oben beim File Comment noch mal an, das sind die Sachen, die wirklich ganz oben an der Datei stehen. Wer hat-- Worum geht's hier? Wer hat's erstellt? Da gibt's beispielsweise einen ganz normalen Copyright Tag, Li-Lizenzangaben dazu, zu welchem Paket gehört welche Version, welche Revision, ist, liegt in der Datei, wer hat zuletzt modifiziert.

Vor allem die letzten Sachen Revision, Version, last modified. Das sind so die klassischen Sachen, wenn man auch mit Subversion oder anderen Versionsverwaltungen arbeitet, die das, die das, die Systeme quasi standardmäßig in die Dateien rendern.

Was eben auch sehr wichtig ist, falls irgendwie ein Bug auftritt, beim Rendering im Browser, dass man eben eine Version zurückschalten kann oder überarbeitet diese Version, dass man genau gucken kann: Mensch, gestern hat's noch funktioniert, jetzt hast du drin rumgearbeitet und heute funktioniert's nicht mehr. Und anhand dieser Kommentare und Revision kann ich dann eben feststellen: Wo genau waren die Änderungen jetzt, ne?

Genau. Und das eine ist eben, dass beispielsweise, wenn man so was wie Subversion nimmt, die schreiben jetzt selbstverständlich diese Revision und oder auch die, das Datum der letzten Änderung selbstständig in die Dateien, wenn man das einfach das entsprechende Schlüsselwort in der Datei hinterlässt.

Der Vorteil, wenn man jetzt eben sich auch an die Notation hält, wie man jetzt, davor eben diesen Tag formuliert und dazu schreibt, dann hat man eben die, die Möglichkeiten, dass so eine Entwicklungsumgebung wie E-Eclipse beziehungsweise Aptana, das ja nun direkt auf HTML und CSS auch zielt, dort in Zukunft auch diese Kommentare wie Doc Blöcke problemlos auslesen können und das auch wirklich, sehr leicht zugänglich machen, diese Information, dass man eben gar nicht mehr unter Umständen in jede einzelne Datei rei-reingucken muss, sondern dass es eben so eine automatische Auswertung gibt.

So und für die, wenn man dann weitergehen, die einzelnen Section Comments, das ist also eine Section, ganz normal ein Abschnitt, eine Unterteilung, die ich eben innerhalb einer Datei arbeiten kann.

Das wäre die einfachste Möglichkeit der Gliederung, wenn ich Querverweise machen will, wie der Tom vorhin gesagt hat, wenn ich eben meinen Rezeptblock von irgendwo hernehme und einfach einfüge, beispielsweise das Standardrezept von Erik Meier, dann ist eben einfach: Das ist mein Rezeptblock, der kommt dahin. Ich kann auch einen Querverweis machen zu der entsprechenden Version, wenn man sich erinnert, Erik Meier, ich glaube, sein aktueller Rezeptblock, der ist im Mai entstanden.

April, Mai, der hat, glaube ich, drei oder vier Versionen innerhalb seines Blog, seines, Blogs. Ne? Einfach einen Link hin und man hat auch nach einem halben Jahr noch die Information, wo es herkommt und wo es eventuell mal klemmen könnte irgendwann mal nachlich.

Oder dass ich mir dann eine neue Version runterlade und die dann integriere.

So, und dann geht's eben weiter. Dann kommen zusätzliche Tags. Wir hatten ja, CSS Doc liefert eine ganze Menge. Wir hatten uns jetzt für die Sendung ein paar rausgepickt, die wir eben mal genauer beschreiben wollten. Ich hatte vorhin schon auf diese Bugfixes, angesprochen. Dort haben wir zwei Unterscheidungen: einmal @bugfix und einmal @workaround. Das ist also schon mal ein Hinweis.

Beseitige ich wirklich ein Problem, was existiert mit einem richtig regelgerechten Bugfix, wenn man sich beim Internet Explorer an diesen double float margin Bug erinnert, der eben einfach, die Randabstände von Float-Objekten verdoppelt, ne? Den kann ich einfach mit einem Display inline beseitigen, der ist dann auch weg. Infolgedesse wäre das die klassische Anwendung für einen Bugfix.

Dagegen ein Workaround, auch wieder der Internet Explorer, der diese Angewohnheit hat, sobald, ein beliebiger Container dieses Merkmal has layout hat, dann schließt er eben automatisch in diesem Container alle Inhalte ein, egal ob es nun Floate oder statische Inhalte sind. Das ist da etwas, was alle anderen Browser nicht tun. Und das ist auch was, was man nicht wirklich beseitigen kann. Man kann es nur mit einigen Kniffen und Handgriffen, zum Teil die, die optischen Auswirkungen verstecken.

Da gibt's also Workarounds, die das Problem minimieren, auf irgendeine Weise umgehen, aber nicht wirklich lösen.

Also der Unterschied zwischen Bugfix oder Workaround. Bugfix heißt, ich habe wirklich die Lösung, das funktioniert und das sind ein, zwei Kleinigkeiten. Oder Workaround heißt dann, ich gucke mal, ich arbeite ein bisschen drauf hin und, und versuch's zu minimieren, aber so richtig hundertprozentig sitzen tut's noch nicht.

Kann man im Prinzip so beschreiben, ne. Das eine ist wirklich Bugfix heißt, ich gehe drauf zu, schlag drauf und das Ding ist, danach macht's das, was ich will. Und ein Workaround ist wirklich, das Wort ist passend. Ich gehe, ich versuche, das Ganze wirklich zu umschiffen. Indem ich irgendwas tue, wirklich, um-- teilweise sind ja so Workaround um drei Ecken gedacht, um dieses Problem, was da auftritt, irgendwie in den Griff zu bekommen, ne. Und gerade da kann's dann mal kompliziert werden.

Und dann habe ich eben diese Tags. Entweder, dass ein Bugfix kommt oder dass ein Workaround kommt. Und dann kommt als Nächstes, würde ich an so einen Tag, ergänzen, der nennt sich, Affects. Wo ich einfach, die Browser danach aufführe, die dieses Problem wirklich haben. Dass ich eben sagen kann, der IE sechs, der IE fünf, der IE sieben hat dieses Problem.

Also ich habe eine einheitliche Schreibweise und sag nicht, im Kommentar: „Das ist jetzt für einen Internet Explorer sechs“, weil der geht mir eh auf den Zeiger und das ist jetzt für einen Internet Explorer sieben, sondern ich habe mit Affected eine, einheitliche Schreibweise, wo ich sofort auf den ersten Blick erkennen kann, für welchen Browser ist das jetzt.

Genau, ich sage erst mal als allererstes, worum geht's? Welcher Browser ist betroffen? Als Nächstes, das wäre der Affected Tag. Als Nächstes kann ich schreiben, in, in, haben wir einen Tag CSS vor. Also für, für welche Browser, werden das folgende CS, das folgende CSS, den Hack oder was auch immer jetzt kommt, welche Browser verstehen das? Ne?

Mache ich, benutze ich also beispielsweise standardmäßig, wenn wir als Beispiel wieder nehmen den, den Double Float Margin Bug, den kann ich einfach mit Display Inline beseitigen. Das ist, der ist, der validiert. Da gibt's überhaupt keine Probleme. Den kann ich, da brauche ich keine extra Datei dafür anlegen.

Den kann ich einfach mit reinschreiben, wenn ich ein Objekt floaten lasse, weil in jedem normalen Browser würde Display Inline an der Stelle, sobald ein Objekt floatet, vom Browser ignoriert werden. Glücklicherweise bei IE löst das aber gleichzeitig das Problem. Andere Hacks oder andere Bugs, um die zu beseitigen, muss ich spezielle Parser Hacks einsetzen, um eben nur die Eigenschaften, die ich, zum Beseitigen des Bugs brauche, an den entsprechenden Browser zu schicken.

Also eben an den IE sechs oder an den IE sieben und andere Browser dürfen das gar nicht sehen. Also schreibe ich, kann ich das auch genauso wieder angeben, indem ich sage, dieses folgende CSS ist nur für den IE fünf, für den IE sechs oder auch mal für den Firefox. Auch der glänzt da gelegentlich mal mit einem Bug. Nur diese sollen das sehen. Und als Drittes wäre quasi, die Möglichkeit anzugeben: Das, was ich jetzt hier unten schreibe, ist das valide oder ist es nicht? Ne?

Auch das ist für jemanden, der täglich damit Umgang hat, der wird draufgucken und den einen oder anderen Parser Hack, Hack kennen und sagen: „Ja gut, hier ist ein Validitätsproblem.“ Und dann kann ich mich entscheiden: Lege ich es in eine extra Datei oder lasse ich es in meinem normalen Text drin? Aber auch hier ist der Hinweis eigentlich, man gibt es einfach mit an, valide ja oder valide nein und der Nachfolgende, der draufguckt, hat es einfach einfacher.

Also praktisch fällt mir jetzt direkt ein, die Transparent, also die Opacity, wenn ich die angebe, die validiert derzeit noch nicht, funktioniert aber in fast jedem Browser. Das wäre eine Sache, wo ich sage, würde zum Beispiel nicht validieren und in Zukunft, wenn die Browser das dann, nativ via CSS unterstützen, dann, wäre das valide.

Genau. Da kann man sicherlich, spinnen. Man kann sich diese ganzen Vorteile, was man jetzt, wenn man das wirklich als maschinenauswertbar jetzt hier rannimmt und entsprechende Plugins für Entwicklungsumgebung schreibt, kann man sich eine ganze Menge vorstellen, was man dann damit machen kann und wie man diesen Text auch auswerten kann. Ja, hier ist eben mit CSS Doc, das ist ein Vorschlag quasi von uns dreien, wie, es dann gestaltet werden kann, wie es sich für sinnvoll eignet.

Ich habe das bei YAML einfach mal umgesetzt. Da sind auch schon, als ich das damals gemacht habe im Juni, haben wir auch hier schon eine ganze Menge geändert, dazugefügt, wieder weggelassen an Text, wo wir einfach gesagt haben, das bringt einfach nichts. Wir sind jetzt auf einem Stand, wo man sagen kann, für die Anwendung halte ich sie zumindest oder, oder wir für sinnvoll. Der nächste Schritt wäre, entsprechende Tools zu bereitzustellen, dass einfach die Arbeit damit etwas leichter wird. Ne?

Beispielsweise die ganze Einrückung, wenn man sich die Kommentare anguckt. Da sieht man, nach einem gewissen Schema geschrieben. Da hat beispielsweise der Tom extra für mich zunächst erst mal, ein kleines Skript geschrieben, womit ich meine Kommentare einfach schreiben kann, so wie ich es gewohnt bin und er anschließend mir die CSS-Dateien noch mal sauber formatiert, damit die eben ordentlich aussehen und damit auch diese DocBlocks sauber eingerückt sind.

Bitte nicht machen, nachmachen, liebe Hörer. Nein, aber ich habe mir jetzt eine ganze Menge, Vorteile, rausgeschrieben oder eine ganze Menge Vorteile haben wir uns dann erörtert. Was sind denn so die Nachteile generell, von dieser ganzen Geschichte CSS Doc?

Also was man als Feedback auch bekommt – man, Feedback ist nach wie vor erwünscht –, ist, dass die Leute sagen: „Na ja, da musst du jetzt zu viel reinschreiben.“ Ja, das heißt, die Dateien werden so ein bisschen aufgebläht.

Also mehr Aufwand sozusagen.

Es ist, ja gut, Mehraufwand ist ja, ist ein zwiespältiges Argument. Ich meine, um eine bessere Dokumentation zu machen, muss ich sowieso mehr Aufwand betreiben. Ob ich die jetzt nur nach CSS Doc mache oder mit, mit CSS Doc mache oder mit My Doc oder ich schreibe so, wie ich es will oder wie wir im Team beschlossen haben. Ja. Das, das spielt ja keine Rolle. Das wird immer mehr Aufwand sein. Aber wir haben natürlich, wenn man die Tags reinpackt et cetera pp.

oder auch durch diese mehrzeiligen Kommentare, bläht es schon die Dateien ein Stück weit auf. Ja, und wenn jetzt Leute sagen, das ist, das ist ja natürlich wirklich ein wichtiger Punkt bei CSS: Ja, wir wollen die Seiten natürlich auch alle Ladezeiten optimiert haben. Ja. Dann ist das natürlich was, was im Wege steht, weil da sind Bytes drin, die braucht der Browser nicht wirklich, um die Seite korrekt darzustellen.

Obgleich man dann einen Parser drüber laufen lassen könnte, zum Beispiel CSS Tidy oder was auch immer, die diese Kommentare eben entfernt, sodass ich sie in einer Entwicklungsumgebung habe, diese Kommentare, und dann später in der Webseite, wenn sie ausgeliefert wird und ich habe eine High-Traffic-Seite, dass die dann eben entfernt sind, zum Beispiel.

Ganz genau. Das ist, das ist auch das, was wir dann eigentlich immer sagen oder wo, worauf das auch, hingeht. Vielleicht auch, wenn man, ja, diese Schritte hat zu einer Publikation hin, dass diese Dateien halt auch noch mal weiterverarbeitet werden. Und da ist ja auch wiederum, da ist dieser Nachteil dann eben schnell weg, wie du auch sagst, weil da hat man eh einen Schritt dazwischen, wo das rausgestrippt wird, also rausgenommen wird.

Und dazu hinaus, das überlegen wir auch so ein bisschen bei CSS Doc mit an: Wir wollen auch die Möglichkeit geben für solche Parser, die das zum Beispiel auch rausnehmen danach, Hinweise zu geben.

Da gucken wir auch ein bisschen bei CSS Tidy zum Beispiel, wie die das machen, Hinweise zu geben: „Ja, jetzt kommt zum Beispiel CSS, was überhaupt nicht valide ist." Ja, das heißt, wenn ich jetzt ein Komprimierprogramm habe für CSS wie CSS Tidy oder andere Tools, die würden womöglich den Effekt oder den Hack kaputtmachen, dass man dort auch damit wiederum mit so Textmarker reinsetzt und diesen Tools wiederum auch signalisiert: „Hier, pass mal auf.

Jetzt das Nächste, was kommt, das pack mir bitte nicht an. Du kannst zwar die Kommentare rausnehmen, aber alles, was nicht Kommentar ist, oder alles, was nicht bis zu dem nächsten Kommentar ist, der wiederum neu gekennzeichnet wurde als valide, lass bitte so, wie es ist. Lass bitte so stehen."

Macht Sinn, ja. Mhm.

Ja, zum Beispiel. Ja, was sind noch so Nachteile, was man so hört? Ich weiß net. Dirk, fällt dir gerade was ein?

Hast du Feedback bekommen über deine, über deine Kommentare in, in YAML oder, gab’s irgendwas Negatives?

Sagen wir so: Bei YAML, das große Negative, was immer kam, war eben die Dateigröße. Ne? Jeder, der sich YAML im Prinzip angeguckt hat als Erstes, hat auf die, auf die einzelne Datei gesehen und hat gesehen, dass da mal locker, wenn ich die Base, die E-Hacks und sonst was da zusammennehme, dass da mal locker fünfzig, sechzig Kilobyte an CSS-Dateien zusammenkommen.

Liegt natürlich daran, dass die, Dateien extrem umfangreich kommentiert sind, dass sie in der nächsten Version auch noch in zwei Sprachen komplett in Deutsch und Englisch ausgezeichnet sind. Und dem kann man einfach entgehen, wenn ich sage oder wenn ich mir das ansehe, ich, liefere deswegen jetzt auch bei YAML, entsprechend für den, den Praxiseinsatz reduzierte Dateien an, aus, ne? Da wird eben aus der Base, die, die ist gerade noch zwei Kilobyte groß. Ne?

Die ist eben vorher, ich glaube, ich hab’s jetzt nicht im Kopf, fünfzehn, sechzehn Kilobyte. Also, da, da fällt das quasi wirklich das ganze Gerüst oder das ganze CSS fällt auch wirklich sehr, sehr wenig zusammen und ich habe für den praktischen Einsatz, eine Version, die ist knackig, schnell. Da muss ich aber auch richtig reingucken, wenn ich irgendwo Fehler suche, aber ich habe eben auf der anderen Seite in der Entwicklererfassung, was richtig kommentiert ist.

Das wäre auch eine schöne, in, in-- Das wäre auch eine schöne Anwendungsmöglichkeit im, in der IDE, dass ich jetzt eben sage: „Entferne jetzt bitte für den produktiven Bereich jetzt alle CSS Docs."

Das, das eigentlich, das Coole ist, also, das gibt’s eigentlich schon. Also, bei YAML haben sich ja einige gefunden, einige Drittautoren, die jetzt, direkte Templates für verschiedene Systeme, CMS-Systeme schon gemacht haben. Ne?

Und da ist beispielsweise von Reinhard Hiebel, das Yoda-Template oder auch von Alexander Haas das Template für Drupal so aufbereitet, die haben also schon die komplette Tidy-Funktionalität drin, sodass, bei diesen beiden es einfach wirklich im Backend, im Template auf Knopfdruck man sagen kann: „Das, was ich bitte auf der Webseite sehe, das optimiere mir bitte vorher und lege es in deinen Cache." Und wenn ich daran arbeiten will, dann nehme ich meine ganz normale Entwicklerversion.

Das, das Template vollkommen automatisch diesen Schritt noch macht und ich brauche mich auch nicht mehr darum kümmern, dass ich das von Hand rausschmeiße und extra meine CSS-Dateien noch mal durch Tidy durchjage, sondern die haben es einfach, ins Template oder in dieses Plugin integriert und damit ins CMS drin. Finde ich eine absolut fantastische Sache.

Und das macht es natürlich extrem einfach, dann noch zu sagen: „Ich kommentiere, damit ich meinen eigenen Code verstehe" und gleichzeitig auf Knopfdruck, kriegt mein Nutzer, der meine Webseite ansieht, trotzdem was wirklich, was hauchdünn ist, was wirklich schnell ist.

Wie sitzt denn-- Müsst ihr jetzt auf die verschiedenen IDE-Hersteller darauf zugehen und sagen: „, wir haben jetzt hier einen Standard gemacht, CSS Doc. Das sind die Vorteile. Möchtest du das in deiner IDE einbinden, in dein Programm? Oder gibt es Schnittstellen für die Programme, die eventuell heute schon gefüttert werden können?" Wie sieht’s da aus?

Robert, willst du oder ich?

Ja, ich hab ein bisschen recherchiert. Es gibt, es gibt diverse Ansätze. Ich meine, wir haben einmal diese große Welt und die wächst ja immer noch weiter aus, aus dem Bereich von Eclipse-basierten Tools, ob es nun IDEs sind oder eben halt auch so was wie Atana, das für Webdesign und halt auch CSS da, beliebt ist, die im Endeffekt, die kommen ja-- Eclipse hat sehr viel mit Java zu tun und Java Doc oder auch PHP Doc, das ist ja sehr ähnlich wie dieses CSS Doc.

Also, da schätze ich die Wahrscheinlichkeit sehr hoch ein, dass es da relativ bald was geben könnte, weil man eigentlich Programmbibliotheken verwenden kann, die man, so Parser, die man auch schon für, ja, Java-Dateien, PHP-Dateien oder auch JavaScript-Dateien verwenden könnte. Also, in Aptana gibt’s, gibt’s was, das nennt sich Script Doc und das ist genau so eine Adaption von diesem Java-Doc-Standard eben für JavaScript-Dateien.

Da habe ich auch mal mit rumprobiert, ob ich jetzt da CSS-Dateien einladen kann und der macht mir das schon automatisch. Das hat leider so nicht geklappt, dass es quasi schon fertig wäre. Aber wo ich mir schon vorstellen kann, dass es da irgendwie halt in Zukunft schon was gibt, ja.. Es gibt auch schon Tools, das ist dieser CSS Edit heißt der glaube ich, den gibt's auch auf dem Macintosh von McRabbit Software. Der hat schon auch so einen Tag mit drin.

Das ist, nennt sich das Add Group Tag und der benutzt das schon intern, um Gruppen zu bilden. Wobei das halt jetzt, sage ich mal, deren Erfindung ist und auch nicht ganz so aufgebaut ist wie CSS Doc. Da müsste man dann halt natürlich gucken bei so Herstellern, ob die überhaupt das wollen, ja, ob das überhaupt miteinander kompatibel ist, dass sich das vielleicht ergänzt, was ja wünschenswert wäre.

Würdet ihr das auch auf eure Fahnen schreiben, dass ihr eventuell dann auf diese Hersteller drauf zugeht und mit denen Gespräche anfangt?

Also ich kann mir schon-- Gerade bei Aptana ist es relativ, wäre das sinnvoll, zumindest, sie mal darauf hinzuweisen, dass es in der Richtung was tut.

Natürlich, ist schon schwer jetzt, sagen wir so vom Aufwand her, es läuft ja alles irgendwo nebenbei, jetzt, die verschiedensten Editoren, Hersteller da anzuschreiben, aber gerade in diesem Bereich, Eclipse ist, fände ich das schon sinnvoll, die Leute einfach erst mal darauf hinzustoßen, einfach auch drin zu testen, weil ich auch glaube, so was wie CSS Doc, es ist ja im Moment kein Selbstläufer, der sagen würde, die Leute rennen uns die Bude ein, wenn die den bisher benutzen wollen.

Ne, sondern, es ist einfach 'ne Idee. Wir haben sie mal um, wir haben sie bei wenigen Projekten, die sind jetzt umgesetzt. Wir halten's für sinnvoll und jetzt ist es einfach an der Zeit. Deswegen ist ja auch heute die Sendung zum Beispiel da, um es einfach anderen, schmackhaft zu machen, andere mal dafür zu interessieren, ob's denn, ob's denn auch für, für sie, für den täglichen Alltag Sinn macht.

Und wenn es das tut, dann ist es, denke ich mal, auch, ganz viel weniger ein Problem, dort Softwareentwickler dafür zu begeistern. Zumal eben die Nähe zu Java Doc, zu Script Doc bereits da ist, sodass man einfach sagen kann, ich meine, bei Aptana läuft's ja auch nicht anders drin, ne. Da ist 'n Parser drüber und wenn ich den CSS Reader da hab, dann ist die Funktionalität da und wenn ich eine CSS-Datei aufmache, dann wird im Moment dieses Plugin ausgeblendet.

Und ich meine, das verstehen, diese Schreibweise im Generellen verstehen's auch die, die Programmierer in Russland oder die hier in Deutschland oder wo sie auch immer sitzen, verstehen denn die Schreibweise, weil sie denn eben ein bisschen angelehnt ist. Also von daher mache ich mir da eh keine Gedanken. Und wenn ich sogar-

Ja, Vorteil in das kann es eben, könnte es eben bringen, dass, hier auch, 'ne Unterstützung seitens eben so einer Entwicklungsumgebung relativ unkompliziert auch hergestellt werden kann. Und darauf hoffen wir natürlich.

Und zumal, wenn ich eh sage, im Internet heißt es ja, sobald es zwei oder drei, Institutionen oder Programme, was auch immer nutzen, ist es ja quasi schon Standard, auch wenn's keiner ist.

Ja gut, ich meine, das ist natürlich so 'ne Standardisierung ist, ist denke ich einmal kein Selbstläufer und man muss sie auch machen.

Also man muss, das ist denke ich für CSS Doc auch wichtig und das sehe ich auch gerade als einen, ja, den, den Kernpunkt in der Arbeit an, was CSS Doc betrifft, ist wirklich, dass man eine Anlaufstelle schafft, wo man sagt, okay, wir, wir haben das und das vor, wir wollen das und das machen und eben dieses Angebot gibt und Leute auch bittet, irgendwie darauf Feedback zu geben und auch zu gucken, dass man das irgendwie vorantreibt.

Ob das jetzt die IDEs sind oder ob das auch die Diskussion ist, welche Tags verwende ich dort, was macht dort Sinn, um dort wirklich ein Angebot zu haben, auf das sich auch andere beziehen können und sagen können, okay, das ist so weit stabil, dass man das auch als eine Art Standard einsetzt und sich darauf einigen kann. Ja.

Das ist, das ist nicht nur, sage ich mal, dass man guckt in, dass das in IDEs integriert ist, sondern das ist gerade am Anfang, ist es zum Beispiel erst mal irgendwie, ja, 'ne, 'ne erste Spezifikation, einfach mal komplett aufzuschreiben von vorne bis Ende und die einzelnen Tags zu erläutern und zu sagen, was sollen die machen.

Und da fällt einem schon auf diesem recht niedrigen Niveau in Anführungszeichen au, was da alles mit reinspielt, was da zu tun ist, wie man zum Beispiel welchen Wert bei irgendeinem Tag hinschreibt und so.

Weil das bräuchte auch ein Anwendungsentwickler, wenn jetzt zum Beispiel ein paar Jungs von Aptana sagen: „Hey, die Idee gefällt uns einfach." Also viele Leute, die, die diese Idee hören, die sind wirklich auch begeistert und die sagen: „Hey, cool", und so weiter und finden die auch sehr nachvollziehbar. Die bräuchten dann aber auch, so ein Entwickler bräuchte dann aber auch was an die Hand, wo er weiß, okay, so und so, darauf kann ich mich verlassen. Ja.

Und das ist, sage ich mal, so ein Prozess, den man, ja, wenn man, denke ich, den gut macht oder wenn man den gut vorantreibt, dass dann so was, wie Dirk ja eben auch meinte, gerade aus, aus so einer Ecke wie Aptana oder auch aus anderen Open-Source-Projekten, klar, wo Leute kommen: „Hey, die Idee ist gut, also, also bauen wir die mit ein oder setzen wir das mit um." Ja.

Also man muss es auch natürlich verwenden. Also das ist auch der einzige Nachteil, den ich an CSS Doc sehe, ist, dass es eben freiwillig ist und nicht einfach vorgeschrieben wird, sodass man's machen muss und die Webseiten funktionieren nicht. Schön wäre es. Das sind, ich denke, es gehört zu diesem, CSS Doc oder die Dokumentation im Allgemeinen gehört zum Dreierblock, den sehr viele Leute eben nicht machen, weil sie darauf keinen Bock haben oder weil sie's nicht können oder wollen.

Dazu gehört das Backup des eigenen Computers, dazu gehört die Versionierung von Webseiten oder von seinen eigenen Photoshop-Dateien oder was auch immer und die Dokumentation. Und, das ist so der einzige Nachteil, den ich sehe. Ansonsten sehe ich eigentlich nur Vorteile, gerade wenn wir von skalierten, also skalierbaren Projekten, oder in, von einer Projektarbeit reden, ne.

Ja. Also es wird wahrscheinlich so sein, dass jemand, der sein heimisches Blog, in CSS selber gestaltet, wahrscheinlich, wenn's ihm, wenn's ihm nicht unendlich viel, viel Spaß macht, seine eigene Arbeit zu, zu kommentieren, dann, dann muss er's nicht einsetzen, dann braucht er's nicht einsetzen. Und wie gesagt, für kleine Seiten mit wenig, - Mit CSS-Formatierung, ist die Übersicht auch meistens gegeben. Ne?

Es ist wirklich bei größeren Projekten, sobald eben, wenn ich, wenn ich eben sehe, was Tom vorhin schon gesagt hat oder du selber, wenn, wenn in der Firma gearbeitet wird, wenn dort mehrere Leute dran arbeiten, wenn es Coding-Standards gibt, wie gewisse Sachen einfach übergeben werden, damit auch, der Nachfolgende sofort wieder damit da einsteigen kann- -ohne groß sich, Gedanken machen zu müssen, dann wird's effektiv und dann macht's auch selbst bei kleinen Projekten sofort wieder Sinn, weil ich eben, weil ich sowieso gezwungen bin zu dokumentieren.

Dann kann ich mir eben Gedanken machen oder jeder Einzelne kann in sich brüten und sagen: „Wie, wie bring ich's dem anderen rüber?" Oder ich greif einfach auf was zurück, wo ich sage: „Da wissen alle, wie's zu lesen ist, und das kann einfach verwendet werden."

Wie geht's denn jetzt bei euch dreien, wenn ich den Timo damit einschließe, im Team weiter, gerade um CSS Doc? Also ihr habt 'ne Webseite, da ist das Ganze schon dokumentiert. Das werden wir auch noch verlinken. Wie geht's jetzt weiter bei euch?

Also ich bin grade drauf und dran, diesen ersten Public Draft, wo auch mal komplett alle Tags, die wir so weit erarbeitet haben, ja in einer Art Referenz Stück für Stück erläutert sind, auch mit Beispielen, dass das einmal fertiggestellt wird. Da gibt's auch Vorabversionen. Also es ist eigentlich recht offen gestaltet an der Prozess. Also man kann sich eigentlich angucken, was wir gerade machen. Also da gibt's immer mal wieder 'ne Veröffentlichung in Form von 'ner PDF.

Ist jetzt auch grade drauf gekommen oder halt in unserem Wiki, wo so'n paar Informationen, die gesammelt werden, hinzu getragen werden. Ja, und da gibt's diesen Draft und danach geht's so in Richtung Tools, würd ich mal so sagen.

Ja, also der Dirk hat durch diese Arbeit, dass er das mal komplett in YAML integriert hat, hat, ja, hat sehr viel, hat dem Projekt sehr viel noch mal beigetragen, weil YAML ist ein sehr großes CSS-Framework, was wirklich schon über 'ne längere Zeit gewachsen ist, wo Dokumentation auch Sinn macht. Also dass es nicht nur 'n Selbstzweck ist quasi. Das ist 'ne wirklich 'ne schöne Anwendung gewesen, um CSS Doc mal zu testen.

Ja, und, dass dieses Fazit, was wir daraus jetzt gezogen haben aus dieser Arbeit, haben wir auch noch 'n paar mehr Tests gemacht, dass das jetzt halt mal in so 'ner Art First Public Draft, heißt es so intern, publiziert wird, der dann mal die Version 1.0 haben soll und den man quasi rausgeben kann, auf den man sich als Standard beziehen kann oder als Entwurf für so 'n Standard beziehen kann.

Und dann kann man halt eben diese Tools-Varianten angehen, wie 'n Stripper, dass er das Zeug rauszieht oder halt von den IDEs, ja.

Also auf jeden Fall super Geschichte. Schön, dass ihr euch das annehmt und ich denke, spannend wird's obendrein. Dirk.

Ja, von mir aus dasselbe. Der Tom hat's gerade schon erwähnt. Er ist also gerade dabei, das Ganze mal wirklich zusammenzuschreiben und wirklich 'ne Erklärung, 'ne Erläuterung zu bringen, wie denn die Kommentare, die Tags wirklich anzuwenden sind, wo es denn macht, in welchem Kontext. Das ist so, wie ich jetzt gesehen habe, es steht 'ne aktuelle PDF, bei css-doc.net bereits zum Download zur Verfügung, wo man sich das ansehen kann. Wie gesagt, bei YAML ist es komplett drin.

Dort kann man sich einfach mal live anschauen, wie denn die Dateien kommentiert sind, wie das funktioniert. Was wir uns jetzt wünschen, ist eigentlich wirklich nur, dass Leute, die das, die der Meinung sind, das könnte sinnvoll für uns sein, das wirklich einfach mal ausprobieren, bei eigenen Projekten einsetzen. Ganz wichtig: wirklich Feedback geben, schreiben an den Tom, an den Timo, an mich. Wo klemmt's, wo knackt's?

Wo sind auch vor allen Dingen jetzt in der Spezi- Spezifikation, die der Tom gerade zusammenschreibt, wo gibt's Verständnisprobleme? Und wenn, wenn dieses Feedback da ist, dann kann man auf alle Fälle weiterarbeiten und kann das Ding rundschleifen, dass wirklich dort eine saubere Version 1.0 da rauskommt. Und damit ist es sehr viel einfacher, dann wirklich an Entwickler oder an Softwareentwickler ranzutreten, um dafür zu werben, dass es 'ne entsprechende Unterstützung auf Softwareseite gibt.

Mhm. Also ich würd-- mein persönliches Fazit: Ich bin sehr neugierig geworden, werd mir das auf jeden Fall anschauen. Ich bin ja bei einigen, die mich jetzt persönlich kennen oder meine Arbeitsweise kennen, ja ein regelrechter Freak, dass ich darauf achte, dass es wirklich sauber ist und sauber programmiert und sauber geschrieben und alles schön dokumentiert. Und genau in diese Kerbe, kommt ja auch das CSS Docs, sodass es mich da ein bisschen unterstützen kann.

Und wir fangen nächste Woche, an, Sam Note komplett neu aufzusetzen. Das wird wohl bis Ende des Jahres gehen und, ich schau mir das mal an und guck mal, ob wir das dann genau dort integrieren können. Also, auf jeden Fall 'ne spannende Geschichte.

Ja. Und wem's gefällt, auf alle Fälle drüber bloggen, kann ich nur sagen.

Genau, also die Links, die Links zur Sendung wird's auch noch geben. Ich hab noch drei Sachen, Technikwürze intern, die möchte ich noch kurz, bevor wir schließen, noch mitteilen. In der letzten Sendung hatte ich ja gesagt, die Technikwürze 100, das ist ja in drei Folgen so weit, die erscheint am 26.11. und die nehmen wir am 26.11. auch live beim Webmontag in Hannover mit auf. Wer also dabei sein möchte bei der Sendung, kommt bitte nach Hannover.

Die Infos, den Link zum Webmontag auch wieder auf Technikwürze.de. Das wird, glaube ich, sehr spannend, zumal's die erste Live-Sendung ist. Dann hatten wir noch, in der letzten Sendung wollten wir von euch Fragen haben für die hundertzweite Sendung. Die erscheint, ich muss gerade mal schauen, am 10.12. Da wird Technikwürze genau zwei Jahre alt.

Wenn ihr Fragen habt, sei es auch von CSS Doc irgendwas oder irgendwas, was ihr nicht verstanden habt oder das wollt ihr mal erörtert wissen, wir werden da ein Expertengespräch machen und dann werden wir eure Fragen, wenn sie in auditiver Form kommen, ansonsten werden wir sie vorlesen, werden wir dann beantworten. So, und eine dritte Geschichte habe ich jetzt noch: Der Sascha Postner macht ja gerade bei der Urban Challenge in den USA mit.

Das ist ja das, das werdet ihr in den Nachrichten sicherlich verfolgt haben oder vielleicht zufällig, wo diese Roboter da in diesen Autos rumfahren. Also diese Autos, da sitzt kein Mensch mehr drin, sondern, ist irgendwie so'n Wettbewerb von der, von der, ja sag schnell, von, von dem Militär in den USA. Die haben gesagt: „Pass auf, macht uns bitte 'n Auto, was irgendwie automatisch fahren kann in der Stadt." Da ist er mit dabei.

Und,, der Sascha nutzt das natürlich gleich mit dazu und macht ein persönliches Interview mit dem, Jakob Nielsen., 'n recht bekannter Mann eigentlich. Und wenn ihr Fragen habt für den Jakob, die der Sascha ihm stellen soll, dann schreibt uns die bitte an echo@technikwirtse.de oder haut was in den Kommentarbereich. Dann leite ich dem Sascha das in die USA und dann werdet ihr dann eure Fragen und die Antworten von dem Jakob dann in einer der nächsten Sendungen hören. Also soweit, meinerseits.

Ich bedanke mich, Dirk, dass du dabei warst. Auch Tom, vielen Dank an dich.

Ja, vielen Dank für die Einladung.

Ich sage danke fürs Zuhören und wir hören uns nächste Woche Montag wieder. Bis dahin, bye bye.