CSS-Microformats – Trennung von Form, Form, Form und Inhalt

Diesmal gibt es ein kleines Vorwort. Der folgende Text hat sich in Minuten vom absoluten Krampf, zu einem Eintrag entwickelt, der die Veröffentlichung hoffentlich wert ist. Ich bitte daher zu entschuldigen, wenn sich das Ganze noch sehr sinnentleert liest, dieser Text war lange Zeit ohne echte Substanz, da ich kein Freund von zu viel Sorgfalt beim Bloggen bin, geht das hier so ungefärbt online. Das ist also mal ein Schnellschuss zum Ende der Woche.

Ich habe die HTML Struktur dieser Version, mal zur Abwechslung mit größerer Sorgfalt angelegt. Waren die früheren Versuche noch Markups, jeweils für die individuelle Version, so hoffe ich diesmal eine länger haltbare Basis gefunden zu haben. Ich möchte versuchen, das Ganze am Beispiel zu erklären. Auch wenn es nun mittlerweile Standard geworden ist Form und Inhalt zu trennen, so gibt es auch dafür, mehr als eine Möglichkeit der Umsetzung.

Ich weiß selbst noch nicht genau, ob der Text den Eintrag wert ist. Vielleicht ist es die Fortsetzung der Raster-Tutorials, vielleicht auch nicht. Die Geschichte dahinter liest sich wie folgt: ich komme immer wieder in die Situation, bei der ich unsicher bin, auf welches HTML-Element, die später zu formatierende CSS-Klasse oder ID gehört. Wo ist diese ID nun logischer? Bei welcher Lösung habe ich später mehr Möglichkeiten? Die Antwort auf alle Fragen, beantwortet mir meist der Quellcode dieser Startseite hier. Ich denke hier eine relative flexible HTML/CSS-Struktur gefunden zu haben, die sich auch gut skalieren lässt und nicht nur für so ein paar Inhaltseiten funktioniert.

Wer die Entwicklung dieser Gestaltung von Anfang an verfolgt hat, wird mitbekommen haben, wie oft und schnell ich die vielen Listen auf der Startseite neu angeordnet habe. Genau das begründet sich auf der Markup-Struktur der Seite, in Kombination mit einer sehr effizienten Verteilung von CSS-IDs und Klassen. Ich mag es schnell auch kompliziertere Elemente neu positionieren zu können, auch deshalb wurde diese Listen speziell dafür optimiert, besonders in Hinsicht auf ihre Struktur Markup.

Praxis

Grundlage für die Arbeit am Quellcode dieser Seite, war wie auch bei der Gestaltung, das Grundraster. Folgende Tabelle ist erste Anlaufstelle, wenn ich ein neues inhaltliches Element in die Seite integrieren möchte.

HTML-Tag | 1 Spalte | 2 Spalten | 3 Spalten | 4 Spalten
| 244 Pixel | 488 Pixel | 732 Pixel | 976 Pixel
| 224 Pixel | 488 Pixel | 732 Pixel | 976 Pixel
| 204 Pixel | 204 Pixel | 204 Pixel | 204 Pixel

Hier zu sehen, Kenndaten um Elemente auf dem Raster zu positionieren. Diese Tabelle beinhaltet alle wichtigen Größen um alle Spalten des Raster abdecken zu können. In weiser Voraussicht, existieren auch schon Werte für eine mögliche 4-Spalten Version, bei einer 1024 Pixel breite Darstellung.

Alles noch recht unspektakulär, aber diese kleine Tabelle beinhaltet alles was notwendig ist um schnell, einfach und pixelgenau die Listen neu anzuordnen. Es ist problemlos möglich alle nur erdenklichen Listenformate, auf dieses Raster zu bringen. Wer sich etwas mehr umschaut, wird auch sehen, dass die Listen hier und da in ein anderes Format wechseln und das mit ganz geringem Aufwand. Ein Ausschnitt des Quellcodes zeigt diesen Aufbau:


Letzte Kommentare

...



An dieser Stelle die erste Überlegung. Wäre es nicht vielleicht sinnvoller, der Liste die ID zu geben und nicht extra dafür eine DIV anzulegen? Nun ja eigentlich wär dies die Puristen-Lösung, für all jene, die jedes zusätzliche DIV-Element meiden, wie Vampire das Licht. Zwar gehöre auch ich zu den sehr nihilistischen HTML-Codern, aber für meine Seite ist diese Lösung perfekt. Warum?

ein kleiner Schritt zurück

Ein Blick zurück in den zweiten Teil des Raster-Tutorials. Eine Aussage dieses Textes ist, dass ich jedes Element auch auf dieses Raster passend, floaten lassen kann. Mit dieser Erkenntnis sind nun alle Listen auf dieser Seite gleich formatiert: alles fließt und passt. Jede Liste hat ihr eigenes mit einer ID versehenen DIVs. Nun braucht man sich, beim Blick auf das Stylesheet dieser Seite, nicht mehr über solche ellenlangen Aufzählungen wundern:

/* globale Listenformate
=========================================== */
#lastComments,
#last10,
#qlinks,
#adverts,
#archive,
#themed,
#footcategory,
#prenextBottom,
#mostComments,
.sideDetail,
.side-caption {
width:244px;
float:left;
margin-left:0;
display:inline;
}

#lastComments ul,
#qlinks ul,
#last10 ul,
#archive ul,
#themed ul,
#footcategory ul,
#mostComments ul {
padding:0;
list-style-type:none;
margin:0;
width:224px;
float:left;
display:inline;
}

#lastComments ul li,
#last10 ul li,
#qlinks ul li,
#archive ul li,
#themed ul li,
#footcategory ul li,
#mostComments ul li {
font-size:90%;
margin-left:20px;
width:206px;
float:left;
display:inline;
padding-left:18px;
}

Hier passieren nur ganz grundsätzliche Sachen, nichts Spannendes. Dennoch sieht man hier die Grundlage für jede Liste dieser Seite. Die DIVs dienen mir nun ausschließlich dazu, die Listen hin und her zu schieben und ihre Layout zu verändern. Man kann drüber streiten, ob es der Logik entspricht, Element so indirekt zu formatieren, denn ich definiere diese Listen primär über ihren Container und führe so einen einen gewissen Teil überflüssigen CSS-Code mit. Die separaten Anpassungen der jeweiligen Liste, überschreiben nämlich die oben dargestellten Formate. Wenn die Archivlisten plötzlich über 3 Spalten fließen sollen, muss ich die Breiten ändern:

#archive,
#archive ul {
width:732px;
}

Dennoch hat es mehr Vorteile als Nachteile, vorher eine globale Formatierung vorzunehmen und diese dann individuell anzupassen. Selbst ohne die individuellen Formate, sitzen diese Elemente perfekt auf dem Raster und durch diese Struktur ist der Aufwand viel geringer Änderungen vorzunehmen.

Wer sich die Raster-Tutorials durchgelesen hat, wird feststellen, dass ich für Floats auf einem Raster, Probleme ergeben können. Dies ist auch hier der Fall. Ich werde nun nicht im Detail aufzeigen wo, wie und was auch hier schief läuft. Man soll ja immer seine Schokoladenseite offenbaren und nicht die dreckigen Ecken. Nur soviel, hier und da kommt mal ein Spaltenzwischenraum hinzu und muss mal wieder vom der Floatbreite subtrahiert werden. Wer sich die Tabelle oben anschaut erkennt schon das Problem, auch hierbei helfen mir die zusätzlichen DIV-Elemente.

Stylesheet Format

Es gibt zweifellos die Möglichkeit diese jetzige Code-Struktur effektiver anzuordnen. Auch hier bin ich nicht auf der Jagd nach einzusparenden Bytes, sondern nach Logik und Handling, wie es so schon neudeutsch heißt. Ich weiß wie gern ich kleine Veränderungen benutze, also lege ich diese Seite auch darauf an.

Sicherlich wäre es platzsparender statt:

#lastComments ul,
#qlinks ul,
#last10 ul,
#archive ul,
#themed ul,
#footcategory ul,
#mostComments ul {
....
}

eine neue alles beinhaltende DIV zu generieren und dann ganz einfach so zu stylen:

#ganzNeueDIV ul {
....
}

Um das Ganze noch dynamischer zu machen wären IDs und Klassen auf den Listen an sich ebenfalls vorstellbar. So könnte ich das absolut gleiche Ergebnis, mit weniger Code erzielen:

#ganzNeueDIV ul#lastComments {
....
}

Dennoch bleibe ich bei der jetzigen Variante, die auf den ersten Blick aufgeblähter und weniger optimiert wirkt, aber auf den zweiten Blick und spätestens beim Redesign ihre vollen Stärken offenbart. Ich sehe immer wieder Beispiele (ich werd mich hüten Links zu setzen, zu viele Referer-Dramen in der letzten Zeit), wo durchaus ansprechende Gestaltung präsentiert wird, das Ganze jedoch auf wenig dynamischen Code-Strukturen basierend. CSS ID und Klassen-Monster, die zu Handhaben es einen wahren Zeichendeuter braucht. Ich verstehe dabei natürliche den Sinn bei Auftragsarbeiten, leichter als durch wenig transparente und komplexe Code-Strukturen, kann man den Kunden nicht an sich binden.

CSS + Microformats = CSS-Microformats?

Zwar erscheint in jedem zweitem meiner Texte, der große Hammer mit der Aufschrift „Weniger ist mehr!“, aber wie man sieht, kann etwas mehr manchmal doch auch seine Vorteile haben. Ich hab mich die letzten Wochen verstärkt mit Mikroformaten beschäftigt, eine höchst interessante Angelegenheit und mit Sicherheit der nächste große Zug, auf den viele aufspringen werden. Für alle die nicht wissen was Mikroformate sind, versuche ich es kurz zu erläutern.

Microformats are markup that allow expression of semantics in an HTML (or XHTML) web page. Programs can extract meaning from a standard web page that is marked up with microformats.

Existing XHTML (and HTML) standards allow for semantics to be embedded and encoded within them. This is done using specific HTML attributes:

class

rel

rev

Adding microformats to a standard HTML web page allows machines to process HTML text and to possibly load data into remote databases. This would allow programs such as web crawlers to find items such as contact information, events, and reviews on web pages.

Man stelle sich eine neue Norm vor, die vorschreibt wie man Informationen innerhalb zu strukturieren hat. Diese Norm sind Mikroformate. Vorteil dabei? Informationen werden universell und denoch zugänglicher. Beispiel: wenn ich eine heute bei Google nach einer CD Kritik suche, gebe ich meist den Interpreten, den Titel und das englische Wort für Rezension „Review“ ein. In vielen Fällen kommt dabei Unbrauchbares zu Tage. Nun gibt es genau dafür schon ein Review-Mikroformat, welches mit absoluter Sicherheit bessere Suchergebnisse liefern würde als Google, sofern ein Microformats-Google existieren würde.

div#reviews ul, ul#reviews, ul li.reviews, ul li a.reviews …

Im gewissen Rahmen habe ich kleine Mikroformate, so genannte Nanoformate /joke, für den CSS-Code dieser Seite geschaffen, mit eben den gleichen Vorteilen wie bei Mikroformaten. Ich muss nicht schauen welche ID, welche Klasse oder wie der Code an dieser Stelle ist. Es gibt ein festes CSS-Format, welches mir die Arbeit ungemein erleichtert. CSS Stylesheets können schon heute unglaublich komplex werden und mit Sicht auf CSS-3, wird sich das auch nicht mehr ändern. Zeit darüber nachzudenken auch hier feste Formate zu entwickeln? Ich für meine Arbeiten beantworte diese Frage mit ja. Für viele mag dieser „Ansatz“ trivial sein, für mich ist er relativ neu und die Überlegung wert, sorgfältig weiter entwickelt zu werden.