Starten eines Refactorings mit CSS Dig

Der folgende Beitrag ist ein Gastbeitrag von Tom Genoni. Tom hat eine Open-Source-Chrome-Erweiterung zur Analyse von CSS entwickelt. Ich überlasse ihm die Vorstellung.

Es ist ein neues Webprojekt. Sie beginnen bei Null. Das Frontend wird sauber und ordentlich sein. Sie haben Ihre Standardeinstellungen vorgenommen. Ihre CSS-Dateien sind organisiert. Sie haben ein System! Dieses Mal wird es anders sein. Was kann schon schiefgehen?

Wenn Ihnen das bekannt vorkommt, wissen Sie, wie es normalerweise endet: Langsam, unvermeidlich, der Code beginnt anzuschwellen und Sie verlieren die Kontrolle. Er wird komplex und verschlungen. Sie überschreiben Stile, die Benennung ist inkonsistent, magische Zahlen und Hacks sind allgegenwärtig. Älterer Code ist schwer zu analysieren, schlecht dokumentiert und viel Glück, wenn neue Kollegen ihn verstehen.

Entschlossen, dieses Schicksal zu vermeiden, recherchierte ich Refactoring-Techniken, aufkommende Best Practices und entwickelte schließlich CSS Dig. In diesem Beitrag werde ich drei Bereiche hervorheben, in denen CSS Dig helfen kann, und einige Refactoring-Tipps geben.

Den Audit starten

In Nicolle Sullivans Präsentation über ihr Refactoring von Trulia empfiehlt sie, Screenshots von jeder Nische und Ecke Ihrer Website zu machen und die Designelemente zusammenzufassen, um das Universum der Schriftgrößen, Schaltflächen, Hintergründe, Ränder usw. zu sehen. Allein diese Übung deckt oft viele Inkonsistenzen auf (und eine beträchtliche Menge an Stöhnen) und bietet einen Ausgangspunkt für die Standardisierung.

Nachdem Sie erkannt haben, dass Sie zu viele Schaltflächenvariationen haben, besteht der nächste Schritt darin, Ihre Stile zu "durchsuchen": Untersuchen Sie Ihr CSS auf die gleiche Weise, und Sie werden oft eine breite Palette von Eigenschaften und Werten finden, die für eine Konsolidierung in Frage kommen. Hier kann CSS Dig helfen.

Nach der Installation der Chrome-Erweiterung sehen Sie deren Symbol in der oberen rechten Ecke Ihres Browsers. Navigieren Sie zu einer Website, die Sie untersuchen möchten, und klicken Sie auf das Symbol. Einige Vorbehalte

• Bei Websites mit viel CSS und je nach Ihrer Verbindungsgeschwindigkeit kann es einige Sekunden dauern, bis CSS Dig abgeschlossen ist.
• Websites mit strengen "Content Security Policies" können dazu führen, dass CSS Dig fehlschlägt. Zum Beispiel facebook.com und github.com.
• Per @import referenziertes CSS wird ignoriert. Es gilt als schlechte Praxis und die meisten Websites vermeiden es mittlerweile.

Dinge beschleunigen

Das erste, was Sie sehen werden, ist ein Dialog, der alle CSS-Dateien und Stilblöcke auflistet, die auf der Seite gefunden wurden. Beachten Sie, dass einige Remote-Dateien, wie z. B. Schriftanbieter, nicht zugänglich sind und als "Undiggable" aufgeführt werden. Sie können Elemente, wie z. B. Drittanbieter-Bibliotheken, die Sie nicht in die Analyse einbeziehen möchten, deaktivieren. Bevor Sie jedoch mit dem "Graben" beginnen, werfen Sie einen genauen Blick auf die Liste. Die Reduzierung von HTTP-Anfragen ist die wichtigste Regel für die Leistung, daher ist die Kombination von CSS in weniger Dateien ein guter Ausgangspunkt.

Sobald Sie das zu untersuchende CSS ausgewählt haben, klicken Sie auf "Start Digging". Sie werden dann auf den Hauptbildschirm von CSS Dig weitergeleitet. Auf der linken Seite sehen Sie die Eigenschaften und ihre Anzahl. Ein Klick auf diese zeigt die tatsächlich im CSS verwendeten Deklarationen an. Und ein Klick auf die einzelnen Deklarationen isoliert die Regelsets in der rechten Spalte.

Zu viele Farben

Eines der ersten Dinge, die ich gerne untersuche, sind die Farben. Hohe Zahlen hier sind oft ein Vorbote von Problemen in anderen Bereichen. Vor einiger Zeit habe ich CSS Dig auf huffingtonpost.com laufen lassen. Sie haben seitdem einiges aufgeräumt, aber zu dieser Zeit war das, womit sie arbeiteten

Verschiedene Websites haben unterschiedliche Bedürfnisse und Einschränkungen – aber vergleichen Sie das mit den Farben von apple.com

Da CSS Dig Ihnen die Anzahl der Verwendungen einer Farbe anzeigt, können Sie ziemlich schnell identifizieren, welche Farben konsolidiert werden sollen. Wählen Sie ein dominantes Blau (oder Rot oder Grün) und machen Sie es zum Standard. Wenn Sie einen Präprozessor verwenden, erstellen Sie Variablen und halten Sie sich daran. Ihre Benutzer erhalten eine konsistentere Erfahrung und es ist für Sie einfacher zu warten. Sass-Maps eignen sich hervorragend dafür.

$ui-color: (
  brand         : #0081BA,
  brand-light   : #9ACCE2,
  brand-dark    : #036,
  bad-news      : #C60C0C,
  good-news     : #97C70A
);

Und dann eine Farbe referenziert mit

.foo {
  color: map-get($ui-color, brand);
}

Abstände

Weitere Bereiche für die Standardisierung sind Abstände und Ränder. Es ist nicht ungewöhnlich, eine große Bandbreite an Werten zu haben, manchmal in verschiedenen Einheiten, insbesondere wenn verschiedene Teams an separaten Teilen einer Website arbeiten. Aber wenn Komponenten gemischt und angepasst werden müssen, können Inkonsistenzen schnell offensichtlich werden.

Eine Möglichkeit, dies anzugehen, ist die Einrichtung eines globalen Abstandsrasters, das für alle Elemente gilt (mit gelegentlichen Ausnahmen). In der UI-Bibliothek bei Optimizely verwenden wir eine Abstandseinheit, derzeit 10 Pixel, und alle Komponentenabstände basieren darauf. Dies hilft, "magische Zahlen" auszuschließen und gibt dem CSS-Autor dennoch etwas Ermessensspielraum.

Zum Beispiel der folgende Code

.foo {
  padding: spacer(1);
  margin: spacer(1.5) 0;
}

kompiliert zu

.foo {
  padding: 10px;
  margin: 15px 0;
}

unter Verwendung von

@function spacer($value) {
  @if ($value * 2) % 1 != 0 {
    @warn 'Spacer value must be a multiple of 0.5';
    @return 'Spacer value must be a multiple of 0.5';
  } @else {
    @return $spacer-unit * $value;
  }
}

Wenn unsere Spacer-Funktion einen Wert sieht, der kein Vielfaches von 0,5 ist, gibt sie einen Fehler zurück. Nichts hindert den Autor daran, eine fest codierte Zahl zu verwenden, aber Ausnahmen können in einer Code-Überprüfung besprochen werden. Ich habe festgestellt, dass dies häufig zu serendipitärer Harmonie über Komponenten hinweg führt.

Spezifitätskriege

Als Sass an Popularität gewann, war es nicht ungewöhnlich, dass Entwickler versuchten, die verschachtelte Struktur des HTML, das sie stylten, nachzubilden. Es scheint eine gute Idee zu sein. Ich habe es versucht. Aber es stellt sich heraus, dass dies alle möglichen Komplikationen mit sich bringt und es jetzt verpönt ist.

Zu den Schmerzen, die es verschlimmert, gehört der seit langem bestehende Kampf mit der CSS-Spezifität. Das Überschreiben langer Selektoren, um eine hochspezifische Komponente wiederzuverwenden, ist eine verwirrende und ärgerliche Erfahrung, die oft zu mehr Selektoren und (gasp) !important Regeln führt und zu Code, auf den Sie hoffen, niemals jemandem erklären zu müssen.

Im Selektoren-Tab eines CSS Dig-Berichts sehen Sie alle Selektoren mit Optionen zum Sortieren nach Länge und Spezifität. Diese werden mit dem Specificity Calculator von Keegan Street berechnet. Dies hilft, potenzielle Selektor-Zeitbomben zu identifizieren und hoffentlich den Prozess zu beginnen, die Stile weniger verschachtelt, wiederverwendbarer und einfacher zu warten zu machen. Ich empfehle auch die Verwendung des CSS Specificity Graph Generator, um einen Überblick über Ihren Code zu erhalten.

Weitermachen

Wenn Sie nach der Überprüfung Ihres eigenen Codes feststellen, dass Sie ein tieferes Refactoring durchführen möchten, hier sind noch ein paar weitere Schritte zu beachten.

1. Wählen Sie einen kurzen Codenamen für das Refactoring. Dies hilft, dem Projekt Bedeutung zu verleihen und, was noch wichtiger ist, eine Möglichkeit zur Benennung neuer Klassen zu bieten. Bei Optimizely verwenden wir lego- als Präfix für alle Klassen (ja, ich weiß, super origineller Name), aber es war von unschätzbarem Wert, eine klare Trennung zwischen neuen und alten Klassen zu schaffen.
2. Übernehmen Sie einen modularen, objektorientierten Ansatz, wie BassCSS, SMACSS oder Harry Roberts bevorstehende Auffrischung seines Inuitcss. Dies hat die Menge des von uns geschriebenen neuen Codes erheblich reduziert und die Entwicklungszeit erheblich beschleunigt.
3. Verwenden Sie einen Linter (wie CSS lint oder SCSS-lint). Dieser erzwingt automatisch eine lange Liste gängiger Code-Standardisierungen und hält Ihren Code sauber und konsistent.

Beitragen

Der Quellcode von CSS Dig ist auf GitHub verfügbar. Ihre Vorschläge, Anfragen und Fehlerberichte sind willkommen.

Außerdem arbeite ich bei Optimizely – schauen Sie bei uns vorbei. Wir arbeiten an einigen interessanten Dingen.