comme nous l'avons vu, CSS n'est pas le langage le plus sympatique: opérant globalement, fuyant de partout, dépendant de la localisation, difficile à encapsuler, basé sur l'héritage… Mais ! rien de tout cela n'approche les horreurs de la spécificité.
Quels que soient les efforts que vous aurez mis dans votre nommage, aussi parfaite soit l'ordre de vos source, la gestion de votre cascade, et comment vous aurez géré la portée de vos bases de règle, une seule base de règle trop spécifique peut réduire cela à néant. c'est un énomre piège qui sape la nature profonde du CSS de cascade, héritage, et ordre des sources.
Le problème avec la spécificité est qu'il établi des précédents et cartes (trumps ?) qui ne peuvent être surpassés simplement. Si nous prenons un exemple réel dont je fus responsable il y a quelques années :
#content table { }
Non seulement cela montre une piètre Selector Intent — Je ne souhaitais pas en effet sélectionner toutes les table de la zone #content, je voulais sélectionner un type spécifique de table qui se trouver être là — ce qui est un sélecteur totalement sur-spécifique. cela apparut quelques semaines plus tard lorsque j'eu besoin d'un second type de table:
#content table { }
/**
* Uh oh! My styles get overwritten by `#content table {}`.
*/
.my-new-table { }
Le premier sélecteur surpassait la spécifité de celui défini après it, à l'encontre du principe d'ordre des sources de CSS concernant l'application des styles. Pour remédier à ça, j'avais deux options principales, je pouvais :
Malheureusement, la refactorisation aurait pris trop de temps, il s'agissait d'un produit mûr et les répercussions de la suppression de l'Id aurait au des business cost plus substantiels que la seconde option : écrire simplement un sélecteur plus spécifique.
#content table { }
#content .my-new-table { }
J'avais alors un sélécteur encore plus spécifique ! Et si je voulais l'overrider, j'aurais à écrire un sélecteur avec au moins le même degré de spécificité et définit après celui-di. J'avais démarré une spirale sans fin.
La spécificité peut, entre autre choses :
Tout ces problèmes sont grandement amplifiés lorsque l'on travaille sur un grand projet avec plusieurs développeurs contribuant au code.
Le problème avec la spécificité n'est pas nécessairement qu'elle soit haute ou basse; c'est le fait qu'elle soit si variable et qu'on ne puisse pas choisir de ne pas s'y soumettre : le seul moyen de la gérer est d'être progressivement plus spécifique — les fameuses guerres de spécificité que nous avons regardées d'en haut.
Un des seuls et plus simples trucs pour se simplifier la vie en écrivant des CSS — en particulier à une taille raisonnable — est de toujours essayer de conserver la spécificité aussi basse que possible. Essayez de vous assurer qu'il n'y a que peu de variance entre les sélecteurs de votre base de code, et que les sélecteurs ont une spécificité aussi réduite que possible.
S'en tenir à cela vous aidera à maîtriser et gérer votre projet, signifiant qu'aucun sélecteur sur-spécifique ne risquera d'impacter ou affecter quoi que ce soit de plus basse spécificité où que ce soit. Cela signifieras aussi que vous risquez moins d'avoir à vous battre pour des histoires de spécificités, et aussi probablement que vous écrirez des feuilles de style bien plus petites.
des changement simples à notre manière de travailler incluent, mais ne se limitent pas à :
ne pas utiliser d'ID dans votre CSS; ne pas nicher de sélecteurs; ne pas qualifier les classes; ne pas chaîner les sélecteurs.
La spécificité peut être discutée et comprise, mais il est plu ssimple de l'éviter complètement.