17.02.07Generische CSS-Klassen
Generische CSS-Klassen sind zunächst Selektoren, die unabhängig von bestimmten Elementtypen sind. D.h. man stellt dabei keinen Elementbezeichner voran (z.B. DIV.klasse)
.klasse {
...
}
Sie können auf jedes beliebige Element angewendet werden. Diesen Umstand kann man sich zu Nutze machen und auf diese Weise universell einsetzbare CSS-klassen definieren. Ein Element kann mehrere CSS-Klassen zugewiesen bekommen.
<p class="klasse1 klasse2">...</p>
Diese Art von Klassen kann oft ein sehr wirksames Mittel gegen zu große CSS-Dateien darstellen und die Dateigröße deutlich reduzieren. Vor allem in sehr großen Projekten mit komplexen Designs lohnt sich ihr Einsatz. Die folgende Übersicht zeigt wichtige Typen solcher Klassen.
.float-right {
float: right;
}
.float-left {
float: left;
}
.clear-both {
clear: both;
}
.block {
display: block;
}
.no-border {
border: none;
}
.no-bullets {
list-style-type: none;
}
.bold {
font-weight: bold;
}
Ein durchgeführter Selbsttest anhand des Stylesheets meiner Website ergab eine Reduzierung von 7%. Weitere Vergleiche bei der Entwicklung eines sehr komplexen GUI-Designs in unserem Webdesign-Team führten zu noch deutlicheren Einsparungen von CSS-Code. Im Bereich von 10-15%. Dieser positive Effekt ergibt sich durch die Einsparung vieler Zeilen CSS-Code. So muss z.B. Elementen, die links gefloatet sein sollen nicht immer wieder die Eigenschaft float: left; mitgegeben werden. Sie nutzen dann die Klasse .float-left.
Natürlich kann ein ähnlicher Effekt durch die Aneinanderreihung mehrerer Elementselektoren und nachfolgender Zuweisung der CSS-Eigenschaft erreicht werden. Verkürzt z.B.
div.klasse1, div.klasse3, p.klasse 4 {
float: left;
}
Allerdings gilt es dabei zu beachten, dass das Ganze sehr schnell sehr unübersichtlich wird und die Lesbarkeit des Codes dadurch reduziert wird.
Der Einsatz generischer CSS-Klassen ist in jedem Fall eine Überlegung wert. Allerdings sollte man es nicht übertreiben und versuchen, alle möglichen Elementeigenschaften auf diese Weise zu steuern. Die oben genannten Klassen sind sehr eingänglich und beinhalten CSS-Eigenschaften, die sehr oft verwendet werden. Denkbar schlechte Eigenschaften betreffen Farb- und Größenangaben, wie z.B.:
.fff {
color: #fff;
}
.width500 {
width: 500px;
}
Was, wenn sich Farbe (z.B. durch Änderung eines Corporate Designs) oder Breite der Elemente ändern. In diesem Fall würden diese Klassen für Verwirrung sorgen. Am besten geeignet sind CSS-Eigenschaften, die Elemente positionieren und grundlegende Eigenschaften steuern. Weniger bis gar nicht geeignet sind solche, die Dimensionen und Farben steuern.
Die Nutzung generischer CSS-Klassen führt auf der anderen Seite natürlich zu etwas mehr HTML Code, durch die Klassenangaben. Unterm Strich aber, sind sie ein wichtiger Baustein für schlankeren Code.
Der Einsatz generischer Klassen und die Beachtung wichtiger Grundregeln - wie sie hier bereits beschrieben wurden - bilden eine solide Basis für effiziente Stylesheets.
Jeena Paradies am Feb 17, 2007 | Reply
Das stimmt so IMHO gar nicht. Wir haben auf der Arbeit eine light Version unseres Hauptproduktes, bei der wir ausschließlich das CSS und Kundenspezifische Inhalte ändern dürfen. Ich weiß nicht genau wie viele Installationen davon in Betrieb sind, aber es sind ziemlich viele.
Wenn man dabei Klassennamen wie float-right, no-border oder bold benutzen würde wäre das ein gehöriger Schuss nach hinten und würde die Lesbarkeit des Codes erheblich verschlechtern, da nicht jeder Kunde zum Beispiel die Subnavigation rechts haben möchte, etc.
Übrigens, für .bold gibt es was in 99% der fälle besser dazu gedacht ist etwas hervorzuheben ;-)
patrick h. lauke am Feb 17, 2007 | Reply
klassennamen und IDs sollten semantisch sein…du solltest sagen WAS etwas is, nicht WIE es aussieht.
http://www.w3.org/QA/Tips/goodclassnames
patrick h. lauke am Feb 17, 2007 | Reply
“diesmal halt mit CSS anstatt FONT, B, I usw.”
Bernhard am Feb 17, 2007 | Reply
In einigen, wenigen Fällen, nutze ich deinen „Vorschlag“ aber schon so ähnlich.
Beispielsweise bei Bildern, die umflossen werden sollen, oder als Helferlein für Javascript-Effekte, wie das Ein- und Ausblenden von Objekten.
Björn am Feb 17, 2007 | Reply
Und deswegen mache ich die Einschränkung auf relativ wenige Fälle. gut das Bsp. “bold” ist etwas ungeschickt gewählt. Ansonsten haben uns solche Klassen in der Vergangenheit ganz konkret weiter gebracht. Es ist zwar nicht die “reine Lehre”. Aber auch sie stößt in der Praxis mal an ihre Grenzen.
Jeena, dass es bei Dir nicht hinhaut,verstehe ich auch. Aber es gibt viele Fälle, wo es was bringt. Die Gründe die Du anführst sind ganz klar nachvollziehbar und sind auch in meiner täglichen Praxis Grund dafür, diese generischen Klassen auch mal “stecken zu lassen”.
Schön zu sehen, dass es sich um ein diskussionswürdiges Thema handelt und andere Sichtweisen eingebracht werden.
Eric Eggert am Feb 18, 2007 | Reply
Keines deiner Beispiele hat eine praxisrelevante Funktion. Selbst wenn du das Stylesheet um 7% verkleinerst, so hast du die ganzen Klassen eben im Markup stehen und der HTML-Code ist eben aufgebläht.
Was, wenn dein
float-right-Element links floaten soll. Willst du das dann lieber in der Präsentationsdatei ändern oder im HTML?Meiner Meinung nach hat das im HTML überhaupt nichts zu suchen. Generische CSS-Klassen sind ohne Frage toll, aber wenn ich jedem Element zig Klassen mitgeben muss, damit es so aussieht wie ich will, dann macht das überhaupt keinen Sinn.
Du siehst, ich bin da völlig bei Jeena und Patrick. Nacht.
Kjell Bublitz am Feb 18, 2007 | Reply
Genau das wollte ich auch gerade vorbringen. Es bringt nicht viel und macht zudem die Anwendung des “neuen Schemas” schwierig. Also mich würde es stören wenn ich für ein italic oder ähnliches immer schauen müsste was fürn klassennamen ich mir ausgedacht habe.
Die Methode verführt auch dazu, dass man sich aus welchen Gründen auch immer das definieren einer eignene Klasse spart und auf langatmige class Attribute umschwenkt, frei nach dem Motto: “Das kann ich auch mit ner Kombi aus fünf Klassen haben.”
Deine float Beispiele und auch no-bullets sind absolut legitim. block hingegen ist imho wieder overkill: Typische Anwendungsgebiete für “display:block” sind Anker oder Labels. Diese kommen jedoch häufig im Quelltext vor, und das auch meist gruppiert (menüs, formulare, linklisten). Daher wäre es besser dem übergeordnetem Element diese Eigenschaft vererben zu lassen anstatt class=”block” ständig zu wiederholen.
Alles in allem ist das schon eine praktikable Methode, aber mit äusserste Vorsicht zu geniessen. Man sollte nicht dazu tendieren seinen eigenen MarkUp mit CSS zu erfinden.
Björn am Feb 18, 2007 | Reply
Es sind eben keine zig Klassen. Es gibt insgesamt in dem betreffenden Projekt vielleicht ein dutzend Fälle, wo es zu drei Klassen kommt - noch mehr Klassen wurden keinem Element zugewiesen. Ansonsten einige mit zwei und das war es dann auch schon. Und wie schon angemerkt hat es was gebracht, sonst hätten wir es nicht getan.
Nochmal: “Bold” ist ein blödes Beispiel, welches auch in dem betreffenden Projekt nicht verwendet wird. Wir konzentrien uns auf die floats und clears.
Jeder sollte also für sich entscheiden, ob diese Methode in Frage kommt. Bei meiner eigenen Website würde ich es so nicht praktizieren, da 7% bei knapp 13kb kein gewichtiges Argument sind, mir in meiner Freizeit diesen Mehraufwand zu machen. Aber 10-15% bei über 100kb schon.
Björn am Feb 18, 2007 | Reply
Au contraire Eric, etwa 4-5kb gesamt HTML stehen etwa 15kb weniger CSS gegenüber. Im konkreten Fall ist es so, glaub mir. Wir fahren entsprechende Auswertungen mit Skripten. Die entsprechenden Kennzahlen sprachen eine deutliche Sprache (diese generischen Klassen sind nur ein Baustein).
troy am Feb 21, 2007 | Reply
Ich kann nur schärfstens davon abraten!!!
Björn am Feb 21, 2007 | Reply
Mir zu pauschal. Und wie bereits angemerkt funktioniert es bei uns im konkreten Fall gut.
Markus Petschenig am Feb 21, 2007 | Reply
Ich hab mich bis jetzt eigentlich eher davon distanziert, da mir wie gesagt die Funktionstauglichkeit davon nicht bekannt ist. Danke für den thematischen Ansatz!
mfg Markus
Finn am Feb 21, 2007 | Reply
Gruz,
Finn
Björn am Feb 22, 2007 | Reply
Bingo! :-)
Siegfried am Feb 26, 2007 | Reply
rein technisch gesehen sicher richtig. Dabei wird aber mMn von falschen Voraussetzungen ausgegangen. Der Artikel impliziert, daß Klassennamen von html-Elementen ausschließlich, zu 100% als Vehikel für CSS dienen. Doch genau dazu sind Klassennamen nicht da. Sie sind dazu da, dem html-Element entweder überhaupt erst eine Semantik zu verleihen (im Fall von div und span), oder die dem lement inhärente Semantik zu verfeinern, zu präzisieren. Ob was auch immer irgendwie floatend dargestellt wird, hat Nichts, aber auch gar Nichts, mit der Bedeutung des entsprechenden Blocks zu tun, und schon gar nicht hat eine rein visuelle Aufbereitung gleich welcher Art etwas mit der Bedeutung des Blocks zu tun.
Sicher richtig ist, daß es bestimmte Klassennamen gibt, die sehr gut auf verschiedene Elemente anwendbar sind. Einige der Klassennamen aus dem Microformats Projekt sind dafür gute Beispiele. Und ich selber habe mal vor einiger Zeit eine Seite online gestellt, die etwas Ähnliches für die altbekannten Dublin Core Klassen postuliert (http://www.rorkvell.de/tech/dc). Allerdings wird man dadurch kaum Platz im css sparen.
Oliver Timmermann am Mrz 15, 2007 | Reply
larsen am Jun 23, 2007 | Reply
Die ganz große Idee hinter den Cascading Sylesheets ist ja eben Layout und Content strikt(!!!) voneinander zu trennen. Der o.g. Paragraph hieße dann vielleicht
Warum? Bei der nächsten Layoutüberarbeitung ist der ehemals rote Text dann plötzlich blau, und die Klasse ‘roterText’ wäre dann dazu extrem verwirrend!
Klar — man kann das dann auch in den HTML-Seiten ändern; aber wenn man selbige z.B. einmal über unzählige einzelne kleine Include-Snippets in ein CMS-gegeben hat will man das nicht mehr machen!!!
Darum: IDs und Klassen  I M M E R semantisch benennen,  N I E nach ihren (gerade aktuellen) Design !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
larsen am Jun 23, 2007 | Reply
Das Comment-Feature hat die Angaben mit spitzen Klammern gekillt.
Im ersten Absatz sollte es heißen (nun ohne spitze Klammern):
p class=”roterText”
Entsprechend am Ende des folgenden Absatzes:
p class=”alert”
larsen am Jun 23, 2007 | Reply
Ein viel viel viel zu selten beachtetes Feature von CSS betrifft dessen ersten Buchstaben: “C” = cascading.
Darin liegt eine ganz enorme Kraft, die — richtig angewendet — aus ein-und-derselben sehr(!) einfachen(!) HTML-Struktur (nur) über CSS wirklich JEDES Layout entstehen lässt.
div#head h1 { … }
div#head p { … }
div#head p a { … }
div#head p a img { … }
div#body h1 { … }
div#body p { … }
div#body p a { … }
div#body p a:hover { … }
…
-> So lassen sich fast allein über die Definition der Hauptbereiche über die Kaskadierung wunderbar spezifische Gestaltungsangaben anbringen, wie in diesem Fall unterschiedlich für #HEAD und #BODY …
larsen am Jun 23, 2007 | Reply
Darum noch ein schneller Nachtrag:
Warum ist das o.g. Verfahren so toll?
Gib den Codern ’ne genau definierte HTML-Struktur in die Hand; dann können die das mit PHP (oder was auch immer) auseinander sägen wie sie lustig sind.
Und während die noch ihr CMS coden kannst Du parallel (ausschließlich!) in der CSS-Datei Dein Design applizieren.
Kleines Bonbon: Mit der o.g. sehr strukturierten Herangehensweise über Kaskadierung organisiert sie das Layout quasi von selbst(!!!) :-)))
Björn am Jun 23, 2007 | Reply
Nur noch soviel. Was hier niedergeschriebn wurde sollte nicht - und das müsste ersichtlich sein - universell festgeschrieben werden. Es hat sich aber in der echten Praxis in einem Team mit mehreren Webdesignern in einer sehr großen Webanwendung bewährt. Ist einfach so. Von Klassen “roter Text” war auch gar nicht die Rede. Punkt.
Thomas am Sep 20, 2007 | Reply
Ich arbeite ebenfalls mit solchen Klassen. Und sie machen Sinn, wenn man verschiedene Module für eine CMS programmiert.
Wenn der Redakteur entscheidet wo denn das Bild neben dem Text stehen soll dann wird diese Eingabe kontrolliert und die entsprechende Klasse (in diesem Bspl. float-left, float-right) in das -Tag geschrieben.