So überarbeiten Sie 17.000 Zeilen CSS

    Viele von uns arbeiten an großen Projekten. Die, über die ich sprechen werde, lebt seit 15 Jahren und enthält ein paar Dutzend Webanwendungen in ASP.NET WebForms, von denen die Hauptanwendung etwa eineinhalb Tausend Aspx-Seiten enthält.

    Warum so viel? Der Wunsch, sich an Kunden mit unterschiedlichen Anforderungen anzupassen, macht sich bemerkbar. Jeder möchte eine spezielle Funktionalität für sich und bekommt sie schließlich. Aber darum geht es nicht. Neben einer großen Anzahl von Seiten hatten wir viele CSS-Stile. Sehr viel.

    Ein Bild, um Aufmerksamkeit zu erregen

    Quelle: Ursus Wehrli. Die Kunst des Aufräumens


    Anfangs gab es ein Webprojekt. Er hatte eine CSS-Datei. Die Datei war nicht zu groß und ihre Lesbarkeit warf keine Fragen auf. Die Zeit verging, Leute kamen, erstellten neue Funktionen und fügten der CSS-Datei Selektoren hinzu. Es sah nicht sehr beängstigend aus, man konnte immer noch den Inhalt herausfinden.

    Dann kam die Zeit für komplexe Funktionen, als sich die Steuerelementstile auf bestimmten Seiten überlappten, wodurch eine bestimmte Klasse aufgehängt wurde. Designer und Benutzer mochten die Benutzeroberfläche, und die Klasse wurde ohne semantische Verbindung mit dem ursprünglichen Ort auf andere Seiten migriert. Irgendwann verwandelte sich die Akte in eine riesige Müllkippe mit 17.000 Zeilen.

    Um nicht zu einfach zu wirken, hat das System benutzerdefinierte Skins (separate Stile) für einzelne Kunden entwickelt. Diese 17.000 Zeilen sind für alle gleich, aber wir werden etwas mehr herausnehmen, um die Farben des Textes und des Hintergrunds anzupassen. In der Tat stellte sich heraus, ziemlich viel, aber sehr viel. Kilometer CSS, und ein Teil davon könnte allen gemeinsam sein.

    Das Problem


    Wir wussten, dass das Projekt trotz der offensichtlichen visuellen Integrität des Designs viele Ausnahmen von den Regeln aufweist. Hier einige Beispiele:
    • 12 verschiedene Gitter, die nicht so sehr ähnlich aussehen, aber nicht so sehr unterschiedlich.
    • 4 Optionen für Symbolleisten über Raster mit drei Optionen für Schaltflächen und Dropdown-Listen (ebenfalls unterschiedlich, aber im Stil verdächtig ähnlich).
    • Sogar Informationsnachrichten, bei denen es sich nur um Text mit einem Symbol auf rotem, gelbem oder blauem Hintergrund handelt, und es gab zwei Optionen.

    Es gibt noch etwas zu sagen. Wir haben nicht ein Webprojekt, sondern mehrere. Die Steuerelemente und Stile für jeden von ihnen entwickelten sich ziemlich lange parallel, als schließlich jemand keine Ahnung hatte, all dies zu kombinieren und in die Bibliothek der allgemeinen Steuerelemente mit einem Teil der gemeinsamen Stile aufzunehmen (die sich dann in jedem der Projekte überlappen können). Das Schreiben dieser Bibliothek bedeutete nicht die Vereinigung von allem und jedem und das Entfernen von Duplikaten. Stattdessen gibt es noch mehr Steuerelemente und Stile. Ein gemeinsam genutztes Raster in einer gemeinsam genutzten Bibliothek ist eine nützliche Sache, aber Sie können nicht 12 von dreihundert Stellen im gesamten Projekt entfernen - kein einziges normales Team wird es abonnieren. Im Allgemeinen haben die Leute irgendwann aufgehört zu verstehen, welche unserer vielen Kontrollen in einem bestimmten Fall verwendet werden sollten.

    Außerdem sind wir in Internet Explorer 9 auf ein bekanntes Problem gestoßen, das sich aus irgendeinem Grund weigerte, mehr als 4095 Selektoren in unsere herrliche Datei aufzunehmen.

    Deshalb mussten wir das gesamte Design der Anwendung komplett ändern. Es war klar, dass eine Änderung des Designs für Sie selbst teurer sein würde - Sie mussten zuerst CSS umgestalten. Alles CSS. Die Produktbesitzer haben die Situation verstanden und wir haben die Genehmigung für das Refactoring erhalten.

    Erste Schritte


    Also waren wir uns alle einig und bekamen Handlungsfreiheit - wir fangen an, die Trümmer aufzuräumen. Was haben wir auf Lager?
    • Eine riesige CSS-Datei mit 17.000 Zeilen für die Hauptwebanwendung
    • Mehr als 50 benutzerdefinierte Skins für jede separate CSS-Datei. Theoretisch sollten nur geringfügige Unterschiede darin vorhanden sein, in der Praxis wurden ziemlich belastete Teile des gemeinsamen Codes angetroffen.
    • CSS-Datei mit einer Bibliothek von Steuerelementen, die nicht nur in der Haupt-, sondern auch in anderen Anwendungen verwendet wurde.
    • CSS-Dateien für zusätzliche Anwendungen. Hier war nicht alles schwierig, schon allein deshalb, weil sie alle, wenn auch mit Copy-Paste, eher klein waren

    Als erstes haben wir unbenutzte Stile entfernt. Mit C # -Code ist alles einfach, der Lösungsanalysator ist eingeschaltet und es wurde gezeigt, welche der öffentlichen Methoden entfernt werden können. Bei Stilen ist die einzige Möglichkeit eine Textsuche nach Lösung. Wenn Sie jemals aufgefordert werden, 17.000 Zeilen in einer CSS-Datei zu bereinigen, die sich auf diese Weise in einer Lösung von 250 Projekten befindet, fragen Sie sich nach einem SSD-Laufwerk. Der Prozess wird etwas schneller gehen.

    Aber wenn Sie gerade vorhaben, ein solch gigantisches Projekt von Grund auf neu zu schreiben, dann sind hier einige Tipps für Sie:

    Verwenden Sie immer den Namen des Selektors im gesamten Code.


    Brechen Sie es niemals in Stücke, zum Beispiel:

    public const string ProgressBar = "progressbar";
    public const string ProgressBarSmall = ProgressBar + "small";
    

    Sie finden einen großen Fortschrittsbalken und löschen einen kleinen, der beim Refactoring nicht verwendet wird. Dann müssen Sie wiederherstellen. Sie denken, und erinnern Sie sich, was verwendet wird und was nicht? In einem Projekt von anderthalb tausend Seiten? Und mit Hunderten von Einstellungen, die verschiedene Funktionen aktivieren und deaktivieren?

    Seien Sie auch nicht schlau mit Konstruktionen dieser Art:
    public class Feedback
    {
        public static string CssClass = GetType().ToString();
    }
    

    Erstens funktioniert es für Klassenerben immer noch nicht ( GetType()Sie müssen es ändern typeof(Feedback)), und zweitens ist es unmöglich zu suchen.

    Behalte einfach den Text. Suchen Sie Text in Lösung mit Groß- und Kleinschreibung und ganzem Wort. Kompliziere dein Leben nicht.

    Verwenden Sie Präfixe.


    Darüber lohnt es sich, weiter unten separat zu sprechen. Lassen Sie uns zunächst die Möglichkeit aus, Selektoren, die zu verschiedenen Modulen gehören, bedingt zu unterteilen und ihnen separate Präfixe zu geben.

    Sie können nicht nach CSS-Klassen mit den folgenden Namen suchen:
    .hidden
    .visible
    .error
    .text
    

    Viel schöner mit Präfixen. Die ersten beiden können bedingt Helfern zugewiesen werden - Helfern. Geben Sie ihnen Präfixe: .h-hiddenund .h-visible. Schon können Sie suchen! Wenn die Klassen spezifisch sind, können Sie den Namen des Projekts verwenden. MyProject? Lass es sein .mp-. Sagen wir mal .mp-login-page. Sind die Kontrollen üblich? - .ct-

    Einige Bibliotheken von Drittanbietern verwenden auch Präfixe. Durch das Präfix wird es leicht zu unterscheiden, wozu der Code gehört. Darüber hinaus wird ein geringes Risiko der Namenskreuzung beseitigt.

    Verwenden Sie nicht dieselben Selektornamen für unterschiedliche Anforderungen.


    Zum Beispiel .errorund .textim vorigen Beispiel - ist sehr weit fortgeschritten Fall. Selektoren sind nicht immer eindeutig und können in verschiedenen Fällen auf völlig unterschiedliche Weise verwendet werden.
    .mp-login-page .error
    {
        color:red;
    }
    .ct-feedback .error
    {
        background-color: red;
    }
    

    Ich würde dies durch die folgenden Selektoren ersetzen:
    .mp-login-page-error
    {
        color:red;
    }
    .ct-feedback-error
    {
        background-color: red;
    }
    

    Umständlich? Zweifellos. Aber es ist gut gesucht und entfernt.

    Machen Sie sich eine Liste von Stilen.


    Machen Sie sich zu einer statischen Klasse, die nicht alle, dann zumindest häufig verwendete Stile angibt. Es wird viel einfacher sein und dann suchen und umbenennen.

    Schauspiel


    Mein Onkel hat immer gesagt, dass es bereits in der Bauphase notwendig ist, darüber nachzudenken, wie man es macht, damit all dies auf Wunsch am leichtesten kaputt geht.

    Denken Sie, dass Ihr Projekt klein ist und Sie es nicht müssen? Wir haben auch nicht gedacht und das Projekt wurde zu einem sehr großen Monster . Im Allgemeinen ist das Löschen nicht verwendeter Stile eine ganz normale Situation. Es gab viele nicht verwendete Klassen, oft war es möglich, mehrere Textbildschirme hintereinander zu löschen. Infolgedessen blieben nur 17.000 Zeilen in unserer Datei mit 17.000 Zeilen. Stimmt es, dass wir das alles nutzen? Ja! Dies ist unser alles, was wir im Laufe der Jahre erworben haben. Alles wird benötigt!

    Was weiter? Es stellte sich heraus, dass wir noch viele Selektoren haben und nach der Reinigung alle 100% davon verwendet werden. Beim Löschen nicht verwendeter Stile haben wir auf solche Selektoren geachtet, bei denen der Klassenname nur einmal gefunden wurde
    .personal-report-bottom-section
    {
        margin-top: 10px;
    }
    .users-overview-header
    {
        padding-left: 15px;
    }
    

    Es stellte sich irgendwie völlig dumm heraus. Eine Reihe ähnlicher Stile in Klassen, die einmal verwendet wurden. Die Idee wurde von Bootstrap entlehnt, um Hilfsklassen zu verwenden. Nehmen wir an, margin-top: 10pxSie können den Namen .h-mt10für padding-left: 15px;- verwenden .h-pdl15. Dies half, viele weitere Orte zu räumen.

    Dann begannen sie nach Stücken zu suchen, deren Bedeutung sich wiederholte. Am beliebtesten war es, einen Hyperlink oder einfachen Text mit einem Bild links zu haben ():
    a.ct-imagewithtext
    {
        text-decoration: none;
    }
    .ct-imagewithtext img,
    .ct-imagewithtext span
    {
        vertical-align: middle;
    }
    .ct-imagewithtext img
    {
        margin-right: 4px;
    }
    .ct-imagewithtext span
    {
        text-decoration: underline;
    }
    

    Ich denke, dass der Code 20 ähnliche Stile enthielt, nicht weniger. Aber jedes Mal, wenn die Klassennamen neu waren, unterschieden sich die Stile manchmal geringfügig und manchmal sehr ernst. Während des Konvertierungsprozesses sah das Projekt optisch besser aus - klein, aber durch Augenunterschiede auf verschiedenen Seiten erkennbar, begann allmählich zu verblassen.

    In Zukunft ist es uns gelungen, ähnliche Steuerelemente mit völlig unterschiedlichen Stilen zu überarbeiten - wir haben selten verwendete entfernt und sie in analoge geändert. Wenn es zu viele Anwendungen gab, übernahmen sie aus Sicht von CSS die erfolgreichste Kontrolle und machten dies für alle anderen „wieder gut“. Nicht alles wurde entfernt oder erfunden, aber dazu später mehr.

    Schließlich erreichten die Hände die Bibliothek der allgemeinen Kontrollen. Wie ich bereits schrieb, wurde nur ein Teil der Stile im allgemeinen Teil herausgenommen. Dann überlappten sich diese Stile bereits in jeder unserer Webanwendungen. Die Idee war nicht sehr erfolgreich - alles, was sich überlappte, überlappte sich in jeder Anwendung auf die gleiche Weise, d. H. Es war eigentlich Copy-Paste. Allerdings nicht wirklich. Wenn das Design die Farben ein wenig ändern musste, änderten sie sich nur an einer Stelle und vergaßen den Rest. Wir haben das alles in den allgemeinen Teil aufgenommen und dann Copy-Paste für eine lange Zeit getötet. Die Anwendungen waren besser - Symbolleisten, Raster und andere Steuerelemente in verschiedenen Farben wurden einander ähnlich.

    Irgendwann wurde uns klar, dass es schön wäre, eine Art CSS-Reset in diese Bibliothek aufzunehmen. Zuvor wurde CSS Reset in nur zwei Anwendungen eingeführt, und jede für sich. Infolgedessen wurde beschlossen, zu verwendenNormalize.css , das wir ganz am Anfang aufgenommen haben. Dort haben wir grundlegende Stile für unsere Anwendung hinzugefügt - Schriftgröße und Schriftart (auch überall unterschiedlich) und viele andere Dinge.

    In diesem Moment waren wir noch auf die eine oder andere Weise damit beschäftigt, Copy-Paste zu entfernen und Stile zu vereinheitlichen. Schließlich erreichten die Hände die benutzerdefinierten Skins. Tatsächlich haben sie die Benutzeroberfläche nicht wesentlich verändert, aber aus irgendeinem Grund enthielten sie eine große Anzahl von Stilen. Es gab ungefähr 50 Skins, einige alte waren handgeschrieben, neuere verwendeten WENIGER. Trotzdem gab es keine gemeinsame Vorlage, die Generierung erfolgte manuell und das Ergebnis wurde dann an einen gemeinsamen Teil angedockt. Wir haben mit ihnen angefangen. Erstens nahmen sie ein gemeinsames Muster (nicht alle übereinstimmend) und einen sich wiederholenden Teil heraus. Zweitens haben wir die Generierung von CSS-Dateien beim Erstellen eines Projekts mit dem Dienstprogramm lessc konfiguriert . Dann gingen wir zu den alten Skins, wo WENIGER nicht verwendet wurde.

    Trotz der großen Menge an Code stellte sich heraus, dass nach dem Kopieren und Einfügen nicht viel geändert wurde. Am Ende haben wir für alle den gleichen gemeinsamen Teil, eine 1,5-Bildschirm-Vorlage und 50 weniger Dateien mit 15 Variablen zum Anpassen der Skin.

    Am Ende unserer riesigen Akte wurde ein gemeinsames Stück angelegt. Da bei gleichen Gewichten von CSS-Selektoren die Priorität im Text eingeräumt wird, ist dies wichtig. In der nächsten Phase des Refactorings hat uns das Add-On zu Visual Studio - Web Essentials sehr geholfen . Das Ding ist sehr nützlich, kurz gesagt, eine Art CSS Resharper. Mit Web Essentials können Sie nicht nur Syntaxfehler und Tipps zum Hinzufügen des fehlenden Herstellerpräfixes finden, sondern auch nach denselben Klassen in einer Datei suchen. Und es stellte sich heraus, dass in unserem Code eine solche Situation oft auftrat.

    Ein Selektor ist definiert, beispielsweise in Zeile 6255:
    .topmenu-links
    {
        margin-top: 15px;
        background-color: blue;
    }
    

    Dann irgendwo am 13467 .:
    .topmenu-links
    {
        margin-top: 10px;
        background-color: green;
    }
    

    Ich übertreibe ein wenig, aber es war so. Darüber hinaus war der Fall kein Einzelfall, sondern ein massiver. Es kam zu vier Etagen. Web Essentials schwört gnadenlos auf solche Dinge, so dass sie alle gefunden und gelöscht wurden. Wie gesagt, wenn die Gewichte der Selektoren gleich sind, ist die Priorität niedriger. Entfernen Sie also die Selektoren von oben und kombinieren Sie sie. Der Prozess ist etwas riskant. Mit einer großen Anzahl unterschiedlicher Stile, die an demselben Element hängen, und der Streuung der Selektoren in der Datei ist das Verschieben mit einer Änderung der Priorität verbunden. Aber es gibt nichts zu tun. Während der gesamten Arbeit ging unsere Qualitätssicherung regelmäßig alle Seiten des Systems durch und verglich die Ansicht mit der Produktion.

    Irgendwann waren wir reif, bevor wir unser riesiges CSS in Segmente aufteilten. Es stellte sich heraus, 120. Beim Erstellen der Datei wurde auf eins zurückgegriffen. Und nach einer Weile wechselten wir zu WENIGER.

    Wie ist es jetzt?


    Mal sehen, wie das alles anhand eines Beispiels aussieht .

    Vereinfachen wir die Aufgabe ein wenig und stellen uns vor, wir haben eine Bibliothek mit allgemeinen Steuerelementen ( CommonControls) und ein Projekt für statischen Inhalt (CDN), das im Hauptwebprojekt verwendet wird.

    Screenshot der Lösung mit Projekten


    In der Bibliothek mit Steuerelementen befinden sich WENIGER Dateien, die beim Erstellen in one ( common-controls.less) gesammelt und dann in CSS ( common-controls.css) übersetzt werden.

    Screenshot des CommonControls-Projekts


    Lassen Sie uns genauer betrachten, was wo gespeichert ist.
    • 01-essentials.lessspeichert nur Variablen und Mixins. Sie werden von WENIGER Dateien der Steuerelementbibliothek sowie von Dateien anderer Projekte verwendet.
    • 02-normalize.less. Ich habe schon ein wenig über ihn gesprochen. Es speichert CSS-Normalisierungscode, der leicht an die Anforderungen des Projekts angepasst ist.
    • 03-default-styles.lessspeichert gängige Designstile (z. B. die Hintergrundfarbe des Elements body, die Schriftart der verwendeten Schriftart usw.)
    • 04-helpers.less speichert Hilfsklassen wie Ränder und bereits beschriebene Auffüllungen.
    • Als nächstes kommen die tatsächlichen Steuerungsstile.

    Konfigurieren Sie Build-Ereignisse für das CommonControls-Projekt. Ich habe alles in einer separaten Datei abgelegt, um die Projektdatei nicht jedes Mal zu bearbeiten oder zusammenzuführen, wenn sich der Inhalt des Skripts ändert.

    Das Fenster mit den Einstellungen für Build-Ereignisse


    Der Skriptcode ist sehr einfach. Wir stellen alle WENIGER Dateien im Ordner zusammen Stylesheetsund übertragen das Ergebnis in den Ordner CombinedStylesheets. Dann starten wir den Präprozessor und bereiten CSS vor.
    set ProjectDir=%~1
    copy "%ProjectDir%Stylesheets\*.less" %ProjectDir%CombinedStylesheets\common-controls.less
    call "%ProjectDir%..\Tools\lessc\lessc.cmd" %ProjectDir%CombinedStylesheets\common-controls.less %ProjectDir%CombinedStylesheets\common-controls.css
    

    Schauen wir uns nun die Stile des Cdn-Projekts an. Der Ordner _csspartsenthält die Projektstile, die dann zu einer Datei zusammengesetzt werden combined.less. In einem echten Projekt gibt es viele Dateien. Im Screenshot ist alles etwas vereinfacht.

    Screenshot des CDN-Projekts


    Die Reihenfolge der Dateien spielt keine große Rolle, außer der allerersten und der allerletzten.

    001-imports.lessenthält den folgenden Code:
    // Importing LESS template from CommonControls
    @import "../../CommonControls/Stylesheets/01-essentials.less";
    // Usual CSS import
    @import "common-controls.css";
    

    In diesem Fall importiert die erste Direktive den Inhalt der LESS-Datei 01-essentials.less. Dies ist das gleiche, als ob wir diese Datei beim Kombinieren mit dem Rest verkettet hätten. Beim Importieren können Sie alle Variablen und Mixins verwenden, die wir in der Bibliothek definiert haben CommonControls. Die zweite Direktive - klassischer Import - wird wie im resultierenden CSS generiert. Im Allgemeinen werden CSS-Importe nicht empfohlen, und der einzige Grund dafür ist IE9.

    z-ie9-special.lessenthält einen einzelnen Selektor, der der letzte in der kombinierten Datei ist und auf einer speziellen Seite verwendet wird, um zu verstehen, ob er verwendet wird oder nicht. Wenn die Gesamtzahl der Selektoren 4095 überschritten hat, gilt der Stil nicht. Sie müssen die Datei also in Teile aufteilen. Tatsächlich mussten wir das resultierende CSS der Steuerungsbibliothek und das tatsächliche CSS für das Webprojekt nicht kombinieren.

    Beim Bauen passieren folgende Dinge:
    @REM Copy common controls stylesheet
    COPY %ProjectDir%..\CommonControls\CombinedStylesheets\common-controls.css "%ProjectDir%Skins\common-controls.css" /Y
    @REM Combine CDN LESS files and run preprocessor
    copy "%ProjectDir%Skins\_cssparts\*.less" %ProjectDir%Skins\combined.less
    call "%ProjectDir%..\Tools\lessc\lessc.cmd" %ProjectDir%Skins\combined.less %ProjectDir%Skins\combined.css
    

    Die Skinskombinierte CSS-Bibliothek aus Steuerelementen und CSS für das Webprojekt gelangt in den Stammordner . In realen Projekten kann das Kombinieren des resultierenden CSS eleganter gestaltet werden als das Verketten von Dateien. Dies ist jedoch nur ein Beispiel.

    Schauen wir uns nun die Generierung von benutzerdefinierten Skins an.

    Screenshot des Ordners mit benutzerdefinierten Skins im Cdn-Projekt


    Der Ordner _custom-partsenthält eine Vorlage zur Generierung custom-template.less. Angenommen, es reicht uns vorerst, die Farben der Überschriften H1 und H2 anzupassen (in Wirklichkeit gibt es natürlich noch viel mehr Dinge). custom-template.lesswird so aussehen:
    h1
    {
        color: @h1Color;
    }
    h2
    {
        color: @h2Color;
    }
    

    Default-values.less enthält die Standardwerte von Variablen (um nicht alles in der Skin in einer Reihe überlappen zu können, sondern nur einige der Werte):
    @h1Color: #F58024;
    @h2Color: #E67820;
    

    In jedem der Skins ( skin.less) gibt es so etwas wie diesen Code:
    @import "..\_custom-parts\default-values.less";
    @h1Color: #000;
    @h2Color : #707050;
    @import "..\_custom-parts\custom-template.less";
    

    Wir importieren die Standardwerte, überlappen sie mit unseren Werten und importieren die Vorlage.

    Um all dies zu generieren, schreiben Sie diesen Code in das Pre-Build-Ereignis:
    @REM Regenerate customskins using their LESS templates
    for /r "%ProjectDir%Skins\" %%i in (*.less) do (
        if "%%~nxi"=="skin.less" call "%ProjectDir%..\Tools\lessc\lessc.cmd" "%%~dpnxi" "%%~dpni.css"
    )
    

    Am Ausgang neben jedem erhalten skin.lesswir skin.csszum Beispiel das Obige dieses Formulars:
    h1
    {
      color: #000000;
    }
    h2
    {
      color: #707050;
    }
    

    Im Allgemeinen unterschied sich der Inhalt unserer WENIGER Dateien (ohne benutzerdefinierte Skins) zunächst nicht von normalem CSS. Mit wenigen Ausnahmen, wenn der Parser sich weigerte, den ungültigen Code zu akzeptieren, sagen wir Folgendes:
    margin-top: -4px\0/IE8+9;
    

    Ich bin mir nicht sicher, ob der Hack für IE so aussieht, aber Gott segne ihn. In WENIGER können Sie eine Zeichenfolge mit Zeichen maskieren ~"":
    margin-top: ~"-4px\0/IE8+9";
    

    Alles andere verlief reibungslos. Bald tauchten einfache Variablen auf:
    @сtDefaultFontSize: 14px;
    

    Dann sind Mixins komplizierter:
    .hAccessibilityHidden()
    {
        position: absolute;
        left: -10000px;
        top: -4000px;
        overflow: hidden;
        width: 1px;
        height: 1px;
    }
    

    Die Bedeutung dieses Mixins ist, dass es zusätzlich zu seiner Verwendung in der Hilfsklasse auch in einigen anderen verwendet wird. In unserem Fall ist es noch interessanter geworden. Als wir irgendwann feststellten, dass es nicht möglich war, nach den Stilen von 12 Gittern umzuschreiben oder sogar zu „schminken“, war es eine gute Idee, gemeinsame Farben und Stile in Variablen und Mixins einzufügen. Es stellt sich heraus, dass WENIGER für alte Projekte noch interessanter ist als für neue. Im Allgemeinen gibt es Orte, an denen man herumlaufen kann. Zum Beispiel die Erzeugung eines Hintergrundbildes für Schaltflächen verschiedener Typen in Gegenwart eines Sprites:
    .ct-button-helper(@index, @name, @buttonHeight: 30, @buttonBorderThickness: 1)
    {
        @className: ~".ct-button-@{name}";
        @offset: (@buttonHeight - 2*@buttonBorderThickness - @buttonIconSize) / 2;
        @positionY: @offset - (@index * (@buttonIconSize + @buttonIconSpacingInSprite));
        @{className} { background-position: 8px unit(@positionY, px); }
        @{className}.ct-button-rightimage { background-position: 100% unit(@positionY, px); }
    }
    

    Wir nennen so etwas:
    .ct-button-helper (0, "save");
    .ct-button-helper (1, "save[disabled]");
    .ct-button-helper (2, "cancel");
    .ct-button-helper (3, "cancel[disabled]");
    

    Es ist immer noch gut, CSS für Schriftbeschreibungen zu generieren, obwohl die Implementierung des Mixins häufig von der jeweiligen Schriftart abhängt.

    Zusammenfassung


    Werfen wir einen kurzen Blick auf das, was wir getan haben.
    • Wir haben eine große Menge unbenutzter Stile entfernt.
    • Удалили большое количество классов, использующихся только в одном месте, заменив их на вспомогательные классы. На самом деле это очень значительная часть всего CSS в проекте, не стоит недооценивать этот пункт.
    • Вынесли общую часть из кастомных скинов, добавив её в конец основного CSS. Этот пункт важно было выполнить перед следующим. Использовали LESS для генерации кастомных скинов.
    • Удалили большое количество перекрытий одного и того же класса несколько раз в одном и том же CSS файле. Тут очень помог WebEssentials. Этот пункт тоже важно было выполнить перед следующим.
    • Разбили общий CSS на части для удобства редактирования. При билде все эти части собираются в один файл.
    • Вынесли перекрытия стилей контролов в сами стили контролов. Удалили копипасту в стилях остальных приложений.
    • Поскольку во всех приложениях использовался единый стиль оформления, общие части (normalize.css, размеры шрифтов, цвета фона) тоже вынесли в библиотеку контролов, удалив куски CSS из всех веб-приложений.
    • Перешли на LESS во всех веб-приложениях.
    • Вынесли часть часто используемых вещей в переменные и миксины в библиотеке контролов, подключили их к каждому веб-приложению, так что использовать их можно везде.
    • Сделали обёртку на C# (простой статический класс со статическими пропертями) для часто используемых CSS классов. Не для всех, их очень много, и не всегда есть смысл.
    • Внедрили префиксы… Не во всех местах, а в часто используемых. Стараемся использовать префиксы для всех новых стилей, но всем пофиг.

    Im Allgemeinen haben wir die Kontrolle über den Code wiedererlangt. Die anschließende Neugestaltung verlief problemlos. Außerdem machten sie ihn schlauer, indem sie Komponente für Komponente wechselten. Um nicht zu sagen, dass der Code perfekt geworden ist oder dass er zehnmal kleiner geworden ist. Wir haben noch viele Dinge, und es kann schwierig sein, dies herauszufinden. Andererseits wurde die Anzahl der Kopier- und Einfügevorgänge erheblich reduziert, und infolgedessen gab es weniger visuelle Unterschiede in verschiedenen Teilen des Systems, die theoretisch gleich aussehen sollten.

    Jetzt auch beliebt: