Danke erstmal für Deinen ausführlichen Beitrag!
Bspw. eine Angabe wie body#blog, body#archiv, ... ist in meinen Augen vollkommen überflüssig. Die IDs können doch gar nicht anders, als Erben von body sein.
Das ist schon richtig, aber nicht zuende gedacht. Selbstverständlich brauche ich die IDs für meine Navigationsmarkierung. Da ich nicht mit Conditionals im CMS arbeite, greife ich hier auf "matchende" CSS Paare zurück - eine geniale Methode. Mehr dazu hier:
Ich halte die Selektierung deiner IDs, wie z. B. div#wrapper, div#mainContent, auch für übertrieben, da du diese IDs von vornherein für den Div wrapper, mainContent vorgesehen hast und nie für was anderes nehmen kannst.
Genauso die Klassen, wie .entryBox. Es ist doch unerheblich, ob du die sowieso vorhandene Kaskade nochmals definierst, du rufst .entryBox nur im Div #mainContent auf.
Ob ich nun #mainContent oder div#mainContent schreibe ist wurscht, ich schreibe die Kaskade aus, damit ich und andere später im CSS sofort sehen können, in welchen Teil des Layout-Rasters die Selektoren passen. Gleich dazu mehr...
Code:
div#mainContent div.entryBox p span.fs18 { font-size: 1.4em; color: #444; }
div#mainContent div.entryBox p span.fs20 { font-size: 1.6em; color: #222; }
Es reicht doch, wenn man die Klassen
.fs12–.fs20 anlegt, ohne den gesamten Wust davor. Dann könntest du diese universell für deine
.entryBox und deine
.tagcloud einsetzen. So hast do zwei mal dieselben Deklarationen mit Unmengen unnötigem Code davor.
Nein, eben nicht. Wenn man so arbeitet, hat man am Ende 50 verschiedene Klassen für alle möglichen Elemente und man verliert den Überblick, welche Klasse wohin gehört. Ferner beeinflussen diese sich mit den Element-Selektoren ohne Klassenname. Im Falle der Tagcloud reicht im Moment noch eine (gleiche) Deklaration für beide Bereiche, aufgrund der zunehmenden Menge an Tags wird sich das bald ändern, die Tagcloud im Contentbereich zeigt andere Tags als in der Sidebar an.
Das was Du "Wust" und "Kaskadenbombe" nennst, ist der eleganteste Weg, um eindeutige Sile für die Zielelemente ohne viele Klassen zu erreichen. Auch bietet es sich an, in Vorbereitung für CM-System so zu arbeiten, will man die Redakteure nicht mit unterschiedlichen Klassendefinitionen belästigen.
Ein Beispiel: Ich brauche für meine Listen im Text eine spezielle Stildefinition.
Reicht nicht, da ich damit alle Listen formatiere.
Das ist Dein Vorschlag. Funktioniert schon, allerdings muss ich dafür sorgen, dass der Redakteur die Klasse mit im Editor oder sonstwo vergibt - ist nicht sehr benutzerfreundlich für die Schreiberlinge, da diese oft auch kein Verständnis von HTML und CSS haben -> "Klasse häh?"
Schafft durch die Kaskade einen eindeutigen Bezug zu der entsprechenden Liste, das CSS regelt alles und der Redakteur muss nur tippen. Baue ich noch mehr Spezifität rein, kann ich noch differenzierter Stile vergeben:
Code:
body#blog div#mainContent ul {}
body#archiv div#mainContent ul {}
Ich hoffe, dass Bsp. ist einleuchtend genug. Wie man in meinem CSS sehen kann, sind die meisten "Ziel"-Elemente der einzelnen Bereiche ohne Klassen als h2, h1, h3, p usw. ausgezeichnet, die Zuordnung erreiche ich über die Kaskade.
Code:
div#mainContent a.pagination,
div#mainContent a.pagination:link,
div#mainContent a.pagination:visited,
div#mainContent a.pagination:hover,
div#mainContent a.pagination:active { margin-bottom: 1em; }
Ist auch überflüssig, da Eigenschaften an Pseudoklassen vererbt werden.
Auch wieder nicht zuende gedacht. Sicher hätte ich das Ganze mit
div#mainContent a.pagination. abkürzen können, allerdings hatte ich mit verschiedenen Deklarationen für die Links in der Entstehungsphase gearbeitet, sprich z. B. mit
border für unterschiedliche Pseudoelemente und diese Eigenschaft wird nicht weitervererbt. Dass jetzt nur der margin übrig geblieben ist, ist durch den Gestaltungsprozess bedingt, allerdings ändert sich diese auch wieder. Ich könnte es im Moment löschen, das ist wohl war...
Was ich generell für ein Verbrechen an sauberem Code halte, ist sowas:
Code:
div#footer h3 { padding: 0.3em 0; margin: .5em 0; font: 1.7em/1.2em "lucida grande", sans-serif; font-weight: normal; color: #fff; background-color: transparent; border-bottom: 1px #fff dotted; }
Code muss übersichtlich sein. Wie man sich das selber „einteilt“ ist jetzt egal. Ich fange z. B. mit den grundlegenden Eigenschaften an, also float, display, height/width, dann kommen sachen wie padding, margin, border – auch wenn’s nicht exakt der Box-Modell-Reihenfolge entspricht. Hier sind wir aber wieder beim Thema, wie jeder mit seinem Code klarkommt.
Code:
div#footer h3 {
padding: 0.3em 0;
margin: .5em 0;
font: 1.7em/1.2em "lucida grande", sans-serif; /* Bei sowas würde ich nicht mit Schriftdeklarationen sparen, und wenn’s die blöde Arial für Windows ist. Generische Familien sind der (aller)letzte Notanker. */
font-weight: normal;
color: #fff;
background-color: transparent;
border-bottom: 1px #fff dotted;
}
Es wird zwar von der Höhe her wesentlich länger, dafür wird es aber wesentlich übersichtlicher.
Mit einem Selektor ist das natürlich übersichtlicher. Tu noch 2 dazu und es ist vorbei mit der Übersichtlichkeit. Ein Beispiel für ein simples Image Replacement Grundgerüst:
Code:
div#header h1 {}
div#header h1 a {}
div#header h1 a span {}
Eine mehrzeilige Deklaration
erschwert hier das Lesen des CSS, schliesslich interessiert nicht nur primär, was für Eigenschaften vergeben wurden, sondern welche Spezifität und Kaskadierung für welches Element wirksam sind. Das lässt sich nur in einem einzeiligen Stil leicht erfassbar darstellen. Sicher ist da Gewöhnung dabei, nach etwas Einarbeitungszeit möchte man dieses System nicht mehr missen. Hier steht auch etwas dazu:
Und wie Du sicher gesehen hast, arbeite ich auch display, die floats und das Boxmodell mit margins und paddings ab - allerdings nicht ganz konsequent, wie die strukturelle Reihenfolge des Box-Modells es vorgibt, da ist noch Potenzial vorhanden
Allerdings: Du hast das grundsätzliche System meiner Kaskadierung im CSS nicht verstanden. Deswegen halte ich die Aussage
in meinen Augen ist das CSS schlicht anfängerhaft und unprofessionell.
für vermessen und unangebracht. Wenn das Wort "Kaskade" im Namen der Technologie vorkommt, wird da schon was dran sein. Die Dinger heissen ja schliesslich nicht "
Classified Style Sheets"
Auch ich habe früher mit vielen verschiedenen Klassen ohne Kaskadierung und mit mehrzeiligen Deklarationsblöcken gearbeitet. Beim Reinzeichnen von Photoshop Layouts in XHTML/CSS-Vorlagen für CM-Systeme wie u. a. Typo3 als Auftragsarbeiten für Agenturen (was ich im Moment ständig mache) hat sich dieser CSS-Stil für alle Beteiligten als der Effizienteste herauskristallisiert, um nicht in 1000 Klassen zu ersticken, bei denen keiner weiss, welche wohin gehört.
Ergänzung1:
Die Seite sieht übrigens mit deaktiviertem CSS so aus:
Um diese Struktur mit einem Layout zu versorgen, braucht man schon ein paar Stile, zumal es zwei unterschiedliche Breiten für den Inhaltsbereich gibt. Nur weil man einzeilige CS-Sheets gaaaanz selten sieht und kaum jemand da draussen konsequent kaskadiert, heisst das noch lange nicht, dass das Unfug oder dilletantisch ist. Ist wohl ein bisschen wie mit den Macs vs. Windows oder dem Bauern: Was er nicht kennt, frisst er nicht
Ergänzung 2:
Hier ist noch ein schöner praktischer Beitrag von Jens Grochtdreis (Webkrauts) zum Thema:
Er schreibt interessanterweise:
J. Grochtdreis schrieb:
So vorzugehen bedeutet nicht zwangsweise eine Code-Ersparnis. Das CSS wird aber lesbarer, weil Bezüge sichtbar werden. Wir sehen auf einmal, welche Elemente von welchen anderen Elementen umgeben werden. Sprächen wir sie direkt an, könnten wir es nur wissen oder möglicherweise aus dem Namen erschließen.
