|
|||
![]()
Bitte schaut hier hinein, bevor ein neues Thema eröffnet wird.
Weitergehende Fragen können dann, mit Darstellung der bisherigen Versuche, in einem eigenen Thema diskutiert werden. Bitte stellt spezielle Fragen im Forum, nicht hier. Die FAQ-Liste wird beizeiten erweitert. FAQ - häufige Fragen und deren Antworten ------------------------------------------------------------------------ CSS-Prolog - Welche (globalen) Definitionen sind wichtig und nützlich? F: Wieso stimmt der Abstand da nicht? Wieso zeigt der IE das anders an als andere Browser? A: Es ist sinnvoll am Anfang des CSS mit dem Universalselektor alle browserseitig unterschiedlichen Defaultabstände auf Null zu setzen: Code:
* { margin: 0; padding: 0; } ABER: Formularelemente sollten evtl. beim "globalen Nullen" außen vor gelassen werden, indem man alle übrigen einzeln aufführt (mühsam, aber u.U. sinnvoll): Code:
html, body, p, ul, h1, h2, ... { margin: 0; padding: 0; } F: Die Abstände sind immer noch verschieden. A: Stimmt auch der Doctype? Wenn dieser nicht korrekt angegeben ist, befindet sich der IE im Quirksmodus (auch hier beschrieben) und das Boxmodell wird falsch darstellt. Weitere Anregungen zu einem sinnvollen "CSS-Prolog" ------------------------------------------------------------------------ 1) Container sollen "mitwachsen" - Faux Columns F: Wie kann ein Container die Höhe eines anderen Containers annehmen, der je nach Inhalt verschiedene Höhen hat? Beispiel: ![]() A: Nebeneinander stehende Container können nicht wirklich "mitwachsen". Mit Hintergrundfarben- oder Bildern, welche mit der Faux Columns-Technik eingebunden werden erreicht man, dass es so aussieht, als ob der Container gleich hoch sei. ------------------------------------------------------------------------ 2) Container ragen aus anderen heraus - Clearing floats/Easy Clearing/Clearen ohne Markup F: Container ragen aus anderen heraus, was mache ich falsch? (Problem tritt nicht im IE auf) Beispiel: ![]() A: Es wird nicht oder falsch gecleart. Der Container, der floatierte Elemente beinhaltet, benötigt am Ende ein clearendes Element. Der IE fasst diese floatierten Elemente ohne clearen ein, was aber den Webstandards widerspricht. Hier zwei Erklärungen zu float und clear: Cascading Style Sheets { Vollreferenz zu CSS 1 und CSS 2.1 : FLOAT } und Cascading Style Sheets { Vollreferenz zu CSS 1 und CSS 2.1 : CLEAR } . Wie immer gilt: Erst die Grundlagen verstehen, dann diese vertiefen, und Easy-Clearing anwenden (deutsche Übersetzung). Auch hier im Forum in der Knowledge-base ist ein Beispiel vorhanden. Wichtiges Update: Im obigen Artikel wird display: inline-table; verwendet, was mit dem IE7 nicht mehr funktioniert. Statt dessen sollte es display: inline-block heissen. Hier ein ausführlicher Artikel zum easy-clearing im IE7 ------------------------------------------------------------------------ 3) Tabellenloses Layout / 2- oder 3-Spalten-Layout mit CSS F: Wie erstellt man ein reines CSS-Layout ohne Tabellen? Beispiel: ![]() A: Einfaches Beispiel ohne Beschreibung: Flexible 3 Spalten mit Kopf und Fuss Tutorial für 2- oder 3-Spalten-Layout: "The holy grail" (Vorsicht: der IE7 könnte damit Probleme haben) Komplexe Lösung zum herunterladen: Yet another Multicolumn Layout ------------------------------------------------------------------------ 4) 100% Höhe F: Wie ereicht man, dass eine Seite immer 100% Höhe hat, auch wenn der Inhalt weniger Platz einnimmt? Beispiel:: ![]() A: Wichtig ist zu verstehen, dass eine prozentuale Höhen- oder Breitenangabe sich immer auf die Maße des Elternlements bezieht (so diese dort definiert ist, sonst geht es zu den Grosseltern usw. bis zum <body>). Mit 100% height oder width ist _nicht_ die restliche zur Verfügung stehende Höhe/Breite gemeint. Ein 100px hoher Header und ein 100% hoher Content darunter sind zusammen grösser als 100%, nämlich 100%+100px, es enstünde dann also ein Scrollbalken! Lösungen: 100% Höhe mit floatierenden DIVs 100% Höhe mit Footer stets am unteren Rand, Stichwort "Footer Stick Alt" ------------------------------------------------------------------------ 5) Vertikal zentrieren F: Wie ereicht man horizontale und vertikale Zentrierung? Beispiel:: ![]() A: Wenn ein HTML-Element vertikal zentriert werden soll, geht das mit der CSS-Eigenschaft vertical-align. Diese kann aber nur auf Inline-Elemente oder Tabellenzellen angewendet werden. Vertikales und horizontales zentrieren einer kompletten Webseite und vertikal zentrierte Bilder ------------------------------------------------------------------------ 6) Min- und Max-width auch für den IE F: Der IE kennt weder min- noch max-width. Wie kann man er diese Breiten dennoch einhalten, ohne ihn in den Quirksmodus zu schicken? A: Das geht nur mit etwas JavaScript und Conditional Comments als Browserweiche. Ulle hat in der Knowledge-Base ein sehr gutes Beispiel erstellt. Variante 2: Per ConditionalComment und darin befindlichen einzelligen Tabellen kann dem IE eine max-width untergejubelt werden. ------------------------------------------------------------------------- 7) Fusszeile immer am unteren Rand / "Footer Stick Alt" F: Wie ereicht man, dass eine Fusszeile immer am unteren Rand "klebt" (egal, ob der Inhalt die Seite ausfüllt)? Beispiel:: Contentbereich leer, Fusszeile aber trotzdem am unteren Rand und Viel Inhalt, dann Fusszeile am unteren Rand A: Eine einfache und effektive Technik ist "Footer Stick Alt". Kurze Erläuterung: Der "non-footer"-Bereich erhält eine min-height von 100% (und eine height: 100% für den IE der min-height nicht kennt). Im HTML-Code wird #non-footer dann geschlossen. Erst danach (wichtig!) folgt #footer. Dieser wird mit negativem margin-top "hochgeholt". Die verlinkte Seite beschreibt es ausführlich. ------------------------------------------------------------------------- 8) "Fly-Out" oder "Drop-Down" Menus mit CSS erstellen (und ohne Javascript) F: Wie erstellt man ein Fly-Out / Drop-Down Menu mit CSS (und nach Möglichkeit ohne Javascript)? Beispiel:: A List Apart: Articles: Suckerfish Dropdowns StuNicholls Menus (zu finden unter "Menus - Multi-Level CSS Only" -> ganz ohne JavaScript, aber mit ConditionalComments für den IE) Dazu lesen: Barrierefreies JavaScript, aber besser keine JavaScript-Effekthascherei ------------------------------------------------------------------------ 9) Entwicklungsumgebung Sehr zu empfehlen ist, Webseiten zunächst im Firefox zu testen und erst später den IE anzupassen. In aller Regel zeigt der IE Webseiten nicht korrekt an, wenn die Darstellung im IE dem Wunsch des Gestalters entspricht, ist dies kein Hinweis auf eine korrekt erstellte Seite! Sinnvoller ist es, Seiten erst mit Firefox zu testen und diese später an den IE anzupassen. Essentielles Tool für den Firefox: Der "Web Developer". Damit lässt sich unter anderem das CSS einer Seite live editieren (in der Menubar -> CSS ->Edit CSS) was Änderungen sofort sichtbar macht. Sehr praktisch ist auch das Highlighten der Elemente, auf denen sich die Maus gerade befindet. Dazu in der Web-Developer-Menubar "->Outline->Outline current Element" aktivieren und mal mit der Maus über die Seite gehen. Viele Fragen zu Positionierungen, Breiten, Höhen und Abständen erklären sich dann von selbst. Noch komplexer und detaillierter als der Web-Developer funktioniert die Firefox-Erweiterung Firebug. Wer einmal damit gearbeitet hat, kann nicht mehr ohne. Ein muss für professionelle Entwickler und eine unbezahlbare Hilfe bei der Analyse komplexer Webseiten. Für den Firefox ist der "HTML Validator" ein wichtiges Tool um stets den Quellcode zu validieren und bei Fehlern und Warnungen gleich Hilfestellungen zu erhalten (inzwischen validiert dieses Tool zuverlässig). Zuverlässiges Validieren des Codes geht auch online unter W3C-Validator (oder auch hier).. Oft ist es nötig mit Conditional Comments im HTML-Code, bestimmte IE-Versionen anzusprechen oder auszuschliessen. Um überhaupt für die verschiedenn Versionen des InternetExplorers testen zu können, ist die lokale Installation von multiplen IE-Versionen sehr sinnvoll. Ein Artikel auf positioniseverything beschreibt das vorgehen mit multiplen IE-Versionen und Conditional Commetns Noch ein genereller Tipp: CSS und HTML-Code sollten auch in der Test- und Entwicklungsphase stets getestet und validiert sein, um damit verbundene Darstellungsfehler zu vermeiden! Geändert von hemfrie (29.07.2012 um 17:34 Uhr) Grund: Anker hinzugefügt |
Sponsored Links |
|
||||
![]()
Erstellung von Menüs - und welche Extra-Regeln der Internet Explorer < 8 dafür benötigt
(am 24.07.2010 um weitere Abschnitte ergänzt) Vorab einige Anmerkungen: Sämtliche hier erklärten Methoden und Techniken habe ich erfolgreich getestet im IE-Win ab 5.0 (der IE-Mac bleibt außenvor), Opera ab 7.0, Gecko (z.B. Firefox und Netscape) ab Netscape 7.0, sowie Safari ab 3.0 (ältere Versionen habe ich nicht getestet, dürften aber ebenfalls keine Probleme bereiten). Auch der IE 8 stellt erfreulicherweise alles auf Anhieb korrekt dar, also werden Hacks nur für die IE-Versionen 7 und kleiner benötigt. Voraussetzung dafür ist natürlich ein Doctype, der die IE-Versionen 6 bis 8 im Standardsmode rendern lässt. Und obwohl die meisten der nachfolgend beschriebenen Bugs den IE < 7 betreffen, kann zeitweilig auch der IE 7 betroffen sein (und sei es auch nur ansatzweise). In diesen Fällen helfen die für den IE 6 beschriebenen Methoden auch für den IE 7 einwandfrei. Allerdings muss berücksichtigt werden, dass "hasLayout" (deutsche Übersetzung) beim IE 7 nicht durch das für den IE < 7 beschriebene height: 1px; ausgelöst werden darf, sondern auf eine der anderen in dem verlinkten Artikel beschriebenen Weisen. 10) Vertikale Menüs Um dieses Markup Code:
<ul id="navi"> <li><a href="#">Link 1</a></li> <li><a href="#">Link 2</a></li> <li><a href="#">Link 3</a></li> </ul> Code:
* { margin: 0; padding: 0; } #navi { list-style: none; width: 15em; } Code:
#navi a { display: block; } Oft sieht man zwar auch eine Vertikalzentrierung per line-height, jedoch ist davon abzuraten, da diese Methode erstens sehr ungenau ist, zweitens bei Zeilenumbruch überdimensionierte Zeilenabstände bewirkt, und drittens Text mit großer line-height extrem sensibel auf Textzoom reagiert, d.h. er wandert bei Vergrößerung wesentlich schneller nach unten als bei geringer line-height, so dass die Vertikalzentrierung sehr schnell verlorengeht. Vor allem aus letzterem Grunde sollte für die Vertikalzentrierung von Menü-Texten immer eine geringe line-height gewählt werden, erst recht wenn der Text in einem Menü mit fester Höhe vertikal zentriert werden soll (wovon grundsätzlich allerdings abzuraten ist). In diesem Falle wird die Vertikalzentrierung des Textes erzielt, indem a height und padding-top bekommt (padding-bottom sollte hierbei Null sein). Dank geringer line-height wird sich der Text bei Vergrößerung nur unwesentlich nach unten bewegen, so dass das Menü relativ viele Vergrößerungsstufen verträgt, bevor sein Text überläuft. Da Links nicht auf sich selber zeigen sollten, bietet sich an, auf der jeweils betrachteten Seite den entsprechenden Menülink zu entfernen und durch z.B. <strong> oder <em> zu ersetzen, nach dem Prinzip <li><strong>Home</strong></li>, und dieses Element grundsätzlich genauso zu stylen wie <a>, nach folgendem Prinzip: Code:
#navi a, #navi strong { display: block; padding: 0.5em; } Das sollte übrigens immer gemacht werden, auch bei allen nachfolgend erklärten IE-Hacks: Alle Maßnahmen für <a> müssen immer auch auf <strong> angewandt werden (auch wenn ich es nicht jedesmal explizit schreibe). Alle Browser stellen das Menü damit gleichermaßen dar, mit Ausnahme des IE < 7 für Windows, dessen Darstellung in folgenden Punkten abweicht: 1. Die Links sind nicht über die volle Breite anklickbar (sondern nur ihr Text) 2. Der IE < 7 erzeugt unerwünschte Abstände zwischen den Links (verursacht durch den "Whitespace-Bug", der durch die Zeilenumbrüche im Quelltext ausgelöst wird) Für den IE 6 wird beides behoben, indem die Links hasLayout bekommen, beispielsweise durch eine Dimension in Form von width oder height. Da es allerdings meist umständlich (und ohnehin überflüssig) ist, eine Breite für die Links zu definieren (zumal dies unter Umständen auch eine Boxmodell-Korrektur für den IE 5.x erfordert), kann man den Links auch durch eine Minimalhöhe hasLayout geben. Dies geschieht beim IE < 7 durch height: 1px; (da diese Versionen height wie min-height interpretieren). IE 5.5 und 5.0 stellen das Menü allerdings immer noch nicht einwandfrei dar: Beide rücken die Links etwas nach rechts (genau an die Position, die sie bei der Darstellung mit Listenpunkt einnähmen). Dies geschieht übrigens auch im IE 6, falls #navi floatet und wegen des "Doubled-Float-Margin-Bugs" display: inline; bekommt. Darüberhinaus zeigt der IE 5.0 immer noch kleine Lücken zwischen den Links. Abhilfe für alle Punkte schafft: Code:
#navi li { display: inline; } In manchen Fällen kann es allerdings wichtig sein, dass #navi li z.B. margin- oder padding-Deklarationen bekommt, die es als Inline-Element natürlich nicht mehr uneingeschränkt annimmt. In diesen Fällen kann eine Alternative zu display: inline; angewandt werden: Code:
#navi li { width: 15em; float: left; clear: left; } 11) Einbindung der Extra-Regeln für den IE Alle oben genannten Extra-Regeln dürfen nur vom IE < 7 gelesen werden; dies wird am Besten durch einen Conditional Comment (CC) innerhalb von <head> erreicht (der CC steht hinter - d.h. unter - der Einbindung des Standard-Stylesheets): Code:
<!--[if lt IE 8]> <link rel="stylesheet" type="text/css" href="ie.css" /> <![endif]--> Das so eingebundene Stylesheet "ie.css" wird ausschließlich vom IE gelesen, in den Versionen von 5.0 bis 7, während der IE 8 außenvor bleibt ("lt IE 8" bedeutet "less than IE 8"), da dieser - wie eingangs bereits erwähnt - für alle hier erklärten Techniken keinerlei Hacks benötigt. Weiterhin bleiben auch der IE 4 (und kleiner) sowie der IE-Mac (alle Versionen) außenvor, denn diese Browser kennen keine CCs. Ich empfehle übrigens, nicht jede IE-Version mit einem eigenen CC anzusprechen, sondern ausschließlich den genannten CC zu verwenden und die verschiedenen IE-Versionen darin mit den üblichen Hacks anzusprechen, um nicht am Ende drei oder noch mehr CCs innerhalb von <head> zu haben. Im konkreten Fall enthält das IE-Stylesheet folgende Regeln: Code:
* html #navi li { display: inline; } * html #navi a, * html #navi strong { height: 1px; } 12) Horizontale Menüs Es gibt zwei Möglichkeiten für die horizontale Darstellung: 1. #navi li bekommt display: inline; (die Links dürfen dann nicht als Block dargestellt werden) 2. #navi li bekommt float: left; 12.1) Die inline-Variante Bei dieser Variante wird in der Regel #navi a margin und padding zugewiesen, damit sich die anklickbare Link-Fläche vergrößert und die Links ggf. einen kleinen Abstand zueinander haben: Code:
* { margin: 0; padding: 0; } #navi { list-style: none; text-align: center; } #navi li { display: inline; } #navi a, #navi strong { margin: 0 1em; padding: 0.5em; } Der IE 7 zeigt bei dieser Variante einen Bug beim Zoomen der Seite: Die seitlichen Abstände der Links verschwinden, so dass sie unmittelbar nebeneinander stehen. Abhilfe schafft zoom: 1; für #navi a. Falls sowohl #navi als auch #navi a vertikales padding haben, müssen die Werte von #navi nun angepasst (d.h. etwas verringert) werden, denn im IE werden inline-Elemente durch zoom prinzipiell zu inline-block-Elementen, und werden dadurch von ihrem Elternelement auch anders behandelt. Es schadet übrigens nicht (und ist in manchen Fällen sogar sinnvoll), diese Änderungen auch allen älteren IE-Versionen zu zeigen. Man muss zwar beachten, dass die Eigenschaft "zoom" Microsoft-proprietär und daher nicht valide ist, aber da das entsprechende CSS dem IE per CC zugewiesen wird (siehe oben), kann man darüber hinwegsehen - der CSS-Validator tut dies schließlich auch ![]() Der IE 5.0 kennt die Eigenschaft zoom nicht, lässt sich aber durch height: 1px; zu einem identischen Verhalten bewegen. Und genau diese Deklaration ist im konkreten Fall auch für #navi a nötig, denn fehlt sie, akzeptiert der IE 5.0 (im Gegensatz zu allen späteren Versionen) weder margin noch padding für die Links, so dass das Menü dort quasi in sich zusammenfällt. Nutzt man für sein horizontales Menü die Variante per display: inline; für #navi li, stellt man fest, dass (selbst bei Reduzierung jeglicher margins auf Null) immer ein kleiner horizontaler Abstand zwischen den einzelnen Links bleibt. Dieser entsteht durch den Quelltext-Whitespace (Leerzeichen bzw. Zeilenumbrüche im HTML-Quelltext) zwischen den einzelnen li-Elementen. Was auf den ersten Blick verwundern mag, ist ein normales und völlig logisches Verhalten: Inline-Elemente werden hier ähnlich wie Fließtext behandelt, und bei diesem möchte man ja auch, dass ein Quelltext-Leerzeichen zwischen 2 Wörtern einen kleinen horizontalen Abstand zwischen ihnen bewirkt. Eine mögliche Abhilfe wäre, jeglichen Whitespace zwischen den li-Elementen auszukommentieren oder ihn zu entfernen, indem man alle <li> in einer Zeile direkt aneinander schreibt, aber diese Methode hat den Nachteil, dass dadurch kein Umbruch mehr entsteht, wenn die Links z.B. durch Textvergrößerung nicht mehr nebeneinander in das Menü passen - stattdessen bleiben sie in einer Reihe stehen und "sprengen" das Menü, genau wie ein "endlos" langes Wort. Eine weitere Möglichkeit wäre z.B. margin-right: -.25em; für #navi li, aber auch das ist keine gute Lösung, da nicht alle Browser identische default-Werte für den Abstand der inline dargestellten <li> zueinander haben. Daher ist die sinnvollste Methode zur Entfernung der kleinen horizontalen Zwischenräume, #navi li ohne width-Deklaration floaten zu lassen (siehe nächster Abschnitt), denn bei Blockelementen wirkt sich Quelltext-Whitespace natürlich nicht mehr aus. 12.2) Die float-Variante Die horizontale Menü-Darstellung per Float bietet einige Vorteile, da man es ausschließlich mit Blockelementen zu tun und dadurch mehr Kontrolle über ihre Darstellung hat. #navi li floatet links und kann beispielsweise eine Breite bekommen (die für Links mit längeren Texten auch nach dem Prinzip #navi li.breit anpassbar ist, oder vollständig individuell per ID), und die als Block dargestellten Links nehmen automatisch die volle Breite von #navi li ein. Code:
* { margin: 0; padding: 0; } #navi { list-style: none; } #navi li { float: left; width: 5em; } #navi a, #navi strong { display: block; text-align: center; padding: 0.5em; } Ab CSS 2.1 darf auch ohne width gefloatet werden, und damit kann das sogenannte "shrink-to-fit-width"-Verhalten genutzt werden: Floatende Elemente ohne width-Deklaration werden auf eine ihrem Inhalt entsprechende Minimalbreite "zusammengeschrumpft" (vergleichbar mit Tabellenzellen, wenn weder für sie noch für <table> eine Breite definiert ist). Achtung: Zwar verhalten sich IE/Win ab 5.0, Gecko ab Netscape 7.0, Opera ab 7.0 und Safari hier grundsätzlich identisch (bei mehreren Wörtern innerhalb des Menülinks kann es zwar in absoluten Ausnahmefällen einen Zeilenumbruch geben, jedoch kann diesem mit white-space: nowrap; vorgebeugt werden), aber der IE für Mac stellt Floats ohne width über die volle Breite ihres Elternelements dar, so dass bei einem horizontalen Menü die Menülinks untereinander stehen (als würde ihnen die float-Eigenschaft fehlen). Zu dieser Darstellung kommt es übrigens auch im IE < 7, wenn #navi a display: block; hat und hasLayout gesetzt ist, es allerdings keine width-Deklaration hat. In diesem Falle schafft Abhilfe, außer <li> auch <a> zu floaten (natürlich ebenfalls ohne width). Ich empfehle übrigens, bei ohne width floatenden <li> immer auch <a> ohne width floaten zu lassen, auch für den IE 7. Zuguterletzt ist bei der Float-Variante in jedem Falle wichtig, dass #navi die innerhalb floatenden #navi li einschließt. Dazu gibt es zwei gute Möglichkeiten: 1. #navi floatet ebenfalls (Prinzip "Float Nearly Everything"). Bei dieser Variante sollte #navi unbedingt eine Breite bekommen (u.a. wegen älterer Opera-Versionen), und falls auf #navi ein nicht floatendes Element folgt, braucht dieses ein "clear". 2. Falls man #navi nicht floaten lassen möchte, kann auch "Easy Clearing" auf #navi angewandt werden (siehe oben, Punkt 2 von mazzos Posting, sowie mein nächster Abschnitt). 12.3) Anmerkungen zum "Easy Clearing" "Easy Clearing" (auch als "Clearfix" bekannt) wird von vielen Leuten als kompliziert und/oder "dirty" empfunden, was in erster Linie an der Berücksichtung des IE-Mac liegt, die einige Zusatz-Hacks erfordert. Da sie allerdings nur Sinn ergibt, wenn ein CSS-Autor den IE-Mac auch in allen übrigen (CSS-)Belangen berücksichtigt (und folgerichtig auch in diesem Browser testet), dies aber kaum noch jemand tut, stelle ich nachfolgend eine Variante vor, die den IE-Mac außenvor lässt und dadurch wesentlich kürzer und leichter verständlich wird. Außerdem füge ich noch zwei Deklarationen hinzu, die zeitweilig auftretende Probleme beheben. Vorab noch eine Erklärung, wie "Clearfix" überhaupt funktioniert: Das Pseudo-Element :after fügt unmittelbar vor dem schließenden tag (z.B. </div>) des Elementes, auf das es angewandt wird, einen Inhalt ein. Stellt man diesen als Block dar und lässt ihn clearen, ist der Effekt derselbe, als hätte man im Markup ein leeres, clearendes div eingefügt. Zwar kennt der IE < 8 :after nicht, doch lässt er ein Element seine enthaltenen Floats einschließen, wenn für dieses Element hasLayout gesetzt ist. Die allgemein bekannte clearfix-"Grundregel" ist folgende: Code:
.clearfix:after { content: "."; display: block; height: 0; clear: both; visibility: hidden; } Die komplette Regel lautet also: Code:
.clearfix:after { content: "."; display: block; height: .1px; clear: both; visibility: hidden; font-size: 0; overflow: hidden; } Code:
.clearfix { min-height: 0; } * html .clearfix { height: 1px; } Code:
.clearfix { zoom: 1; } Übrigens sehe ich oft eine unbedachte bzw. unnütze Verwendung der clearfix-Klasse: Man muss im HTML-Code nicht z.B. <ul id="navi" class="clearfix"> schreiben, wenn man im CSS auch #navi:after schreiben und sich dadurch die Klasse im HTML sparen kann. Durch Kommatrennung können der clearfix-Regel beliebig viele Selektoren hinzugefügt werden (z.B. #navi:after, #content:after etc.). Für den IE < 8 müssen dann nur noch die betreffenden Elemente hasLayout bekommen - sofern das überhaupt noch nötig ist, denn hat ein Element z.B. bereits eine width-Deklaration, ist hasLayout ohnehin bereits gesetzt. 13) Ohne width gefloatet und dennoch horizontal zentriert Möchte man seine ohne width gefloateten Menüpunkte nun horizontal zentrieren, steht man vor dem Problem, dass dies bei Floats natürlich nicht ohne weiteres möglich ist. Es gibt mehrere mögliche Lösungen, von denen ich 2 erklären werde. Diese basieren respektive auf folgenden Eigenschaften: 1. display: table; 2. display: inline-block; (diese Variante ist allerdings vor allem in Firefox < 3 unter Umständen instabil) 13.1) Die display-table-Variante (Vorab sei bemerkt, dass die nachfolgende Methode auf Stu Nicholls | CSSplay | Centering Floats basiert, aber dennoch anders ist - Dank geht dabei auch an fricca ![]() Diese Variante nutzt die display: table-Eigenschaften, damit #navi auf die Breite zusammenschrumpft, die die enthaltenen Links erfordern, so dass #navi anschließend per margin: 0 auto; horizontal zentriert werden kann. Ein Bug im Firefox erzwingt bei dieser Variante ein zusätzliches div, denn wie auf der verlinkten Seite beschrieben, kann es dem angedachten CSS-Konstrukt widerfahren, dass der Firefox die li-Elemente zweizeilig anordnet, und um dies zu verhindern, muss eine "echte" Tabellenzeile her, die die Darstellung der li-Elemente in einer Reihe erzwingt. Diesen wird im Zuge dessen auch das float genommen und durch display: table-cell; ersetzt, um eine saubere CSS-Tabelle zu bekommen. Das geänderte Markup sieht folgendermaßen aus: Code:
<div id="navi"> <ul> <li><a href="#">Link 1</a></li> <li><a href="#">Link 2</a></li> <li><a href="#">Link 3</a></li> </ul> </div> Code:
* { margin: 0; padding: 0; } #navi { display: table; margin: 0 auto; } #navi ul { display: table-row; } #navi li { display: table-cell; } #navi a, #navi strong { display: block; padding: 0.5em; } Code:
#navi { text-align: center; } #navi ul, #navi li { display: inline; zoom: 1; } #navi a, #navi strong { float: left; } * html #navi ul, * html #navi li { height: 1px; } Noch ein allgemeiner Hinweis zu dieser Navigation: Falls sie trotz zentrierter Links immer die volle verfügbare Breite einnehmen soll (z.B. für eine durchgehende Hintergrundfarbe), ist das zusammengeschrumpfte #navi natürlich zu schmal. Abhilfe schafft ein div, das um #navi gelegt wird. Zwar sollte man nach Möglichkeit nie einzelne Elemente mit einem div umgeben (wenngleich dies hier bei der Navigationsliste leider unvermeidbar ist), aber da es u.a. für die Nutzer von Screenreadern sinnvoll ist, auch die Navigation mit einer Überschrift zu versehen, wäre folgendes Markup bestens geeignet: Code:
<div id="navi"> <h2>Navigation</h2> <div> <ul> <li><a href="#">Link 1</a></li> <li><a href="#">Link 2</a></li> <li><a href="#">Link 3</a></li> </ul> </div> </div> Möchte man die h2 vor den Nutzern grafischer Browser verstecken, tut man dies einfach durch Code:
#navi h2 { position: absolute; left: -9999px; top: -9999px; } 13.2) Die inline-block-Variante Vorab sei gesagt, dass ich persönlich diese Variante nach Möglichkeit nicht verwende, da sie (wie bereits erwähnt) vor allem in Firefox < 3 unter Umständen instabil ist - spätestens, wenn eine Sub-Navigation hinzugefügt wird, wird das Ganze sehr problematisch. Eine Variante, die auch in Firefox < 3 unter allen Umständen stabil ist, ist zwar möglich, aber wäre extrem aufwendig und ohne weitere Elemente innerhalb der <li> kaum zu realisieren. Auf http://www.brunildo.org/test/indext1.shtml ist eine stabile Variante zu sehen, die für dortigen Zweck natürlich ideal ist, aber meiner Meinung nach für eine Navigation übertrieben wäre, solange es auch einfachere Möglichkeiten gibt, die zum gleichen Ergebnis führen. Aber trotz allem, für ein Menü mit nur einer Ebene ist die inline-block-Methode auch in "einfacher Ausführung" problemlos geeignet, und daher nun ihre Beschreibung: Sie verwendet display: inline-block; statt float für #navi li, so dass diese (trotz enthaltener Links mit display: block; ) nebeneinander stehen und darüberhinaus per text-align: center; für #navi horizontal zentriert werden können. Übrigens ist bei dieser Variante (im Gegensatz zur zuvor beschriebenen table-Methode) im Falle von Überbreite auch ein Zeilenumbruch der Menüpunkte möglich. Allerdings müssen bei dieser Variante auch die Quelltext-Whitespaces zwischen den einzelnen <li> entfernt werden, da andernfalls die bereits erläuterten kleinen horizontalen Abstände zwischen den <li> entstehen würden, die sich per CSS nicht zuverlässig entfernen lassen. Man kann die Whitespaces entweder auskommentieren, oder alle <li> in dieselbe Zeile schreiben, oder den Zeilenumbruch früher machen: Code:
<ul id="navi"> <li><a href="#">Link 1</a></li ><li><a href="#">Link 2</a></li ><li><a href="#">Link 3</a></li> </ul> ![]() Das zugehörige CSS sieht folgendermaßen aus: Code:
* { margin: 0; padding: 0; } #navi { list-style: none; text-align: center; } #navi li { display: -moz-inline-box; -moz-box-orient: vertical; display: inline-block; vertical-align: top; } #navi a, #navi strong { display: block; padding: 0.5em; position: relative; outline: none; } Bei #navi a dient position: relative; dazu, dass sich in Firefox < 1 die gesamte Link-Fläche hovern und anklicken lässt, und dass Opera < 7.5 z.B. eine Hintergrundfarbe für die Links akzeptiert. outline: none; entfernt die Fokus-Outline, deren Erscheinen in Firefox < 3 leider dazu führen würde, dass ein angeklickter Link sein umgebendes <li> (und damit die gesamte Navigation) vertikal ausdehnt. Und da sich auch bei dieser Variante der IE < 8 querstellt (er kennt display: inline-block; nicht), muss ihm das gewünschte Verhalten auf dieselbe Weise beigebracht werden, die im vorigen Abschnitt (über die Variante per display: table; ) beschrieben wurde. Allerdings sollte <ul> dabei außenvor bleiben - es genügt, die beschriebenen Extra-Regeln für <li> und <a>/<strong> zu übernehmen. 14) Horizontales Menü mit vertikal zentrierten ein- und zweizeiligen Links Eine Vertikalzentrierung der Linktexte ist kein Problem, solange sie einzeilig sind, doch sobald auch zweizeilige hinzukommen, muss ein deutlich höherer Aufwand betrieben werden. Für alle guten Browser liegt die Lösung in den table-Eigenschaften, die die gewünschte Vertikalzentrierung problemlos ermöglichen. Da der IE < 8 diese Eigenschaften nicht kennt, wird er nach diesem Prinzip dazu gebracht, den Text immer vertikal zentriert darzustellen. Vorab einige Anmerkungen zu dem nachfolgend gezeigten Code-Beispiel: 1. Auch wenn man möglichst nie einem Element, das Text enthält, eine height-Deklaration geben sollte, ist dies in diesem Falle leider für #navi a nötig, da es keine andere Möglichkeit gibt, alle Links auf dieselbe Höhe zu bringen. Ohne height-Deklaration wären die zweizeiligen Links immer höher als die einzeiligen, und das würde eine Umsetzung des gewünschten Designs unmöglich machen. Verwendet man für height allerdings einen Wert in em und testet das Textzoom-Verhalten seines Menü ausgiebig, ist die height-Deklaration kein Problem. 2. <span> ist für den IE < 8 nötig (damit er den kompletten Text vertikal an <b> ausrichtet, das immer die volle Link-Höhe einnimmt), kann gleichzeitig aber auch sinnvoll für alle guten Browser eingesetzt werden, indem es display: table-cell; bekommt und sein Elternelement #navi a display: table;. 3. Ob man <b> per CC versteckt oder nicht nicht, ist Ermessensache - versteckt man es nicht, ist der Code schlanker, aber dafür steht ein leeres Element im Markup, mit dem einzigen Zweck, dem IE < 8 nachzuhelfen. Hier nun der komplette Code (die durch die 1px-border strenggenommen nötigen minimalen Boxmodell-Korrekturen für den IE < 6 lasse ich außenvor): HTML-Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="de" xml:lang="de" xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Menü-Beispiel</title> <style type="text/css"> * { margin: 0; padding: 0; border: none; font: 100%/1.3 Arial, sans-serif; text-decoration: none; } body { font-size: .8em; padding: 15px; } ul { list-style: none; width: 37.5em; float: left; background: #ffd500; color: inherit; border: 1px solid #000; padding-left: 7em; } li { float: left; width: 6em; border-left: 1px solid #000; } #last { border-right: 1px solid #000; } li * { text-align: center; vertical-align: middle; } a, strong { display: table; width: 100%; height: 3.5em; background: #c00; color: #fff; } span { display: table-cell; padding: 0 1em; } a:hover, strong { background: #fff; color: #000; } </style> <!--[if lt IE 8]> <style type="text/css"> a, strong { display: block; width: auto; padding: 0 1em; } span, b { zoom: 1; padding: 0; } a span, a b { cursor: pointer; } b { height: 100%; } * html ul { width /**/: 44.5em; } * html a span, * html a b { cursor /**/: hand; } * html span { height /**/: /**/1px; } </style> <![endif]--> </head> <body> <ul> <li><a href="#"><span>Text</span><!--[if lt IE 8]><b></b><![endif]--></a></li> <li><strong><span>Text</span><!--[if lt IE 8]><b></b><![endif]--></strong></li> <li><a href="#"><span>mehr Text</span><!--[if lt IE 8]><b></b><![endif]--></a></li> <li><a href="#"><span>Text</span><!--[if lt IE 8]><b></b><![endif]--></a></li> <li id="last"><a href="#"><span>Text</span><!--[if lt IE 8]><b></b><![endif]--></a></li> </ul> </body> </html> Ein Menü, das seinen Text in Form von Hintergrundgrafiken enthält, hat den Nachteil, dass für Besucher, die in ihrem Browser das Laden von Grafiken deaktiviert haben, keinerlei Link-Texte mehr sichtbar wären und die Seite daher nicht mehr navigierbar wäre. Eine einfache Abhilfe wäre natürlich, die Grafiken als <img> mit "alt"-Attribut einzubinden, aber das widerspricht der Trennung von Inhalt und Design, denn bereits eine Grafik mit spezieller Schrift (ganz zu schweigen von zusätzlichen Schatten oder ähnlichen Effekten) ist ausschließlich ein Design-Mittel und gehört daher nicht ins Markup, sondern ins CSS. Doch es gibt glücklicherweise auch die Möglichkeit, zwar Hintergrundgrafiken zu verwenden, aber dennoch bei deaktivierten Grafiken den regulären Link-Text anzeigen zu lassen: Durch die "Gilder/Levin-Methode", auf der meine nachfolgend erläuterte Variante basiert. Diese stellt das Menü in horizontaler Form dar (da diese Variante aufwendiger ist, so dass sie für die vertikale Darstellung nur noch vereinfacht werden muss). Als erstes bekommt jedes Element #navi li seine eigene ID, da ja später individuelle Hintergrundgrafiken zugewiesen werden sollen: Code:
<ul id="navi"> <li id="home"><strong>Home<span></span></strong></li> <li id="team"><a href="#">Team<span></span></a></li> <li id="kontakt"><a href="#">Kontakt<span></span></a></li> </ul> Code:
#navi li { float: left; width: 50px; } #navi #kontakt { width: 60px; } #navi a, #navi strong { display: block; height: 30px; width: 100%; position: relative; } Als erstes wird nun eine allgemeine Regel aufgestellt, so dass anschließend nur die noch Regeln für die Anzeige der individuellen Hintergrundgrafiken benötigt werden. Code:
#navi span { position: absolute; width: 100%; height: 30px; top: 0; left: 0; background: url(navi.png); } Da empfohlen wird, zu Gunsten einer optimalen Website-Performance die Anzahl der HTTP-Anfragen zu reduzieren (sprich: durch möglichst wenig zu übertragende Dateien), bietet es sich an, alle Grafiken zu einer einzigen zusammenzufassen (die im vorstehenden CSS-Code schlicht "navi.png" heißt), und den jeweils gewünschten Teil per background-position in den sichtbaren Bereich des dazugehörigen Links zu rücken. Weitere Vorteile dabei: Es ist keinerlei Preload für die Hover-Effekte mehr nötig, und die Dateigröße einer Grafik, die alle Zustände enthält, ist auch geringer als die Summe der entsprechenden Einzel-Grafiken (u.a. da es insgesamt nur einen Grafik-Header gibt). In dieser Link-Grafik können z.B. in der oberen Reihe alle Link-Texte nebeneinander stehen. Diese Reihe wird dann dupliziert und nach unten versetzt, und bekommt dort z.B. die geänderte Farbe für die Hover-Effekte, so dass man auf der fertiggestellten Grafik schließlich das gesamte Menü zweimal sieht, z.B. einmal oben mit weißem Text, und darunter noch einmal mit rotem Text. Nun muss die Grafik nur noch für jeden einzelnen Link sowie seinen Hover-Effekt an die richtige Position gebracht werden. Dies geschieht nach folgendem Prinzip: Code:
#navi #home a span { background-position: 0 0; } #navi #home a:hover span, #navi #home strong span { background-position: 0 -30px; } Der CSS-Code sieht schließlich wie folgt aus: Code:
* { margin: 0; padding: 0; } #navi { list-style: none; float: left; width: 100%; } #navi li { float: left; width: 50px; } #navi #kontakt { width: 60px; } #navi a, #navi strong { display: block; height: 30px; width: 100%; position: relative; overflow: hidden; } #navi span { position: absolute; width: 100%; height: 30px; top: 0; left: 0; background: url(navi.png); } #navi #home a span { background-position: 0 0; } #navi #home a:hover span, #navi #home strong span { background-position: 0 -30px; } ![]() Code:
#navi a span { cursor: pointer; } Und auch der IE 5.x schießt hier noch einmal quer, denn er kennt den Wert "pointer" nicht - er möchte hier "hand" gesagt bekommen. Dieser Wert ist zwar leider kein gültiges CSS, aber wie bereits weiter oben gesagt: Da das entsprechende CSS dem IE per Conditional Comment zugewiesen wird, kann man darüber hinwegsehen - der CSS-Validator tut dies schließlich auch ![]() Und zuguterletzt gibt es noch einen ärgerlichen Bug des IE 6, der Hintergrundgrafiken beim Hovern "flackern" lässt. Achtung: Er tut dies nur bei einer bestimmten Einstellung des IE, also selbst wenn beim abschließenden Test nichts flackert, bei anderen Nutzern wird dies definitiv passieren! Alle Infos zu diesem Problem stehen auf http://www.fivesevensix.com/studies/ie6flicker/, und ebenso die Ideallösung per .htaccess (zu finden unter "Update - 06/03/2004"). Geändert von heiko_rs (14.12.2010 um 02:18 Uhr) |
Sponsored Links |
|
||||
![]()
Ich würde hier noch die CSS-Spezifität mit angeben.
Die Fragen "warum mein CSS nicht funktioniert" können oft so geklärt werden. Wie (wirklich!) alle Browser diese implementiert haben, wird hier sehr gut in dem MSDN erklärt: Understanding CSS Selectors
__________________
Ich bin keine Signatur, ich putz hier nur |
|
||||
![]()
Da würde ich eine deutsche Ausführung doch eindeutig vorziehen, die kann dann im normalfall wenigsten sprachlich jeder verstehen.:
Spezifität | Webdesign mit XHTML und CSS Die Kaskade - Einführung in CSS - Einführung in XHTML, CSS und Webdesign - Michael Jendryschik SELFHTML: Stylesheets / CSS-Formate definieren / Kaskade - Anwendung von Stylesheets auf Dokumente
__________________
Ohne Quelltext gibts selten Hilfe. Also: Onlinebeispiel hochladen und Link bereitstellen! Foren-FAQ |
|
|||
![]() Zitat:
Laut Bugzilla ist dieser Bug behoben. Oder habe ich etwas falsch verstanden? Und wie sieht es mit neueren IE Verisonen aus? Danke schon im Voraus
__________________
Cu Chullain |
|
||||
![]()
Die Frage ist alt, aber noch aktuell:
Zitat:
Das steht im Beitrag ganz oben (und was für 8 gilt, gilt natürlich erst recht für 9 & 10):
__________________
Wer keinen Link auf seine problembehaftete Seite posten kann, weil diese noch nicht online ist: Testcase bauen, online stellen, Link posten. Internet-Grundregel: Unbekannte Begriffe googeln! (Erspart 99% aller Nachfragen.) |
|
|||
![]() Zitat:
Aber eine CSS-Tabelle die nur aus table und table-cell (einer oder mehreren) besteht ist nicht weniger sauber als eine, die aus table, table-row-group (die darfst du nicht vergessen), table-row und dann erst table-cell besteht. Das ist der Sinn der Erzeugung anonymer Boxen. Im Gegenteil: Wenn du so vorgehst machst du das HTML unsauber. Wohin das führt, sieht man sehr gut am Beispiel Ruby und dem Durcheinander das besteht, weil die Erzeugung anonymer Boxen bei der Erstspezifikation nicht berücksichtigt wurde.
__________________
Über Internet Explorer 8: Noch bis 8. April 2014 wird der Internet Explorer 6 mit Sicherheitsupdates versorgt. Bereits jetzt kann dieser Browser aber vollständig durch den IE8 ersetzt werden. Ältere Betriebssysteme und Browserversionen werden von Microsoft nicht mehr unterstützt. Auch Programme, die den IE7 benötigen, sind kein Argument gegen IE8, da dieser über entsprechende Kompatibilitätsschichten verfügt. Ab sofort gilt daher der Internet Explorer 8 als vorausgesetzer Mindeststandard. |
|
||||
![]() Zitat:
Und bei anderen Beispielen in meinem Beitrag (z.B. der Vertikalzentrierung innerhalb der Navi-Links) verzichte ich ja auch auf ein zusätzliches tr-Element, da dort dessen Garantie für zuverlässige Stabilität nicht nötig ist. Aber letztlich kann das ja eh jeder machen wie er will, und ich sage ja auch nicht, dass es mit einer CSS-Konstruktion von table > td nicht funktioniert. Ein einziges div um die Navi-ul macht das HTML definitiv nicht unsauber.
__________________
Wer keinen Link auf seine problembehaftete Seite posten kann, weil diese noch nicht online ist: Testcase bauen, online stellen, Link posten. Internet-Grundregel: Unbekannte Begriffe googeln! (Erspart 99% aller Nachfragen.) |
Sponsored Links |
|
|||
![]() Zitat:
Zitat:
![]() Nein, das will ich nicht behaupten. In der Regel eignet sich so ein Element ohnehin um die navigationsbegleitende Überschrift zu gruppieren. |
Sponsored Links |
![]() |
Stichwörter |
css, css prolog, doctype, faq, grafische menüs, horizontale menüs, vertikale menüs |
Themen-Optionen | |
Ansicht | |
|
|
![]() |
||||
Thema | Autor | Forum | Antworten | Letzter Beitrag |
Viele grundlegende Fragen die im FAQ nicht beantwortet werden. | Angel-2 | CSS | 13 | 20.05.2011 16:29 |
Interview : Fragen und Antworten | vik.alive | Serveradministration und serverseitige Scripte | 3 | 31.03.2009 12:09 |