Verwaltung der CSS-Explosion

Question

Ich habe mich für eine Website, an der ich arbeite, stark auf CSS verlassen. Im Moment werden alle CSS-Stile pro Tag angewendet, und deshalb versuche ich jetzt, sie zu einem externen Styling zu verschieben, um bei zukünftigen Änderungen zu helfen.

Das Problem ist jedoch, dass ich festgestellt habe, dass ich eine "CSS-Explosion" erlebe. Es wird immer schwieriger für mich zu entscheiden, wie ich die Daten innerhalb der CSS-Datei am besten organisieren und abstrahieren kann.

Ich verwende eine große Anzahl von div Tags innerhalb der Website und wechselte von einer stark tabellenbasierten Website. Ich erhalte also eine Menge CSS-Selektoren, die wie folgt aussehen:

div.title {
  background-color: blue;
  color: white;
  text-align: center;
}

div.footer {
  /* Styles Here */
}

div.body {
  /* Styles Here */
}

/* And many more */

Es ist noch nicht allzu schlimm, aber da ich ein Anfänger bin, habe ich mich gefragt, ob es Empfehlungen gibt, wie man die verschiedenen Teile einer CSS-Datei am besten organisiert. Ich möchte nicht für jedes Element auf meiner Website ein eigenes CSS-Attribut haben, und ich möchte immer, dass die CSS-Datei ziemlich intuitiv und leicht zu lesen ist.

Mein Ziel ist es, die Verwendung von CSS-Dateien zu vereinfachen und ihre Leistungsfähigkeit zu demonstrieren, um die Geschwindigkeit der Webentwicklung zu erhöhen. Auf diese Weise werden auch andere Personen, die in Zukunft an dieser Website arbeiten, in die Praxis der guten Kodierungspraktiken eingeführt und müssen sie nicht erst lernen, wie ich es getan habe.

Answer 1

Das ist eine sehr gute Frage. Überall, wo ich hinschaue, neigen CSS-Dateien dazu, nach einer Weile außer Kontrolle zu geraten - vor allem, aber nicht nur, wenn man im Team arbeitet.

Im Folgenden sind die Regeln aufgeführt, die ich selbst zu befolgen versuche (was mir nicht immer gelingt).

• Frühzeitig refaktorisieren, oft refaktorisieren. Bereinigen Sie häufig CSS-Dateien, indem Sie mehrere Definitionen der gleichen Klasse zusammenführen. Entfernen veralteter Definitionen sofort .

• Wenn Sie beim Beheben von Fehlern CSS hinzufügen, geben Sie einen Kommentar dazu ab, was die Änderung bewirkt ("Damit wird sichergestellt, dass der Kasten im IE < 7 links ausgerichtet ist").

• Vermeiden Sie Redundanzen, z. B. die Definition desselben Begriffs in .classname et .classname:hover .

• Kommentare verwenden /** Head **/ um eine klare Struktur zu schaffen.

• Verwenden Sie ein Verschönerungswerkzeug, das Ihnen hilft, einen konstanten Stil beizubehalten. Ich verwende Polystyle mit dem ich sehr zufrieden bin (kostet $15, ist aber gut angelegtes Geld). Es gibt auch kostenlose Programme (z. B. Code-Verschönerer auf Grund CSS aufgeräumt (ein Open-Source-Tool).

• Erstellen Sie sinnvolle Klassen. Siehe unten für einige Hinweise dazu.

• Semantik verwenden, DIV-Suppe vermeiden - verwenden <ul> s für Menüs, zum Beispiel.

• Definieren Sie alles auf einer möglichst niedrigen Ebene (z. B. eine Standardschriftfamilie, -farbe und -größe in der body ) und verwenden inherit soweit möglich

• Wenn Sie sehr komplexes CSS haben, hilft vielleicht ein CSS-Pre-Compiler. Ich plane einen Blick in xCSS aus genau demselben Grund bald. Es gibt noch einige andere in der Nähe.

• Wenn Sie in einem Team arbeiten, weisen Sie auf die Notwendigkeit von Qualität und Standards auch für CSS-Dateien hin. Jeder legt großen Wert auf Codierungsstandards in seiner/ihren Programmiersprache(n), aber es gibt wenig Bewusstsein dafür, dass dies auch für CSS notwendig ist.

• Wenn Sie in einem Team arbeiten, hacer die Verwendung der Versionskontrolle in Betracht ziehen. Damit lassen sich die Dinge viel leichter verfolgen und Bearbeitungskonflikte viel leichter lösen. Es lohnt sich wirklich, auch wenn Sie sich "nur" mit HTML und CSS beschäftigen.

• Arbeiten Sie nicht mit !important . Nicht nur, weil IE =< 7 damit nicht umgehen kann. In einer komplexen Struktur ist die Verwendung von !important Es ist oft verlockend, ein Verhalten zu ändern, dessen Ursache nicht gefunden werden kann, aber es ist Gift für die langfristige Instandhaltung.

Aufbau sinnvoller Klassen

So baue ich gerne sinnvolle Klassen auf.

Ich wende zuerst die globalen Einstellungen an:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

Dann identifiziere ich die Hauptbereiche des Seitenlayouts, z. B. den oberen Bereich, das Menü, den Inhalt und die Fußzeile. Wenn ich ein gutes Markup geschrieben habe, werden diese Bereiche mit der HTML-Struktur identisch sein.

Dann beginne ich mit der Erstellung von CSS-Klassen, wobei ich so viele Abstammungen wie möglich festlege, solange sie sinnvoll sind, und verwandte Klassen so eng wie möglich gruppiere.

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

Stellen Sie sich die gesamte CSS-Struktur als eine Baum mit immer spezifischeren Definitionen, je weiter man von der Wurzel entfernt ist. Sie wollen die Anzahl der Klassen so gering wie möglich halten und sich so selten wie möglich wiederholen.

Nehmen wir zum Beispiel an, Sie haben drei Ebenen von Navigationsmenüs. Diese drei Menüs sehen unterschiedlich aus, haben aber auch bestimmte gemeinsame Merkmale. Zum Beispiel sind sie alle <ul> haben sie alle die gleiche Schriftgröße, und die Elemente stehen alle nebeneinander (im Gegensatz zur Standarddarstellung eines ul ). Außerdem gibt es in keinem der Menüs Aufzählungspunkte ( list-style-type ).

Definieren Sie zunächst die gemeinsame Merkmale in einer Klasse namens menu :

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

dann die spezifischen Merkmale jedes der drei Menüs definieren. Ebene 1 ist 40 Pixel hoch, die Ebenen 2 und 3 20 Pixel.

注 Sie könnten auch mehrere Klassen dafür verwenden, aber Internet Explorer 6 hat Probleme mit mehreren Klassen Dieses Beispiel verwendet also id s.

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

Das Markup für das Menü wird wie folgt aussehen:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

Wenn Sie semantisch ähnliche Elemente auf der Seite haben - wie diese drei Menüs - versuchen Sie zuerst, die Gemeinsamkeiten herauszuarbeiten und sie in eine Klasse zu packen; dann arbeiten Sie die spezifischen Eigenschaften aus und wenden sie auf Klassen an, oder, wenn Sie Internet Explorer 6 unterstützen müssen, auf IDs.

Verschiedene HTML-Tipps

Wenn Sie diese Semantik zu Ihrer HTML-Ausgabe hinzufügen, können Designer später das Aussehen von Websites und/oder Anwendungen mit reinem CSS anpassen, was ein großer Vorteil und eine Zeitersparnis ist.

• Wenn möglich, geben Sie jeder Seite eine eigene Klasse: <body class='contactpage'> Dies macht es sehr einfach, der Formatvorlage seitenbezogene Anpassungen hinzuzufügen:

  body.contactpage div.container ul.mainmenu li { color: green }

• Wenn Sie Menüs automatisch erstellen, fügen Sie so viel CSS-Kontext wie möglich hinzu, um später eine umfassende Gestaltung zu ermöglichen. Zum Beispiel:

  <ul class="mainmenu">
   <li class="item_first item_active item_1"> First item </li> 
   <li class="item_2"> Second item </li> 
   <li class="item_3"> Third item </li> 
   <li class="item_last item_4"> Fourth item </li> 
  </ul>

  Auf diese Weise kann jeder Menüpunkt entsprechend seinem semantischen Kontext zur Gestaltung herangezogen werden: Ob es das erste oder letzte Element in der Liste ist, ob es das derzeit aktive Element ist und nach Nummer.

Note dass diese Zuweisung mehrerer Klassen, wie im obigen Beispiel beschrieben funktioniert im IE6 nicht richtig . Es gibt eine Abhilfe um den IE6 in die Lage zu versetzen, mit mehreren Klassen umzugehen. Wenn die Umgehung nicht möglich ist, müssen Sie die für Sie wichtigste Klasse festlegen (Artikelnummer, aktiv oder erste/letzte) oder auf IDs zurückgreifen.

Answer 2

Hier sind nur 4 Beispiele:

• CSS-Konventionen / Code-Layout-Modelle
• Gibt es irgendwelche CSS-Standards, die ich beim Schreiben meines ersten Stylesheets beachten sollte?
• Was ist die beste Methode, um CSS aufzuräumen?
• Bewährte Praktiken - CSS-Stylesheet-Formatierung

Auf alle 4 Fragen habe ich geantwortet und empfohlen, die PDF-Datei von Natalie Downe herunterzuladen und zu lesen. CSS-Systeme . (Die PDF-Datei enthält zahlreiche Anmerkungen, die nicht in den Folien enthalten sind, also lesen Sie die PDF-Datei!). Achten Sie auf ihre Vorschläge zur Organisation.

BEARBEITEN (2014/02/05) vier Jahre später, würde ich sagen:

• Verwenden Sie einen CSS-Präprozessor und verwalten Sie Ihre Dateien als Partialdateien (ich persönlich bevorzuge Sass mit Compass, aber Less ist auch ziemlich gut und es gibt noch andere)
• Informieren Sie sich über Konzepte wie OOCSS , SMACSS et BEM o getbem .
• Schauen Sie sich an, wie beliebte CSS-Frameworks wie Bootstrap et Zurb Stiftung strukturiert sind. Und lassen Sie auch weniger beliebte Frameworks nicht außer Acht - Inuit ist ein interessantes Beispiel, aber es gibt noch viele andere.
• Kombinieren/Minifizieren Sie Ihre Dateien mit einem Build-Schritt auf einem Continuous-Integration-Server und/oder einem Task-Runner wie Grunt oder Gulp.

Answer 3

Schreiben Sie keine Überschriften in CSS

Teilen Sie einfach Abschnitte in Dateien auf. Alle CSS-Kommentare sollten genau das sein, nämlich Kommentare.

reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css

Verwenden Sie ein Skript, um sie zu einem einzigen zu kombinieren, falls erforderlich. Sie können auch eine schöne Verzeichnisstruktur haben und Ihr Skript einfach rekursiv suchen lassen nach .css Dateien.

Wenn Sie Überschriften schreiben müssen, stellen Sie ein Inhaltsverzeichnis an den Anfang der Datei.

Die Überschriften im Inhaltsverzeichnis sollten genau den Überschriften entsprechen, die Sie später schreiben. Es ist mühsam, nach Überschriften zu suchen. Um das Problem noch zu verschlimmern, wie genau soll jemand wissen, dass Sie eine weitere Überschrift nach Ihrer ersten Überschrift haben? ps. Fügen Sie beim Schreiben von TOCs keine doc-ähnlichen * (Stern) am Anfang jeder Zeile ein, das macht es nur noch lästiger, den Text auszuwählen.

/* Table of Contents
   - - - - - - - - -
   Header stuff
   Body Stuff
   Some other junk
   - - - - - - - - -
 */
...
/* Header Stuff 
 */
...
/* Body Stuff 
 */

Schreiben Sie Kommentare mit oder innerhalb der Regeln, nicht außerhalb des Blocks

Erstens: Wenn Sie das Skript bearbeiten, ist die Wahrscheinlichkeit 50/50, dass Sie auf das achten, was außerhalb des Regelblocks steht (vor allem, wenn es sich um einen großen Textklumpen handelt ;) ). Zweitens gibt es (fast) keinen Fall, in dem Sie einen "Kommentar" außerhalb benötigen. Wenn er außerhalb steht, handelt es sich in 99% der Fälle um einen Titel, also belassen Sie es dabei.

Aufteilung der Seite in Komponenten

Die Komponenten sollten folgende Eigenschaften haben position:relative , nein padding und keine margin die meiste Zeit über. Dies vereinfacht die %-Regeln erheblich und ermöglicht auch eine viel einfachere absolute:position von Elementen, denn wenn es einen absolut positionierten Container gibt, verwendet das absolut positionierte Element den Container bei der Berechnung der top , right , bottom , left Eigenschaften.

Die meisten DIVs in einem HTML5-Dokument sind normalerweise eine Komponente.

Eine Komponente ist auch etwas, das als unabhängige Einheit auf der Seite betrachtet werden kann. Laienhaft ausgedrückt: Behandeln Sie etwas wie eine Komponente, wenn es Sinn macht, etwas wie eine Komponente zu behandeln. Blackbox .

Nochmals das Beispiel mit der QA-Seite:

#navigation
#question
#answers
#answers .answer
etc.

Indem Sie die Seite in Komponenten aufteilen, unterteilen Sie Ihre Arbeit in überschaubare Einheiten.

Setzen Sie Regeln mit kumulativer Wirkung in dieselbe Zeile.

Zum Beispiel border , margin et padding (aber nicht outline ) tragen alle zu den Abmessungen und der Größe des Elements bei, das Sie gestalten.

position: absolute; top: 10px; right: 10px;

Wenn sie auf einer Zeile nicht so gut lesbar sind, sollten sie zumindest in unmittelbarer Nähe zueinander stehen:

padding: 10px; margin: 20px;
border: 1px solid black;

Verwenden Sie wenn möglich die Kurzschrift:

/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;

Niemals einen Selektor wiederholen

Wenn Sie mehrere Instanzen desselben Selektors haben, besteht eine gute Chance, dass Sie zwangsläufig mehrere Instanzen derselben Regeln haben. Zum Beispiel:

#some .selector {
    margin: 0;
    font-size: 11px;
}
...
#some .selector {
    border: 1px solid #000;
    margin: 0;
}

Vermeiden Sie die Verwendung von TAGs als Selektoren, wenn Sie id/classes verwenden können

Zunächst einmal sind die DIV- und SPAN-Tags die Ausnahme: Sie sollten sie nie verwenden, niemals! ;) Verwenden Sie sie nur, um eine Klasse/Id anzuhängen.

Das...

div#answers div.answer table.statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
    outline: 3px solid #000;
}

Sollte so geschrieben werden:

#answers .answer .statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

Denn die zusätzlichen baumelnden DIVs dort fügen dem Selektor nichts hinzu. Außerdem erzwingen sie eine unnötige Tag-Regel. Wenn Sie ändern würden, zum Beispiel, .answer von einer div zu einer article Ihr Stil würde brechen.

Oder wenn Sie mehr Klarheit wünschen:

#answers .answer .statistics {
    color: pink;
    border: 1px solid #000;
}
#answers .answer table.statistics {
    border-collapse: collapsed;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

Der Grund dafür ist die border-collapse ist eine besondere Eigenschaft, die nur sinnvoll ist, wenn sie auf eine table . Si .statistics ist keine table sollte sie nicht gelten.

Allgemeine Regeln sind böse!

• Vermeiden Sie es, generische/magische Regeln zu schreiben, wenn Sie können.
• sofern es sich nicht um ein CSS-Reset/Unreset handelt, sollten alle Ihre generischen Zaubereien auf mindestens eine Root-Komponente angewendet werden

Sie sparen keine Zeit, sondern lassen Ihren Kopf explodieren und machen die Wartung zu einem Albtraum. Wenn Sie die Regeln schreiben, wissen Sie vielleicht, wo sie gelten, aber das ist keine Garantie dafür, dass Ihre Regeln Ihnen später nicht in die Quere kommen.

Hinzu kommt, dass allgemeine Regeln verwirrend und schwer zu lesen sind, selbst wenn man eine gewisse Vorstellung von dem Dokument hat, das man gestaltet. Das soll nicht heißen, dass Sie keine generischen Regeln schreiben sollten. Verwenden Sie sie nur, wenn Sie wirklich beabsichtigen, dass sie generisch sind, und fügen Sie selbst dann so viele Bereichsinformationen in den Selektor ein, wie Sie können.

Dinge wie diese...

.badges {
    width: 100%;
    white-space: nowrap;
}

address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

...hat das gleiche Problem wie die Verwendung globaler Variablen in einer Programmiersprache. Sie müssen ihnen einen Anwendungsbereich geben!

#question .userinfo .badges {
    width: 100%;
    white-space: nowrap;
}

#answers .answer .userinfo address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

Das bedeutet im Grunde genommen Folgendes:

components                   target
---------------------------- --------
#answers .answer   .userinfo address
-------- --------- --------- --------
domain   component component selector 

Ich verwende gerne IDs, wenn eine Komponente, von der ich weiß, dass sie ein Singleton auf einer Seite ist, Ihre Bedürfnisse können anders sein.

Hinweis: Im Idealfall sollten Sie gerade genug schreiben. Die Nennung von mehr Komponenten im Selektor ist jedoch der verzeihlichere Fehler im Vergleich zur Nennung von weniger Komponenten.

Nehmen wir an, Sie haben eine pagination Komponente. Sie verwenden sie an vielen Stellen auf Ihrer Website. Dies wäre ein gutes Beispiel dafür, dass Sie eine allgemeine Regel schreiben sollten. Sagen wir, Sie display:block die einzelnen Seitenzahl-Links und geben ihnen einen dunkelgrauen Hintergrund. Damit sie sichtbar sind, müssen Sie Regeln wie diese aufstellen:

.pagination .pagelist a {
    color: #fff;
}

Angenommen, Sie verwenden Ihre Paginierung für eine Liste von Antworten, dann könnte es etwa so aussehen

#answers .header a {
    color: #000;
}
...
.pagination .pagelist a {
    color: #fff;
}

Dadurch werden Ihre weißen Links schwarz, was Sie nicht wollen.

Der falsche Weg ist, dies zu beheben:

.pagination .pagelist a {
    color: #fff !important;
}

Die korrekte Vorgehensweise ist:

#answers .header .pagination .pagelist a {
    color: #fff;
}

Komplexe "logische" Kommentare funktionieren nicht :)

Wenn Sie etwas schreiben wie: "Dieser Wert ist abhängig von blah-blah in Kombination mit der Höhe von blah-blah", ist es einfach unvermeidlich, dass Sie einen Fehler machen und alles wie ein Kartenhaus zusammenfällt.

Halten Sie Ihre Kommentare einfach; wenn Sie "logische Operationen" benötigen, sollten Sie eine dieser CSS-Vorlagensprachen wie SASS o LESS .

Wie kann ich eine Farbpalette erstellen?

Lassen Sie dies für das Ende. Legen Sie eine Datei für Ihre gesamte Farbpalette an. Ohne diese Datei sollte Ihr Stil noch eine brauchbare Farbpalette in den Regeln haben. Ihre Farbpalette sollte überschrieben werden. Sie verketten Selektoren mit einer sehr hohen übergeordneten Komponente (z.B.. #page ) und schreiben Sie dann Ihren Stil als einen eigenständigen Regelblock. Es kann nur Farbe oder etwas mehr sein.

z. B.

#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
    color: #222; background: #fff; 
    border-radius: 10px;
    padding: 1em;
}

Die Idee ist einfach: Ihre Farbpalette ist ein vom Basisstil unabhängiges Stylesheet, das Sie Kaskade in.

Weniger Namen, weniger Speicherbedarf, dadurch leichtere Lesbarkeit des Codes

Es ist besser, weniger Namen zu verwenden. Verwenden Sie idealerweise sehr einfache (und kurze!) Wörter: Text, Hauptteil, Überschrift.

Ich finde auch, dass eine Kombination von einfachen Wörtern leichter zu verstehen ist als eine Suppe von langen "passenden" Wörtern: postbody, posthead, userinfo, etc.

Halten Sie das Vokabular klein, so dass ein Fremder, der Ihre Stilsuppe liest (wie Sie selbst nach ein paar Wochen ;)), nur verstehen muss, wo Wörter verwendet werden und nicht, wo jeder Selektor eingesetzt wird. Ich verwende zum Beispiel .this wenn ein Element angeblich "das ausgewählte Element" oder "das aktuelle Element" usw. ist.

Räumt hinter euch auf

CSS schreiben ist wie essen, manchmal hinterlässt man eine Sauerei. Stellen Sie sicher, dass Sie das Chaos aufräumen, sonst stapelt sich der Code-Müll nur. Entfernen Sie Klassen/ids, die Sie nicht verwenden. Entfernen Sie CSS-Regeln, die Sie nicht verwenden. Achten Sie darauf, dass alles schön straff ist und Sie keine widersprüchlichen oder doppelten Regeln haben.

Wenn Sie, wie ich vorgeschlagen habe, einige Container als Blackboxes (Komponenten) in Ihrem Stil behandeln, diese Komponenten in Ihren Selektoren verwenden und alles in einer eigenen Datei aufbewahren (oder eine Datei mit einem TOC und Kopfzeilen richtig aufteilen), dann ist Ihre Arbeit wesentlich einfacher...

Sie können ein Tool wie die Firefox-Erweiterung Dust-Me Selectors verwenden (Tipp: Zeigen Sie damit auf Ihre sitemap.xml), um den Müll zu finden, der sich in Ihren Css-Nukes und Carnies versteckt.

Behalten Sie eine unsorted.css Datei

Angenommen, Sie gestalten eine QA-Site und haben bereits ein Stylesheet für die "Antwortseite", das wir als answers.css . Wenn Sie nun viel neues Css hinzufügen müssen, fügen Sie es in die Datei unsorted.css Stylesheet und refaktorisieren Sie dann in Ihr answers.css Stylesheet.

Hierfür gibt es mehrere Gründe:

• Es ist schneller, nach der Fertigstellung zu refaktorisieren, als nach Regeln zu suchen (die wahrscheinlich nicht existieren) und Code einzufügen.
• Sie werden Dinge schreiben, die Sie entfernen wollen, und das Einfügen von Code macht es nur schwieriger, diesen Code zu entfernen.
• das Anhängen an die Originaldatei führt leicht zu einer Duplizierung von Regeln/Selektoren

Answer 4

Schauen Sie sich an 1. SASS 2. Kompass

Answer 5

Das beste Mittel, das ich gesehen habe, um gegen CSS aufzublähen, ist die Verwendung objektorientierter CSS-Prinzipien.

Es gibt sogar eine OOCSS Rahmen da draußen, der ziemlich gut ist.

Einige der Ideologien stehen im Widerspruch zu dem, was hier in den Top-Antworten gesagt wurde, aber wenn man erst einmal weiß, wie man Architekten CSS in einer objektorientierten Art und Weise werden Sie sehen, dass es tatsächlich funktioniert, um den Code schlank zu halten.

Das Wichtigste dabei ist, "Objekte" oder Bausteinmuster in Ihrer Website zu identifizieren und mit ihnen zu arbeiten.

Facebook hat den Schöpfer von OOCSS eingestellt, Nicole Sullivan um eine Menge Einsparungen in ihrem Front-End-Code (HTML / CSS) zu erhalten. Ja, Sie können tatsächlich Einsparungen nicht nur in Ihrem CSS, sondern auch in Ihrem HTML, die durch den Klang der es, ist sehr möglich für Sie, wie Sie erwähnen, die Umwandlung einer table basierten Layout in eine Vielzahl von div 's

Ein weiterer großartiger Ansatz, der in einigen Aspekten dem von OOCSS ähnelt, besteht darin, Ihr CSS von Anfang an so zu planen und zu schreiben, dass es skalierbar und modular ist. Jonathan Snook hat einen brillanten Bericht und ein Buch/Buch über SMACSS - Skalierbare und modulare Architektur für CSS

Ich werde Ihnen ein paar Links zur Verfügung stellen:
5 Fehler von massivem CSS - (Video)
5 Fehler von massivem CSS - (Folien)
CSS Bloat - (Folien)