CSS-Selektoren nach Spezifität sortieren

Eine lange Selektorliste von Hand zu vergleichen, ist jedoch langsam und fehleranfällig. Dieses Werkzeug nimmt einzelne CSS-Selektoren entgegen, prüft deren Syntax, berechnet jeweils den dreiteiligen Spezifitätswert und gibt die gesamte Liste vom niedrigsten bis zum höchsten Wert sortiert zurück. Moderne funktionale Pseudoklassen wie :is(), :not(), :has(), :where() und :nth-child() werden berücksichtigt; bei gleichem Gewicht bleibt die ursprüngliche Reihenfolge erhalten.

Den dreiteiligen Spezifitätswert richtig lesen

Jedes Ergebnis verwendet die übliche Gliederung in IDs, Klassen und Typen. Die erste Zahl zählt ID-Selektoren wie <code>#checkout</code>. Die zweite Zahl umfasst Klassen, Attributselektoren und Pseudoklassen wie <code>.active</code>, <code>[disabled]</code> und <code>:hover</code>. Die dritte zählt Typselektoren und Pseudoelemente wie <code>button</code> und <code>::before</code>. Universalselektoren und Kombinatoren erhöhen den Wert nicht. Verglichen wird lexikografisch: Eine einzelne ID wiegt schwerer als beliebig viele Einträge in den anderen Spalten; bei gleicher ID-Anzahl überwiegt eine Klasse beliebig viele Typselektoren. Das Array <code>specificity</code> lässt sich bequem programmatisch verarbeiten, während <code>specificity_text</code> denselben Wert kompakt und lesbar darstellt. Die aufsteigende Ausgabe setzt breit wiederverwendbare Regeln an den Anfang und besonders schwer zu überschreibende Selektoren ans Ende. Stimmen zwei Werte vollständig überein, behält das Werkzeug ihre Eingabereihenfolge bei, statt eine zusätzliche alphabetische Sortierung zu erfinden. Dieses stabile Verhalten macht wiederholte Durchläufe vorhersehbar und erhält den nützlichen Zusammenhang aus einem Stylesheet oder einer Prüfliste.

Moderne Pseudoklassen korrekt berücksichtigen

Bei funktionalen Pseudoklassen passieren manuelle Rechenfehler besonders häufig. <code>:where()</code> trägt stets null zur Spezifität bei, einschließlich aller enthaltenen Selektoren. So können Sie eine Struktur genau beschreiben, ohne spätere Überschreibungen zu erschweren. Dagegen übernehmen <code>:is()</code>, <code>:not()</code> und <code>:has()</code> die Spezifität ihres stärksten Arguments, ohne selbst einen zusätzlichen Pseudoklassenpunkt hinzuzufügen. <code>:nth-child()</code> und <code>:nth-last-child()</code> liefern einen Pseudoklassenpunkt sowie den höchsten Wert einer optionalen, mit <code>of</code> eingeleiteten Selektorliste. Auch Shadow-Tree-Formen wie <code>:host()</code> und <code>::slotted()</code> werden einbezogen. Der Parser verfolgt verschachtelte Klammern, eckige Klammern, Zeichenketten in Anführungszeichen und Escape-Sequenzen. Deshalb verwechselt er Kommas innerhalb einer Funktion nicht mit Trennzeichen auf oberster Ebene. Übergeben Sie jedes Listenelement als genau einen Selektor. Ein Komma auf oberster Ebene würde mehrere Selektoren mit möglicherweise unterschiedlichen Werten darstellen und wird deshalb abgelehnt, anstatt irreführend zu einem einzigen Wert zusammengefasst zu werden. Somit gehört zu jeder Eingabe genau ein Ausgabewert.

Mit der sortierten Liste die Kaskade vereinfachen

Ein Spezifitätsbericht eignet sich vor allem als Hilfe beim Refactoring und nicht als Anreiz für immer stärkere Selektoren. Fügen Sie repräsentative Selektoren einer Komponente, eines Designsystems oder eines älteren Stylesheets ein und prüfen Sie das obere Ende der Ausgabe. Große Sprünge weisen oft auf IDs, stark qualifizierte Zustände oder ein mächtiges Argument innerhalb von <code>:is()</code> beziehungsweise <code>:not()</code> hin. Solche Selektoren können späteren Code zwingen, strukturelle Details nur zum Überschreiben einer Deklaration zu wiederholen. Ersetzen Sie sie gegebenenfalls durch eine Klasse mit klarer Einzelaufgabe, schwächen Sie optionalen Kontext mit <code>:where()</code> ab oder ordnen Sie Ebenen so, dass der Vorrang nicht von ständig steigenden Werten abhängt. Auch das untere Ende ist aufschlussreich: Elementregeln und leichte Hilfsklassen lassen sich besser wiederverwenden, wenn ihre Rolle klar ist. Automatisierte Abläufe können die API für $0.002 aufrufen, um neue Selektoren oberhalb einer Teamgrenze zu melden, Spezifitätswerte zusammen mit erzeugtem CSS zu speichern oder sortierte Hinweise in einer Prüfung anzuzeigen. Eine ungültige Eingabe lässt die gesamte Anfrage fehlschlagen, sodass ein Teilbericht keinen fehlerhaften Selektor verbirgt. Die Berechnung ist deterministisch und ohne Netzwerkzugriff; identische Eingaben erzeugen immer dieselben Werte in derselben Reihenfolge.