Nachdem ich an mehreren großen Webanwendungen gearbeitet habe und riesige Stylesheets ohne klare Struktur gesehen habe, würde ich sehr gerne wissen, ob die Leute Möglichkeiten gefunden haben, ihre CSS für große und komplizierte Webanwendungen sauber zu halten.

Wie kommst du von einem Vermächtnis, einem Durcheinander von CSS zu aufgeräumten, schön kaskadierenden, trockenen Stylesheets?

Die App, an der ich gerade arbeite, hat 12000 CSS-Zeilen. Es ist organisch auf diese Größe angewachsen, da es zu Beginn keine Standards oder Überprüfungen des CSS gab. Die einzige Regel war, die App an das Design anzupassen. Einige der Probleme, die wir ständig haben:

Konfliktstile: Ein Entwickler fügt einen .header {font-weight: bold;} hinzu, aber .header wurde bereits in anderen Modulen verwendet und sollte in diesen nicht fett sein.

Kaskadenprobleme: Das Foo-Widget verfügt über eine .header-Datei, enthält jedoch auch eine Liste von Leisten-Widgets mit .header-Klassen.

Wenn wir .foo .header {...} und .bar .header {...} definieren, wird alles, was in foo nicht explizit überschrieben wurde, in bar angezeigt.Wenn wir ".foo> .header" und ".bar> .header" definieren, aber später "foo" ändern müssen, um den Header in ein div zu setzen, werden unsere Stile unterbrochen.

Vererbungsprobleme, wir definieren Widget-Schriftarten ständig auf 11px / normal neu, da in einigen oberen Containern eine Zeilenhöhe von 12px / 18 px verwendet wird.

Kämpfen Sie gegen Widget-Bibliotheken, indem Sie Bibliotheken wie dojo / dijit oder jquery ui verwenden, die Tonnen von Stilen hinzufügen, um zu funktionieren. Dies bedeutet, dass unser Code mit Stellen übersät ist, an denen wir die Bibliotheksstile überschreiben müssen, damit die Dinge genau richtig aussehen. Es gibt ~ 2000 CSS-Zeilen, nur um die eingebauten Dijit-Stile zu optimieren

Wir sind an einem Punkt angelangt, an dem wir die folgenden Regeln implementieren möchten:

Namespace alle neuen Widget-Klassen - Wenn Sie ein Widget haben, werden alle Unterklassennamen .foo_ sein, so dass wir erhalten: .foo, .foo_header, .foo_content, .foo_footer. Dies macht unser CSS im Wesentlichen zu FLAT, aber wir sehen keine andere Möglichkeit, unseren Code für die Zukunft zu organisieren, ohne auf die alten Stile oder die oben erwähnten Kaskadenprobleme zu stoßen.

Police generische Stile - eine kleine Handvoll allgemeiner Klassen, die nur in ganz bestimmten Situationen angewendet werden dürfen. z.B. .editable - auf Teile eines Satzes anwenden, die einen Editor aufrufen sollen - sollte nur Textknoten enthalten.

utzen Sie CSS-Compiler-Mixi Um zu vermeiden, dass dieselben Stile in verschiedenen Widgets wiederholt definiert werden, definieren und verwenden Sie Mixins. Obwohl wir uns Sorgen machen, dass auch die Mixins außer Kontrolle geraten.

Wie sonst können wir uns vom CSS-Chaos, das ständig Regressionen hervorruft, zu etwas bewegen, das in Zukunft gewartet werden kann.