Als das W3C Ende 1996 die Spezifikation zu CSS1 verabschiedete, sollte den Webdesignern ein Werkzeug zur genauen Gestaltung einer Website in die Hand gegeben werden. Denn HTML bietet, das war damals schon klar, viel zu wenige Möglichkeiten, um das Aussehen einer Webseite genau zu bestimmen.
Mit CSS ist es aber auch möglich, Design und Inhalt vollständig voneinander zu trennen. Doch CSS bietet noch viele weitere Vorteile: Eine mit CSS erstellte Website wird schneller im Browser geladen und kann auch viel schneller modifiziert werden, da alle Einstellungen an zentralen Punkten gespeichert sind.
Leider hat CSS mit einem grossen Problem zu kämpfen, nämlich der Tatsache, dass CSS vom Browser interpretiert werden muss, was aber nach wie vor nicht überall gleich bewerkstelligt wird. Die Hersteller der Browser haben den Standard CSS zu einem der grössten Probleme bei der Gestaltung von Webseiten gemacht.
Damals stand eine Verwendung von CSS noch ausser Frage, denn so lange kein Browser etwas davon beherrscht, besteht auch kein Verlangen danach. Erst als man aber mit dem IE 4.0 die Auswirkungen von absoluten Schriftgrössen erleben konnte und das W3C im Rahmen von HTML 4.0 die <font>-Tags verbannte, weil sie dank den neuen Möglichkeiten von CSS überflüssig wurden, begannen viele Webverantwortlichen, ihre Seiten auf CSS umzustellen. Die Folge war, dass vielerorts Kommentare wie "Style Sheets funktionieren nicht" zu hören waren.
Das Jahr 2000 verbesserte die Situation für die Style-Sheet-Entwickler, denn dank des Jahr-2000-Fehlers wurden in den Unternehmen viele Computer ausgewechselt, so dass neue Browser installiert und Altlasten wie Netscape 3 und IE 3, die so gut wie keine CSS verstanden haben, über Bord gekippt wurden.
Netscape 6, die Hoffnung aller CSS-Entwickler auf Besserung bei der Unterstützung der Standards, entpuppte sich beim Release letzten Herbst allerdings als herbe Enttäuschung: Zwar ist der CSS-Support beinahe perfekt, die Akzeptanz des neuen Browsers unter den Usern aber so niedrig, dass sie dem Vorgänger die Treue halten.
Somit steht man als Entwickler vor einem Problem: Anzeigegeräte, um eine rein auf CSS basierende Seite so anzuzeigen, wie sie vom Entwickler erdacht wurden, sind vorhanden, werden aber noch immer nicht von allen Besuchern genutzt. Das zwingt einen dazu, Kompromisse einzugehen und die Seiten auf Browser zu optimieren, welche eine Generation älter sind.
Trotzdem ist es nicht unmöglich, ein fast zu hundert Prozent kompatibles Style Sheet zu erschaffen, wenn man sich an einige Grundsätze hält. Wohl wichtigstes Kriterium für den Erfolg ist absolut fehlerfreier Code, denn sowohl Syntax-Fehler als auch kleine Vertipper können unvorhergesehene Probleme hervorrufen.
Grösstes Gefahrenpotential bieten aber fehlerhaft in die Browser implementierte CSS-Elemente, ganz im Gegensatz zu den nicht unterstützten Objekten, deren Identifikation in der Regel sehr leicht ist.
Die korrekte Anwendung der fehlerhaften CSS-Bestandteile erfordert aber viel Fingerspitzengefühl und eine grosse Anzahl Tests auf vielen Plattformen und Browsern.
Wohl wichtigstes Hilfsmittel bei der Erstellung eines Style Sheet sind sogenannte "Compatibility Charts" (siehe Kasten "Links zu hilfreichen Tools und Seiten"), welche akribisch genau jedes Verhalten eines Style Sheet in einem Browser festhalten, wobei auch diese nicht über alle Zweifel erhaben sind. Trotzdem ermöglichen diese Listen schon eine Selektion der Style Sheets, welche man gefahrlos einsetzen kann oder eben nicht.
Wo ein dickes "No" in der Liste steht, kann man beruhigt sein und davon ausgehen, dass mit diesem Style Sheet nicht zu rechnen.
Teilweise oder nur fehlerhaft unterstützte Elemente können hingegen verwendet werden, müssen aber akribisch genau getestet werden, denn jeder Browser kann darauf anders reagieren. Oftmals handelt es sich aber um harmlosere Szenarien, welche geflissentlich übergangen werden können. Bei den härteren Fällen muss man entweder auf das Element verzichten oder einen Workaround erfinden.
Die heimtückischsten Elemente sind die, welche angeblich fehlerfrei funktionieren, aber erst bei genauem Hinsehen ihr fehlerhaftes Gesicht zeigen. Der Interpretationsfehler in Navigator zählt zu dieser Kategorie:
Das Code-Beispiel verlangt vom Browser eine neue Definition des Tags
Trotzdem haben wir jetzt ein Problem, falls es auf genau diese wenigen Pixel ankommt. Der Workaround ist aber schnell gefunden.
Man kann über eine Klasse in Verbindung mit einem
Einer der schwerwiegenderen Fälle ist das nächste Beispiel, wobei der Fehler im Element "background-color" schon aus den meisten Buglisten ersichtlich ist.
Hier verlangt der Code vom Browser, dass jeglicher Text, welcher von den Tags
und
eingerahmt und mit einem blaugrauen Hintergrund versehen wird, der eine Art Box bildet, die sich über die ganze Zeile erstreckt und erst mit dem abschliessenden -Tag beendet wird. Netscapes 4.7 ist im Gegensatz zur Referenz der Meinung, dass direkt hinter dem letzten Buchstaben der Hintergrund beendet werden sollte. Das Resultat ist mindestens vom ästhetischen Standpunkt aus gesehen eine Katastrophe.Die Workarounds in CSS sind nur knappes Flickwerk, beispielsweise lässt sich um den Block ein Rand in der gleichen Farbe des Hintergrunds spannen, was das Ausfransen der Box verhindert, aber nicht die Box über das ganze Browserfenster verlaufen lässt. Hier hilft nur ein Griff zu einer 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.
Im Beispiel wurde nun eine Tabellen-Zelle mit einem blaugrauen Hintergrund versehen. Wer gleich die ganze Tabelle oder Zeile identisch formatieren will, kommt nicht darum herum, jedem
Gleichzeitig führt sich dieser Workaround selber ad absurdum: Man kann auf die Style-Angabe verzichten und dafür reines HTML verwenden.
Wenn einmal sämtliche Workarounds nicht mehr helfen, empfiehlt sich einmal ein Blick auf die CSS-Anweisung @import, welche dazu dient, Style Sheets ähnlich zu einzubinden, aber nicht im NN 4.x und IE 3.x funktioniert. Dies hat einen Vorteil: Man hat ohne grössere Probleme eine akzeptable 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 Style Sheets wie Breitenangaben, Schriftgrössen oder sämtliche Definitionen für Boxes in eine andere Datei schreibt, welche über @import aufgerufen wird.
Im Vergleich zu den Vorgängerversionen hat man bei Microsoft und Netscape starke Verbesserungen vorgenommen, was auch die Kompatibilitätslisten beweisen, wobei vor allem noch IE 5.0 mit vielen nur teilweise unterstützten Features aufwarten kann. Interessanterweise häufen sich diese Lücken bei den Elementen, welche für eine rein auf CSS basierende Seitengestaltung notwendig sind.
Diese Lücken disqualifizieren CSS als reines Seitengestaltungswerkzeug. So ist man, ganz im Gegensatz zu der Empfehlung des W3C, auf einen Mix aus Tabellen in HTML für die Seitenaufteilung und CSS für die Formatierung der Elemente angewiesen. Zwar gibt es einige wagemutige Designer, welche den Aufstand proben, die Resultate sind aber Kompromisslösungen, mit welchen man keine wichtigere Site belasten sollte.
Grosses Ärgernis sind bei diesen Elementen vor allem die fehlerhafte Interpretation von Grössen. Die Browser wissen beispielsweise nicht, wie gross ein Pixel ist, was man doch erwarten dürfte. Teilweise werden bei fehlenden Angaben auch irgendwelche Formate angenommen, was sowohl im IE als auch Netscape nervt.
Hier wurden bewusst die Pixel bei der Definition des linken Rands unter den Tisch fallen 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 Style Sheets. 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 aber aus ästhetischen Gründen Nachteile: Schriftsätze wie Verdana oder Tahoma, welche auf das Internet ausgelegt sind, werden sehr gross dargestellt, was besonders auf Windows stört. Auch ist die Schriftgrösse ü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 auf 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 ab Version 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 IE ab Version 5.5 zu betrachten ist.
Auch wenn man über den 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. Und 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. Hier ist also Entspannung angesagt.
Abschliessend kann man sagen, dass ein Gebrauch von CSS im Prinzip ungefährlich ist, so lange nicht die ganze Seite auf jedem System, 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 Seite 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 Texte, Titel, eventuell auch Hintergründe über CSS definieren.
Komplette Layouts gemäss der W3C-Empfehlung mit Style Sheets zu codieren, ist nicht zu empfehlen, da vor allem mit Netscapes 4.x mittelschwere Darstellungsunfälle fast nicht zu vermeiden sind.
Falls man doch nicht darauf verzichten möchte, kann man auch auf Spezialtricks wie Browserweichen (siehe Kasten Seite 33) zurückgreifen, womit der Entwicklungsaufwand aber steigt.
