Welche Schriftarten kann man im Web einsetzen?

Zunächst ein wenig Theorie. Es gibt folgende Schriftfamilien (englisch: font-family), die in den folgenden Beispielen nur mit ihrem generischen Namen formatiert sind:

  • serif - Eine Schriftart mit Serifen: diese Schriftarten haben sogenannte Serifen, das sind kleine Hilfslinien an den Buchstaben, die den Lesefluß erleichtern sollen. Fast alle Bücher und Zeitungen verwenden deshalb Serifenschriften. Die bekanntesten Vertreter sind Times und Georgia.
  • sans-serif - Eine Schriftart ohne Serifen: die Buchstaben haben keine Serifen und werden in Papiermedien meist für Überschriften verwendet. Bekannte Vertreter dieser Schriftfamilie sind Arial, Verdana und Helvetica.
  • monospace - Eine Schriftart mit dicktengleichen Zeichen: bei diesen Schriften haben alle Buchstaben die gleiche Breite, das kleine i nimmt also genau den gleichen Raum ein wie das große M. Die alten Schreibmaschinen konnten nur solche Zeichen tippen. Ein Vertreter dieser Familie ist Courier.
  • cursive - Eine Schriftart für Schreibschrift: Schräg gestellte Buchstaben können auf dem Computer zwar viele Schriften darstellen, im Web sehen sie aber nur selten gut aus und sind schwer lesbar. Eine Schriftart, die auch für kursiv (italic) designed wurde, ist Comic Sans MS.
  • fantasy - Eine Schriftart für ungewöhnliche Schrift: Diese Schmuckschriften sind höchstens für Überschriften einzusetzen. Diese Schriftart-Familie wird aber im den gängigen Browsern einfach nur als sans-serif angezeigt.

Die Web-Browser haben sich bislang an der Tradition der Printmedien orientiert und verwenden deshalb eine Serifenschrift als Standard, unter Windows ist es Times New Roman. Leider wirkt diese Schrift auf dem Bildschirm völlig anders als auf Papier. Bedingt durch die Pixelstruktur des Mediums (und damit abhängig von der Qualität und Größe des Monitors) können die Serifen nicht deutlich dargestellt werden und den Lesefluss des Betrachters unterstützen. Im Gegenteil, sie erschweren sogar das Lesen, da die Buchstaben nicht sauber voneinander getrennt erscheinen. Überprüfen lässt sich dies an den Beispielen oben.

Deswegen verwenden die meisten Webseiten eine serifenlose Schrift. Unter Windows sind hier vor allem Arial und Verdana verbreitet und auf dem Mac Helvetica. Die Schriftart Arial (die vom Browser wahrscheinlich im obigen Beispiel verwendet wird) hat dabei den Nachteil, dass die Laufweite sehr gering ist, die Buchstaben also dicht bei einander liegen - auch dieses fördert das Lesen nicht unbedingt. Darum geben viele Webdesigner der Verdana den Vorzug gegeben, die speziell für den Bildschirm entworfen wurde.

Da die serifenlosen Schriften auf die Hilfslinien verzichten, haben sie mehr Pixel pro Buchstabe zur Verfügung und nutzen diese zur saubereren Darstellung auf dem Bildschirm - die Schrift wird größer dargestellt als die Serifenfamilie. Deshalb wird bei Einsatz dieser Schriftarten meistens die Schriftgröße verringert (und die Zeilenhöhe vergrößert), da bei zu großen Buchstaben der Überblick in der Satzstruktur verloren geht.

Und damit hat man das nächste Problem: Die verschiedenen Systeme haben eine unterschiedliche Bildschirmauflösung. Während Windows-PC 96 dpi (dots per inch, also Pixel pro Inch) darstellen, sind es bei Mac und Unix/Linux meist nur 72 dpi. Deren Benutzer sehen den Text also kleiner als die "Dosen". Siehe dazu auch den folgenden Abschnitt über das Schriftmaß und vor allem dessen weiterführende Links.

Das Wichtigste beim Einsatz vom Standard abweichender Schriftarten ist jedoch, dass dieser Font auch auf dem Computer des Besuchers dargestellt werden kann, dass er dort überhaupt vorhanden ist. Denn was ein anderer User auf seinem Rechner installiert (oder gelöscht) hat, entzieht sich jeder Kontrolle des Erstellers von Webseiten. Deshalb ist es wichtig, bei der Font-Definition in CSS mehrere Alternativen anzugeben und als letztes den generischen Familiennamen der jeweiligen Schrift, mit dem jeder Browser etwas anzufangen weiß. Also:

font-family: Verdana, Tahoma, Arial, Helvetica, sans-serif;
oder
font-family: "Times New Roman", Georgia, Times, serif;
oder
font-family: "Courier New", Courier, monospace;

Der Browser geht die Definition von links nach rechts durch, und verwendet im Ernstfall die Default Schrift, wie sans-serif oder monospace.
Für einen Vergleich der Schriften im Lauftext habe ich eine Testseite zu Schriftarten erstellt. Da eine gute und ermüdungsfreie Lesbarkeit jedoch nicht nur vom gewählten Font abhängt sondern auch von der Zeilenlänge, ist im unteren Bereich die Textbreite auf 500px begrenzt. Wer einen großen Monitor besitzt, kontrolliere es einmal im Vollbild-Modus. Hier sollte es wesentlich einfacher sein, vom Ende einer Zeile auf den Anfang der nächsten zu springen. Nicht umsonst sind Zeitungsseiten z.B. in mehreren Spalten angeordnet. Aber die Usability von Webseiten ist wieder ein anderes Thema.

Probleme mit Liquid Design

Beim Design von Webseiten unterscheidet man zwischen

  • Ice Design: Alle Bereiche der Seite sind in ihrer Breite pixelgenau festgelegt. Damit bleibt das Layout des Designers bei jeder Browsergröße erhalten.
    Nachteil: Ist mein Browserfenster kleiner als die Vorgabe des Designers, liegt ein Teil des Dokuments außerhalb des Bildschirms und es erscheinen hässliche horizontale Scrollbalken. Beispiel: Webreview CSS Compatibility Chart und alle Seiten "optimiert für eine Bildschirmauflösung von 1024 * 768". Oder das Design ist schmaler als das Browserfenster, dann bleibt rechts ein leerer (weißer) Raum. Beispiele: W3Schools und Spiegel.
  • Liquid Design, die hohe Kunst des Webdesigns: Die Breite der Bereiche passt sich dynamisch dem Browserfenster und der Schriftformatierung an, die zur Verfügung stehende Fenstergröße wird optimal ausgenutzt.
    Nachteil: Bei hoher Bildschirmauslösung und ein Browserfenster im Vollbild-Modus werden Textzeilen sehr lang und damit schwer lesbar. Beispiele: die W3C-Dokumente und Jakob Nielsen's Alertbox.

Kein Designer weiß, wie sein Werk auf dem Bildschirm eines Besuchers aussehen wird. Statistiken wie die von WebHits sagen zwar, dass die Mehrzahl der User einen Bildschirm mit 1024*768 Pixeln besitzen, zunehmend mehr haben eine noch größere Auflösung und nur eine Minderheit benutzt noch einen 800*600er-Bildschirm. Also kann man die Breite von 1024 Pixeln doch ausnutzen, die etwa 90% der Besucher zur Verfügung haben, oder? Falsch, denn die meisten von ihnen werden ihren Browser nicht im Vollbild einsetzen, schon um jederzeit Zugriff auf den Desktop zu haben. Und niemand verändert sein Browserfenster gerne nur wegen einem rücksichtslosen Webdesigner.

Die Zeilenbreite von Fließtext muß ein richtiges Verhältnis von Schriftgröße und Zeilenabstand aufweisen. Nur wenn alle drei Faktoren optimal aufeinander abgestimmt sind, ist eine gute Lesbarkeit gegeben. Als Faustregel hat sich eine Textbreite von 60 - 80 Buchstaben pro Zeile bewährt. Breitere oder schmalere Textzeilen behindern die Lesefreundlichkeit. Wer dieses selber ausprobieren möchte, unter Berücksichtigung von Schriftart und Schriftgröße, kann dieses interaktiv auf meiner Testseite zur Zeilenbreite machen.

Wie kann man eine optimale Zeilenlänge mit Liquid Design erreichen? Hier beginnt die hohe Kunst des Webdesigns. Mehrspaltige Seiten sind dabei flexibler als Einspalter. Während mir bei Glish die prozentuale Aufteilung der Bereiche bei kleinerer Fensterbreite noch nicht optimal erscheint, haben beispielsweise A List Apart und KommKonzept das Problem besser gelöst.

Um das grundlegende Problem der Zeilenläge beim Liquid Design zu lösen, wurden in CSS2 die Attribute max-width und min-width eingeführt. Während Firefox und Opera diese seit langem unterstützen, verweigerte sich der Marktführer Internet Explorer hier bis zur letzten Version 6. Da der IE 7 sich langsam aber sicher durchsetzt, sollte man diese Methoden zur besseren Lesbarkeit von Texten ruhig öfters benutzen als es bis jetzt der Fall ist. Die Leser im Web werden es danken.

in <div> zentrieren

Mit dem gewohnten, in XHTML aber nicht mehr enthaltenen <center>-Tag und align=center war es einfach, Elemente mittig auszurichten. In CSS heißt es jetzt text-align:center und gilt nur noch innnerhalb von Block-Elementen, etwa Absätzen, Tabellen oder Div-Bereichen.

Um eine <div>-Box selber horizontal auf dem Bildschirm zu zentrieren, wird in Standard konformen Browsern seine margin auf auto gesetzt.

  <div style="width: 200px; margin: 0px auto">
    Hallo Welt
  </div>

Zu den Browsern, die dieses verstehen, gehören Firefox, Netscape 6+, der Internet Explorer 6+ und Opera 7+. Ältere Browser, aber auch der IE im Quirks-Modus, kennen es nicht und ignorieren die Angabe. Bei den Oldies klebt die Box am linken Bildschirmrand.

Ein Workaround, der auch alte Browser befriedigt, ist, den zu zentrierenden Bereich in einen anderen Bereich einzubetten, der seinen Inhalt dann mit text-align zentriert. Notfalls ist als übergeordneter Bereich auch der <body> des Dokuments zu verwenden.

  <div style="text-align: center">
  <div style="width: 200px; margin: 0px auto; text-align: left">
    Hallo Welt
  </div>
  </div>

Man beachte, daß durch die Vererbung das text-align vom übergeordneten Element bzw. <body> auf alle enthaltenen Elemente übergeht. Will man dieses ausschalten, muss ihre Ausrichtung eigens wieder auf left gesetzt werden. Etwas umständlich, aber problemlos machbar.

Problematischer ist eine vertikale Zentrierung auf dem Bildschirm zu erreichen. Ein height=100% hat früher bei Tabellen mehr oder weniger gut funktioniert, gehörte aber nie zum HTML-Standard und verhindert heute, dass ein Dokument valide ist. Und wo ist die Mitte eines Browserfensters anzusetzen? Sind Sidebars, Tableisten, Toolbars, Statuszeile usw. berücksichtigt? Macht ihre Vernachlässigung nicht vielmehr das ganze angestrebte Design zunichte? Von den Möglichkeiten alternativer Displays ganz zu schweigen. Die Tipps in den unten angegebenen Verweisen können mich jedenfalls nicht überzeugen.

Die oben vorgeschlagene Lösung zur horizontalen Zentrierung ist problemlos einsetzbar. Weitere Tricksereien, etwa zur vertikalen Zentriertung, mögen für eine einfache Message-Box noch sinnvoll sein. Ansonsten halte ich sie jedoch für höchstens theoretisch interessant, in der praktischen Umsetzung aber nicht nutzbar. Es durchbrecht die logische Anordnung der Elemente auf dem Bildschirm, ihre sichere Umsetzung in allen Umgebungen und die Zusammenwirkung mit anderen Elementen ist viel zu ungewiss. Es gilt vielmehr, den normalen Fluss der Bereiche zu verstehen und ihn sinnvoll zu nutzen. Siehe dazu CSS Positionierung und der Fluß der Elemente.

Ursache vieler CSS-Probleme im IE - hasLayout

Entwickelt man moderne Webseiten und vergleicht sie in allen gängigen Browsern, stößt man des öfteren auf scheinbar merkwürdige Besonderheiten im Internet Explorer (alle Versionen). In den meisten Fällen handelt es sich Auswirkungen eines Konzeptes, das nur der IE kennt und das nicht einfach zu verstehen ist: die Eigenschaft hasLayout.

Anders als andere Eigenschaften in CSS wird es im IE den Objekten nicht extra zugewiesen, sondern bestimmte Elemente haben automatisch "Layout", anderen wird es stillschweigend mit bestimmten CSS-Angaben hinzugefügt. Ob ein Element "Layout" hat oder auch nicht, kann u.a. folgendes nach sich ziehen:

  • Viele bekannte IE-Fehler im Zusammenhang mit float
  • Die betroffenen Boxen selbst behandeln grundlegende Eigenschaften unterschiedlich
  • Zusammenfallende Ränder zwischen einem Container und seinen Nachfahren
  • Verschiedene Probleme bei der Erstellung von Listen
  • Unterschiede beim Positionieren von Hintergrundbildern
  • Unterschiede zwischen Browsern beim Einsatz von Scripts

Wenn man auf Merkwürdigkeiten des IE in diesen (oder anderen) Fällen stößt, sollte man zunächst einmal versuchen, die Layout-Eigenschaft des betreffenden Elements zu erzwingen durch Hinzufügen von zoom: 1. Diese Eigenschaft bewirkt (außer dem Layout-Modus im IE) nichts: sie gilt nur für Microsofts Browser und bewirkt eine Größenveränderung um den Faktor 1, also gar nicht. Allerdings ist die Seite dann nicht mehr valide, aber zum Testen reicht es allemal. Eine andere und valide Möglichkeit wäre, der betreffenden Box ein position: relative zu geben, falls es im Seitenkonzept problemlos ist.

Wer genaueres über das noch immer nicht ganz erforschte Konzept des IE wissen will oder muß, sollte sich durch den Artikel On having layout - The concept of haslayout in IE/Win oder seine deutsche Übersetzung Über hasLayout - das Konzept im IE/Win quälen. Es ist kein leichter Stoff und auch nicht immer logisch, eher ein tragischer Fall von "IE Voodoo".

CSS Hacks - Browser austricksen, pro & kontra

Leider ist die Unterstützung modernen CSS noch nicht in allen Browsern gleichmäßig verwirklicht, vor allem die älteren Versionen (Netscape 4, IE 5, teilweise auch IE 6) neigen dazu, ein valides Stylesheet nur fehlerhaft anzuzeigen. Hier kommen jetzt die Trickser zum Zuge, die mit ausgeklügelten Hacks spezielle Anweisungen vor speziellen Browser zu verstecken suchen. CSS-Hacks sind nicht anderes, als eine Unzulänglichkeit eines Browser durch eine andere Unzulänglichkeit zu umgehen.

Ich stehe diesen Tricksereien jedoch eher skeptisch gegenüber. Sie machen die an und für sich einfache und logische Struktur von CSS zunichte und erschweren die Weiterentwicklung von Webseiten. Fängt man erst einmal mit Hacks an, ist das Konzept für Änderungen und Erweiterungen nahezu verbaut. Und wenn eine neue Browserversion einen Teil eines Hacks beherrscht, muss die ganze Seitenstruktur neu angelegt werden. Der Artikel von Peter-Paul Koch Keep It Simple, the Lure of CSS Hacks, deckt sich deshalb weitgehend mit meiner Auffassung. Lediglich Tricks gegen alte Browser, die nicht mehr weiter entwickelt werden, lässt er gelten. Ich ergänze: Gegen Microsofts Oldies helfen problemlos Conditional Comments, alles andere ist von Übel.

Darum ist der richtige DOCTYPE wichtig

Zuerst einmal: Bisherige Seiten, die kein modernes CSS verwenden, brauchen diese Angabe nicht. Wer allerdings neuere Techniken nutzen will und dabei erwartet, dass eine Webseite in allen Browsern (annähernd) gleich dargestellt wird, muß die richtige Document Type Deklaration (DTD) an den Anfang seines Dokuments stellen. Nur dann rendern moderne Browser ein Dokument so wie es in diesen Spezifikationen festgelegt ist. Warum das so ist und wie der DOCTYPE richtig angegeben wird, beschreiben die unten verlinkten Artikel.

Wer überprüfen will, ob eine Webseite den (X)HTML- und CSS-Standards entspricht oder nicht, tippe oder kopiere
javascript:alert(document.compatMode)
in die Adresszeile seines Browsers auf entsprechenden Seiten. "CSS1Compat" als Ergebnis bedeutet moderner Standard-Modus, "BackCompat" ist eine im alten Stil erstellte Webseite im Quirk-Modus mit allen Unzulänglichkeiten und browserspezifischen Eigenheitenen, zum Beispiel beim Box Model; diese Seiten haben dann eine Macke (engl.: quirk).

Den Codeschnipsel zur Ermittlung des Kompatibilitäts-Modus gibt es hier auch als Bookmarklet: compatMode.

Einige Webseiten wollen eine XML-Konformität dadurch erreichen, dass sie dem Dokument zusätzlich die XML-Deklaration <?xml version="1.0" encoding="ISO-8859-1"?> voranstellen. Das bewirkt unter den heutigen Gegebenheiten aber genau das Gegenteil: es ist für XHTML nicht nötig, schaltet dafür aber den IE 6 in den nicht Standard gemäßen Quirk-Modus. XML ist nur dann sinnvoll, wenn die Seite auch als application/xml ausgeliefert wird, doch das kann der IE bisher nicht darstellen. Also unbedingt weg lassen!

Der W3C-Validator bemängelt color-Definition

Da hat man seine Webseite zufriedenstellend fertig gestellt, sie funktioniert auch auf allen Browsern und nun prüft man sie noch mit dem W3C-Validator auf syntaktische Richtigkeit. Doch der fängt an sich zu beschweren und stößt jedesmal, wenn man für ein Element eine Farbe festgelegt hat, eine Warnung aus: "Sie haben keine Hintergrundfarbe zu der Vordergrundfarbe angegeben". Das war doch so gewollt, die Hintergrundfarbe ist global festgelegt und braucht doch eigentlich nicht ständig wiederholt zu werden.

Hier sind die Standards meiner Meinung nach überpenibel. Man wollte wohl verhindern, daß durch die Vererbung auf untergeordnete Elemente sich ungewollte Hintergrundfarben einschleichen. Als ob man sich seine Webseiten nicht gelegentlich selbst einmal im Browser ansieht.... Ich halte diesen Zwang zur ständigen Wiederholung der Hintergrundfarbe sogar für kontraproduktiv: Will man die Farbe einmal wechseln, muß man sie nicht nur einmal im übergeodneten Element ändern, sondern vielfach.

Doch auch hier gibt es einen Trick: wählt man background-color: transparent, bleibt die Hintergrundfarbe wie sie ist und der Validator ist zufrieden gestellt. Tja, er ist eben auch nur ein Computer-Programm. Aber das sind die Browser ja auch.

Weitere interessante Tipps & Tricks zu den Themen Windows, Suchmaschinen, Internet und Benutzer-Freundlichkeit gibt auf dieser Seite www.connexin.net/de/ die auch von uns betreut wird.