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 |
---|---|---|---|---|
<div> | 244 Pixel | 488 Pixel | 732 Pixel | 976 Pixel |
<ul> | 224 Pixel | 488 Pixel | 732 Pixel | 976 Pixel |
<li> | 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:
<div id="lastComments"> <h5>Letzte Kommentare</h5> <ul> <li>...</li> </ul> </div>
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.
3 Kommentare
Für diesen Eintrag wurden die Kommentare geschlossen.
global $hemingway ?>Naja… ich hab Microformate auch die Tage entdeckt und würde das mal spontan als (X)HTML-Hack bezeichnen. Warum? Die relevante Spezifikation von (X)HTML des W3C sagt weit weniger über die Inhalte dieser Attribute aus, als die Microformate. Microformate schränken soz. die funktionale Validität des Dokumentes weiter ein und kommen zudem nicht vom W3C. Aber anyway… fine for me.
Am Ende des Tages bleibt die Einsicht, dass HTML eigentlich völlig unzureichend für semantische Auszeichnung ist, und für typographische Gestaltung erst recht. Das ist ziemlich schlimm eigentlich, weil das ja die beiden Aufgaben sind, die HTML erfüllen soll. Bleibt die Frage, wie beheben wir diese Fehler. Microfromate sind ein möglicher Weg. Ergänzung von HTML durch flexibleres Markup (RDF oder XHMTL-Module) ein möglicher anderer.
Was ich aber bevorzugen würde, und deshalb war ich ja auch von deinem Raster-Tutorial so begeistert, ist in der Tat ein xmlbasiertes Zwischenformat, das nochmal zwischen HTML (oder docbook, oder was auch immer) und der Präsentation geschoben wird, und das ein strukturierte Beschreibung der gaphischen Gestalt erlaubt.
Ich glaube auch, dass Microformate eine relevante Rolle spielen werden. Dennoch ist es nicht gerade ein „großer Wurf“, sondern eher eine nette Zusatzfunktion. Mein Vorreder hat da recht 😉 – eigentlich reicht da HTML schon gar nicht mehr aus. Ich bemerke gerade, wie mehr und mehr RSS feeds mit Stylesheets versehen werden. Die Möglichkeiten die XML birgt, sind ja nahezu unbegrenzt….Google wertet Webseiten schon lange nicht mehr nach HTML tags aus, sondern nach reinem Textinhalt. Doch denke ich dass mit Wachsen der Blogosphäre, mehr und mehr Augenmerk auf Dienste wie Technorati und Digg gerichtet wird. Automatisierte Blogspider werden es einfacher haben, die Informationen durch semantische Strukturierung zu verwerten und zu speichern, klar. Aber der Nachteil kann auch sein, dass viele Spammer, sollten Microformats wirklich erfolgreich werden, irgendwann ebenfalls „auf den Zug aufspringen“ und dadurch das ganze Grundprinzip wieder aushebeln.
Google wertet Webseiten schon lange nicht mehr nach HTML tags aus, sondern nach reinem Textinhalt.
Das stimmt so auch nicht 100%ig, denn valide Seiten werden bei gleichen Inhalten von Google bevorzugt. Diese Seite hier bekommt Unmengen Google Hits zu World-of-Wacraft-Suchen, nicht weil ich die exakten Antworten auf die Suchanfragen habe, sondern weil viele WoW-Seiten furchtbar schlecht strukturiert sind. Ganz frisch ist nun auch Googles Versuch zugängliche Seiten speziell heraus zu heben.
http://labs.google.com/accessible/
Man stelle sich vor Google würde von nun an nur noch diesen Mechanismus nutzen. Mehr als 90% aller Seiten würden sofort ignoriert werden.