Die meisten von uns haben ja sicherlich bereits von Listen in HTML-Dokumenten gehört, die gibt es als <ol>, <ul> oder auch <dl> (wozu es übrigens erst kürzlich einen tollen Artikel gab). Oftmals verwenden wir dabei Symbole zum verdeutlichen von Funktionalitäten, wie wir es etwa im Beispiel-Screenshot sehen können. Wir schalten die Listenpunkte durch list-style: none; im CSS einfach ab und verpassen den jeweiligen Punkten ein Symbol wie z.B. ein kleines Häuschen als Symbol für die Startseite.
Zur Realisierung solch grafischer Listenpunkte gibt es im Prinzip 3 Herangehensweisen die ich erst einmal kurz vorstellen möchte:
1. Einbindung der Grafik durch CSS mittels list-style-image
Hierbei wird das jeweilige Element, also meist li, dt oder dd mittels CSS angesprochen und über die CSS-Eigenschaft list-style-image eine alternative Grafik als Bullet-Symbol definiert. In der Praxis wäre also z.B. folgendes denkbar:
ul#navigation li.startseite{
list-style-image: url(images/homepage.gif);
}
Das Problem an dieser Technik ist, dass sie nicht wirklich flexibel ist, denn man kann wirklich nur eine Grafik hinterlegen und keine weiteren “Optionen” wie z.B. Wiederholungen oder Hintergrundverschiebungen angeben.
2. Einbindung der Grafik durch CSS mittels background
Bei dieser von mir bevorzugten Technik schaltet man zuerst mittels list-style: none; die Standard-Bullets der Listenpunkte ab und verpasst dem List-Item mittels CSS und background bzw. background-image die richtige Grafik. Damit nun der Text des Listenpunkts nicht das Symbol überlagert muss man nur noch mittels padding den Inhalt der Liste aus dem Bereich der Grafik verschieben. Das könnte dann in der Praxis so aussehen:
ul#navigation li.startseite{
list-style: none;
padding-left: 25px;
background: #000 url(images/homepage.gif) no-repeat left center;
}
Hier sieht man auch schon direkt die Vorteile dieser Technik, man hat mehr gestalterische Möglichkeiten. Man kann zum einen direkt die hinterlegte Hintergrundfarbe bestimmen, das Wiederholungsverhalten sowie die Position der Hintergrundgrafik.
3. Einbindung mittels <img />
Die ersten beiden Möglichkeiten behandelten jeweils die Formatierung mittels CSS. Es ist aber natürlich auch möglich die jeweiligen Grafiken direkt ins HTML einzubinden und später mittels CSS nur noch deren Position anzugeben. Das HTML dazu kann in unserem Fall also z.B. so aussehen:
<ul> <li><img src="images/homepage.gif" alt="Icon: Homepage" /> Homepage</li> <li><img src="images/persona.gif" alt="Icon: Persona" /> Persona</li> </ul>
Der “Vorteil” den diese Technik hat ist, dass die Symbole fest im HTML verankert sind, somit eben auch von Screenreadern erfasst werden können und auch bei abgeschaltetem CSS noch sichtbar sind.
Gerade die letzte Variante begegnet mir seit einiger Zeit wieder häufiger. Die Frage die ich mir dabei stelle ist, sind solche Symbole wirklich ein Fall fürs Markup oder doch eher für die CSS-Datei? Ist es semantisch korrekt eine eher schmückende Listengrafik über den HTML-Output zu steuern? Bei einer großen Liste kann hier zudem auch das Dokument ziemlich aufgebläht werden. Die Pflegbarkeit ist z.B. bei verschiedenen Farbvarianten einer Seite auch über CSS besser lösbar.
Wie seht ihr das? Listensymbole eher ins HTML, oder doch wie ich es bisher mache über ein externes Stylesheet?
Kommentare zum Thema Symbole in Listen via CSS oder HTML einbinden?:
2
II
2
Definitiv Variante 2.
Das grosse Problem von Variante 1 (die ja eigentlich als die “native” Lösung zu bevorzugen sein sollte) ist die sehr schlechte Positionierbarkeit der Grafiken.
Variante 3 kann (bei anderen Anwendungen als der im Beispiel) hilfreich sein um zusätzliche Informationen fuer Screenreader zu transportieren.
Variante 2 aus den von #7 genannten Gründen. Die Unterschiede in der Positionierung sind extrem. Ich hatte mal mehr oder minder das gleiche in einem Post geschrieben und (wenn ich so frei sein darf das so zu verlinken) diese Animation erstellt. Unten Background, oben nicht. Da stellt sich die Frage nach der Methode gar nicht mehr.
@Michel Naja, ehrlich gesagt bin ich ein fauler Sack, und wenn bei der Textvergrößerung nicht mehr alles total perfekt aussieht, dann lasse ich das meistens durchgehen, da eh alle Browser nach und nach zum Fullpage-Zoom übergehen und das Problem damit eigentlich aus der Welt ist. Ich finde wirklich mitzoomende Layouts bekommt man nur in einem begrenztem grafischem Rahmen ohne einen riesen Mehraufwand hin, so zumindest meine Erfahrung.
@Peter Ja klar, immer her mit guten Links ;) Ja genau das Verhalten hatte ich damals auch beobachtet warum ich auch seit jeher Variante 2 benutze.
Ganz klar: 2
Das ist nach meiner Efrahrung nicht so eindeutig. Gerade in Sachen Zugänglichkeit bietet das <img /> einige Vorteile für Menschen mit Sehbehinderung. Diese surfen oft mit lokalen Einstellungen, die dann Hintergrundbilder wegschlucken. Im Markup bleiben sie erhalten und wenn man die Größe via CSS noch mit em definiert, skalieren sie auch noch mit.
Die alt-texte kann man weglassen oder sie auch ergänzend benennen.
Auch für Screenreader kann das von Vorteil sein. Denn Wenn man <img verwendet, wird es eine Art Navigation sein. Dadurch kann man sie von anderen Listen im Inhalt unterscheiden, also bspw. mit img ist es die Sevrice-Navi, mit <dfn> die Inhaltsnavi, mit a, b, c die Gedönsnavi und alles andere sind normale Listen im Inhalt.
Einzig Variante 1 hat sich als unpraktisch heraus gestellt. Und in Sachen trennung von Inhalt und Präsentaiton dürfte es sich um einen Grenzfall handeln.
Kommt drauf an: wenn die Listenpunkte weitgehend statisch sind kann 1. Vorteile haben.
2. ist einfacher zu handhaben, wenn die Inhalte dynamisch zusammengestellt werden, wobei es da immer noch die Alternative mit einem Style-Attribut gibt.
Da solche Symbole jedoch meistens mit Links verwendet werden, würde ich die Grafik als Hintergrundbild im A-Tag setzen und nicht im LI. Damit kann dann auch das Bild angeklickt werden und ich kann es mit :hover oder :visited austauschen.
Kommentar-Feed für diesen Artikel
Nutzt Google Analytics als Ranking-Kriterium? Antworten zu Webentwicklung und Webdesign
bin für punkt 2 :-) wenn schon punkt 3, dann bitte ohne alt-attribut. benutzer mit screenreader lassen sich ungerne alles doppelt vorlesen.