Cascading Style Sheets ::Artikel

Sitemap-Formatierung mit CSS

Ein Inhaltsverzeichnis, dass dem Besucher hilft, sich zurechtzufinden, ist ein obligater Bestandteil jeder größeren Website. Dabei handelt es sich oft um einen mehr oder weniger detaillierten Überblick der gesamten Site, es können aber auch nur Teile einer Website dargestellt sein.

Eine Sitemap kann auf verschiedene Weise aufbereitet sein, z. B. als Baumdiagramm à la Explorer, als nummerierte Liste oder als Tabelle. Auch eine Auflistung der Themen mit kurzen Anreißern wird oft verwendet. Wichtig ist hierbei, dass es sich nicht nur um ein einfaches Inhaltsverzeichnis handelt (wie in einem Buch), sondern um die strukturelle Darstellung des Inhalts einer Website.

HTML bietet verschiedene Elemente mit unterschiedlichen semantischen Eigenschaften, die wir dazu verwenden können, solche Seitenübersichten darzustellen. Zum Beispiel:

Dieses Tutorial soll einige mögliche Lösungen vorstellen, die auf normale Absatz- Elementen P, aber auch auf Listenelementen basieren. Alle Spezialfälle können natürlich nicht hier behandelt werden, sie lassen sich aber relativ leicht aus den vorgestellten Lösungen ableiten. Letztlich muß jeder selbst entscheiden, welche Lösung er/sie für angemessen hält.

Noch zwei Vorbemerkungen:

Baumstruktur im Explorer-Stil

In diesem Abschnitt wollen wir uns nur der explorerartigen Darstellung des Inhalts widmen, in der links neben dem Text die Baumstruktur der Website dargestellt wird. Die Baumstruktur wird in der Regel durch eine Kombination senkrechter und waagerechter Linien dargestellt. Wir realisieren sie deshalb durch grafische Diagramme, die wir jeder Zeile voranstellen.

Realisierung mit Hilfe von Block- Level- Elementen, 1. Ansatz

Screenshot 1

Die zeichnerische Darstellung so einer Baumstruktur ist eine vorrangig vertikal ausgerichtete Grafik, die für unsere Zwecke in horizontale Scheiben aufgeteilt werden soll, wie es im Screenshot 1 gezeigt ist. Um damit eine Struktur mit drei Hierarchiestufen darzustellen, benötigen wir 14 verschiedene Grafiken. (Für eine Struktur mit zwei Hierarchieebenen würden wir sechs verschiedene Grafiken benötigen, bei vier Hierarchieebenen sind wir bereits auf 30 verschiedene Grafiken angewiesen.)

Dazu könnten wir nun jeder Zeile das Element IMG voranstellen und damit die Baumstruktur im HTML codieren. Einmal davon abgesehen, dass wir damit den Code unnötig aufblähen würden, wäre diese Lösung auch nicht sehr wartungsfreundlich, denn spätere Änderungen sind nur sehr zeitintensiv durchzuführen, da jedes Element einzeln geändert werden müsste.

Da ist es schon besser, wenn die grafische Darstellung zentral im Stylesheet realisiert wird. Wir verwenden dazu die Hintergrundeigenschaften des CSS und schieben einfach die Textzeile mit Hilfe von padding-left so weit nach rechts, dass sie rechts neben der Grafik erscheint. Nach der Spezifikation wird auch die padding-Fläche noch durch das background-image mit hinterlegt, und dies wird auch durch alle modernen Browser so dargestellt. Voraussetzung dafür ist allerdings, dass jede Textzeile in ein separates HTML-Element eingefasst wird.

Hier erscheint es zunächst vorteilhaft, Inline- Level- Elemente zu verwenden (z. B. SPAN oder A) und diese jeweils durch ein BR voneinander zu trennen. Das hat jedoch zwei Nachteile:

Deshalb fassen wir die einzelnen Textzeilen in Block-Level Elemente ein und legen zusätzlich noch einen DIV-Container um die Sitemap, um unseren CSS-Deklarationen eine größerere Spezifizität zu geben - siehe Beispiel 01.

Zur Formatierung jeder Zeile unserer Sitemap benötigen wir jetzt grundsätzlich zwei CSS-Regeln. Mit der ersten Regel wird deklariert, wie weit jede einzelne Zeile nach rechts gerückt werden muss. Dies ist abhängig von der Stellung des Links innerhalb der Hierarchie der Site und könnte deshalb auch aus einer Datenbank ausgelesen werden. Die zweite Regel definiert die Grafik, die als Hintergrundbild eingesetzt wird. Wenn wir bei der Namensgebung der verwendeten Dateien (und der CSS-Klassen) systematisch vorgehen, können auch diese Bezeichnungen aus dem Datenbankinhalt ermittelt werden. Dies wird weiter unten noch deutlicher.

Natürlich können wir die Regeln für padding und Hintergrund jeder Zeile in einer Regel zusammenfassen. Wir verzichten aber darauf und erhalten uns so eine größere Flexibilität.

Indem wir den Wert für padding-left vergrößern, schieben wir den Inhalt jeder Zeile etwas nach rechts. Dazu benötigen wir eine separate Regel für jede Hierarchiestufe. Wir bevorzugen hier padding anstelle von margin, um den Effekt der zusammenfallenden Außenabstände (collapsing margins) zu vermeiden. Es ist jedoch auch kein Problem, hier mit margins zu arbeiten, wenn wir die Eigenschaften des umschließenden Blocks im Auge behalten. (Dies ist auch ein Grund, aus dem wir die Sitemap in einen Extra-DIV-Container eingefasst haben.)

Zusätzlich entfernen wir alle padding, margin und Rahmen an den Elementen P, um unerwünschte Zwischenräume zu vermeiden. Den umschließenden DIV-Container ziehen wir ein wenig aus der Ecke oben links heraus, indem wir ein paar einfache Ergänzungen im Stylesheet einfügen.

Das Ergebnis bis hierhin ist im Beispiel 02 zu sehen,
die Änderungen sind in Quelltext und CSS rot hervorgehoben.

Mit dem nächsten Schritt wollen wir die Hintergrundgrafiken ergänzen und gleichzeitig die ganze Darstellung etwas auflockern. Deshalb vergrößern wir die Zeilenhöhe ein wenig (in unserem Fall auf 20 Pixel) und passen die Höhe der Grafiken so an, dass sie der Höhe mehrerer Zeilen Text entspricht. Den Text stellen wir links noch etwas frei, indem wir das padding ein wenig vergrößern. Für unser Beispiel benötigen wir 14 verschiedene Grafiken, daher müssen wir auch 14 verschiedene Klassen definieren. Im Stylesheet deklarieren wir als Ursprung der Grafiken die Ecke links oben und verbieten die Wiederholung.
So weit, so gut: Beispiel 03.

Das wär's auch schon. Am ersten 'Unterkapitel' im vorhergehenden Beispiel kann man gut erkennen, weshalb die Höhe der Hintergrundgrafiken der Höhe mehrerer Textzeilen entsprechen sollte. Wenn jede Grafik nur so hoch ist wie eine Zeile, die Bezeichnung des Unterkapitels aber so lang ist, dass sie mehr als eine Zeile benötigt, kann eine Lücke in der grafischen Baumstruktur entstehen. Dies fangen wir ab, indem wir die Hintergrundgrafiken nach unten verlängern.

Realisierung mit Hilfe von Block- Level- Elementen, 2. Ansatz

Screenshot 2

Für alle, denen die grafischen Arbeiten für das obige Beispiel zu aufwändig sind, soll hier noch eine andere Möglichkeit auf derselben Basis vorgestellt werden. Wenn wir uns die grafische Darstellung etwas genauer ansehen, stellen wir fest, dass sie, unabhängig von der Schachtelungstiefe, aus vier verschiedenen Icons besteht, die sich immer wiederholen (siehe Screenshot 2). Wir können also den gleichen Effekt erzielen, indem wir mehrere dieser Icons am Zeilenanfang neben einander stellen. Das Problem hierbei ist jedoch, dass wir einem HTML-Element nur einen Hintergrund zuordnen können. Wir benötigen also mehrere Elemente, die wir jeweils mit einem eigenen Hintergrundbild versehen.

Block- Level- Elemente lassen sich im normalen Elementfluß nicht neben einander platzieren. Elemente, die im Kontext zur Inline- Formatierung stehen oder mit display:inline-block formatiert sind, lösen das Problem zwar einfacher, aber leider wird diese Möglichkeit noch nicht von allen Browsern unterstützt.

Die beste crossbrowser-taugliche Möglichkeit ist, DIV-Container zu benutzen und diese zu schachteln, wie es im Beispiel 04 dargestellt ist. Im Beispiel gut zu erkennen ist auch, dass Stylesheet und HTML gegenüber Beispiel 3 deutlich einfacher sind.

Die grafischen Darstellungen und das CSS dieser zweiten Lösung sind zweifellos einfacher als die der vorhergehenden Lösung. Das HTML dagegen ist deutlich aufgebläht. Auch lässt sich argumentieren, dass ein mehrfach verschachteltes DIV innerhalb jeder Zeile nur für eine Sitemap einem gewissen Overkill darstellt.

Zusammenfassend kann man sagen, dass der erste Ansatz der 'reinen Lehre' des CSS mehr entspricht, da die Darstellung, d.h. die Präsentation, allein auf Grafik und CSS beruht. Der zweite Ansatz nutzt HTML-Elemente, d.h. Inhalte, um die Darstellung zu beeinflussen, was sich insbesondere bei Sitemaps größeren Umfangs auch in mehr Aufwand niederschlägt.

Realisierung mit Hilfe von verschachtelten Listen

Ein ähnliches Ergebnis können wir erreichen, in dem wir ungeordnete Listen ineinander verschachteln. Am Beispiel 05 sehen wir, wie so eine Verschachtelung ohne CSS aussieht.

Unser erstes Problem ist hier, dass die Einrückung der Listenpunkte durch die verschiedenen Browser auf unterschiedliche Weise verwirklicht wird: einige Browser verwenden padding, andere verwenden margin, einige bringen es am Element UL an, andere am Element LI. Deshalb entfernen wir zuerst alle list-items und die Abstände padding und margin. Siehe Beispiel 06 - die Änderungen sind auch hier wieder farbig hervorgehoben. (Da wir die List-Items alle entfernen, ist es im Grunde genommen egal, ob wir nun geordnete oder ungeordnete Listen verwenden.)

Screenshot 3

Wenn wir jetzt die Grafiken anbringen, stellen wir fest, dass wir nicht sechs, 14 oder gar 30 verschiedene dazu benötigen, sondern nur drei: zwei für das Element LI (im Screenshot 3 etwas kräftiger blau unterlegt) und eins für das Element UL (im Screenshot blass blau unterlegt). Da wir nur drei Grafiken benötigen, brauchen wir auch nur drei CSS-Klassen.

Für die Definition der CSS-Deklarationen machen wir uns einige Regelmäßigkeiten zu Nutze, die im Screenshot gut erkennbar sind. Für das letzte Element LI innerhalb jeder Liste wird eine andere Grafik benötigt als für die vorhergehenden Elemente LI. Das lässt sich durch Einführung einer speziellen Klasse für das jeweils letzte Element bewerkstelligen. Hier wäre die Pseudoklasse :last-child, die für CSS 3 geplant ist, eine große Hilfe.

Weiter wird für die Elemente UL nur ein Icon benötigt (die durchgehende senkrechte Linie), die zwei anderen Icons werden für die Elemente LI gebraucht.

Ein kleiner Trick ist noch dabei: wir müssen die linke Kante aller Elemente UL um die Breite der Grafiken nach links ziehen, damit die senkrechten Linien ohne Versprung aneinander anschließen. In unserem Beispiel sind das 24 Pixel. Das erledigen wir durch negative margin-left und gleichgroße padding-left.
Beispiel 7 stellt die fertige Sitemap dar.

Rahmen und Hintergründe

Hauptaufgabe einer Sitemap ist es, die Struktur der Website darzustellen. Darüber hinaus sollen einzelne Punkte der Liste gelegentlich auch besonderen Gestaltungsansprüchen genügen, d. h. visuell hervorgehoben werden. Bedingt durch die Schachtelung der Listen lässt sich der Schriftzug "Abschnitt" (siehe Beispiel) aber nicht für sich allein gestalten, denn das zugehörige Listenelement umfasst auch alle Nachkommenelemente.

Abhilfe schafft hier, wenn wir das Wort "Abschnitt" (das hier nur als Platzhalter für die genaue Bezeichnung des Abschnitts steht) in ein Element span einfassen. So lassen sich Hintergründe, Farben und Rahmen deklarieren, die dann nur für diese eine Zeile gelten.

Das sieht jetzt noch ein wenig zusammen gedrückt aus. Auch schieben sich padding und border, da sie Inline- Level- Elemente sind, in den Bereich der benachbarten Zeilen hinein. Um das zu ändern, müssen wir die Zeilenhöhe anpassen.

Eine Änderung der Zeilenhöhe bewirkt jedoch erst dann etwas, wenn wir span als Block- Level- Element deklarieren. Also machen wir das so.

Jetzt fällt auf, dass der IE/Win die Zeilenhöhe nicht korrekt darstellt. Wir verändern deshalb die Höhe, sodass für IE/Win alles in Ordnung ist. Die korrekte Höhe für alle anderen Browser verbergen wir vor IE/Win mit dem schon bekannten Kindselektor-Hack. Das Ergebnis zeigt Beispiel 7a. Diese Formatierung lässt sich für jede einzelbe Ebene der Listenelemente separat durchführen.

Nun bestehen Sitemaps sowieso in der Regel aus Links, sodass wir innerhalb des Listenelements bereits ein verschachteltes Element für unsere Regeln haben. Wir können also problemlos das Element span durch ein Element a ersetzen. Damit haben wir visuell formatierbare Links erstellt, die auch im IE/Win auf ihrer ganzen Fläche hover- und klickfähig sind: Beispiel 7b.

Einbau von hover-Images

Screenshot 4

Zum Schluß dieses Abschnitts soll noch ein kleines Schmankerl vorgeführt werden, das zeigt, wie wenig Code tatsächlich notwendig ist, wenn alle Browser die heute gültige CSS-Spezifikation in vollem Umfang unterstützen: im Beispiel 08 ist mit Hilfe von generierten Inhalten jeder Zeile ein kleines Verzeichnis- oder Datei-Icon vorangestellt, dass im hover-Status seine Farbe ändert.

Der Screenshot 4 zeigt, wie es aussehen sollte. Fährt man mit der Maus über den Text eines Unterkapitels, dann ändert sich nicht nur das dazugehörige Image, sondern auch die Grafiken der übergeordneten Kapitel. Dieses Beispiel wird bis jetzt nur durch Opera 7+ korrekt und vollständig dargestellt. Firefox 2.0 und IE 7 zeigen noch die generierten Inhalte, aber nicht mehr deren hover-Status an, während IE/Win 6 gar nichts ausgibt.

Wie lässt sich dies nun nur mit Hilfe von CSS-Umgehungregeln, ohne JavaScript, so kodieren, dass es in allen neueren Browsern funktioniert? Antwort: gar nicht!

Wir werden gleich den Code für eine ähnliche Darstellung entwickeln, aber die Hervorhebung aller Ahnenelemente exakt wie im Beispiel 8 ist anders mit reinem CSS nicht möglich.

Der Grund dafür ist einfach: es wird dort die Pseudoklasse hover auf das Element LI angewendet. Das hat zur Folge, dass die Maus, wenn sie über einem Element LI ist, sich gleichzeitig über allen Ahnenelementen befindet. Dadurch gelangen gleichzeitig alle Ahnenelemente in den Status hover. Leider kann aber IE bis zur Version 6 hover nur für Elemente A darstellen.

Weiter werden dort die kleinen Icons als generierte Inhalte erzeugt, die im hover-Status wechseln. Generierte Inhalte als solche sind im IE/Win nicht darstellbar, ihre Auswechslung durch den Status hover ist im Firefox (bis Version 2.0) noch nicht möglich.

Und nun zur Realisierung einer cross-browser-tauglichen Darstellung ähnlich der des Beispiels 08. Dazu sind nur drei Schritte notwendig:

Zunächst führen wir in jeder Zeile ein Element A ein. Das ist weiter kein Problem, denn ein Link wird in jedem Punkt der Sitemap sowieso auftauchen müssen. Dies bewirkt, dass diese (eingeschränkte) Lösung auch im IE/Win funktioniert. Wollte man den im Beispiel 8 gezeigten Effekt genauso auch im IE/Win funktional machen, müsste man die Elemente A verschachteln. Haben Sie daran gedacht? Wenn ja, dann denken Sie nicht weiter, es führt nämlich zu Mehrdeutigkeiten im Code und ist deshalb verboten.

Im HTML bringen wir jetzt an diese Elemente A die Darstellung der Grafiken an und entfernen sie an den Elementen LI, d. h. wir ordnen einfach die dazu notwendigen Klassenattribute den Elementen A zu.

Dann ersetzen wir im CSS die generierten Inhalte durch Hintergründe, d.h. die Eigenschaft content in den CSS-Deklarationen wird ersetzt durch die Eigenschaft background-image.
Beispiel 09 zeigt das Ergebnis.

Eine andere denkbare Lösung wäre, die Icons nicht als Hintergrundbilder, sondern als Elemente IMG innerhalb des HTML zu kodieren. Aber neben der Tatsache, dass auch dies immer noch nicht im IE/Win funktioniert, würde dadurch auch der Code unnötig aufgebläht.

Listen mit vorangestellter Nomenklatur

Eine weitere Möglichkeit, Sitemaps darzustellen, wird im Beispiel 10 illustriert, d. h. die gesamte Sitemap wird mit einem Nummerierungssystem versehen, deren Nummern den Stichworten für die Inhalte zugeordnet sind. Es liegt nahe, bei der hier gezeigten Darstellung sofort an eine Tabelle zu denken, auch wenn man weiß, dass Tabellenstrukturen eine Menge unnötigen Code produzieren. CSS bietet aber effizientere Möglichkeiten, den Code so einer Übersicht zu formatieren.

Speziell für Szenarien wie dieses wurden die Eigenschaften zur Steuerung von Zählern in CSS entwickelt (siehe hierzu auch die Erläuterungen zu den Eigenschaften content, counter-increment und counter-reset). Leider werden die beiden letzteren bis heute von keinem der modernen Browser erkannt.

Deshalb wollen wir hier auf eine andere Möglichkeit ausweichen: die Darstellung mit Hilfe von Definitionslisten. Im Beispiel 11 ist die Inhaltsübersicht des Beispiels 10 als einfache Definitionsliste dargestellt.

Jedes Element DD einer Definitionsliste wird automatisch eine Zeile tiefer als das vorhergehende Element DT gesetzt und etwas eingerückt. Das bedeutet, dass wir die Elemente DT und DD vertikal alignieren müssen. Wir ziehen deshalb alle DD mit Hilfe einer negativen margin-top so weit nach oben, bis sie mit den Elementen DT auf einer Höhe liegen. Dazu ist es hilfreich, wenn wir vorher die Zeilenhöhe explizit definiert haben. Die Abstände zwischen den Elementen DD passen sich automatisch an, da jedes Element DD vertikal am vorausgehenden Element DT ausgerichtet wird.

Um eine Überlappung der Elemente DT und DD zu vermeiden, schieben wir alle Elemente DD mit Hilfe von margin-left ein Stückchen weit nach rechts — siehe Beispiel 12.

Zusätzlich kann man noch mit Hilfe einiger CSS-Regeln die Gliederung ein wenig hervorheben, um die Lesbarkeit zu erleichtern — siehe Beispiel 13.

Listen mit vorangestellter Nomenklatur, eingerückt

Ähnlich der im vorhergehenden Beispiel gezeigten Strukturierung gibt es auch die Möglichkeit, die Unterkapitel inklusive Nummerierung nach rechts in den Text einzurücken, so wie es im Beispiel 14 dargestellt ist.

Die Hauptarbeit leistet hierbei aber nicht das CSS, sondern wir erreichen das Einrücken der Unterkapitel durch einen kleinen Trick im HTML, nämlich die Schachtelung der Definitionslisten. Dabei muß man zwei Dinge beachten:

  1. Es dürfen innerhalb einer Definitionsliste beliebig viele Elemente DD und DT hinter- bzw. untereinander stehen — es muß nicht auf jedes DD ein DT folgen;
  2. Die nachgeordnete Definitionsliste muß vollständig sein — das heißt, sie muß einschließlich des Elementes DL innerhalb des übergeordneten Elementes DD stehen. Es reicht also nicht, einfach nur die Elemente DD bzw. DT zu verschachteln.

Beispiel 15 zeigt die Schachtelung der Definitionslisten.

Wenn wir jetzt die Elemente DD nach oben ziehen wollen, wie wir es bereits im Beispiel 12 getan haben, stoßen wir auf ein kleines Problem. Durch das CSS, das wir dort verwendet haben, werden die Inhalte aller Elemente DD genau um die Höhe einer Zeile nach oben gezogen. Da aber die nachgeordneten Definitionslisten innerhalb des Elementes DD verschachtelt sind, werden diese ebenfalls um die gleiche Distanz nach oben gezogen. Das bewirkt, dass die erste Zeile jeder Definitionsliste sich mit der vorhergehenden Zeile der übergeordneten Liste überlappt. Im Beispiel 15a ist dies gut zu erkennen.

Deshalb ziehen wir jede nachgeordnete Definitionsliste wieder nach unten durch ein margin-top mit umgekehrten Vorzeichen an den DL wie im Beispiel 16.

Auch hier können wir durch geeignete CSS-Regeln die Gliederung noch ein wenig deutlicher hervorheben: Beispiel 17.

Die letzten Beispiele dieses Abschnitts, Beispiel 18 und Beispiel 19, machen deutlich, dass diese Codierung nicht nur mit einfachen Titelzeilen funktioniert, sondern auch mit beliebig langen Textabsätzen. Damit lassen sich z. B. kurze Anreißer zu jedem Thema anbringen. Im Grunde genommen ist sie dafür auch besser geeignet.

Sitemap in mehreren Spalten

Anders als in den vorangegangenen zwei Beispielen bestehen die Beschreibungen der Abschnitte und Unterabschnitte einer Website oft nur aus wenigen Worten. Wenn wir also alle Links unserer Sitemap vertikal untereinander anordnen, bleibt rechts oft noch viel Platz. Einigen wird das bei den ersten Beispielen dieser Seite schon aufgefallen sein. Diese Fläche können wir nutzen, um unsere sonst doch recht schmale Sitemap in mehrere Spalten aufzuteilen. Damit vermeiden wir gleichzeitig, dass der Besucher zu viel scrollen muss.

Wir beginnen wie immer mit dem rohen Code. Im Beispiel 20 haben wir verschachtelte ungeordnete Listen. Die erste Ebene besteht aus fünf Listen mit jeweils nur einem Listenpunkt. Wir könnten sie theoretisch auch zu einer einzigen Liste zusammen fassen, damit handeln wir uns aber in einem späteren Stadium einige vermeidbare Schwierigkeiten ein.

Im ersten Schritt stellen wir sicher, dass unsere Deklarationen später eindeutig sind und nicht zu Missinterpretationen führen können. Wir fassen deshalb unsere Liste in einen div-Container ein und geben ihm den Identifizierer sitemap. Aus Gründen der Übersicht geben wir dem Container zunächst eine feste Breite und stellen ihn durch automatische Seitenabstände genau in die Mitte. Auch die fünf Listen erhalten für's erste eine feste Breite. Später werden wir die Aufteilung noch variabler gestalten. Ohne die Breitenangabe passt der Container sich der Breite des umgebenden Elements (hier das Element body) an. Beispiel 21.

Im nächsten Schritt sorgen wir nun dafür, dass wir ein wenig mehr Platz haben und entfernen dazu die Listenpunkte vor den Aufzählungen. Zusätzlich entfernen wir alle Außenabstände an den Listen wie im Beispiel 22.

Damit kommen wir schon zum Kern der Sache: der Aufteilung der Listen in mehrere Spalten. Die meisten haben es sicher schon geahnt: wir erreichen das, indem wir die Listen floatieren. Für jede der äußeren Listen deklarieren wir float:left. Zu jedem Float gehört eine feste Breite, in diesem Fall 200 Pixel. Dazu erhält jeder Float im Beispiel 23 noch Abstände und einen Rahmen.

Wer das Beispiel 23 mit einem standardstreuen Browser ansieht, wird merken, dass unsere Listen sich noch ein wenig merkwürdig verhalten. Die Liste mit der Überschrift 'Sonstiges' sollte unterhalb der längsten Liste der ersten Reihe ganz nach links rutschen. Zudem wird der div-Container nicht bis unter die zweite Reihe aufgezogen (Ausnahme: IE einschließlich Version 7, aber dieses Verhalten ist nicht standardsgemäß).

Wir lösen das erste Problem, indem wir zwischen der dritten und der vierten Liste eine unsichtbare horizontale Linie einfügen, die mit clear freigestellt ist. Dazu reicht uns ein einfacher dimensionsloser Container. Das so deklarierte Block- Element bewirkt, das die folgenden floatierten Elemente so weit nach unten rutschen, bis sie unterhalb dieses Elements zu liegen kommen.

Dieser Container muss aber zwischen zwei Block- Elementen, wie ul, stehen. Steht er zwischen zwei Elementen li, ist das Ergebnis von Browser zu Browser sehr unterschiedlich. Dies ist ein Grund für die Einführung verschachtelter Listen am Anfang und für die Aufteilung in einzelne Listen mit nur jeweils einem Listenpunkt. Der andere Grund ist, dass unser Code so semantisch richtig ist.

Laut Spezifikation sollte es dasselbe Ergebnis bringen, wenn wir die Eigenschaft clear für die vierte Liste ('Sonstiges') deklarieren und auf den zusätzlichen Container verzichten. Leider spielt der IE 7 hier nicht mit. Er scheint das clear:left nur auf ein vorhergehendes Element zu beziehen, aber nicht auf alle.

Wie wir sehen, rutscht damit auch die Unterkante des umschließenden Elements hinunter bis zur Mitte. Wir fügen deshalb nach der letzten Liste einen weiteren unsichtbaren horizontalen Container ein und bewirken damit, dass der div-Container nun auch in den standardstreuen Browsern unsere Listen wirklich umschließt wie im Beispiel 24.

Warum ist das so - warum benötigt man einen weiteren Container, damit das Eltern- Element auch wirklich die Elemente umschließt, die es laut Quelltext einfassen soll?

Es liegt am Float. Die floatierten Teile einer Website sind vom normalen Elementfluss ausgeschlossen. Dadurch wird es möglich, dass der Fließtext seitlich an den Floats vorbeiläuft. Das umschließende Element schließt genau genommen nur die Elemente ein, die dem normalen Fluss unterliegen, nicht die Floats. Es ist also in unserem Beispiel anfangs leer. Danach erhält es als einzigen Inhalt die beiden horizontalen div-Container. Der zweite dieser Container wird durch die Deklaration von clear bis unter die letzte floatierte Liste hinunter geschoben und zieht dabei das Eltern- Element mit auf.

Damit wäre diese Technik im Grunde erklärt. Wir bringen zum Schluss noch ein wenig Farbe ins Spiel, damit das alles nicht ganz so trist aussieht - Beispiel 25.

Nun wollen wir es natürlich nicht bei der festen Breite belassen, sondern unsere Sitemap ein klein wenig flexibler gestalten. Dazu haben wir zwei Möglichkeiten:

  1. Wir halten nur die Breite des äußeren div-Containers flexibel. Davon abhängig werden mehr oder weniger Listen nebeneinander ausgegeben.
    Damit stoßen wir auf das schon in Beispiel 23 erkennbare Problem. Eine floatierte Liste rutscht zwar nach unten, wenn rechts in der Reihe kein Platz mehr ist. Sie rutscht aber nicht gleich ganz nach links, weil eine der vorhergehenden Listen zu lang ist. Die Eigenschaft clear hilft uns hier nicht weiter, da sie dann für alle Floats der Sitemap gelten würde. Deshalb sehen wir uns zuerst noch die andere Möglichkeit an.
  2. Wir machen alles flexibel: den äußeren Container, die Listen und die Abstände. Dabei belassen wir aber die Anzahl der Floats pro Reihe, so wie sie ist.
    Da wir unsere Listen in zwei Schachtelungsebenen haben, ist das recht einfach. Wir brauchen nur für die horizontalen Werte des Boxmodells relative Werte einzusetzen.

Wenn wir uns an die zweite Möglichkeit halten, haben wir auch gleich das der ersten Möglichkeit innewohnende Problem vermieden. Die Breitenangabe des Eltern- Containers kann ganz wegfallen, denn er passt sich sowieso der verfügbaren Breite an. Das Ergebnis ist im Beispiel 26 zu sehen. Verändern Sie ruhig einmal die Breite des Browserfensters.

Bei der Deklaration solcher Breitenangaben mit Prozentwerten sollte man sich immer über die Bezugsgröße für Prozentwerte im klaren sein. Dies ist in der Regel die Breite des umschließenden Blocks. Der umschließende Block für unsere floatierten Listen ist die padding- Innenkante des einschließenden Containers. Haben wir dort also absolute Werte für padding deklariert, beziehen sich die Prozentwerte nur auf die Breite zwischen den padding-Streifen.

Falls wir das padding des div-Containers auch mit Prozentwerten angeben, rechnet der Browser die absoluten Werte dafür abhängig von der Breite von dessen Eltern- Element aus.

Insgesamt sollten wir die Prozentwerte für die Floats so wählen, dass ihre Summe 0.2% bis 0.5% weniger als 100% erreicht. Dadurch wird vermieden, dass ein Browser durch Rundung hier oder da einen Pixel mehr vergibt als insgesamt zur Verfügung stehen. Auch Rahmen, deren Breite ja stets mit absoluten Werten deklariert wird, müssen wir hier berücksichtigen.
TOP

Hinweise:
Die in diesem Beispiel für Verzeichnisse und Dateien verwendeten Icons entstammen Directory Opus, einem sehr empfehlenswerten Dateiverwaltungsprogramm, das auch in deutscher Sprache erhältlich ist.
Dieser Artikel ist seit dem 07. März 2004 online. Unabhängig davon wurden einige der in diesem Artikel vorgestellten Ideen am 30. März 2005 bei A List Apart unter dem Titel Spruced-Up Site Maps veröffentlicht.

Home|Vollreferenz|Schnellreferenz|Grundlegendes|Tutorials & Artikel|Quiz|Allgemeines

© Copyright All Contents 2002-2023
Commercial Use prohibited.

Notizen: