Share
Falls Sie nichts davon mitbekommen haben, wurde die CSS-Analyseseite cssstats.com kürzlich überarbeitet. Es ist ein wunderschön gestaltetes Tool, das Ihnen viele objektive Einblicke in Ihren Code bietet, aber wie können Sie die CSS-Statistiken optimal nutzen? Für was solltest du schießen? Was bedeuten sie und wie können Sie sie täglich nutzen??
Heute werden wir über Best Practices von CSS, Spezifität und Wartbarkeit sprechen. Außerdem lernen Sie, wie Sie CSS-Statistiken richtig interpretieren und besser nutzen. Lass uns eintauchen!
Gehen Sie zu cssstats.com, geben Sie entweder die URL Ihrer Website und das Stylesheet ein oder fügen Sie das unformatierte CSS direkt in den Textbereich ein und klicken Sie auf Gehen.
Nach dem Analysieren erhalten Sie eine Menge Statistiken über das CSS. aus der Anzahl der verwendeten Regeln, ihrer durchschnittlichen Größe, der Aufgliederung der einzelnen Deklarationstypen, der Schrift- und Hintergrundfarben, der Schriftfamilien und -größen sowie der Spezifitätsdiagramme.
Das ist es, was CSS Stats Ihnen bietet. Schauen wir uns jetzt an, was wir mit allen Daten machen können.
Als Front-End-Entwickler sind wir ständig um Leistung und Benutzererfahrung besorgt. Wir sind auch für die Erstellung von Software verantwortlich, aber das Wort „Software“ ist vielen Front-End-Entwicklern, die aus Designgründen kommen, fremd. Es ist oft leicht, Best Practices zu ignorieren, wenn wir unser CSS codieren.
Die Wahrheit ist jedoch, dass die Front-End-Entwicklung ebenso wie jede andere Software-Entwicklung auf Best Practices fokussiert werden muss. Die Regeln für bewährte Vorgehensweisen werden im Internet ausführlich diskutiert. Im Interesse dieses Artikels werden wir uns jedoch mit der wohl wichtigsten Vorgehensweise auseinandersetzen, die sich auf CSS bezieht: Wartbarkeit.
Die Wartbarkeit von CSS hat viele Facetten.
Wir werden nicht in jedes dieser Elemente einzeln eintauchen, aber wenn wir über Wartbarkeit sprechen, wirkt sich jede dieser Überlegungen auf die allgemeine Wartbarkeit Ihrer Codebase aus.
Die ehrliche Antwort? Nichts unbedingt. Sie lernen nichts über die Wartbarkeit, indem Sie einfach die CSS-Statistiken betrachten. Sie müssen auch den Kontext dieses bestimmten CSS sowie den Kontext der aktiven Entwicklung verstehen.
Die erste Möglichkeit, Ihre CSS-Statistiken zu analysieren, besteht darin, nach Anzeichen von CSS-Aufblähung zu suchen.
Durch aufblasen wir meinen nicht verwendetes, redundantes oder anderweitig unnötiges CSS.
Nehmen wir zum Beispiel eine einseitige Anwendung mit fünf verschiedenen Inhaltsmodulen. Welche Arten von CSS-Statistiken würden Sie von einer einzelnen Seite erwarten? Eine typische Einzelseitenanwendung hat möglicherweise einen Bruchteil der Anzahl von CSS-Regeln und möglicherweise die Hälfte der Anzahl von Farbdeklarationen als große Site für Veröffentlichungen von News oder eine vielseitige SAAS-Anwendung.
Wenn Sie eine enorme Anzahl von Selektoren sehen (z. B. wenn Ihre einfache Seite mit einer Seite so viel CSS wie ein Web-Framework wie Bootstrap enthält, das bei knapp 2400 Selektoren erscheint), haben Sie wahrscheinlich irgendwo einen Fehler gemacht . Wenn Sie in 30 Schriftgrößen laden und Ihr Design 10 erfordert, haben Sie wahrscheinlich ungenutzte, aufgeblähte Stile oder möglicherweise inkonsistente Stile.
Eine mögliche Ausnahme von dieser Regel in Bezug auf die Wartbarkeit ist, dass Sie dies tun tatsächlich mit Bootstrap oder einem anderen beliebten, gut dokumentierten Framework; Da die Dokumentation zu diesen Projekten relativ umfangreich ist und die Nutzung das Web überlastet hat, müssen Front-End-Entwickler dies nicht unbedingt tun pflegen Bootstrap, solange die primäre Quelle die Kernimplementierungen von Bootstrap beibehält. Wenn Sie jedoch das Bootstrap-Framework lediglich für das Grid oder einige Oberflächenelemente verwenden, sollten Sie stattdessen eine angepasste Version erstellen, die nicht das zusätzliche CSS enthält, das Sie niemals verwenden möchten.
Es ist möglich, dass Ihre Anwendung etwas tut, was eine große Anzahl von Selektoren, Farben oder Schriftgrößen erfordert. Wenn Sie beispielsweise einen Online-Shop betreiben, der Produktfarben verwendet, ist es möglich, dass eine große Anzahl von Farben in Ihrem CSS angezeigt wird und ein durchaus legitimer Fall ist. Ein anderes Beispiel ist, wenn Sie eine Website ausführen, auf der Benutzer aus einer Liste von Schriftgrößen und Schriftarten für den von ihnen erstellten Inhalt auswählen können. In diesen Beispielen ist es sinnvoll, große Zahlen in diesen bestimmten Kategorien zu sehen.
Medium.com verwendet irgendwo eine Schriftgröße von 301px… Wenn Sie jedoch beispielsweise ein Blog mit einem eingeschränkten Farbschema erstellen, sollte Ihre CSS-Statistik die Anzahl der Farben und die Deklaration der Schriftarten widerspiegeln.
Definieren Sie in Ihrem CSS zwanzigmal die gleiche Schriftgröße? Sehr oft kann dies vermieden werden und ist in der Regel auf mangelnde Planung zurückzuführen. Wenn Sie Ihre Schriftgrößen bestimmen, bevor Sie ein anderes CSS schreiben, können Sie diese Größen leichter auf den Rest des Systems anwenden.
Dasselbe gilt für jeden wiederholten Stil. Wenn Sie feststellen, dass Sie dasselbe mehrmals schreiben, verdient diese Stilgruppe vielleicht eine eigene Präsentations- oder semantische Klasse oder eine andere modulare Definition?
Gehen Sie hier nicht über Bord. Die Neudefinition einiger Schriftgrößen oder Hintergrundfarben ist keine große Sache. Eine mehrfache Neudefinition einer Anzahl von Stilen in sehr ähnlichen Modulen kann jedoch bedeuten, dass Sie eine Basisklasse erweitern sollten. Wenn Sie beispielsweise eine Button-Klasse haben:
.btn font-size: 1.2em; Schriftgewicht: 400; Buchstabenabstand: .06em; Farbe: #fff; Hintergrundfarbe: # 4a4a4a; Polsterung: 6px 8px;
Angenommen, Sie möchten eine blaue Version derselben Schaltfläche. Wie sollen Sie das definieren? Wenn Sie dasselbe neu definieren btn Klasse, würde es ungefähr so aussehen:
.btn-blue font-size: 1.2em; Schriftgewicht: 400; Buchstabenabstand: .06em; Farbe: #fff; Hintergrundfarbe: # 0C508D; Polsterung: 6px 8px;
Natürlich gibt es viele Probleme damit. Erstens verstößt es gegen das Prinzip DRY (sich nicht wiederholen). Aber warum ist das wichtig?? Wartbarkeit. Nehmen wir zum Beispiel an, das Design ändert sich und erfordert eine kleinere Schrift auf den Schaltflächen. Sie müssen dann in die .btnund das .BTN-Blau Klasse, um die Schriftgröße zu ändern. Noch komplizierter wird es, wenn Sie Varianten der blauen und normalen grauen Schaltflächen benötigen, beispielsweise eine blau umrandete Version. Alle Ihre Änderungen an einer Schaltfläche müssen an vielen Tasten vorgenommen werden.
Das ist unglaublich ineffizient. Stattdessen sollten Sie die Tatsache ausnutzen, dass Klassen modular sind und es Ihnen ermöglichen, Schaltflächenstile zu definieren, die Ihre Basis erweitern .btn Klasse.
.btn font-size: 1.2em; Schriftgewicht: 400; Buchstabenabstand: .06em; Farbe: #fff; Hintergrundfarbe: # 4a4a4a; Polsterung: 6px 8px; .btn.btn-blue Hintergrundfarbe: # 0C508D;
Aha! Und jetzt haben wir eine viel wartungsfähigere Lösung, die auch eine beträchtliche Anzahl von CSS-Zeilen entfernt und dem DRY-Prinzip folgt.
Spezifität ist eine der schwieriger zu verstehenden dunklen Ecken von CSS, die selbst die erfahrensten Entwickler oft in Frage stellen. In CSS Stats sehen Sie eine Spezifitätstabelle, die zeigt, wie genau die Selektoren in Ihrem CSS sind und wo diese Selektoren angezeigt werden.
CSS-Spezifität von der BBC-WebsiteDieses Diagramm zeigt die Spezifität von Selektoren, wie sie im CSS von bbc.co.uk vorkommen. Stellen Sie sich vor, die linke Seite des Diagramms befindet sich oben im Stylesheet x-Achse wie es das Stylesheet nach unten liest. Je genauer die Regel ist, desto höher ist die dunkelblaue Linie auf der y-Achse.
Wir geben drei allgemeine „Faustregeln“ an und erläutern die Regeln.
Wir werden ausführlicher über jedes dieser Themen sprechen, aber zuerst ein wenig darüber, wie die Spezifität funktioniert.
CSS-Selektoren erhalten eine Spezifitätsbewertung, um die Browser-Rendering-Engine darüber zu informieren, welche Regeln für welche Elemente gelten. Der Grund, warum dies erforderlich ist, ist auch der Grund, warum CSS so mächtig ist: Stile können in CSS vererbt und kaskadiert werden. Dies bedeutet, dass Sie mehr als einen Satz von Stilen auf ein bestimmtes Element anwenden können. Die Rendering-Engine muss alle diese Regeln konsolidieren und etwas präsentieren. Was passiert jedoch, wenn zwei unterschiedliche Werte für dieselbe Stildeklaration festgelegt werden? Zum Beispiel:
a color: #fff; a.button color: # 000;
Wenn die CSS-Engine auf ein trifft tag mit einer Klasse von Taste, es muss feststellen, ob die Farbe Attribut sollte sein #F f f, # 000, oder der Browser-Standard. Die CSS-Spezifität ist der Regelsatz, den der Browser für diese Bestimmung verwendet.
Wie funktioniert die Spezifität? Verwenden Sie dieses Scoring-System als Richtlinie, direkt von CSS-Tricks übernommen:
Accentsconagua
!wichtig übertrumpft sie alle* Selektoren erhalten eine Spezifität von 0.Beachten Sie, dass in diesem Bewertungssystem, wenn etwas über 10 hinausgeht, es nicht in die nächste Spalte geht. Wenn Sie beispielsweise einen Selektor mit 11 Elementen hätten, würde es nicht über eine Spezifität von 0 hinausgehen. 0,1,1. Es wäre stattdessen 0,0,0,11.
Hier sind einige Selektoren und ihre Ergebnisse.
nav li a / * 0,0,0,3 * / .nav-item / * 0,0,1,0 * / nav .nav-item / * 0,0,1,1 * * / #logo / * 0,1,0,0 * /
eine Hintergrundfarbe: blau! wichtig; / * Im vorherigen Beispiel haben wir Inline-Stile verwendet, um die Hintergrundfarbe auf Rot zu setzen. Wenn wir diesen Stil jedoch mit dem wichtigen Qualifier anwenden, würde er den Inline-Stil überschreiben. * /
Okay - jetzt, da wir eine grundlegende Einführung in die CSS-Spezifität haben, wie sollte dies unseren Code beeinflussen? Kommen wir zu unseren drei Daumenregeln für CSS-Spezifität zurück.
Diese Regel besagt im Wesentlichen, dass allgemeine Selektoren am Anfang Ihres CSS stehen sollten und spezifischere Selektoren später in Ihrem CSS. Die Gründe für diese Regel sind vielfältig.
Wenn Sie zunächst allgemeine Regeln an den Anfang Ihrer Anwendung setzen, wird in Ihrem Code normalerweise festgelegt, welche Basismodule erstellt werden sollen. Wenn Sie in Verbindung mit # 2 am wenigsten bestimmte Stile zu Beginn haben, wird sichergestellt, dass Sie zuerst mit der geringsten Spezifität schreiben. Später, wenn sich Ihr Code weiterentwickelt, kann das Hinzufügen spezifischer Stile erforderlich sein, um vorherige Stile zu überschreiben oder zu erweitern.
Styles auf der Apple-Website sind zu Beginn des Stylesheets stark spezifisch
Die Spezifität des Pure CSS-Frameworks nimmt im Allgemeinen zum Ende des Stylesheets zuDies führt zu unserem zweiten Punkt: Was passiert, wenn die CSS-Rendering-Engine auf zwei Selektoren trifft, die dieselbe Bewertung haben? Es muss sich noch entscheiden, also wird es sich für die letzte der beiden Regeln entscheiden. Wenn Sie sich am Anfang Ihrer Datei als am wenigsten genau bezeichnen, stellen Sie sicher, dass Ihre Überschreibungen für die Spezifität spezifischer sind, wenn Sie später in die Datei gehen. Dies bedeutet, dass eine einzelne Klasse später in der Datei in der Lage sein sollte, einzelne Klassen, die sich früher in der Datei befanden, überschreiben zu können.
Durch diese Vorgehensweise wird sichergestellt, dass die spätere Entwicklung desselben Projekts das Kaskadensystem schnell verstehen kann.
Wenn Sie schon lange Front-End-Entwickler waren, haben Sie wahrscheinlich den „CSS-Spezifitätskrieg“ erlebt. Sie schreiben eine Auswahl und einige Regeln und aktualisieren dann den Browser nur, um festzustellen, dass die Änderungen nicht übernommen wurden. Sie wissen aus früheren Projekten oder aus Gesprächen über die Spezifität, dass der Selektor nicht spezifisch genug ist. Statt zu versuchen, das Problem auf den Selektor zurückzuführen, der zu spezifisch ist, entscheiden Sie sich für das neue Mehr Spezifisch. Sie fügen eine oder zwei IDs hinzu, und wenn dies den Trick nicht schafft, werfen Sie einfach !wichtig daran. Und, voila - Ihre Styles zeigen sich.
Dieser Ansatz funktioniert technisch gesehen; Wenn Sie jedoch diesen Stil erweitern möchten, müssen Sie die Komplexität immer weiter erhöhen. Bevor Sie sich dessen bewusst sind, sind es Ihre Selektoren äußerst Sie müssen Code wiederholen, anstatt Klassen einfach wiederzuverwenden. Darüber hinaus ist es fast unmöglich, genau zu bestimmen, welche Spezifität neue Stile haben sollten, ohne immer mehr IDs und IDs hinzuzufügen !wichtig Erklärungen.
Wenn Sie Ihre Selektoren weniger spezifisch halten, ist dies eine viel sicherere und wartungsfreundlichere Methode, um mit CSS zu arbeiten.
Diese Regel gilt in erster Linie, um seltsam platzierte Regeln zu vermeiden. Wenn Sie beispielsweise einige Klassen für die Textdarstellung definieren und plötzlich eine Regel mit sechs Klassen und einer ID verwenden, sollte diese bestimmte Regel kontextabhängig mit spezifischeren Selektoren platziert werden, auf die sie sich bezieht.
CSS-Statistiken bieten Ihnen Einblick in die Art und Weise, wie CSS geschrieben wird. Dies ist jedoch nur nützlich, wenn Sie eine Vorstellung davon haben, wie diese Statistiken aussehen sollen, bevor Sie sie analysieren. Dies bedeutet, dass Sie ein tiefes kontextbezogenes Verständnis dafür haben, wie Ihr CSS geschrieben wurde und warum. Wenn Ihr CSS wartungsfähig und für die Site geeignet ist, auf der es verwendet wird, sind die Statistiken dieses CSS kein Grund, Ihren Code umzugestalten.
Anstatt blind auf Zahlenregeln zu achten, sollten Sie sich als verantwortungsbewusster Front-End-Entwickler darauf konzentrieren, Ihren Code wartungsfähig zu machen und das Aufblähen zu reduzieren. Statistiken über Ihren Code können Ihnen dabei helfen, Problembereiche zu finden, sie können jedoch nur so weit gehen.
