Jens Grochtdreis hat heute in seinem Weblog einen sehr langen, aber vor allem inhaltlich sehr tief gehenden Artikel zu den zahlreichen Grid-Frameworks veröffentlicht, die derzeit das Licht der Welt erblicken.  Der Artikel zeigt sehr deutlich, wo die eigentlichen Probleme der Grid-Frameworks liegen und woran sich die Kritik, mit der ich vollkommen übereinstimme, entzündet. Es ist weniger die Layoutform eines Grids ansich - problematisch ist vielmehr die technische Umsetzung.

Blueprint und alle davon abgeleiteten Projekte zerteilen das Layout nicht nur visuell in ein Zeilen- und Spaltenraster. Auch der daraus resultierende HTML-Quelltext sieht der Struktur einer HTML-Tabelle zum Verwechseln ähnlich und leidet letztlich auch an den gleichen Schwächen. Lediglich die verwendeten Tags (DIV statt TR und TD) haben sich geändert.

Aber ich will an dieser Stelle gar nicht vertiefend darauf eingehen. Den Artikel kann ich nur jedem empfehlen der meint, die aktuellen Grid-Frameworks seinen eine fortschrittliche Entwicklung. Jens freut sich aber nicht nur über Leser sondern auch auf eine fachliche Diskussion.

Ein halbes Jahr hat es gedauert, seit der letzten YAML-Version. Es ist schon erstaunlich, mein kleines Töchterchen hält mich ganz gekonnt und mit endlosem Charme immer wieder von YAML ab. Vollkommen egal, genau so soll es schließlich auch sein.

Seit gestern nun steht die Version 3.0.5 zum Download bereit, welche viele Kleinigkeiten in Ordnung bringt, die sich seit bereits seit längerer Zeit als unerledigte Dinge auf meinem Schreibtisch befinden. Parallel dazu wurden auch das Simple Project und der YAML Builder aktualisiert. Mit an Bord ist diesmal auch ein neues Layoutbeispiel “3col_fullheight”, bei dem sich die minimale Höhe des Layouts nach der Höhe des Viewports richtet. Ich habe für dieses Beispiel bewusst die neue Rubrik “special interest” eröffnet, denn obwohl diese Lösung hauptsächlich von CSS-Newbies im Forum angefragt wurde, richtet sie sich an erfahrenere Nutzer, denn der Aufbau des CSS ist dann doch etwas kniffliger als gewöhnlich.

Frohe Kunde erreichte mich am Wochenende auch mal wieder aus Görlitz. Michael Preuß hat “endlich” seine YAML-Config Serie mit dem “YAML Green Theme” eröffnet, weitere sollen folgen. Das besondere an diesen Themes ist dabei weniger die Optik sondern es sind vielmehr die umfangreichen Konfigurationsmöglichkeiten der Themes im Backend. Einerseits kann der User sich natürlich am CSS des Themes weiter austoben, auf der anderen Seite bietet das Theme im Wordpress-Backend einige sehr spannende Konfigurationsmöglichkeiten, womit man auch als unbedarfter Nutzer sein eigenes Layout zurechtbasteln kann. Wordpress-User: Unbedingt anschauen! Und wie selbstverständlich liefert Micha auch gleich noch ein kleines Tutorial-Video mit. Klasse - ich freue mich auf die Umsetzung deiner weiteren Ideen.

David kann es halt doch nicht lassen - zum Glück - und hat Jens Grochtdreis und mich zum Sonntag Mittag zu einer gemütlichen Plauderstunde für eine neue Technikwürze-Sendung eingeladen. Thematisch drehte sich die Sendung größtenteils jQuery, ich habe dazu ja schon etwas gebloggt. Ich habe zwei Buchempfehlungen beigesteuert und durfte in der neuen Schimpf-Ecke von Technikwürze meinen andauernden “Wir können Ihnen DSL an dieser Adresse leider nicht bereitstellen” Frust etwas abbauen.

Jens brachte im Anschluss der wiedermal 51 Minuten das Thema auf die aktuell wie Pilze aus dem Boden sprießenden Blueprint-Clones und hat mir damit aus der Seele geredet. Allein im Mai habe ich bisher 3 gezählt:

• BlueTripCSS
• Typogridphy
• GridEasy

Alles in allem reduzieren sich die Modifikationen auf geringfügige Anpassungen im Rahmen des persönlichen Geschmacks (Grid-Geometrie), dem Weglassen einiger Dinge oder der Kombination mit anderen Reset-Stylesheets (z.B. Tripoli). Ein alternativer logischer Ansatz für die Erstellung der Grids steht in keinem Fall dahinter. Und warum gerade wegen anderer Grid-Abstände jedesmal ein neues Framework veröffentlicht werden muss, erschließt sich mir nicht, für Blueprint gibt es einen Grid-CSS-Generator sowie vieles andere mehr. Warum das Rad zweimal erfinden?

Letzten Samstag habe ich auf dem Barcamp in Leipzig einen kleinen Vortrag zu CSS-Frameworks gehalten. Ich habe versucht zu beschreiben, was ein CSS Framework von herkömmlichen Layoutvorlagen unterscheidet und die meiner Meinung nach wichtigsten Vertreter YUI Grids, YAML und Blueprint etwas ausführlicher vorgestellt. Ich habe dabei die Gelegenheit genutzt, auch einige Vorurteile anzusprechen, die mit der Nutzung von CSS-Frameworks immer wieder verbunden werden. Meine Folien stehen bei SlideShare unter Creative Commons Lizenz bereit.

| View | Upload your own

Vielen Dank auch nachträglich nochmal an Oliver, meinem Retter aus Reihe 1, der mir kurzfristig sein Notebook für den Vortrag zur Verfügung gestellt hat. Mein eigenea Notebook wurde aus unerfindlichen Gründen über 15 Minuten lang von Skype vollständig blockiert. Ohne Skype und Murphy’s Gesetz wäre die Welt auch wirklich nicht halb so spannend.

Noch ein Wort zum Barcamp. Die Organisation war hervorragend und auch die Location fand ich ausgesprochen einladend. Als keinen Makel empfinde ich allerdings, dass bei 200 Anmeldungen am Samstag Vormittag gerade einmal die Hälfte den Weg zum MediaCampus gefunden hat. Schade ist das vor allem für diejenigen, die gern teilgenommen hätten, aufgrund der seit Wochen vollen Anmeldeliste es jedoch nicht konnten. Ich hoffe, dass sich dieses “mein Handtuch ist mein Platzhalter” Vorgehen nicht noch weiter um sich greift, denn dazu ist diese Veranstaltungsreihe zu schade und den Organisatoren macht man nur unnötig das Leben schwer.

Dieser Beitrag ist meinem Freund und Kollegen Ansgar  gewidmet.

#1 @charset

Über die @charset Regel kann optional die Kodierung einer CSS-Datei angegeben werden. Zur Auswahl stehen hier zahlreiche ISO-Kodierungen (z.B. ISO-8859-1), wie auch Unicode-Kodierungen (z.B. UTF-8). Bei der Anwendung gibt es jedoch zwei wichtige Regeln zu beachten:

1. @charset muss immer in der ersten Zeile eines Stylesheets stehen, andernfalls ignorieren Browser wie der Safari den kompletten Inhalt der Datei.
2. Es darf immer nur eine @charset Regel in einer Datei stehen. Andernfalls ignorieren einige Browser alle CSS-Regeln ab dem zweiten Auftreten von @charset.

Der zweite Punkt ist besonders wichtig, wenn verschiedene Stylesheets optimiert und zu einer Datei zusammengefasst werden sollen. Die wenigsten CSS-Optimierer beachten die @charset Regel, wodurch diese plötzlich mehrfach vorkommt der Browser das Stylesheet ignoriert.

#2 @import

Über die @import Regel lassen sich externe Stylesheets in ein anderes Stylesheet. Auf diese Weise lassen sich CSS-Deklaration sauber nach Funktionen in verschiedene Dateien zerlegen und unabhängig pflegen. Auch bei der Verwendung von @import gibt es einige Punkte zu beachten.

1. @import muss immer vor allen anderen Regeln stehen (ausgenommen @charset). Der Aufruf mehrerer @import-Regeln hintereinander ist möglich.
2. Innerhalb einer @media-Regel ist @import nicht zulässig. Das wäre eine Verletzung von Regel 1, weshalb Firefox, Safari, Opera und alle anderen modernen Browser die @import-Regel in diesem Fall ignorieren.
3. So verlockend die optionale Angabe des Ausgabemediums auch ist (z.B. @import (mein.css) screen,projection), der IE6 kommt mit den Ausgabemedien nicht klar und ignoriert das externe Stylesheet. Schade eigentlich, aber solange der IE6 in signifikanter Größenordnung genutzt wird, ist diese Option so gut wie unbrauchbar.

Speziell Punkt 3 hat mich vor wenigen Tagen wieder zur Verzweiflung getrieben. Manchmal denke ich, das Internet käme schneller voran, wenn Microsoft den IE8 einstampfen würde und stattdessen damit beginnen würde, das Verständnis für CSS2(.1) des IE6 auf ein annehmbares Niveau zu patchen. Denn dieser Browser klebt der Welt wie Sch**** am Schuh und will einfach nicht verschwinden und so wie Vista nicht XP verdrängt, wird es der IE8 vermutlich auch den IE6+7 nicht endgültig zur Strecke bringen.

#3 @media

Zum Abschluss noch ein paar Worte zur @media Regel, über welche der Wirkungsbereich von CSS-Deklarationen auf vordefinierte Medientypen beschränkt werden kann.

1. Einer der häufigsten Fehler in der Anwendung dieser Regel ist, dass die schließende geschweifte Klammer vergessen wird, denn die CSS-Eigenschaften jedes Selektors werden ebenso in geschweiften Klammern zusammengefasst. Im ungünstigsten Fall ignorieren Browser wie der Firefox daraufhin den kompletten Inhalt der Regel.
2. Vertrauen Sie nicht dem Medientyp handheld. Zwar wurde es speziell für mobile Geräte in den Standard CSS Mobile Profile 1.0 aufgenommen, doch bis heute wird er von kaum einem Gerät unterstützt. Auch für die Ausgabe auf Mobilgeräten kommt in der Regel der Medientyp screen zum Einsatz. 

Das war’s. Ich mach dann mal Feierabend.