Der Stil des Stylesheets
04.03.2009 in: CSS und Webdesign • 18 Kommentare
Letzte Änderung: 16.03.2009, 21:50 Uhr.
Neulich mußte ich CSS-Code anfassen, den ich vor vielen Jahren geschrieben hatte. Dabei sind mir zwei Dinge aufgefallen: Ich hatte einen Hack benutzt, der nicht vorwärtskompatibel war – deshalb mußte ich da überhaupt nochmal eintauchen – und ich konnte den Code besser lesen als meinen aktuellen.
Eine gute Gelegenheit also, mal über den »Stil des Stylesheets« zu reflektieren.
Ich habe 1999 mit CSS begonnen. Seither habe ich ein paar Dinge gelernt … hoffe ich.
- Keine serverseitige Browserweiche.
Mal hängt eine Version für Browser A im Proxy-Cache AOLs und wird an Browser B ausgeliefert, mal ändert ein Browser seine Kennung, mal kommt gar kein User-Agent-Header mit. Irgendwas geht dabei immer schief.
Laß den Browser entscheiden, was er verarbeitet. Teste auf Kompetenz, nicht auf Namen. - Ein Stylesheet pro Ausgabemedium.
Gerade bei größeren Projekten erschwert jedes zusätzliche Stylesheet die Fehlersuche enorm. Außerdem kostet es einen zusätzlichen Request. Man kann jedes browserspezifische Problem innerhalb dieses einen Stylesheets lösen.
Müßte ich rocblanc.com verwalten, wäre die Zusammenfassung der 44 Stylesheets wahrscheinlich mein erster Arbeitsschritt. - Jeder Hack sei vorwärtskompatibel.
Ich mußte das anfangs genannte Stylesheet anfassen, weil ich damals Mozilla mithtml:rootangesprochen hatte. Das kann heute fast jeder Browser. Besser istbody:-moz-last-node, denn das wird nie der falsche Browser interpretieren.
Der beste Hack ist freilich der, auf den man verzichtet.
Das waren eher allgemeine Regeln, auf die jeder selbst kommen kann. Ab hier meine … Vorlieben.
- Kennzeichne die Zeichenkodierung.
Wer nur ASCII-Zeichen benutzt, kann darauf verzichten. In allen anderen Fällen hilft es beim lokalen Abspeichern. Und ich verstehe das auch als Teil der Dokumentation. - Kommentiere, aber übertreib es nicht.
Ich verstehe das Bedürfnis hinter CSSDOC. Wenn aber die Kommentare mehr als 10% des übertragenen Codes ausmachen, wird es höchste Zeit, über einen Filter nachzudenken. Nicht jeder hat DSL.
Gegen ein paar kleine Anmerkungen und Pseudo-Überschriften spricht natürlich nichts. - Halte vertikale Fluchtlinien ein.
Meinen alten Code konnte ich gut lesen, weil ich ihn so geschrieben habe:ul, ol { margin: .5em 0; padding: 0 0 0 .5em; line-height: 1; }Ein Selektor pro Zeile, eine separate Fluchtlinie für die Klammern, eine für die Eigenschaften und eine für die Werte. In solchem Code sucht man nicht – man findet. Ich habe auch meinen aktuellen Code auf diese Schreibweise umgestellt.
- 80 Zeichen Breite
Viele Editoren brechen per Voreinstellung nach dem 80. Zeichen um – eine sinnvolle Grenze, denn weiter rechts verliert man schnell die Übersicht.
Daran halte ich mich in jeglichem Code – in CSS, HTML, PHP und anderen Sprachen.
Wie schreibt ihr eure Styesheets?
Wie viele verwechselst du die Entwicklung und Auslieferung, siehst daher falsche Widersprüche. Mehrere Stylesheets sind bei großen Projekten sehr sinnvoll. Ansonsten hätte man eines mit vielleicht 20.000 Zeilen. Da findet man sich doch nicht besser drin zurecht! Und die Kommentierung sollte so gut sein, wie es für die Entwickler nötig ist. Konzessionen wegen der Dateigröße sind überhaupt nicht nötig. Denn heutzutage fasst man Stylesheets zusammen und komprimiert sie vor der Auslieferung an die Browser.
Die Hinweise zur Menge und Kommentierung gelten selbstverständlich ausgelieferten Stylesheets – genau das meinte ich mit dem Filter. Meine Arbeitsversionen enthalten auch deutlich mehr Code, als die ausgelieferten.
Allerdings halte ich 20.000 Zeilen doch für sehr hochgegriffen. Hast du mal Beispiel, wo das die Grundlage ist?
Was Deinen ersten Punkt angeht: Keine Serverseitige Browserweiche, da knoble ich noch dran. Und wieder einmal ist der IE das größte Problem.
Meine Seiten liefere ich in HTML und XHTML aus, jeweils gezippt und nicht gezippt. Der Gedanke dahinter ist, das als eine Art Browserweiche zu nutzen in genau der von Dir beschriebenen Art. Denn der Firefox kann XHTML, der IE nicht.
Leider klappt das nicht immer. Beim IE ist nicht vorgesehen, eine Auswahl zu haben. Ich habe festgestellt, wenn man im IE die bevorzugten Sprachen einstellt, dann klappt das auch mit der Auswahl HTML/XHTML. Wenn nicht, anscheinend nicht. Das habe ich erst kürzlich herausgefunden. Und zunächst ziemlich rigoros auf HTML festgezurrt.
Wenn das endlich mal klappen würde, wäre das eine perfekte Browserweiche.
Ein anderes Problem ist mir ebenfalls vor ein paar Tagen sauer aufgestoßen. Meine Seiten gibt es in mehreren wählbaren Stilen (alternate stylesheets). Der IE ignoriert diese alternativen Stile. Kann man insofern auch als eine Art Weiche verwenden. Semitransparente PNGs? In den alternativen Stilen kein Problem. Und der IE ignoriert's netterweise. Aber Googles Chrome spielt hier nicht mit. Der hat hier einen Bug und würfelt einfach nach Zufall die verschiedenen alternativen Stile zusammen. Das Ergebnis ist, wie Du Dir vorstellen kannst, schrecklich. Ich habe daher die alternativen Stile aus der HTML-Version erst mal rausgeworfen.
Die Welt könnte so schön sein ohne Browserbugs.
Was CSS Stil angeht: Einen Teil Deiner Empfehlungen halte ich auch so. Allerdings nicht alle. Aber es ist übersichtlicher so, wie Du schreibst. Ich werde das mal überarbeiten.
Noch ein Tip: Aufteilung des Stylesheets in diverse Sektionen. Bei mir gibt's ganz am Anfang eine Grundeinstellung für das Wurzelelement. Dann folgt eine Sektion mit allgemeinen Angaben. Danach folgen je eine Sektion für jeden meiner 4 Hauptcontainer. Danach Spezialitäten wie Microformate, Smilies e.t.c., wobei ich langsam dazu übergehe, diese Spezialitäten in eigenen Stylesheets zusammenzufassen, da sie eigentlich mehrfach nutzbar sind, und auf die art modular und wiederverwertbar werden.
Allerdings habe ich da immer noch eine Menge Arbeit vor mir und zu wenig Zeit dafür :)
Content-Negotiation ist natürlich unumgänglich, wenn du wirklich XHTML brauchst. Das würde ich aber auf die Seiten beschränken, auf denen richtiges HTML nicht ausreicht.
Alternative Stylesheets sind keine »Weiche«, denn sie werden ja beim ersten Aufruf von keinem Browser verarbeitet. Leider merken sich aktuelle Browser die Auswahl eines alternativen Stylesheets nicht – wenn man nicht mit Javascript nachhilft.
Die Sektionierung ergibt sich meistens schon aus der Kaskade: Man geht vom Allgemeinen zum Besonderen und bündelt die Regeln, die einander am stärksten beeinflussen. Das halte ich auch so.
Also ich setze sehr gerne viele Kommentare im Stylesheet. Gut, vielleicht nicht in jedem Stylesheet, aber gerade bei einem komplexeren Layout schreibe ich ziemlich viele Kommentare hinein. Wenn ich dann später wieder hineinschaue, muss ich nicht lange überlegen, warum ich jetzt an dieser Stelle den betroffenen Punkt hingeschrieben habe usw...
Mir ist unkommentierter Code schon oft auf die Füße gefallen, deswegen achte ich momentan sehr darauf, nicht zu wenig zu kommentieren!
Alternative Stylesheets als Weiche: Klar, so richtig nicht. Aber insofern, als dass gewisse Browser eben alternative Stylesheets nicht können. Also eine Art Weiche abhängig von den Fähigkeiten des Browsers.
Permanenz: Stimmt, das ist eine Schwäche der Spezifikation. Für den Firefox gibt es da eine gute Extension. Bei anderen Browsern bin ich mir da nicht sicher. Ich habe mal irgendwo läuten hören, Opera behielte die Wahl ebenfalls bei. Wenn so eine Wahl permanent wird, gewinnt das an Bedeutung als "Weiche", obwohl es natürlich nie eine echte Weiche wird.
XHTML brauchen: Stimmt. Jedenfalls für Produktionsseiten. Auf meiner HP mache ich das, weil das mein Experimentierfeld ist. Das sind andere Voraussetzungen.
XHTML ist allerdings klasse. Da gehen Dinge, von denen man sonst allenfalls träumen kann, wie eingebettetes SVG oder RDF oder RSS. Mit XHTML kannst Du über Namespaces aus dem Vollen schöpfen. Keine mühsame Suche mehr nach dem semantisch wirklich richtigen Element. Man nimmt dann eben einfach eines aus einem anderen Namespace, und schon passt's. Und die Darstellung optimiert man dann mit einem XSL stylesheet. Theoretisch könnte man sogar den Skiplink eliminieren, indem man die Container per XSL einfach umsortiert.
Komplizierte Zusammenhänge? RDF/OWL. Komplexe Bookmarks? Annotea Bookmarks. Adressen? vCard/XML oder FOAF (beides besser als Microformats). Eingebettete scriptbare Grafiken? SVG. Komplexe Animationen? SMIL. Und so weiter. Das, was mit den Microformats angedeutet wurde, kann mit XML richtig gemacht werden. Kein Herumtricksen mit dem class Attribut, und schon gar nicht mit dem title Attribut. Alles sauber und jederzeit per XSL umformbar oder per JQuery abfragbar. Internet-weit.
Ein alternatives Stylesheet muß vom Leser ausgewählt werden, ist also ein rein clientseitiger Mechanismus.
Deine Freude über XHTML teile ich nicht so ganz. Ja, da kann man viel machen – aber der reale Nutzen für die Leser ist so gering, daß ich nichts davon je verwendet habe.
Das liegt einmal daran, daß man dazu auf die heikle Content-Negotiation zurückgreifen muß (obwohl der Accept-Header etwas zuverlässiger ist als der User-Agent-String). Und dann läßt sich fast alles auch mit richtigem HTML (5) und schlichten Links erreichen.
Ich habe XHTML das letzte Mal vor etwa sieben oder acht Jahren benutzt. Und ich werde es für eine normale Webseite frühestens in drei oder vier Jahren nochmal anfassen.
Ich werde aber interessiert mitlesen, wenn du deine praktische Erfahrung damit intensiv bloggst. ☺
"Ich werde aber interessiert mitlesen, wenn du deine praktische Erfahrung damit intensiv bloggst. ☺"
Worauf Du Dich verlassen kannst :) U.A. dazu ist diese Spielwiese ja da.
Deine Idee vom für dich perfekten Stylesheet kann ich fast 1:1 unterstreichen.
Ganz allgemein meine ich, es gibt wenige allgemeingültige Best Practices (bzw. andersrum No-Gos). Es ist eine individuelle Geschichte.
Es muss einem selbst zusagen, - das hat dann in erster Linie mit effizientem Arbeiten zu tun.
Ich glaube auch nicht, dass man sich da irgendwo "Inspirationen" holen kann.
Sowas wächst und wenn es gut ist, dann bleibt es.
Komisch, meine eigenen Präferenzen habe ich noch nie wirklich versucht in Worte zu fassen und wenn ich das wollte, würde ich vielleicht feststellen, dass ich das gar nicht kann.
Aber ein Schema habe ich natürlich auch.
Dein CSS Stil hat mich stark beeindruckt, davon kann man sich eine Scheibe abschcneiden. Aber wie Anne schon gesagt hat - jedem das seine.
Bezüglich Vertikale Fluchtlinien: Was passiert mit dem Abstand zwischen Werten und Eigenschaften, die sich in die Länge ziehen? Schaltest Du dann beispielsweise mehrmals (TAB) um auf gleiche Linie zu kommen? (Vergleich: text-decoration und font)
Was ich an meinem Stil noch hilfreich finde ist, dass ich die einzelnen Eigenschaften in einer bestimmten Reihenfolge halte, sprich Angaben wie Farben, Textformatierungen & Co zu erst und dannach Abstände etc. Eine alphabetische Reihenfolge wäre sicherlich auch nicht verkehrt!
Lange Eigenschaftswerte – wie beispielsweise viele Schriftfamilien oder die Angaben zu
background– breche ich auf mehrere Zeilen um, wobei die nächste Zeile »in Flucht« mit den anderen Werten beginnt.Vereinfachtes Beispiel:
font-family: Minion Web Pro, Minion Web, Minion Pro, Palatino LT Std, Palatino Linotype, Palatino, Georgia, serif;Im fertigen Stylesheet sieht man das nicht immer, weil ich einige Werte aus Scripten generieren lasse.
Text-decoration? Da kann man zwar bis zu vier Werte angeben, aber das habe ich noch nie gemacht. Will ich auch nicht. ☺
Die Reihenfolge ist ziemlich egal, denke ich. Ich schreibe meistens die Eigenschaften im Block, die eng zusammenhängen –
margin/padding,text-shadow/color/background– aber da ich immer wieder was dazuschreibe oder kürze, hält auch das nicht lange.Das Alphabet als Sortierkriterium funktioniert bei mir nicht: Ich sehe das Ergebnis des Codes vor meinem inneren Auge, wenn ich CSS schreibe. Das Nachdenken über die alphabetische Reihenfolge lenkt mich da nur ab (habe ich schon probiert).
Das ist wohl Geschmackssache.
Wenn ich alleine am Stylesheet sitze (Normalfall), benutze ich Tabs. Das ist aber reine Geschmacksache, finde ich. Die Dateigröße hat damit nichts zu tun: Spätestens beim Übertragen zum Client egalisiert Gzip solche Unterschiede, weil es ja ähnliche Zeichenketten sehr gut komprimiert.
Zur Aufteilung in mehrere Dateien: Serverseitig kann man das machen, aber der Client sollte möglichst wenige HTTP-Requests ausführen müssen. Viele Server akzeptieren nur eine sehr begrenzte Zahl gleichzeitiger Requests (4—8); jedes zusätzliche Stylesheet kann also das Laden anderer Dateien (Bilder, Scripte usw.) spürbar ausbremsen. Bei sehr vielen Dateien sollte man daher einen vernünftigen Mechanismus zwischenschalten, der alles zusammenpackt. Von browserspezifischen Stylesheets halte ich – wie schon geschrieben – überhaupt nichts.
ich bin auch gerade dabei den optimalen css code-style für mich zu finden. benutzt ihr tabs? bin genervt dass das codeindenting in vielen programmen unterschiedlich gehandhabt wird, und dewegen dazu übergegegangen nur noch spaces zu verwenden, weil deren darstellung konsistent ist.
das treibt die dateigröße natürlich nach oben, v.a. weil ich auch sehr stark einrücke und verschwenderich whitespace benutze, aber mir ist es lieber gut strukturierten code für die entwicklung zu haben und dann das ganze am ende nochmal packe.
ich finde auch das es bei css dateien mit mit mehr als 500 zeilen sehr viel sinn macht nicht alles in eine datei zu tippen. bei größeren sachen teile ich alles in global reset / baseline grid / typography / layout / colors & backgrounds / utility classes auf. zusätzlich gibts dann script-/browser-/ und seitenspezifische css-dateien.
Andreas Borutta am 11.05.2009 · 11:47
Ja, ich gestehe es. Ich kann meine eigenen CSS-Ergüsse manchmal schlecht überblicken. Zum Einen weil ich bisher noch keine ausgereiften für mich funktionierende Konventionen entwickelt habe. Zum Anderen, weil die meine handgetippte Formatierung nicht konsistent ist. Mein Auge ist ziemlich empfänglich für eine Formatierung, die einem guten und konsistenten Muster folgt. Händisch korrekt zu formatieren war und ist mir zu mühsam.
Kennt ihr gute und mächtige Skripte (Windows)/Tools zum Formatieren von CSS?
Ab und an möchte ich mal meine nicht diszipliniert genug getippten Stylesheets entsprechend den eigenen Konventionen reformatieren.
Beispiele der gewünschten Fähigkeiten:
[ ] Jede Eigenschaft in neuer Zeile
[ ] Nur wenn die gesamte Regel länger ist als [80] Zeichen
[x] Kommentare, die direkt hinter einer Deklaration forlgen, stehen in dergleichen Zeile wie diese
[x] Leerzeichen hinter {
[x] Kein Leerzeichen vor {
[x] Leerzeichen hinter ;
[x] Kein Leerzeichen vor ;
[x] Leerzeilen entfernen
[x] Einrückung des Codeblocks hinter einem Kommentar, der allein in einer Zeile steht. Bis zum nächsten Kommentar.
[x] Einrückung des Inhaltes von @media-Blöcken
[x] Eigenschaften alphabetisch sortieren
[x] Kommaseparierte Selektoren in folgender Reihenfolge sortieren [...]
[x] Meta-Sortierungsregeln verwenden: Selektoren ohne Klassen/IDs vor jenen mit Pseudoklassen, vor jenen mit Klassen/IDs
[ ] Zwei Blöcke zu einem zusammenfassen, wenn sie exakt den gleichen Satz an Eigenschaften aufweisen.
...
Euch fällt sicher noch was ein :)
Ich freue mich über Hinweise.
Danke.
Ich kenne keinen Editor, der eine so detaillierte Codeformatierung über ein Interface anbietet, und ich bezweifle auch, daß es einen gibt. Mir fallen zwei Möglichkeiten ein:
1. Eclipse PDT. Das ist eine komplette IDE zur Webentwicklung mit dem Schwerpunkt PHP. Allerdings ist ein CSS-Editor an Bord, für den du die Code-Formatierung immerhin separat und einigermaßen genau angeben kannst. Per Strg+i überträgt er deine Regeln auf bestehende Stylesheets.
Diese Formatierungsoption ist in Java geschrieben. Du kannst den Quellcode nehmen und sie ausbauen, umstellen … was immer du möchtest. Mit einem Javatutorial bei der Hand sollte das nicht allzuschwer sein.
2. PSPad. Nur ein einfacher Texteditor, aber er kann immerhin Makros aufzeichnen. Die meisten deiner Wünsche lassen sich als regulärer Ausdruck oder mit internen Funktionen PSPads umsetzen. Wenn du die alle einmal über ein Stylesheet laufen läßt und dabei ein Makro mitschneidest, kannst du es später immer wieder mit einem Klick ausführen.
Danke für Deine Anregung.
Jedoch beherrscht der CSS-Editor "Topstyle" bereits mehr als das, was auf dem Eclipse Interface (Dein Screenshot) zu sehen ist.
[05.01.10: Tote Links entfernt, toscho]
Die Formatierungsregel jedoch, die mir am wichtigsten ist, das Sortieren von kommaseparierten Selektoren und das Sortieren von Blöcken anhand von Selektoren gemäß einer frei definierbaren Liste:
das beherrscht Topstyle und auch Eclipse nicht.
Zur Zeit verwendet ich als Texteditor Notepadd++.
Auch dort ist das Aufzeichnen von Makros möglich.
Mir fehlen allerdings die Fähigkeiten, passende und somit entsprechend komplexe RegEx umzusetzen.
IMHO wäre ein System optimal, welches es erlaubt zwischen verschiedenen Sortierungen hin- und her zu schalten.
Mal wäre eine logische Gruppierung wunderbar, ein anderes Mal wünscht man sich maximal dichte Sortierung (System Jens Meiert).
Ich würde jedenfalls sicher flotter zu /meinem/ System finden, wenn ich müheloser switchen könnte.
Manuell ein System unstellen ist ein enormer Kraftakt.
Du verwendest, wenn ich es richtig interpretiere, eine Mischung aus semantischen, gestalterischen und syntaktischen Kriterien: Überschrift, Liste, Text, Link, Tabelle, Header, Skip-Link | Schrift | Inline
Die generische Kategorie "Allgemein" existiert auch.
Mein Respekt übrigends, dass Du ein derart umfangreiches Stylesheet von 1300 Zeilen gut beherrscht.
Zum Vergleich: Jenes von Jens Meiert besteht aus 150 Zeilen.
@Andreas Borutta: Das Umsortieren von Selektoren sollte eigentlich Handarbeit bleiben, weil es sehr schnell ungeahnte Nebenwirkungen hervorrufen kann. Vermutlich gibt es zu wenige Leute, die daran ein Interesse haben, als daß es bald jemand einbaut.
Topstyle … kann kein UTF-8. Das ist kein Editor. Version 4 soll ja angeblich einer werden – vorher sehe ich mir das nicht an. Was deine Screenshots zeigen, ließe sich in Eclipse sicher umsetzen. Aber auch da wirst du selbst ranmüssen. ☺
Ich finde Jens Meierts Stylesheet enorm unübersichtlich. Das wird auf der Produktionsseite vermutlich besser aussehen, aber die vielen
!important-Regeln, die dieser Stil erzwingt, mag ich ganz und gar nicht. Die sind wie eine Mauer: Man kann sie nur mit Mühe überwinden.Mein Stylesheet überblicke ich auch dank des Codebaums, den Eclipse mir freundlicherweise anbietet. Ich nehme mir immer mal vor aufzuräumen, aber dabei bleibt es meistens …
Es ist eben doch recht aufwendig, eine Webseite schlicht aussehen zu lassen.
@toscho
Ja, Du wirst wohl Recht behalten mit Deiner Einschätzung. Sortierung muss wohlbedacht werden.
ACK, Topstyle ist indiskutabel aufgrund seiner fehlenden UTF-8 Unterstützung.
Es kann BTW auch nicht mit "@media" umgehen.
Uralter Bugs. Verstehe einer die Anbieter.
Zu Jens Meierts System:
Ich habe noch keine Position dazu entwickelt. Spontan empfinde ich es auch als "fremd".
Aber die Prägnanz und die in wenigen Regeln darstellbare Systematik hat was.
Zu dem Codebaum in Eclipse:
Gefällt mir sehr gut.
Etwas Ähnliches bietet Topstyle - was leider aus den erwähnten Gründen ausscheidet.