Byteshift: Webdesign aus Berlin


was| wer| wo| details| english

Slashdot: Standardkonform umgearbeitet, Teil I
Autor: Daniel M. Frommelt
Alistapart Ausgabe: 164

{Teil I einer zweiteiligen Folge}

Fragen sie einen IT Experten, ob er Slashdots Motto kennt und er wird antworten "News for Nerds. Stuff that Matters." Slashdot ist eine sehr bekannte Site, aber unter der Haube finden sie eine betagte Maschine, die einen standardkonform arbeitenden Mechaniker gebrauchen könnte.

In diesem Artikel werden wir zeigen, wie eine Generalüberholung durchgeführt werden könnte - und zwar durch die Umwandlung einer einzelnen Slashdot Seite, ausgehend von ihrem jetzigen HTML 3.2 Quelltext, verschachtelten Tabellen sowie nicht validem und unsemantischen HTML in eine präzis eingestellten Rennmaschine. Nicht die Änderung von Slashdot ist das Ziel, sondern der standardkonforme Umbau und das Aufzeigen der sich ergebenden Vorteile.

Bevor sie in Panik geraten, weil ich Slashdot auf's Korn nehme, lassen sie sich gesagt sein, daß ich Rob "CmdrTaco" Malda, den Guru hinter Slashdot, um Erlaubnis bat, diese Informationen zu veröffentlichen, er schrieb mir folgendes per E-Mail:

Viel Spaß. Du kannst uns gerne Patches schicken, wenn dir irgendwas nützliches einfällt. Slashdots Quelltext ist Open Source und auf www.slashcode.com erhältlich.

Der Abriss

Wir begannen, indem wir eine Slashdot-Ausgabe am Dienstag dem 22ten Juli fixierten. Nachdem wir eine Kopie der Seite hatten, bestand der erste Schritt darin, alle nicht essentiellen Tags zu löschen. Was an Tags übrig blieb, waren Anker, Listen, Formulare, Grafiken, Skripten und die Informationen des Headers. Von dieser reduzierten Version ausgehend, wurde der Quelltext nach XHTML 1.0 konvertiert und validiert. An diesem Punkt sah die Seite wie ein Minenfeld von Links in einem Meer an Informationen aus. Sie ist valid, bietet aber keinen schönen Anblick, also weiter zum nächsten Schritt.

Der semantische Umbau

Bei der Sichtung des jetzt validen Quelltexts wurde klar, daß der Größteil der Informationen am besten als Listen darstellbar waren. Beispielsweise waren die Grafiken der Slashdot Kategorien einfach aneinandergereiht. Im Prinzip haben wir alles, was mehr als zweimal vorkam als Listen umgeschrieben, z.B: Login, Sections, Help, Stories, About, Services usw. Listen können von uns beliebig formatiert und positioniert werden - dadurch, das wir diese Elemente als Listen definiert haben, haben wir ihre Beziehungen untereinander beschrieben.

Die Header Tags waren der nächste Schritt. Die Seite hat viele Titel und Informationen, aber keine der Informationen war angemessen beschrieben oder was ihre Beziehung zu anderen Informations-Elementen der Seite betrifft, entsprechend gekennzeichnet. So gaben wir den Titeln der Artikel ein <h1>, den Informationen über die Autoren ein <h2>, das Department bekam ein <h3> und die "read more" Bereiche ein <h4>. Dies identifizierte nun eindeutig jeden Informationsbereich eines Artikels und beschrieb ihre Beziehung zueinander. Dann kam der leichte Schritt: Absätze zu erkennen und den Quelltext zu bereinigen.

Der Vorteil des sematischen Umbaus liegt darin, daß wir Tags dazu verwenden, wozu sie gedacht sind. Es ist offensichtlich, daß die Objekte einer Liste zusammen gehören und unter den Titeln gibt es eine hierarchische Ordnung. Ein weiterer Vorteil liegt darin, daß dies auch bei der Suchmaschinen-Optimierung hilft.

Überall CSS-Container

Wir haben jetzt eine durcheinandergewürfelte Masse von gutbeschriebener Informationen. Diese Informationen müßen gebündelt werden, sie zueinander in Beziehung setzend. Als Anfang wird jeder Artikel in einen <div class="node"> gesetzt. Nun gehören alle Informationen über einen Artikel zusammen und alle Artikel sind gleichgestellt - die Hierarchie wird durch die Reihenfolge im Quelltext festgelegt.

Als nächstes legen wir jede übrigbleibende Informationsgruppe eindeutig fest und kapseln sie jeweils in einem eigenen <div>. Z.B:

<div id="advertisement"> 
<div id="header"> 
<div id="leftcolumn"> 
<div id="centercolumn"> 
<div id="footer"> 

Wir setzen die Informationen in <div> Container um sie logisch gruppieren zu können, dies macht es leichter, sie zu formatieren. Das CSS kann nun jede Informationsgruppe einzeln ansprechen und ihr Attribute zuweisen, sowie Layout und Design. Dies ist nicht unbedingt semantisch, aber für die Präsentation notwendig. Hier ist das semantisch geordnete Beispiel. Es gibt noch kein CSS Layout; es ist noch nur strukturiertes HTML.

Die Rekonstruktion des Skeletts

Jetzt, wo jede Informationsgruppe durch ein <div> gekennzeichnet ist, wird die Seite mit CSS formatiert, so daß das Design dem alten "Look and Feel" angeglichen wird. Dazu braucht es Zeit, Geduld und Übung. Das erste Ziel besteht nicht darin, die alte Site zu imitieren, sondern die Seiten-Elemente korrekt im Rahmen des dreispaltigen Formats zu positionieren, dazu ein Titel- und Fußzeilenbereich für die ganze Seite. Dies wird die erste CSS Datei: layout.css

Eine Seite mit einer einzigen CSS Datei zu positionieren hat einen einfachen Vorteil: sie wissen, wo sie nachsehen müßen, wenn es ein Positionierungsproblem gibt. Die meisten Probleme treten im Zusammenhang mit der Positionierung auf. Bei diesem Schritt bedachten wir, wie sich die Seite in verschiedenen Browsern verhalten würde, deswegen entschieden wir uns, die @import Direktive zu verwenden, da dann die Browser, die sie nicht unterstützen, kein Layout bekommen. Dazu zählen Handys mit Webfähigem Display, PDAs, alte Browser und andere Clients. Hier ist die Seite mit umgesetzter CSS Positionierung.

Neue Kleider

Jetzt zeigt die Seite das richtige Layout, aber sie sieht noch nicht aus wie Slashdot. markup.css ist die zweite externe CSS Datei, sie enthält Angaben über Schriftarten, Farben, Hintergrundgrafiken und die Art und Weise, wie Listen angezeigt werden. Hier ist das endgültige Beispiel.

Wir haben auch die Möglichkeit, ein zweites Layout hinzuzufügen, sollten wir dem Betrachter eine Alternative zur Darstellung der Seite geben wollen. Das zweite Layout muß nicht alle Layout-Informationen duplizieren, diese sollten bereits von layout.css im Cache sein.

Die CSS Referenz

Um den Umbau zu vollenden, müßen wir die CSS Dateien im Header referenzieren.

<link rel="stylesheet" type="text/css" href="styles/layout.css" media='screen' />
<style type="text/css"> @import "styles/markup.css"; </style>

In diesem Beispiel wird layout.css über den Medientyp "screen" verlinkt. Die enthaltenen Information ist nur für die Bildschirmanzeige wichtig, für gedruckte Medientypen ist sie nutzlos, auch für alle anderen (aural,tv,braille, etc.), wo wir schon dabei sind. Die Datei markup.css - sie stellt die "Haut" der Seite dar - wird importiert; so bleibt sie nicht standardkonformen Clients verborgen, denn einige ihrer Angaben konnten der Darstellung abträglich sein oder zu Fehlinterpretationen führen.

Die Vorteile!

Die Seite wird nun in standardkonformen Browsern richtig dargestellt, wie auch schon zuvor - in nicht standardkonformen Browsern wird sie im Sinne der "gracefull degradation" ohne CSS angezeigt. So ist ihr Inhalt auch deren Benutzern zugänglich, auch wenn die Darstellung nicht so schön ist. Der Inhalt wird auch in "Screen Readern" sauberer und mit besser vorhersagbaren Ergebnis angezeigt. Da das CSS ggfls. nicht zur Anwendung kommt, ist der Inhalt sogar PDAs oder webfähigen Handys zugänglich. Zu guter letzt gibt es auch -nur über CSS- eine druckerfreundliche Version (ohne separate "druckerfreundliche" Seite). Möglicherweise ist der größte Vorteil speziell dieser Seite die Bandbreitenersparnis:

Ersparnis der Seite ohne dem Caching der CSS Datei: ~2KB pro Request

Ersparnis der Seite mit dem Caching der CSS Datei: ~9KB pro Request

Auch wenn ein paar KB nicht nach viel Bandbreite klingen, lassen sie uns daß mal zusammenrechnen. Slashdots FAQ zufolge, zuletzt am 13 Juni 2000 aktualisiert, werden pro Monat 50 Millionen Seitenabrufe beantwortet. Heruntergerechnet sind das ~1.612.900 Seiten pro Tag oder ~18 Seiten pro Sekunde. Dies sind die Bandbreitenersparnisse:

Ersparnis der Seite ohne dem Caching der CSS Datei: ~3.15 GB pro Request

Ersparnis der Seite mit dem Caching der CSS Datei: ~14 GB pro Request

Die meisten Besucher werden die CSS Dateien im Cache vorrätig haben, so daß man grob mit ~10 GB Bandbreitenersparnis rechnen kann. Ein größeres Bandbreitenvolumen eines ISP kann irgend etwas zwischen 1$ - 5$ pro übertragenem GB kosten, aber lassen sie uns annehmen, daß es für das ganze Jahr durchgängig 1$ pro GB sei. Mit diesem Beispiel betrüge die jährliche Kostenersparnis für Slashdot: 3.650$!

Bedenken sie, daß diese Berechnung auf der Anzahl der Seitenabrufe vom 13ten Juni 2000 basiert. Ich nehme an, daß Slashdot Traffic heute wesentlich größer ist, aber auch mit diesen drei Jahre alten Zahlen ist die Ersparnis beeindruckend.

Das bisher Erklärte wird von der Universität von Wisconsin detaillierter geschildert - Platteville's Slashdot Web Standards example site.

Die Herausforderung

Ich fordere jetzt die ALA Community heraus. Wir brauchen jetzt einen fähigen, standardkonform arbeitenden Mechaniker (oder ein Team von Mechanikern), der sich durch die Slashdot Maschine, Slashcode, kämpft, um sie standardkonform umzuarbeiten. CmdrTaco hat uns ermutigt, Patches einzusenden und ich weiß, daß wir die Vorteile darlegen können! Die Herausforderung ist da - nimmt sie jemand an?

Das nächste Mal: Ein druckerfreundliches und handheldfreundliches Slashdot durch einige einfache Ergänzungen.


Daniel M. Frommelt ist der "University World Wide Web Coordinator" der University of Wisconsin - Platteville, ein leitendes Mitglied des Campus Web Council of Wisconsin und ein Verfechter von standardkonformen Webdesign. Daniel verbringt seine Freizeit mit der Bierbrauerei.

Originaladresse: www.alistapart.com/articles/slashdot/
Alistapart Diskussionsforum (englisch): www.alistapart.com/discuss/slashdot/

Translated with the permission of A List Apart Magazine and the author[s].

Wichtige Links zum Thema Web Design und Typographie

Valid XHTML 1.0! Valid CSS!