Den Anfang macht das HTML-Grundgerüst, das hier aufs nötigste reduziert wurde. Ein div-Element kapselt dabei die Bewertung, während fünf Links die einzelnen Bewertungen darstellen – diese können später auf das Rating-Script verlinken oder eine JavaScript-Funktion aufrufen. Das soll aber nicht Gegenstand dieses Tutorials sein.

<div class="rating">
	<a href="#" class="rate1">1</a>
	<a href="#" class="rate2">2</a>
	<a href="#" class="rate3">3</a>
	<a href="#" class="rate4">4</a>
	<a href="#" class="rate5">5</a>
</div>

Die Ziffern in den Links stellen die Bewertung dar, eine eins ist dabei das schlechteste, fünf die beste Bewertung. Ohne CSS sieht das ganze noch recht trostlos aus, da die Links alle einfach hintereinander aufgeführt sind – den Anblick können wir uns sparen. Kommen wir also zu unserem Plan: Die Bewertung soll im ursprünglichen Zustand fünf Kreise anzeigen, die sich nur schwach vom Hintergrund abheben. Fährt man mit der Maus über einen dieser Kreise, so wird dieser und alle links davon liegenden farbig hervorgehoben und damit wird die Bewertung dargestellt. Die Ziffern selber sollen nicht sichtbar sein. Bevor wir uns aber Gedanken um die Grafik machen, vereinfachen wir die Darstellung, indem wir einfach nur unterschiedliche Hintergrundfarben wählen, um die Zustände anzuzeigen.

Wir konzentrieren uns also erstmal auf das Konzept. Die Idee dahinter ist, dass die Links übereinander liegen und sich damit teilweise verdecken. Der erste Link ist gerade so breit, dass ein Kreis auf ihm Platz hätte, der letzte nimmt die volle Breite ein (fünf Kreise) und der Rest liegt dazwischen. Gleichzeitig sind die Links der Breite nach sortiert, so dass der erste (und schmalste) ganz oben auf liegt, während der letzte auch der unterste ist. Da dieser aber auch der breiteste ist, gibt es einen schmalen Bereich, der anklickbar ist. Zur Verdeutlichung des eben Beschriebenen habe ich ein kleines Bild gebastelt:

Schematische Darstellung der Link-Ebenen

Der CSS-Code, der dafür nötig ist, hält sich in Grenzen:

.rating {
	position: relative;
	width: 100px;
	height: 20px;
	border: 1px solid #ccc;
	background: #eee;
}

.rating a {
	position: absolute;
	height: 20px;
	text-indent: -9000px;
}

.rating a:hover {
	background: #cdf;
}

.rating .rate1 {
	width: 20px;
	z-index: 5;
}

.rating .rate2 {
	width: 40px;
	z-index: 4;
}

.rating .rate3 {
	width: 60px;
	z-index: 3;
}

.rating .rate4 {
	width: 80px;
	z-index: 2;
}

.rating .rate5 {
	width: 100px;
	z-index: 1;
}

Zuerst wird die Breite und Höhe des gesamten Ratings festgelegt. Pro Kreis ist ein Platz von 20 x 20 Pixeln vorgesehen, so dass die Gesamtbewertung 100 Pixel breit ist. Durch Rahmen und Hintergrundfarbe wird sie erstmal sichtbar gemacht. Außerdem wird eine relative Positionierung angegeben, denn damit beziehen sich absolut positionierte Elemente im Inneren auf das äußere div und nicht auf das Browserfenster. Damit die Links nun auch wirklich übereinander liegen und sich verdecken, müssen sie absolut positioniert werden. Außerdem bekommen sie noch eine Höhe und der enthaltene Text wird weit nach links aus dem sichtbaren Bereich hinausgeschoben, damit die Zahlen später nicht im Weg sind. Beim Überfahren mit der Maus soll sich einfach nur der Hintergrund des jeweiligen Links ändern.

Anschließend wird noch jedem der fünf Links ein eigener Style gegeben. Durch die absolute Positionierung befinden sie sich alle am linken Rand des Ratings, da wir nichts anderes angeben. Die Breite bestimmt, wie weit der Link nach rechts ragt, der z-index bestimmt die Ebene – je niedriger, desto weiter unten (auf der z-Achse) ist das Element. Beim letzten Link ist also ganz rechts ein 20 x 20 Pixel großer Bereich anklickbar, die restlichen 80 Pixel werden von den darüber liegenden Links verdeckt. So ändert sich der Hintergrund des gesamten Ratings, obwohl der Link für den Anwender scheinbar nur sehr schmal ist. Das bisherige Ergebnis zeigt, dass das Prinzip funktioniert.

Nun wollen wir auch die Grafik ins Spiel bringen. Diese ist recht klein – nämlich so breit, wie ein Link, dafür doppelt so hoch, da sie beide Zustände des Kreises beinhaltet. Oben der farblose Kreis, unten der hervorgehobene:

Rating-Grafik

Nun verwenden wir statt der Hintergrundfarbe diese Grafik, die zu ändernden Stellen habe ich hier nur hervorgehoben, der Rest stimmt mit dem eben gezeigten CSS-Code überein:

.rating {
	position: relative;
	width: 100px;
	height: 20px;
	border: 1px solid #ccc;
	background: url(circle.png) top left repeat-x;
}

.rating a {
	position: absolute;
	height: 20px;
	text-indent: -9000px;
}

.rating a:hover {
	background: url(circle.png) bottom left repeat-x;
}

.rating .rate1 {
	width: 20px;
	z-index: 5;
}

.rating .rate2 {
	width: 40px;
	z-index: 4;
}

.rating .rate3 {
	width: 60px;
	z-index: 3;
}

.rating .rate4 {
	width: 80px;
	z-index: 2;
}

.rating .rate5 {
	width: 100px;
	z-index: 1;
}

Der Hintergrund ändert sich dadurch, dass die selbe Grafik verschoben angezeigt wird. Dadurch wird vermieden, dass erst beim Überfahren mit der Maus ein weiteres Bild mit dem anderen Zustand geladen werden muss und dieses stattdessen sofort erscheint. Das Ergebnis lässt sich schon sehen, aber wir wollen mehr. Neben der Anzeige der Kreise wollen wir jetzt auch noch einen kurzen beschreibenden Text anzeigen, der dem Nutzer vermitteln soll, was die Bewertung, die er abgibt, eigentlich bedeutet. In unserem Beispiel sollen das in aufsteigender Reihenfolge die Texte “Mangelhaft”, “Ausreichend”, “Befriedigend”, “Gut” und “Sehr gut” sein. In unserem HTML-Code werden also die Ziffern durch die entsprechenden Texte ausgetauscht:

<div class="rating">
	<a href="#" class="rate1"><span>Mangelhaft</span></a>
	<a href="#" class="rate2"><span>Ausreichend</span></a>
	<a href="#" class="rate3"><span>Befriedigend</span></a>
	<a href="#" class="rate4"><span>Gut</span></a>
	<a href="#" class="rate5"><span>Sehr gut</span></a>
</div>

Die zusätzliche Kapselung in das span-Element ist in unserem Fall nötig, um den erhofften Effekt zu erzielen. Dieses Element wird, ebenfalls mittels absoluter Positionierung, nach rechts außerhalb der Links verschoben. Hier wieder das komplette Beispiel mit den hervorgehobenen nötigen Änderungen:

.rating {
	position: relative;
	width: 100px;
	height: 20px;
	border: 1px solid #ccc;
	background: url(circle.gif) top left repeat-x;
}

.rating a {
	position: absolute;
	height: 20px;
	text-decoration: none;
}

.rating a span {
	position: absolute;
	left: 105px;
	line-height: 20px;
	font-size: 12px;
	color: #999;
	white-space: nowrap;
	visibility: hidden;
}

.rating a:hover {
	background: url(circle.gif) bottom left repeat-x;
}

.rating a:hover span {
	visibility: visible;
}

.rating .rate1 {
	width: 20px;
	z-index: 5;
}

.rating .rate2 {
	width: 40px;
	z-index: 4;
}

.rating .rate3 {
	width: 60px;
	z-index: 3;
}

.rating .rate4 {
	width: 80px;
	z-index: 2;
}

.rating .rate5 {
	width: 100px;
	z-index: 1;
}

Im ursprünglichen Zustand ist der Text unsichtbar, erst beim Überfahren mit der Maus ist er zu sehen. Durch die eingestellte Zeilenhöhe wird der Text passend zu den Kreisen in der Höhe zentriert und das white-space: nowrap; sorgt dafür, dass Worte nicht umgebrochen werden. Ohne diese Anweisung stünde bei der besten Bewertung dank Zeilenumbruch das “gut” unter dem “sehr”. Damit haben wir uns nun auch das Endergebnis erarbeitet und sind fertig. Die fertigen Beispiele könnt ihr euch als Zip-Archiv herunterladen.

Doch das änderte sich mit der Zeit. CSS wurde wichtiger und ersetzte erst nur einige font-Tags und avancierte immer mehr zum Spiel- und Werkzeug der Webdesigner; mit der Zeit wurden Tabellenlayouts verdrängt. Heute sind sie zumeist sogar verpöhnt, weil (X)HTML als semantische Auszeichnungssprache auch semantisch korrekt benutzt werden will. So oder ähnlich wird zumindest argumentiert. Doch nicht zuletzt ist es nun der Internet Explorer, der vielen Entwicklern beim Umsetzen von CSS-Layouts Kopfschmerzen bereitet – insbesondere dann, wenn man erstmalig damit konfrontiert wird. Wären Tabellen nicht einfacher?

Heutzutage findet man im Internet unzählige Tutorials, die einem den Umgang und verschiedene Tricks mit CSS erklären. Von Tabellenlayouts hört und sieht man nichts. Ein Hinweis dafür, dass CSS viel zu kompliziert ist und Erklärung benötigt? So sieht es jedenfalls Ron Garett, der erklärt, wieso seiner Meinung nach CSS nicht für Layout benutzt werden sollte. Seine Gründe: Mit CSS kann man Elemente nur relativ zu ihren Containern positionieren, nicht zu (beliebigen) anderen Elementen und HTML-Code und Stylesheet sind nicht untrennbar und immer in irgendeiner Art und Weise voneinander abhängig.

Damit mag er zum Teil auch Recht haben. Wenn man etwas kompliziertere Layouts umsetzen will, wird man hin und wieder nicht drumrum kommen, Wrapper-Elemente oder semantisch bedeutungslose Konstrukte einzubauen. Und will man (achtung, absurdes Beispiel) den Titel der Webseite plötzlich nicht mehr im Header, sondern unter dem Footer anzeigen, so wird man, solang man keine abenteuerlichen Sachen mit absoluter Positionierung anstellt, die HTML-Struktur wohl ändern müssen. Von einer 100%igen Trennung von Inhalt und Gestaltung kann also keine Rede sein. Aber ist das auch ein Argument für Tabellen? Wohl kaum, denn die Abhängigkeit, die ja unerwünscht ist, ist in dem Fall ja noch viel stärker ausgeprägt. Mal eben die Anordnung von Zeilen oder Zellen zu ändern, ist ohne Tricksereien mit CSS nicht möglich, stellt also auch keinen Vorteil dar.

Weiterhin versucht Ron, seine Argumente mit einem Beispiel zu verdeutlichen. Er baut ein einfaches Drei-Spalten-Layout auf und erklärt, dass der Inhaltsbereich, der in der Mitte zu sehen ist, auch im HTML-Code zwischen linker und rechter Spalte auftauchen sollte. Also tauscht er einfach zwei Spalten und siehe da, das CSS-Layout wird zerschossen. Aber was ist das denn für eine Begründung? Mit CSS ist es möglich, die Spalten in einer beliebigen Reihenfolge im Code anzuordnen, um die Inhalte so für Screenreader (blinder Menschen) oder Suchmaschinen zugänglicher zu machen, während man sich mit Tabellen doch viel mehr festlegt. Mal ganz abgesehen davon, dass Screenreader bei einer Tabelle auch tabellarische Daten erwarten und entsprechend die Barrierefreiheit in Frage gestellt wird.

Weitere Unzulänglichkeiten sieht er darin, dass sich benachbarte Elemente nicht gleichmäßig in der Höhe ausdehnen und sie allgemein zu unflexibel sind. Letzteres lässt sich mit gescheitem CSS durchaus bekämpfen, während das Argument der gleichen Höhen aber nicht ganz aus der Luft gegriffen ist, denn dafür gibt es viele teils unzulängliche oder seltsame Lösungen. Doch das allein überzeugt mich nicht.

Letztlich komme ich zu dem Schluss, dass man ein grundsätzliches oder tiefergehendes Verständnis von CSS braucht, um die Nachteile auszugleichen. Hat man mal etwas Routine und kennt die Probleme, so ist es einfacher, semantisch brauchbares HTML zu schreiben und gleichzeitig ein ansprechendes Design umzusetzen, während man mit Tabellen dann wiederum auf andere Probleme stieße. Aber genau da liegt der Punkt: Man muss sich erstmal eingehend damit auseinandersetzen. CSS mag am Anfang einfach erscheinen, aber gerade wenn es ums Layout geht, ist es alles andere als das. Tabellen sind viel einfacher zu begreifen, da jeder Tabellen kennt und weiß, wie er sie sich vorzustellen hat. Und letztlich geht es bei der Diskussion CSS vs. Tabellen genau darum – die (nicht vorhandene) Simplizität. Und mal ehrlich: Welchen Nutzer interessiert, ob eine Seite aus Tabellen aufgebaut ist oder nicht, hauptsache sie funktioniert und sieht passend aus? Ich kann durchaus nachvollziehen, dass manch einer die einfache Variante vorzieht.

Ich kann mir inzwischen ein Layout ohne CSS kaum noch vorstellen. Oder gut, vorstellen schon, aber machen? Nein danke, dafür habe ich schon genug hässliche bis ins unkenntliche verschachtelte Beispiele gesehen. Ich werde auch weiterhin mit CSS arbeiten und wenn ich mal auf ein Problem stoße, dann finde ich ganz sicher ein kleines Tutorial oder dergleichen, das mir bei der Lösung hilft. Außerdem mag ich semantischen Code, da ich so eher das Gefühl habe, unabhängig von der Darstellung zu sein und das hilft letztlich z.B. auch bei der Suchmaschinenoptimierung. Für mich gewinnt also CSS diesen “Kampf”.

Das besondere an CSRF ist, dass schädlicher Code auf jeder beliebigen Seite auftauchen kann und nicht nur auf der Seite, die angegriffen wird (gut, eigentlich wird nicht die Webseite, sonder der Nutzer angegriffen). Das macht es auch schwieriger, sich dagegen zu schützen. Betrachten wir ein einfaches Beispiel: Jemand hat einen Account auf der Seite www.example.net und ist dort angemeldet. Die Seite hat einen Session-Key oder die Anmeldedaten in Cookies hinterlegt, so dass man angemeldet ist, wenn man die Seite betritt. Um auszuloggen, muss man auf einen Link “Logout” klicken, der zu www.example.net/logout führt. Wenn unser “Opfer” jetzt eine andere Seite aufruft, bei der ein Bild folgendermaßen eingebunden ist: <img src="www.example.net/logout" />, so würde es ausgeloggt werden – ohne eigenes zutun.

Wieso ist das so? Der Browser erkennt, dass das Bild (oder sonstwas) von einer bestimmten URL geladen werden soll und schickt, wie bei jedem Request, die Cookies dieser Domain mit. Die Webseite erkennt diese, identifiziert dadurch scheinbar den Nutzer, obwohl in Wirklichkeit nur der Browser identifiziert wird und führt die mit der URL verbundene Aktion aus. So einfach ist CSRF. Das Kernproblem ist hier also, dass die Webseite www.example.net nicht verifizieren kann, ob der Nutzer den Request tatsächlich authorisiert hat, oder ob er anderweitig von dessen Browser gesendet wurde.

Alle Aktionen, die mit einem simplen GET-Request ausgeführt werden können, benötigen also noch nicht einmal JavaScript, um gefährdet zu sein. Wird eine Aktion über ein Formular mittels POST-Request ausgeführt, so muss ein Angreifer JavaScript verwenden – da die meisten Internetnutzer dieses aktiviert haben, ist es auch kein Problem, derartige Aktionen im Namen des Nutzers auszuführen. Dass von diesem Problem auch viele populäre Seiten betroffen sind, zeigt eine Ausarbeitung von Bill Zeller und Ed Felten. In einem Blog-Eintrag sprechen sie unter anderem über YouTube, wo so ziemlich alles anfällig war, aber auch über eine Bank, wo es durch CSRF möglich war, Geld vom Opfer auf sein eigenes Konto zu transferieren. Eine genaue Erläuterung der Angriffe findet sich in einer Ausarbeitung, die besprochenen Sicherheitslücken wurden inzwischen geschlossen.

Die Lösung, die die beiden für Webseitenbetreiber vorschlagen, sieht es erstmal vor, dass Aktionen, die potenziell Daten verändern können, immer über einen POST-Request behandelt werden sollen. Dafür sind also Formulare vonnöten. Zu Beginn jeder Session wird eine Pseudo-Zufallszahl in einem Cookie gespeichert und in jedem Formular sollte sich ein Gegenstück dazu finden. Dieses versteckte Feld wird von einem JavaScript befüllt, das das Cookie ausliest. Der Browser schickt beim Absenden des Formulars das versteckte Feld und das Cookie zum Server, wo dann beide Werte miteinander verglichen werden. Stimmen sie überein, so ist die Anfrage korrekt, anderenfalls nicht.

Das Geheimnis dahinter ist es, dass die Cookies einer Seite nur dann per JavaScript ausgelesen werden können, wenn das JavaScript unter dieser Domain läuft (Same-Origin Policy). Würde das Formular von einer anderen Seite aus abgesendet werden, so könnte das Cookie nicht ausgelesen werden und der Angriff wäre damit unwirksam. Der große Nachteil ist allerdings, das Nutzer mit deaktiviertem JavaScript in die Röhre gucken. Es ist sogar ein wenig ironisch, dass gerade Cookies und JavaScript in diesem Fall für Sicherheit sorgen, sind es doch diese beiden Technologien, die Angriffe wie XSS und CRSF erst ermöglichen. Vorteil dieser Lösung gegenüber anderen ist es, dass es kein Problem mit dem browsen in mehreren Tabs oder Timeouts gibt, wie es z.B. dann der Fall wäre, wenn pro Formular ein eigener zeitlich begrenzt gültiger Zufallswert generiert würde.

Cross-Site Request Forgery Angriffe erscheinen teilweise recht primitiv, aber dafür sind sie umso wirkungsvoller. Gerade bei einfachen GET-Requests hilft auch kein deaktiviertes JavaScript und jedes Bild könnte eine ungewollte Aktion auf einer beliebigen Seite auslösen. Ein solcher Angriff ist auch recht einfach ausgeführt, denn in Foren und ähnlichem kann man in der Regel problemlos Bilder einbinden und je stärker das Forum frequentiert ist, desto mehr Personen tappen in die Falle und merken noch es noch nicht einmal. Umso mehr müssen sich Webseitenbetreiber dieser Gefahr bewusst werden und sich Lösungen überlegen, auch wenn es sicher nie 100%igen Schutz geben kann.

Also ging ich heute in den Buchladen meines Vertrauens und setzte mich eine Weile hin, um das Buch zu überfliegen und interessantere Stellen im Detail zu betrachten. Da ich selber bereits einige Erfahrung auf dem Gebiet sammeln konnte und Layouts für Seiten umgesetzt habe, die mehrere Tausend Besuche am Tag haben, war ich skeptisch, wie viel mir ein solches Buch bringen würde – zwar bin ich mir ziemlich sicher, dass ich nicht jeden Trick und jedes Geheimnis kenne, aber im Zweifelsfall wird man im Internet fündig. Auch wenn sich mein Eindruck auf etwa eine halbe Stunde beschränkt hat, denke ich, dass meine Skepsis nicht berechtigt war.

Auf eine umfangreiche Erklärung von CSS wird verzichtet, denn schließlich richtet sich das Buch an Fortgeschrittene und Profis. So geht es direkt ans Eingemachte und im ersten und umfangreichsten Teil werden Details zu bestimmten Eigenschaften und Prinzipien vermittelt, die sich in einer Einsteigerlektüre kaum finden lassen. Schon hier las ich Dinge, die ich sehr interessant fand, wie z.B. dass es (leider nur mit zusätzlichem Markup) möglich ist, die vom Firefox intepretierte Eigenschaft display: -moz-inline-box als sinnvollen Ersatz für display: inline-block zu nutzen – meine Erfahrung bisher war es, dass diese Eigenschaft nur in ganz speziellen Fällen als Ersatz herhalten kann.

Weiterhin wird direkt auf die CSS-Bugs diverser Browser eingegangen. An vorderster Stelle sind natürlich die Bugs des Internet Explorers zu nennen, aber auch andere Browser haben an manchen Stellen noch zu kämpfen. Die Bugs werden nicht nur erwähnt, sondern wie es sich für ein Buch gehört, das gezielt die erfahreneren Anwender anspricht, wird auch mindestens eine Lösungsvariante angegeben.

Im zweiten Teil geht das Buch nochmal etwas konkreter auf Bugs und Debugging ein. Es wird erklärt, wie man mehrerer Versionen des Internet Explorers parallel installiert und wie man mit den gängigen Developer-Tools der großen Browser umgeht, wie z.B. Firebug (Firefox), Dragonfly (Opera) oder Developer Toolbar (Internet Explorer).

Im letzten Teil schließlich dreht sich alles um umfangreichere, praxisnahe Beispiele. Neben verschiedensten Arten von Menüs und Navigationen werden auch mehrspaltige Layouts betrachtet. Natürlich habe ich nach der Technik Ausschau gehalten, die ich vor einer Weile im Artikel “Ein flexibles, SEO-gerechtes Layout” beschrieben habe. Sie fand sich als eine von mehreren Möglichkeiten, “Content first” Layouts umzusetzen, wenn auch nicht direkt im Zusammenhang mit einem flexiblen Inhaltsbereich. Dafür fand ich eine Variante, ein solches Layout umzusetzen, ohne dass gleich zwei zusätzliche Wrapper-Elemente nötig wären, indem zusätzlich zu Float noch relative Positionierung eingesetzt wird. Zu guter Letzt werden noch verschiedene teils sehr interessante Möglichkeiten besprochen, wie man gleich hohe Spalten erzwingen kann bzw. den Eindruck erweckt, es wäre so.

Insgesamt hat das Buch einen guten Eindruck auf mich gemacht. Auch wenn man viel Routine im Umgang mit CSS hat, kann es brauchbar sein, sei es weil man vielleicht doch nicht alle Details kennt oder weil man ohne groß im Internet zu suchen bestimmte Problematiken nachschlagen möchte. Zum Nachschlagen von Browserbugs allerdings schien es nicht so sehr geeignet zu sein, da diese an genau den Stellen kurz erläutert werden, an denen sie auftauchen. In dem Fall muss man also schon genau wissen, wonach man sucht.

In meine Buchsammlung würde “Fortgeschrittene CSS-Techniken” jedenfalls prima passen, also drückt mir fleißig die Daumen

Neben vielen möglichen Bugs habe ich einen herausgesucht, der mir vor einigen Wochen begegnete und den ich so bis dato nicht kannte: Ein vom Text umflossenes Bild wurde im Internet Explorer einfach nicht angezeigt, obwohl es sich beim Aufruf der Bild-URL anzeigen ließ. Im ersten Moment dachte ich noch nicht an einen CSS-Bug und beließ es dabei.

Später aber tauchte das Problem an der gleichen Stelle wieder auf (mit anderem Bild und anderem Text), aber nicht das ganze Bild war unsichtbar, sondern nur ein Teil, als wenn das Bild nur zur Hälfte geladen worden wäre. Auf dem folgenden Bild habe ich das Kernproblem nachgebaut. Der Screenshot stammt aus dem Internet Explorer 7 – oben ist die fehlerbehaftete Darstellung, darunter kommt ein kleiner Fix zur Anwendung, den ich im Folgenden erklären werde.

Wie sich bei Betrachten des Bildes vermuten lässt, spielt der Hintergrund, der im Beispiel grau ist, eine Rolle bei dem Problem. Doch wieso wird das Bild ab einer ganz bestimmten Stelle vom Hintergrund verdeckt? Als ich diesen Bug das erste Mal untersucht habe, dachte ich beim Betrachten des nebenstehenden Textes, dass es vielleicht mit der kursiven Schrift zusammenhängt. Dass der Internet Explorer Probleme mit kursiver Schrift hat, war für mich nichts Neues, gibt es doch andere Bugs, die damit zusammenhängen.

Im Text gibt es mehrere kursive Wörter, aber beim ersten Auftauchen der Kursivschrift (“diam voluptua”) ist noch alles in Ordnung, das Problem scheint erst 2 Zeilen später zu beginnen. Erst nach weiterem Betrachten kam mir eine Idee, die ich dann durch Modifizieren des Textes verifizieren konnte: Das zweite Auftauchen von kursivem Text (“no sea takimata sanctus”) wird durch einen automatischen Zeilenumbruch getrennt und genau oberhalb der Zeile, in der dieser kursive Text beginnt, ist das Bild abgetrennt.

Der minimal nötige Versuchsaufbau sieht also so aus, dass es ein Block-Element geben muss, das einen Hintergrund definiert (ob Hintergrundbild oder -farbe ist dabei egal). Innerhalb des Elements gibt es ein Bild, dass aus dem Textfluss herausgenommen wird (zum Beispiel durch die CSS-Eigenschaft float) und natürlich der Text, der dadurch neben dem Bild erscheint. Außerdem muss der Text zumindest in Teilen kursive Schrift enthalten, die automatisch umgebrochen wird. Damit das gegeben ist, habe ich noch ein Wrapper-Element drumrum gebaut, das eine feste Breite vorschreibt – wird die Breite direkt in das schon bestehende Block-Element geschrieben, ist der Fehler nicht sichbar. Wieso, erkläre ich noch.

Das sind Faktoren, die das Auftreten des Bugs eher selten machen und zufällig erscheinen lassen. Tritt der Umbruch des kursiven Textes ganz oben auf, verschwindet das Bild völlig, tritt so etwas nicht auf, ist es gänzlich zu sehen, ist der Umbruch in der Mitte, so erscheint das Bild nur zur Hälfte. Aber hier erstmal der HTML-Code, gefolgt von den eben beschriebenen Styles:

<div class="wrapper">
	<div class="background">
<img src="invisible-sandwich-2.jpg" style="float: left;" /> Lorem ipsum dolor sit amet,
consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore
magna aliquyam erat, sed <em>diam voluptua</em>. At vero eos et accusam et justo duo
dolores et ea rebum. Stet clita kasd gubergren, <em>no sea takimata sanctus</em>
est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr,
sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam
voluptua. <em>At vero</em> eos et accusam et justo duo dolores et ea rebum. Stet clita
kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
	</div>
</div>

div.wrapper {
	width: 560px;
}

div.background {
	background-color: gray;
}

Die Lösung des Problems gestaltet sich recht einfach – zumindest, wenn man sich schonmal mit dem Thema auseinandergesetzt hat. Kern des Bugs ist, wie bei vielen weiteren auch, die hasLayout-Property. Das ist eine nur im Internet Explorer vorhandene Eigenschaft, die jedes Element hat und die je nach angewendeten Styles entweder wahr oder falsch ist.

Standardmäßig hat ein Element “kein Layout”, hasLayout ist also false. Das ist der Auslöser für viele Darstellungsprobleme des Internet Explorers, wie z.B. unsichtbarer und unter bestimmten Bedingungen wieder auftauchender Text. Auch in unserem Fall ist das nicht vorhandene “Layout” das Übel, dort betrifft es das Element, das den Hintergrund definiert. Setzen wir für dieses Element hasLayout implizit auf true, so können wir den Bug beseitigen.

Wie geschieht das? Verschiedene Style-Angaben lösen das aus, allen voran Breiten- und Höhenangaben. Das ist auch der Grund, wieso der Bug nicht auftritt, wenn die in unserem Beispiel durch das Wrapper-Element vorgegebene Breite direkt durch das Element mit dem Hintergrund definiert wird. Beim Internet Explorer 7 tut es auch min-height, die einfach auf 0 gesetzt wird und damit keinerlei sonstigen Einfluss auf die Darstellung hat:

div.background {
	background-color: gray;
	min-height: 0; /* Fix for IE-Bug */
}

Das war auch schon alles und der Tag ist gerettet. Aber wie ist das bei der Version 6 des Internet Explorers? Der kennt die Eigenschaften min-height und min-width schließlich nicht. In unserem Fall ist das aber überhaupt kein Problem, da der IE6 diesen Bug scheinbar nicht hat, er tritt also nur mit Version 7 auf. Da hat Microsoft also ganze Arbeit geleistet, neben alten Bugs auch noch neue rein zu bringen. Hoffen wir, dass es mit Version 8 besser wird.

Der Vollständigkeit halber will ich aber noch beschreiben, wie man im IE6 einem Element Layout gibt. In diesem Fall hilft uns nämlich ein weiterer Bug (ja, manchmal sind die sogar nützlich): Ein Element, dessen hasLayout-Property true ist, wird automatisch so groß, wie es die darin enthaltenen Elemente verlangen. Geben wir einem Element also eine Höhe von 0, so hat es Layout und alles wunderbar. Aber in dem Fall muss man aufpassen, dass kein anderer Browser diese Angabe sieht, was entweder durch den StarHTML-Hack möglich wird oder, was ich prinzipiell bevorzuge, durch Conditional Comments.

Wer einen Internet Explorer sein eigen nennt, der kann sich das Beispiel mit und ohne Fix auch live ansehen. Beachtet aber, dass der Fehler nur mit Version 7 zu sehen ist.

Wer auf einer eigenen Seite Darstellungsprobleme mit dem Internet Explorer hat oder sich grundsätzlich mit dem Thema auseinandersetzen will, der sollte sich die Kategorie Explorer Exposed! von Position Is Everything ansehen, denn dort sind fast alle IE-Bugs zusammen mit möglichen Lösungsvarianten notiert – nur den von mir hier beschriebenen habe ich in der Form dort nicht gefunden. Viel Spaß beim Stöbern in den teils recht skurrilen Fehlern wie dem Peekaboo Bug oder dem Three Pixel Text Jog.

Einfaches Drei-Spalten-Layout

Ich persönlich arbeite gern mit float. Man könnte zwar auch mit absoluter Positionierung arbeiten, aber mein Fall ist das eigentlich nicht. Für die Umsetzung eines typischen Drei-Spalten-Layouts könnte man einfach die Navigation links floaten lassen, eine Sidebar auf der rechten Seite und der Inhalt bleibt in der Mitte und füllt den übrig gebliebenen Platz aus. Schauen wir uns zuerst den HTML-Code an:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de">
<head>

<title>Test</title>
<style type="text/css">
	@import url(style.css);
</style>

</head>
<body>

<div id="page">
	<div id="header"></div>
	<div id="navigation"></div>
	<div id="sidebar"></div>
	<div id="content"></div>
	<div id="footer"></div>
</div>

</body>
</html>

Die einzelnen Bereiche der Seite (Header, Footer, Navigation, Sidebar, Content) sind mit IDs gekennzeichnet und werden in der CSS-Datei über diese ID angesprochen:

/* Viele Elemente haben browserabhängig vordefinierte Abstände nach außen und
   nach innen, mit dieser Anweisung wollen wir diese entfernen. */
* {
	margin: 0;
	padding: 0;
}

/* Dieses Element umschließt die gesamte Seite, um sie auf eine bestimmte Breite
   zu bringen. Block-Elemente wie dieses nehmen automatisch die volle zur
   Verfügung stehende Breite an, die wir hier aber durch Minimum- und Maximum
   einschränken wollen. */
div#page {
	min-width: 700px;
	max-width: 1000px;
	/* Der Abstand von 10 Pixel gilt für oben und unten, "auto" für links
	   und rechts - dadurch wird das Element horizontal zentriert. */
	margin: 10px auto;
	background-color: #ccc;
}

/* Der Header beinhält zumeist den Titel der Website und ist hier nur der
   Vollständigkeit halber aufgeführt. */
div#header {
	height: 100px;
	background-color: yellow;
}

/* Die Navigation wird aus dem Textfluss genommen und ganz nach links geschoben,
   außerdem wird eine feste Breite vorgegeben. */
div#navigation {
	float: left;
	width: 150px;
	height: 500px;
	background-color: maroon;
}

/* Die Sidebar wird aus dem Textfluss genommen und ganz nach rechts geschoben,
   außerdem wird eine feste Breite vorgegeben. */
div#sidebar {
	float: right;
	width: 200px;
	height: 500px;
	background-color: green;
}

/* Der Inhaltsbereich nimmt automatisch die zur Verfügung stehende Breite ein,
   wird aber durch das Margin so weit vom linken und rechten Rand weggedrückt,
   wie Navigation und Sidebar breit sind. */
div#content {
	height: 500px;
	margin: 0  200px 0 150px;
	background-color: navy;
}

/* Der Footer hat wie der Header eher Vollständigkeits-Charakter. Wichtig ist
   hier aber das "clear", damit er auf jeden Fall erst unter Navigation und
   Sidebar erscheint, sollte der Content mal kürzer sein als eines von beidem. */
div#footer {
	clear: both;
	height: 50px;
	background-color: orange;
}

Die Höhenangaben dienen zumeist nur dazu, sich einen Eindruck vom Ergebnis machen zu können. Durch die farblichen Hintergründe kann man die einzelnen Teile auch gut voneinander unterscheiden, das Ergebnis sieht so aus (klicken, um das Beispiel als eigenständige Seite zu sehen):

Ein Unterschied zur Umsetzung mit Tabellen wird hier deutlich: Die Container für die drei nebeneinander befindlichen “Spalten” sind nicht zwangsläufig gleich hoch. Zwar wird die Höhe im Beispiel fest vorgeschrieben, in der Realität aber richtet sie sich zumeist nach dem Inhalt. Mit “Faux Columns” gibt es eine Möglichkeit, zumindest den Anschein zu erwecken, als seien alle Container gleich hoch und es gibt auch verschiedene Methoden, wie man die Höhe tatsächlich erzwingen kann, aber das werde ich vielleicht in einem anderen Artikel näher erläutern.

SEO-gerechtes Drei-Spalten-Layout

Mit der eben genannten Art, ein flexibles Drei-Spalten-Layout zu erstellen, gibt es aber ein Problem und damit kommen wir auf einen Punkt zu sprechen, der schon im Titel dieses Artikels erwähnt wird. Vielleicht habt ihr euch auch schon gefragt, was das denn überhaupt mit Suchmaschinenoptimierung zu tun haben soll und das will ich euch jetzt beantworten.

Stellt euch vor, es gäbe ein Textdokument über Rohrzangen. In dem Fall käme das Wort “Rohrzange” wohl mehrmals im Text vor, insbesondere am Anfang (z.B. im Titel). Ein Wort, um das es eher nicht oder nur am Rande geht, wie z.B. “Säge”, wird, wenn überhaupt, vermutlich erst später im Text erwähnt. Deshalb speichern die meisten Suchmaschinen die Position ab, die ein Wort in einem Dokument hat, und je weiter hinten es auftaucht, desto weniger Gewicht hat es in Bezug auf das Dokument. Dass auch Google auf die Position achtet, kann man im Abschnitt 4.2.5 der Ausarbeitung “The Anatomy of a Search Engine” von Sergey Brin und Lawrence Page nachvollziehen – in dieser Arbeit erklären sie ihren Google-Prototypen.

Was hat das jetzt mit unserem Layout zu tun? Schaut man sich einmal den HTML-Code an, so fällt auf, dass der Content-Bereich, also der, in dem die eigentlichen Inhalte stehen, vor dem Footer das vorletzte Element ist. Alle Wörter, die in Header, Navigation oder Sidebar vorkommen, werden also eine kleinere Position haben und damit höher gewichtet werden, als der eigentliche Inhalt. Zwar könnte ich mir vorstellen, dass Google inzwischen so intelligent ist und Seiten mit selber Domain vergleicht, um herauszufinden, welcher Bereich den eigentlichen Inhalt darstellt und diesen so höher gewichten kann, aber dazu ist mir nichts bekannt und man wäre zumindest auf der sicheren Seite, wenn der Inhalt noch vor den seitlichen Spalten im Code auftauchen würde.

Doch da fangen die Probleme an. Soll der Content-Bereich vor den Sidebars sein, muss er zwangsläufig per float an eine Seite befördert werden (es sei denn, man realisiert das Layout z.B. mit absoluter Positionierung). Die Sidebars wären dann daneben. Hätten alle Spalten eine fest vorgegebene Breite, so könnte man sie nach belieben umsortieren, wie es im Artikel “Any Order Columns” beschrieben wird. Dabei müssen alle Elemente in die selbe Richtung floaten und mittels teils positivem und teils negativem Margin ändert man die visuelle Reihenfolge. Haben z.B. Inhalte und Sidebars feste Breitenangaben im Prozentformat, so wäre die Seite flexibel in der Breite und diese Technik könnte eingesetzt werden.

Ich will aber einen Schritt weiter gehen und wie im Beispiel oben nur den Inhalt flexibel gestalten, Navigation und Sidebar sollen jeweils eine feste, nicht-prozentuale Breite haben. Ein Element, das per float an den Rand befördert wird, nimmt automatisch den gerade so nötigen Platz ein und nicht, wie ein normales Block-Element, den gesamten zur Verfügung stehenden. Soll der Content also die volle Breite einnehmen, muss diese auf 100% gesetzt werden. Aber dann nimmt das Element wiederum die volle Breite des Elternelements an, ungeachtet dessen, ob noch weitere floatende Elemente darin sind.

Eine Lösung für dieses Problem habe ich vor einiger Zeit mal flüchtig in einem Buch über CSS gesehen und als ich diesen Blog gestaltet habe, rief ich es mir nochmal ins Gedächtnis zurück. Anhand eines zweispaltigen Layouts lässt es sich einfach erklären: Inhalt und Sidebar stehen nacheinander im HTML-Code und um beide herum ist ein Div-Container. Dieses Wrapper-Element hat nach rechts einen Abstand, der der Breite der Sidebar entspricht. Diese floatet zur rechten Seite und wird mit negativem rechten Abstand in eben diese Lücke zwischen Wrapper und Seitenrand gezogen. Nun hat der Inhalt die volle Breite des Wrapper-Elements für sich allein, floatet nach links und kann eine horizontale Ausdehnung von 100% bekommen.

Zur Verdeutlichung seht ihr hier den wesentlichen Teil des HTML-Codes und eine kleine Skizze, damit das Grundprinzip klar ist, bevor es zum kompletten Beispiel anhand eines Drei-Spalten-Layouts geht:

<div id="wrapper">
	<div id="content"></div>
	<div id="sidebar"></div>
</div>

Im Falle von drei Spalten braucht man ein zweites Wrapper-Element, wie man im Code leicht sieht:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de">
<head>

<title>Test</title>
<style type="text/css">
	@import url(style.css);
</style>

</head>
<body>

<div id="page">
	<div id="header"></div>
	<div id="outerwrapper">
		<div id="innerwrapper">
			<div id="content"></div>
			<div id="navigation"></div>
		</div>
		<div id="sidebar"></div>
	</div>
	<div id="footer"></div>
</div>

</body>
</html>

Zwar sind verglichen mit der einfachen Ursprungsversion zwei Wrapper-Elemente hinzugekommen, dafür aber ist der Content noch vor Navigation und Sidebar. Man könnte die beiden seitlichen Spalten auch tauschen, müsste dann aber etwas die Styles anpassen, die wie folgt aussehen:

/* Viele Elemente haben browserabhängig vordefinierte Abstände nach außen und
   nach innen, mit dieser Anweisung wollen wir diese entfernen. */
* {
	margin: 0;
	padding: 0;
}

/* Dieses Element umschließt die gesamte Seite, um sie auf eine bestimmte Breite
   zu bringen. Block-Elemente wie dieses nehmen automatisch die volle zur
   Verfügung stehende Breite an, die wir hier aber durch Minimum- und Maximum
   einschränken wollen. */
div#page {
	min-width: 700px;
	max-width: 1000px;
	/* Der Abstand von 10 Pixel gilt für oben und unten, "auto" für links
	   und rechts - dadurch wird das Element horizontal zentriert. */
	margin: 10px auto;
	background-color: lightgrey;
}

/* Der Header beinhält zumeist den Titel der Website und ist hier nur der
   Vollständigkeit halber aufgeführt. */
div#header {
	height: 100px;
	background-color: yellow;
}

/* Das äußere Wrapper-Element enhält Content, Navigation und Sidebar. Außerdem
   hält es Abstand zu den Seiten, um dort für Navigation und Sidebar Platz zu
   schaffen. */
div#outerwrapper {
	/* Breite der Navigation. */
	margin-left: 150px;
	/* Breite der Sidebar. */
	margin-right: 200px;
}

/* Das innere Wrapper-Element enthält Content und Navigation. Es floatet neben
   der Sidebar (in die entgegengesetzte Richtung) und nimmt den vollen Platz
   innerhalb des äußeren Wrappers ein. */
div#innerwrapper {
	float: left;
	width: 100%;
}

/* Der Inhalt hat eine Breite von 100% und nimmt damit den gesamten Platz vom
   inneren Wrapper-Element ein. */
div#content {
	float: right;
	width: 100%;
	height: 500px;
	background-color: navy;
}

/* Die Navigation ist ebenfalls im inneren Wrapper und floatet zur anderen
   Seite, so dass die Navigation neben dem Inhalt am Rand des Wrappers liegen
   könnte (wenn man die Breite des Inhalts mal außer acht lässt). */
div#navigation {
	float: left;
	/* Der negative Abstand nach links befördert die Navigation aus beiden
	   Wrappern hinaus. */
	margin-left: -150px;
	width: 150px;
	height: 300px;
	background-color: maroon;
}

/* Die Sidebar ist neben dem inneren Wrapper und floatet zur anderen Seite, um
   ähnlich wie die Navigation am Rand des Elternelelements zu liegen. */
div#sidebar {
	float: right;
	/* Der negative Abstand nach rechts befördert die Sidebar aus dem
	   Wrapper hinaus. */
	margin-right: -200px;
	width: 200px;
	height: 400px;
	background-color: green;
}

/* Der Footer hat wie der Header eher Vollständigkeits-Charakter. Wichtig ist
   hier aber das "clear", damit er auf jeden Fall erst unter Navigation und
   Sidebar erscheint, sollte der Content mal kürzer sein als eines von beidem. */
div#footer {
	clear: both;
	height: 50px;
	background-color: orange;
}

Das Ergebnis sollte genau so aussehen, wie unser erstes Beispiel oben:

Variante mit Faux Columns

Auch wenn ich die Problematik der gleich hohen Spalten eigentlich in einem anderen Artikel behandeln möchte, so will ich hier doch eine Möglichkeit beschreiben, die ebenfalls in die Kategorie “Faux Columns” fällt. Wenn man die eben vorgestellte Variante nutzt, um eine flexible Seite zu erstellen und außerdem Navigation und Sidebar einen einfarbigen Hintergrund ohne Rand bekommen sollen, so könnte man dem äußeren Wrapper statt Abständen zur Seite einen Rahmen geben.

Außerdem wird es hier nötig, den äußeren Wrapper dazu zu zwingen, so hoch zu sein, wie seine Inhalte – da diese aus dem Textfluss herausgenommen wurden, ist das nicht automatisch gegeben. Der wesentliche Teil des HTML-Codes ändert sich wie folgt:

<div id="page">
	<div id="header"></div>
	<div id="outerwrapper">
		<div id="innerwrapper">
			<div id="content"></div>
			<div id="navigation"></div>
		</div>
		<div id="sidebar"></div>
		<div class="clear"></div>
	</div>
	<div id="footer"></div>
</div>

Im Normalfall bekommt der Rahmen links bzw. rechts des äußeren Wrappers jetzt die selbe Hintergrundfarbe, wie Navigation bzw. Sidebar, während diese keinerlei Hintergrund mehr definieren, damit der Rahmen immer durchscheint (und man beim Anpassen der Farbe nur eine Stelle ändern muss). Da ich aber den Effekt deutlich machen will, gebe ich dem Rahmen eine andere Farbe und so sieht man immer noch, wie hoch Navigation und Sidebar tatsächlich sind:

div#outerwrapper {
	/* Beseitigt einen Bug vom IE7 */
	min-height: 0;
	/* Breite der Navigation. */
	border-left: 150px solid red;
	/* Breite der Sidebar. */
	border-right: 200px solid lime;
}

div.clear {
	clear: both;
	height: 0;
}

In rot sind auch auch hier die wesentlichen Änderungen gegenüber dem vorigen Beispiel. Vielleicht fragt sich der ein oder andere, was es mit dem Bugfix für den Internet Explorer 7 auf sich hat – doch auch das ist ein anderes Thema, das ich sicher noch ansprechen werde. Das ist auch nur deswegen drin, damit Personen mit eben diesem Browser das Beispiel auch korrekt sehen können:

Letzte Hinweise

Abschließend will ich noch hinzufügen, dass Padding, also der Abstand eines Elementes nach innen, auf die Breite draufgeschlagen wird. Bekommt der Inhalt also diesen inneren Abstand, dann ist er breiter als 100%. In dem Fall muss man entweder die Maße der seitlichen Spalten anpassen oder man benötigt einen weiteren Container im Content, der per Margin oder Padding für den zusätzlichen Abstand sorgt. Da ich mit meinen Beispielen aber vorrangig die Grundprinzipien darstellen wollte, habe ich auf derartige Details verzichtet.

Das war jetzt eine Menge Stoff, aber ich hoffe, dass ich es halbwegs verständlich rüberbringen konnte. Wenn es noch Unklarheiten gibt oder ihr andere CSS-Techniken kennen lernen wollt, dann schreibt es mir in die Kommentare und mit ein bisschen Glück bekommt ihr eine Antwort.

Während der Mitarbeit an einer Spiele-Fansite hatte ich vor längerer Zeit mal mit dem Problem der Suchmaschinenoptimierung zu kämpfen, nachdem die Seite plötzlich viele Plätze verloren hatte. Schließlich gelangten wir auch wieder auf die erste Ergebnisseite bei der Suche nach dem Titel des Spiels, aber auf die ersten beiden Plätze kamen wir nicht. Also schaute ich mir mal an, ob ich mir am Aufbau der erstplatzierten Seite etwas abschauen könnte.

Dort stieß ich dann aber auf Methoden, die ich fragwürdig fand. Angefangen von eher harmlosen Dingen wie Spieltitel in class- oder id-Attributen, über kommagetrennte Schlüsselwörter im H1-Tag, das mittels dem Hintergrund angepasster Schriftfarbe vor Besuchern versteckt wurde, bis hin zu einer Art Doorwaypage unter ähnlicher Domain mit wenig sinnvollen Texten, die in verschiedenen Kontexten auf die eigentliche Seite linkte. Ob diese Optimierungen mitverantwortlich für das gute Ranking waren, weiß ich nicht, aber offensichtlich haben sie auch nicht geschadet.

Laut Googles Richtlinien für Webmaster kann es sich negativ auf das Ranking auswirken, wenn eine Seite mit grenzwertigen Tricks optimiert wurde und es gab auch schon einzelne Abwertungswellen, aber wirklich effektiv geht Google nicht dagegen vor. Das Problem, das “ehrlichen” Optimierer dadurch haben, wird auch in einem Artikel über Linkgeiz angesprochen, den ich gestern auf einem anderen Blog gelesen habe. Dort geht es unter anderem um die Problematik des Linktauschs, um dadurch den Pagerank zu verbessern und auch darum, dass viele Seitenbetreiber mit Links geizen.

Linkgeiz kenne ich auch nur zu gut. Gerade größere Fansites vermeiden es oftmals, auf den direkten Konkurrenten zu linken. Dann wird z.B. nicht über Exklusives der anderen Seite berichtet, auch wenn es für die eigenen Besucher interessant gewesen wäre. Oder eine Seite findet etwas heraus und macht eine News dazu, aber andere Seiten tun so, als ob sie es selber und rein zufällig wenige Stunden später herausgefunden hätten, hauptsache man muss nicht verlinken. Leider handeln auch Websites von bekannten Spielemagazinen nach diesem Vorsatz, was meiner Meinung nach nicht gerade journalistisch vorbildlich ist.

Doch zurück zum Thema: Was ist, wenn man gute und teils exklusive Inhalte hat, die eigene Seite relativ gut optimiert wurde, aber aufgrund fehlender Links und entsprechend aggressiver Optimierung der Konkurrenz das Ranking in den Suchergebnissen nur mittelmäßig ist? Sollte man dann die Risiken einer Abwertung in Kauf nehmen und sich ebenfalls vorsichtig in die Grauzonen der SEO vorwagen, um wirklich alles probiert zu haben? Oder sollte man gar die Konkurrenz bei Google melden?

Dieses “Petzen” wäre für mich keine Option, solang die Optimierungen der anderen Seite nicht völlig über die Strenge schlagen. Übertriebene Maßnahmen wie versteckter Text oder Linkkauf kämen für mich auch nicht in Frage. Wäre ich in einer solchen Situation, könnte ich wohl nur auf eine feste Nutzerbasis hoffen, die auch ohne Google regelmäßigen Traffic bringt. Und wer weiß, vielleicht verbessern voting-basierte Suchmaschinen wie WikiaSearch die Ergebnisse – solang sich die Bewertungen nicht manipulieren lassen.

Von der Idee dahinter und der Möglichkeit überhaupt habe ich eben im Beitrag “Zeig mir, was du surfst” auf blog.wieseln.de gesehen. Dabei wird die Tatsache ausgenutzt, dass bereits besuchte Links anders dargestellt werden, als noch nicht besuchte. Ein Javascript öffnet unsichtbar auf der Seite einen iframe, in dem ein Link mit der zu untersuchenden URL erscheint – natürlich auch nicht sichtbar für den Nutzer. Anschließend wird die Pseudo-Klasse link:visited, die man zum Formatieren mittels CSS nutzen kann, abgefragt und daraus ergibt sich dann, ob man diese URL in letzter Zeit schonmal besucht hat oder nicht.

So ist es für jeden Betreiber einer Website möglich, in gewissem Umfang Nutzungsprofile der eigenen Besucher anzulegen, indem bestimmte URLs abgefragt werden, um das für personalisierte Werbung zu nutzen oder einfach nur zu speichern, um es später einmal einem Verwendungszweck zuzuführen (und wenn es das Verkaufen der Daten ist). Als Internetnutzer wird man immer transparenter und mich würde es nicht wundern, wenn man in geraumer Zukunft über jeden Menschen Informationen abrufen könnte – wobei das im Falle von StudiVZ und anderen Social Networks aufgrund der selber preisgegebenen Daten zum Teil schon der Fall ist.

Doch welche Art des Layouts sollte man bevorzugen? Noch vor einigen Jahren wäre ich klar für die variable Breite gewesen, denn so wird das Browserfenster immer optimal ausgefüllt, sei es bei einer Auflösung von 800×600 oder 1280×1024. Es entstehen keine leeren Flächen und die Seite ist immer komplett lesbar, ohne dass horizontal gescrollt werden müsste.

Inzwischen sehe ich das aber anders. Breitbildmonitore mit Auflösungen mit 1680 oder 1920 Pixeln in der Breite sind heute keine Seltenheit mehr und bei einer variabel ausgelegten Seite gibt es dann Probleme: Die Textzeilen werden sehr lang, das Lesen wird erschwert. Außerdem wirkt auch das Layout auf stark unterschiedlichen Auflösungen ganz anders, wodurch weniger Planung beim Schreiben von Artikeln und Einträgen möglich ist, weil ein vom Text umflossenes Bild mal halb so breit wie der Artikel ist und so evtl. ein optimales Ergebnis abgibt, mal aber im Gegensatz zum Rest recht klein und unpassend wirkt.

Beide Varianten haben bei besonders großen Auflösungen Probleme, denn entweder sind die Textzeilen zu lang oder es gibt sehr viel Freifläche neben der Seite, allerdings halte ich die letztgenannte Variante für angenehmer, weshalb ich sie im Zweifel vorziehen würde. Aber das ist nicht mein letztes Wort, denn dank der CSS-Angaben für minimale und maximale Breite kann man die Vorteile beider Möglichkeiten vereinen, was man auch beispielhaft am aktuellen Layout dieser Seite sehen kann.

Dabei wird die Website grundsätzlich erstmal als dynamisch geplant, also der Inhaltsbereich oder die gesamte Website passt sich an die Breite des Browserfensters an. Außerdem schaut man sich an, wann die Seite definitiv nicht schmaler und breiter werden sollte und gibt diese Werte als Maximum und Minimum an. Dabei spielt die Länge der Zeilen auf jeden Fall eine Rolle, aber je nach Seite kann es auch andere Kriterien geben.

Die Vorteile liegen auf der Hand: Die Seite sieht nie wirklich schlecht aus, die Texte lassen sich immer recht gut lesen und innerhalb eines bestimmten Rahmens passt sich die Seite an, falls man z.B. den Browser nicht maximiert hat oder man aus bestimmten Gründen mal eine niedrige Auflösung nutzen muss. So gesehen geht es vorwiegend darum, kleinere Auflösungen durch die Dynamik zu unterstützen, während bei größeren eine optimale Zeilenlänge gegeben sein sollte.

Doch so schön das auch klingen mag, nicht in jeder Situation ist diese Variante möglich. Vielleicht will man absolute Kontrolle über das Aussehen seiner Seite haben und das Verhältnis zwischen Text und Bildern soll immer gleich sein oder aber man schränkt sich durch ein bestimmtes Design stark ein, so dass man um ein feststehendes Layout nicht drumrum kommt. So oder so ist die Entscheidung für eine Variante also letztendlich immer situationsbedingt zu treffen.