Stylesheets für jeden Browser

Nicht jedes Element wird auch in jedem Browser richtig angezeigt. Einige sollen angeblich fehlerfrei funktionieren, beim Einsatz zeigen sich dann jedoch die Fehler. Der Interpretationsfehler in Netscapes Navigator zählt zu dieser Kategorie:

Dieses Beispiel definiert den <H2>-Tag neu: Die Schrift wird zu Verdana geändert, oberhalb des Tags wird ein Abstand von 30 und unterhalb ein Abstand von 10 Pixel angegeben. Netscape 6 und der Internet Explorer zeigen das auch korrekt an. Im Gegensatz dazu zeigt Netscape 4.7 beide Abstände genau gleich gross an.

Der Netscape Navigator hat ein eigenartiges Verhalten: Einem Titel des Typs <H2> fügt er immer oben und unten 20 Pixel an. Zum im Stylesheet angegeben unteren Rand von 10 Pixel zählt Netscape Navigator nun noch die 20 Pixel des <H2> -Tags hinzu, zeigt also schliesslich einen unteren Abstand von 30 Pixel an.

Falls es nun aber genau auf diese wenigen Pixel ankommt, hat man mit dieser Variante ein Problem. Der Workaround ist aber schnell gefunden:

Über eine Klasse in Verbindung mit einem <DIV>-Tag kann man den ursprünglichen <H2>-Tag simulieren. Netscapes Navigator trägt dann auch keine Assoziationen mit und interpretiert das Stylesheet nicht mehr falsch. Allerdings hat diese Methode einen Nachteil: Suchmaschinen oder Text-basierende Browser wie Lynx haben Probleme mit derartigen Workarounds, weil sie die Wichtigkeit eines Abschnitts nicht einschätzen können. Ob man damit leben kann, muss jeder für sich selbst entscheiden.

Das nächste Beispiel ist schon einer der schwerwiegenderen Fälle. Der Fehler im Element background-color ist schon aus den meisten Buglisten ersichtlich.

Mit dieser Angabe soll der Text in einem Abschnitt (zwischen den Tags <P> und </P>) einen farbigen Hintergrund erhalten. Dieser Hintergrund müsste eine Art Box darstellen und sich über die ganze Zeile zeigen. Netscapes Navigator 4.7 ist im Gegensatz zur Referenz der Meinung, dass direkt hinter dem letzten Buchstaben der Hintergrund beendet werden sollte und zeigt den Hintergrund nicht über die ganze Zeile an.

Umgehen lässt sich das nicht richtig. Man könnte um den Textblock einen Rand mit der selben Farbe wie der Hintergrund definieren, womit dann das “Ausfransen” des Textblocks verhindert würde. Trotzdem wird damit der Hintergrund nicht über die ganze Zeile angezeigt.
Im Prinzip hilft hier nur eine HTML-Tabelle, wobei dies nur sinnvoll ist, wenn man sowieso mit Tabellen arbeitet. Wer bei einem reinen CSS-Layout bleiben will, ist dazu gezwungen, einen Layer oder eine Box um den Text zu legen.

<table width="100%">
<tr>
<td style="background-color: #88CCEE;">CSS in Tabelle</td>
</tr>
</table>

Im obigen Beispiel wird eine Tabellenzelle mit einem farbigen Hintergrund versehen. Wer gleich die ganze Tabelle oder Zeile identisch formatieren will, muss jedem <TD> -Tag die Style-Definition anfügen, da sich auch hier Netscape Navigator 4.x nicht an die Richtlinien hält.

Eine Lösung via @import

Wenn sämtliche Workarounds nicht mehr weiterhelfen, lohnt sich ein Blick auf die CSS-Anweisung @import. Diese dient dazu, Stylesheets ähnlich zu <link rel="stylesheet" href="style.css"> einzubinden. Allerdings funktioniert dies nicht im Netscape Navigator 4.x und Internet Explorer 3 .x. Dies hat einen Vorteil: Man hat ohne grössere Probleme eine Browserweiche geschaffen, indem man die problemlosen Style Sheets in eine Datei schreibt und sie normal mit dem HTML-Dokument verknüpft und die gefährlichen Stylesheets wie Breitenangaben, Schriftgrössen oder sämtliche Definitionen für Boxes in eine andere Datei schreibt, welche über @import aufgerufen wird.

Interpretationsfehler in IE 5.x und Navigator 6

Im Vergleich zu den älteren Versionen wurden die Browser um einiges verbessert. IE 5.0 hat noch einige nur teilweise unterstützte Funktionen, die meisten Lücken bei Elementen, welche für eine nur auf CSS gestützte Seitengestaltung nötig wären.

Diese Lücken verhindern, dass Stylesheets für die reine Seitengestaltung eingesetzt werden können. Das W3C empfiehlt diesen Einsatz zwar, doch man ist immer noch auf einen Mix aus Tabellen in HTML für die Gestaltung der Seiten und CSS für die Formatierung angewiesen.

Ärgerlich sind vor allem die fehlerhafte Interpretation von Grössen. Die Browser wissen z.B. nicht, wie gross ein Pixel ist, was man eigentlich erwarten dürfte. Teilweise werden bei fehlenden Angaben auch irgendwelche Formate angenommen, was sowohl im IE als auch im Netscape nervt.

In diesem Beispiel wurden bewusst die Pixel bei der Definition des linken Randes weg gelassen. Der Browser sollte entweder einen Error ausgeben (was generell nicht passiert) oder mindestens das Element ignorieren. Statt dessen wird angenommen, dass der nicht näher definierte Wert 40 als Pixel aufzufassen und entsprechend zu verarbeiten ist.

Schriftgrössen sind wohl das grösste Problem bei der Erstellung von Stylesheets. Zwar liegen die Grössenunterschiede zwischen den einzelnen Plattformen im Bereich von bis zu drei Pixel, was an und für sich nicht besonders viel ist, aber bei der Operation mit kleinen Schriftgrössen die Grenze der Lesbarkeit überschreiten und nebenbei noch das Design der Website zerreissen kann. In der Regel empfiehlt man deshalb, dass man von einer Definition der Schriftgrössen absieht und den Browser die Standardgrösse verwenden lässt.

Dies hat jedoch aus ästhetischen Gründen Nachteile: Schriftsätze wie Verdana oder Tahoma, welche auf das Internet ausgelegt sind, werden sehr gross dargestellt, was besonders unter Windows stört. Auch ist die Schriftgrössen überhaupt nicht mehr vorherzusagen, da der Benutzer jetzt selber Hand anlegen kann. Dies ist zwar aus der Sicht der Benutzerfreundlichkeit ein positiver Effekt, kann aber oftmals für die Gestalter ziemlich frustrierend sein, wenn das Design dadurch zerrissen wird. So ist man öfters doch dazu gezwungen, die Schriftgrössen zu definieren und deshalb den Kampf mit den Ungenauigkeiten aufzunehmen.

Die Definitionsgrössen für die Schrift sind in CSS ziemlich vielfältig. Wählen kann man nicht nur zwischen Pixeln und Punkten, sondern neben diversen relativen Angaben auch zwischen Zoll, Millimeter, Zentimeter und Pica. Leider nützt die grosse Palette an Möglichkeiten im Endeffekt wenig, da die Browser mit den Grössenangaben nach Lust und Laune verfahren.

Ein kleiner Test mit Netscape 4.7 und IE 5.5 unter Windows zeigt schon am Bildschirm einen Grössenunterschied. Der Ausdruck zeigt aber noch klarer, dass die Schriften unterschiedlich gross sind. Zwar beträgt der effektiv gemessene Unterschied etwas weniger als 0.5 mm, ist aber trotzdem schon auffällig und darf nicht sein. Der Unterschied zwischen Windows und Mac fällt da um einiges grösser aus. Diese Differenzen beschränken sich nicht alleine auf die Einheit Zentimeter, sondern sind überall zu beobachten, wobei sie natürlich unterschiedlich gross ausfallen. Eine Sonderstellung nimmt hierbei die Einheit Prozent an, bei welcher die Unterschiede ohne Mühe zu erkennen sind.

Lösungen sind rar und haben schon viele beschäftigt. Der Ruf nach der Browserweiche ertönt meist als erstes, weil diese aber meist zu kompliziert ist, will man wieder auf die alten Font-Tags aus HTML zurückgreifen, um die es aber kaum besser bestellt ist.

Das Erscheinungsbild und langes Nachmessen attestieren der Einheit Pixel die besten Eigenschaften, weil die Unterschiede selbst am Bildschirm marginal und wohl der kleinste gemeinsame Nenner sind, da Pixel einerseits die computereigene Masseinheit und ein Pixel sowohl auf dem Mac als auch auf dem PC gleich gross ist. Die Unterschiede zwischen Browser und Plattformen kann man als Rendering-Ungenauigkeiten auf die Browser abschieben, welche aber höchstwahrscheinlich nicht sehr schnell behoben sein werden.

Ein anderer Fall als die allgemein bekannten Elemente sind die Eigenentwicklungen der Browserhersteller, welche fast immer von Microsoft stammen und somit nur den Benutzern des Internet Explorer zu Teil werden.

Wohl bekanntestes Beispiel sind die Pseudo-Klassen rund um a:hover, welche in sämtlichen Varianten des Internet Explorer 4 und Netscape 6 für Links sorgen, die bei Berührung die Eigenschaften verändern, sofern die Elemente definiert sind.

Ein Effekt aus neuerer Zeit ist die anpassbare Scrollbar, die ebenfalls nur im Internet Explorer ab Version 5.5 zu betrachten ist:

Auch wenn man über Sinn und Zweck solcher Effekte streiten kann, sind sie im Gegensatz zu anderen CSS-Elementen gefahrlos zu benutzen, da Microsoft seine Funktionen durch die Implementation selber bestimmt. Falls das W3C diese Vorschläge einmal in den Standard aufnehmen würde, wie dies schon mit a:hover geschehen ist, kann man davon ausgehen, dass es auch bei der Konkurrenz keine Probleme damit geben wird.

Fazit

Abschliessend lässt sich sagen, dass ein Gebrauch von CSS im Prinzip ungefährlich ist, so lange nicht die ganze Seite auf jedem System und jedem Browser gleich aussehen muss. Wichtig ist, dass man Kompromisse eingeht und abschätzt, wie wichtig welche Zielgruppe ist und wie man sie am besten berücksichtigen kann.

Wer eine kommerzielle Website erstellen muss, hat natürlich darauf zu achten, dass die Website nahezu fehlerlos ist oder die Fehler mindestens nicht sichtbar sind. Deshalb sollte man weiterhin das Layout einer Website über eine Tabelle bestimmen und Text, Titel, eventuell auch Hintergründe über CSS definieren.

Komplette Layouts gemäss der W3C-Empfehlung mit Stylesheets zu codieren, ist nicht zu empfehlen, da vor allem mit Netscapes 4.x mittelschwere Darstellungsunfälle fast nicht zu vermeiden sind.