Trier les sélecteurs CSS par spécificité

Comparer visuellement une longue série de sélecteurs reste pourtant lent et propice aux erreurs. Cet outil reçoit des sélecteurs CSS individuels, valide leur syntaxe, calcule leur valeur de spécificité en trois parties et renvoie la liste entière du niveau le plus faible au plus élevé. Il comprend les pseudo-classes fonctionnelles modernes comme :is(), :not(), :has(), :where() et :nth-child(), tout en conservant l’ordre initial lorsque deux sélecteurs ont le même poids.

Lire le score de spécificité en trois parties

Chaque résultat suit la structure habituelle ID, classes et types. Le premier nombre compte les sélecteurs d’ID tels que <code>#checkout</code>. Le deuxième compte les classes, les sélecteurs d’attribut et les pseudo-classes comme <code>.active</code>, <code>[disabled]</code> et <code>:hover</code>. Le troisième compte les sélecteurs de type et les pseudo-éléments comme <code>button</code> et <code>::before</code>. Les sélecteurs universels et les combinateurs n’ajoutent rien. La comparaison est lexicographique : un seul ID l’emporte sur tout nombre d’entrées dans les autres colonnes, et une classe l’emporte sur tout nombre de sélecteurs de type lorsque le nombre d’ID est identique. Le tableau <code>specificity</code> convient aux traitements logiciels, tandis que <code>specificity_text</code> présente la même valeur sous une forme compacte et lisible. Le tri croissant place les règles largement réutilisables en premier et les sélecteurs les plus difficiles à surcharger en dernier. Quand deux scores sont strictement égaux, l’outil conserve leur ordre d’entrée au lieu d’inventer un classement alphabétique secondaire. Ce comportement stable garantit des exécutions prévisibles et préserve le contexte d’une feuille de style ou d’une liste de contrôle.

Traiter correctement les pseudo-classes modernes

Les pseudo-classes fonctionnelles sont la principale source d’erreurs dans les calculs manuels. <code>:where()</code> apporte toujours une spécificité nulle, y compris pour les sélecteurs qu’elle contient ; vous pouvez ainsi préciser une structure sans rendre une règle plus difficile à surcharger. En revanche, <code>:is()</code>, <code>:not()</code> et <code>:has()</code> prennent la spécificité de leur argument le plus spécifique, sans ajouter leur propre point de pseudo-classe. Les formes <code>:nth-child()</code> et <code>:nth-last-child()</code> ajoutent un point de pseudo-classe, puis la spécificité maximale d’une liste facultative introduite par <code>of</code>. Les formes liées au DOM fantôme, comme <code>:host()</code> et <code>::slotted()</code>, sont également prises en charge. L’analyseur parcourt les parenthèses imbriquées, les crochets, les chaînes entre guillemets et les échappements ; une virgule interne à une fonction n’est donc pas confondue avec un séparateur de premier niveau. Transmettez chaque élément sous la forme d’un seul sélecteur. Une virgule de premier niveau désignerait plusieurs sélecteurs dont les scores peuvent différer : elle est rejetée plutôt que réduite à une valeur unique trompeuse. Chaque entrée correspond ainsi exactement à un score de sortie.

Simplifier la cascade grâce à la liste triée

Un rapport de spécificité sert surtout à guider une refactorisation, pas à encourager des sélecteurs toujours plus puissants. Collez des sélecteurs représentatifs d’un composant, d’un système de conception ou d’une feuille héritée, puis examinez la fin du résultat. Les écarts importants révèlent souvent des ID, des états trop qualifiés ou un argument puissant dissimulé dans <code>:is()</code> ou <code>:not()</code>. Ces sélecteurs peuvent forcer le code ultérieur à répéter des détails structurels uniquement pour surcharger une déclaration. Vous pouvez les remplacer par une classe à fonction unique, diminuer le poids du contexte facultatif avec <code>:where()</code> ou organiser des couches afin que la priorité ne dépende pas d’une escalade des scores. Le début du classement est lui aussi instructif : les règles d’élément et les utilitaires légers se réutilisent plus facilement lorsque leur rôle est explicite. Un processus automatisé peut appeler l’API pour $0.002 afin de signaler les nouveaux sélecteurs dépassant le seuil choisi par votre équipe, d’enregistrer la spécificité avec le CSS généré ou de présenter des diagnostics triés en révision. Toute entrée incorrecte fait échouer la requête entière, de sorte qu’un rapport partiel ne masque jamais un sélecteur mal formé. Le calcul est déterministe et sans accès réseau : une même entrée produit toujours les mêmes valeurs et le même ordre.