Cascading Style Sheets ::Artikel

12 Lektionen für alle, die Angst haben vor CSS und Webstandards

Das Original dieses Textes wurde zuerst am 26. September 2006 unter dem Titel 12 Lessons for Those Afraid of CSS and Standards im Online-Magazin A List Apart veröffentlicht. Der Autor ist Ben Henick. Die Übersetzung erfolgte mit Genehmigung von A List Apart und dem Autor.
Translated with the permission of A List Apart Magazine and the author.

Als ich das erste Mal mit CSS zu tun hatte, im Herbst 1998, wollte ich es gleich für die damals angesagten Dinge nutzen: hier ein Element bewegen, dort eine Farbe ändern usw. Erst nach einem halben Jahr fing ich an, Stylesheets mehr für Formatierung und Gestaltung und weniger für das Verhalten von Elementen einer Website einzusetzen.

Danach brauchte ich zwei Jahre, um mich aus dem goldenen Käfig der Layout- Tabellen zu befreien, und erst nach weiteren zwei Jahren konnte ich Layouts mit CSS ebenso gut wie mit Tabellen erstellen.

Damals war ich noch gezwungen, mit solchen anachronistischen Kunstwerken wie Netscape 4.0 oder Internet Explorer 5.0 zu arbeiten. Trotzdem wurde mir klar, dass ich sehr lange gebraucht hatte, um CSS wirklich zu beherrschen.

Es gibt eine Menge hervorragender Bücher und Artikel über CSS, viele stammen von bekannten Autoren, die auch Artikel für A List Apart geschrieben haben. Die meisten dieser Werke leiten den unerfahrenen Entwickler geschickt durch schwierige Layouts und erklären die Materie am direkten Beispiel. Nur wenige erkennen aber an, dass man eine spezielle innere Einstellung braucht, um standardsgemäße Websites zu erstellen. Diese Einstellung ist selbst vielen erfahrenen Entwicklern noch fremd, deshalb können sie ihre zweifellos vorhandenen Fähigkeiten nicht optimal einsetzen. Ich habe zwei Jahre lang nach einem Weg gesucht, ihre Probleme zu erklären.

Die Frustausbrüche, die ich heute bei anderen Entwicklern sehe, sind für mich nur ein Widerhall meiner eigenen Erfahrungen. Deshalb glaube ich, dass ich ihre Gefühle gegenüber CSS nachvollziehen kann. Ich schreibe diesen Aufsatz, um die wichtigsten Lektionen weiterzugeben, die ich bis heute gelernt hab.

Lektion 1: Alles, was Sie wissen, ist falsch – jedenfalls ungefähr

Wenn Sie jetzt beginnen, mit CSS zu arbeiten, dann kommt Ihnen vielleicht alles, was Sie vorher gelernt haben, nutzlos vor, oder schlimmer als das. Damit wir uns richtig verstehen: dies ist ein Problem, dass Sie möglichst schnell für sich selbst identifizieren und erledigen müssen.

Denn alle die Weisheiten, die Sie sich bisher angeeignet haben, sei es über Design, Code-Optimierung, Benutzerfreundlichkeit, Programmierung, Projektmanagement usw., sind davon überhaupt nicht betroffen. Wenn Sie sich auf standardsgemäße Techniken umstellen, werden sich einzig Ihre Vorstellungen und Gewohnheiten ändern, unter denen Sie dieses Wissen anwenden.

Das bedeutet: ziehen Sie unter Ihre bisherigen Gewohnheiten einen Schlussstrich. Werfen Sie alle alten Einstellungen und Erwartungen über Bord. Krempeln Sie die Ärmel hoch und lernen Sie etwas neues. Streichen Sie die Worte "aber" oder "sollte" für eine Weile aus Ihrem Vokabular — im Sinne von Layout und Produktion. Ersetzen Sie sie durch "Wie" und "Warum" und verpflichten sich einfach nur, Ihre Projektziele einzuhalten.

Beim Schreiben des Code geht es in dieser Lektion um den Unterschied zwischen Tabellen- MarkUp und semantischem Code:

Vergleich von Tabellencodierung mit semantischer Codierung
Tabelle Semantischer Code Bedeutung
Lineare Ordnung Hierarchische Ordnung Design für die Information, nicht trotz der information.
Prozedural Funktional Setzt alle Teile an die richtige Stelle
Lage-basiert Kontext-basiert Der Code beschreibt, was etwas ist, nicht, wo es ist.
Beschränkungen Zugehörigkeit Layout passt sich den Bedürftnissen an, kein Grund für besondere Angaben.

Nach alledem vergessen Sie aber nicht: es gibt Dinge, die Sie mit Tabellen- Layouts erreichen können und es gibt Dinge, die Sie mit CSS-Layouts erreichen können. Einige dieser Dinge schließen sich gegenseitig aus, was aber die Vielseitigkeit des CSS keineswegs schmälert.

Lektion 2: Es wird nicht überall genau gleich aussehen, es sei denn, Sie machen ein Problem daraus – aber vielleicht nicht einmal dann.

Zwischen den Rendering-Engines der einzelnen Browser gibt es jede Menge Unterschiede, und das W3C sanktioniert diese Unterschiede. Sie können Ihr Layout anpassen, Sie können verbessern, hacken oder die Regeln ganz missachten. Wenn Sie aber den letzten Rest Ihrer Freizeit retten wollen, dann lernen Sie, nicht mehr auf Kleinigkeiten zu bestehen — und überzeugen die Interessenvertreter in Ihren Projekten auch davon.

Lektion 3: Sie haben die Wahl – zwischen dem Idealen und dem Praktischen

Leben und Arbeit zwingen einen oft zu Kompromissen, besonders in der Übergangsphase zu einer neuen Entwicklung. Wenn Sie wollen, dass Kompromisse zu Ihren Gunsten ausgehen, ist das Beste eine effektive Vorausplanung.

Dennoch lässt es sich in manchen Situationen nicht verhindern, dass Sie sich für das kleinere Übel von zwei Vorgaben entscheiden müssen. Vielleicht lässt man Ihnen auch gar keine Wahl. Die Folge davon sind Websites, die keine Chance haben, alle Kriterien der Zugänglichkeit oder der Validität zu erfüllen. Dann müssen Sie das schlicht und einfach so hinnehmen, auch wenn alle Ihre Gegenargumente vollkommen korrekt sind.

Respektieren Sie die Ziele Ihrer Projekte und akzeptieren Sie die Dinge, die in Ihrer Firma im Hintergrund ablaufen. Sie selbst treffen die Wahl, was für Sie als professionellen Webdesigner am wichtigsten ist. Sie müssen erkennen, dass Entscheidungen, die über Ihre Einwände hinweg getroffen werden oder bei denen Sie vielleicht nicht einmal gefragt wurden, nichts über Ihre Fähigkeiten aussagen, oder gar über Sie als Person. Sie reflektieren aber doch vielleicht die Menschenkenntnis, mit der Sie sich die Auftraggeber Ihrer Projekte aussuchen. Werden Sie sich über Ihre Standpunkte klar und kämpfen sie dann die Konflikte aus, die Sie auch wirklich gewinnen können.

Lektion 4 (mit Dank an Antoine de Saint-Exupéry): "Perfektion ist erreicht, nicht, wenn sich nichts mehr hinzufügen lässt, sondern, wenn man nichts mehr wegnehmen kann."

Wenn wir für ein standardsfreundliches Layout codieren, ist es nur allzu leicht, an unserer herkömmlichen Arbeitsweise aus dem tabellenbasierten Layout festzuhalten und damit ein Übermaß an Container- Elementen zu erstellen. Anfangs erscheint es uns vernünftig, den Code in das Design zu zwängen. Damit übersehen wir aber den Hauptgrund für eine standardsfreundliche Codierung.

Besser ist es, wenn wir keinerlei Zwänge ausüben und Code nur dort einfügen, wo es durch den Kontext erforderlich wird. Konzentrieren Sie sich zuerst auf die Information. Wenn Sie mehreren Inhalten denselben Zweck oder dieselbe Klassifikation zuordnen können, dann scheuen Sie sich nicht, diese Inhalte in eigene Container einzufassen (div oder span), mit einem Klassenattribut, das den Zweck bzw. die Klassifikation beschreibt. Die meisten Menschen werden nichts dagegen haben, wenn Sie den Fließtext einer Seite in einem Container unterbringen, der auf allen Seiten des Projekts wieder auftaucht.

Sollten Sie statt dessen der Marotte anhängen, dass bestimmte Widgets pixelgenau an besonderen Bildschirm- Koordinaten auftreten müssen, dann haben Sie Ihr Design möglicherweise nicht vollständig durchdacht. In der Konsequenz wird Ihr Code noch schwerer zu unterhalten sein als der tabellenbasierte Code, den Sie ja gerade ersetzen wollen.

Entfernen Sie Tags wann immer möglich und denken Sie dabei auch an die folgende Lektion.

Lektion 5: Einige Websites sind Haufen von Verrücktheiten

Oft sind die Verantwortlichen für das graphische Design einer Website gleichzeitig für keinen anderen Aspekt der Website verantwortlich. Kommt dazu noch das Fehlen strikter Layoutgitter (für das ganze Projekt oder für einzelne Sektionen davon), müssen zu viele Seiten einzeln erstellt werden. Das bedeutet Mehrarbeit bei Codierung und Produktion.

Der Autor dieser Zeilen hat die Erfahrung gemacht, dass solche Ergebnisse viel öfter bei kleinen Projekten als bei großen auftreten. Das führt dazu, dass solche Kleinprojekte budgetmäßig gewaltig aus dem Ruder laufen. Der Leser ist eingeladen, sich die weiteren Folgen davon selbst auszumalen.

Unterstützen Sie Ihre Graphikdesigner wann immer möglich darin, sich an das Gebot stilistischer Konsequenz zu halten. Wenn das dennoch zu nichts führt, dann geben Sie jedem Dokument ein anderes ID und freuen sich über die gute Seite: alles, was mehr Arbeit bringt, macht Ihren Arbeitsplatz ein klein wenig sicherer.

Lektion 6: Längere Entwicklungszeiten sind unausweichlich

Die Entwickler der Browser hatten fünf hektische Jahre, in denen sie eine gleichartige und verhältnismäßig stabile Art der Tabellendarstellung entwickelten. Bis zum Erscheinen von Gecko und KHTML wurde das noch dadurch erleichtert, dass fast alle Engines aus der Mosaic- Engine hervorgingen, die auch an Microsoft lizenziert wurde.

Heute befindet sich die CSS-Technologie in dem Stadium, das die Tabellentechnik Anfang 1998 inne hatte. Lassen Sie ihr also Zeit, sich zu entwickeln und bis dahin: testen Sie gründlich.

Das Gute daran ist, dass Sie die Mehrarbeit, die Sie für Test und Fehlersuche Ihrer Layouts brauchen, später bei Unterhaltung, Erweiterungen und Revisionen wieder einsparen.

Lektion 7: Das Beste ist eine stimmige und vernünftige Codefolge

Wenn Sie Ihr Werk so wohlüberlegt aufbauen, dass sich alle Seiten auch ohne Stylesheets sauber lesen lassen, dann wird sich die investierte Zeit um ein Vielfaches auszahlen. So eine Arbeitsweise hat noch weitere Vorteile:

Lektion 8: Nachfahrenselektoren sind das A und O wirklich leistungsfähiger CSS-Regeln

Am Beginn des Übergangs vom Tabellenlayout zum standardsfreundlichen Layout ist die Versuchung groß, nicht nur Unmengen von div- Containern zu verwenden, sondern auch allen Elementen ein class oder ID anzupappen.

In der Regel brauchen Sie so etwas aber nicht. Denken Sie beispielsweise an ein Element, das Navigationslinks beinhalten soll. Einsteiger machen hier oft den Fehler, dass sie die ganze Sache mit div- Elementen zusammen bauen. So etwas verschnupft Puristen, denn es macht das Lesen einer Seite für die Nutzer von Screen- Readern unnötig schwer.

Divs sind also nicht die ideale Lösung, daher weichen wir aus auf ungeordnete Listen. Screen- Reader können solche Listen per Kommando überspringen. Das bedeutet: ein gutes Navigationselement besteht aus einer ungeordneten Linkliste. Ein gewissenhafter Entwickler wird dann diese Liste vielleicht mit einem #-Identifizierer versehen, nur für die Positionierung. Danach ergänzt er die Links noch mit Klassen, damit sie von allen anderen Links im Dokument unterschieden werden können.

In so einem Szenario ist jedoch nur der Identifizierer wirklich notwendig. Die Links formatiert man dann mit einem Nachfahren- Selektor.

Der folgende Selektor steht für: "Alle Links innerhalb von #nav sollen rot sein."

#nav a { color: red; }

Das nächste Beispiel ist schon komplizierter:

#fliesstext blockquote.wichtig { float: right; width: 30%; padding: .5em; margin: .5em; }

Die Attribute dieser Regel treffen auf alle Elemente blockquote zu, die die Klasse wichtig haben und die innerhalb des Containers #fliesstext auftreten. Dies ermöglicht, dass einfache Elemente blockquote innerhalb von #fliesstext oder aber Elemente blockquote mit der Klasse wichtig in einem anderen Container, z. B. #sidebar, anders formatiert werden können. Zugleich reduzieren wir die Anzahl der benötigten Klassen- und ID- Selektoren auf ein Minimum.

Nachfahren- Selektoren erlauben uns also, die Anzahl der Klassen und Identifizierer effektiv zu reduzieren und dabei den Kontext besser im Auge zu behalten als das ohne diese Selektoren möglich wäre. In Verbindung mit Hintergrund- Images und den Layout- Eigenschaften lassen sich durch Nachfahren- Selektoren Effekte realisieren, die in Tabellen nicht ansatzweise möglich sind.

Lektion 9: Im wirklichen Leben können Stylesheet-Hacks Ihr Projekt retten

Es stimmt: Stylesheet- Hacks sind eine Missachtung der guten Absichten, die hinter der Entwicklung der CSS-Technik stehen. Wahr ist auch, dass wir mit Stylesheet- Hacks die Möglichkeit von Alpträumen in unsere Projekte einbringen, insbesondere nach größeren Änderungen wie der Einführung des Internet Explorer 7. Das Ganze ist ein Chaos im Wartestand.

Der Autor dieser Zeilen vertritt hier einen eindeutigen Standpunkt. Angenommen, man hat die Wahl zwischen Ausreden gegenüber einem Kunden, weshalb das Design in seinem Browser lausig aussieht, einerseits und der einfachen Lösung des Problems andererseits. In dem Fall ist die Entscheidung für das Letztere der bei Weitem einfachere Weg, auf dem man eine erbrachte Leistung in Rechnung stellen kann. Wenn man die Hacks besonnen anwendet und angebrachte Warnungen beherzigt, können Stylesheet- Hacks einem das Leben so viel einfacher machen.

Lektion 10: Umgehungsregeln für Browserfehler sind wie ein Whac-A-Mole-Spiel

Damit meine ich: hat man den einen Browserfehler erfolgreich ausgeschaltet, sieht man sich oft mit einem anderen Fehler eines anderen Browsers konfrontiert (oder einer anderen Version desselben Browsers). Wenn das passiert, können Sie davon ausgehen, dass Sie Ihren ganzen Regelsatz noch einmal völlig neu durchchecken müssen, vielleicht sogar Ihr ganzes Stylesheet- System.

Es gibt aber in aller Regel einen Ausweg aus solchen Verlierer- Situationen. Eine gut eingestellte Websuche bringt meistens eine Lösung, positioniseverything.net ist in solchen Fällen eine besonders wertvolle Ressource.

Lektion 11: Sollten Sie in Layout-Problemen ertrinken, kommen Sie clear, wenn Sie Ihr Layout ruhig floaten lassen und sich der width und der height des Wassers versichern.

Wenn Sie mit Spaltenlayouts arbeiten, sind unschöne Überraschungen an der Tagesordnung. Gut aussehende Spaltenlayouts und eine vernünftige Codefolge erreichen Sie am Besten mit der Eigenschaft float. Damit das gut funktioniert, müssen aber alle Ihre Spaltencontainer eine definierte Breite und manchmal sogar eine definierte Höhe haben. Ohne diese Angaben ist die Darstellung Ihres Layouts unvorhersehbar.

Zudem werden Sie sich wahrscheinlich nicht immer genau an Lektion 4 halten können, wenn Sie Ihr Layout erfolgreich zusammen bringen wollen. Das ist aber einer der Kompromisse, die wir weiter oben schon angesprochen haben. Sie sollten, wenn möglich, solche Kompromisse nur eingehen, nachdem Sie alles andere erfolglos versucht haben.

Lektion 12: Der Unterschied zwischen Schlichtheit und geschmackvoller Verzierung heißt Hintergrundimages

Jede Mischung aus proportionalen und festen Dimensionen, d. h. der Versuch eines elastischen Layouts mit Rahmen, ist Dank der Wechselfälle des CSS- Box- Modells ein sicherer Weg ins Debakel. Eine Illusion von Rahmen kann man mit Hilfe gut durchdachter Hintergrund- Graphiken und entsprechender Einfügung per background erzeugen. Insbesondere in Bezug auf border sind eigene Experimente empfehlenswert.

Eine andere verbreitete Aufgabe ist die Darstellung von Überschriften als graphischer Text. Auch hier halte ich die Nutzung von Hintergrund- Graphiken für angemessen. Die Technik ist umstritten, aber durch die Kombination von background-position und text-indent bleibt der Text für Suchmaschinen und Screen- Reader lesbar. Zugleich tun wir den Ansprüchen der graphischen Designer Genüge und ermöglichen eine hochqualitative graphische Darstellung.

Nur der Vollständigkeit halber und für alle Bedenkenträger: ich habe bis jetzt noch keinen PC-Nutzer getroffen, der im Web surft und dabei Stylesheets freigeschaltet hat, Graphiken jedoch nicht. Die Erwähnung solcher Szenarien führt immer wieder zu fesselnden intellektuellen Diskursen - ich bin mir aber sicher, dass diese wenig damit zu tun haben, wie die Menschen im wirklichen Leben durchs Web surfen.

Abschluss

Aufgrund ihrer Gewohnheiten, die sie vor Jahren in gutem Glauben angenommen haben, sind viele Menschen heute nicht in der Lage, sich den Veränderungen am Arbeitsplatz zu stellen. Das Medienrauschen über Web 2.0, CSS und unzählige andere neue Entwicklungen sind für sie nur noch nichtssagendes Getöse. Ich hoffe, dass meine Erfahrungen, die ich Ihnen hier weiter gegeben habe, einigen von Ihnen helfen, wieder ganz nach vorn zu kommen. Denn dort ist es, wo das Web Sie braucht.
TOPAuthor: Ben Henick
Translation: kl

Hinweis:
Das Original dieses Textes wurde zuerst am 26. September 2006 unter dem Titel 12 Lessons for Those Afraid of CSS and Standards im Online-Magazin A List Apart veröffentlicht. Der Autor ist Ben Henick. Die Übersetzung erfolgte mit Genehmigung von A List Apart und dem Autor.
Translated with the permission of A List Apart Magazine and the author.

Home|Vollreferenz|Schnellreferenz|Grundlegendes|Tutorials & Artikel|Quiz|Allgemeines

© Copyright All Contents 2002-2023
Commercial Use prohibited.

Notizen: