10 erreurs CSS à éviter

Oui, tout le monde connais le CSS mais non, peu de personnes ne font pas d’erreurs lorsqu’ils codent. Avis aux agences web : bookmarkez cet article ou envoyez le à votre développeur pour qu’il en prenne connaissance si la qualité des sites ou applications que vous produisez vous importe. C’est parti !

1/ L’utilisation des IDs

Il y a plusieurs types de sélecteurs : les IDs, les classes et les balises :

#lien { color:green; }
.lien { color:blue; }
a { color:yellow; }

Le premier est le plus spécifique des trois car il utilise un ID. Les IDs ne peuvent être utilisés qu’une fois par page. C’est lui qui est pris en compte (l’ID prime sur le classe ou la balise) pour un lien déclaré de cette façon :

<a href="#" id="lien" class="lien">Ancre du lien</a>

De quelle couleur sera le lien ? Oui, vert ! Le second sélecteur le plus spécifique est la classe, suivie de la balise. Le problème est que vous allez rarement voir l’exemple ci-dessus. En général, les développeurs l’utilisent de cette manière :

#header a { border:1px solid #333; }

Imaginez maintenant que votre client décide que l’un des liens contenu dans le div dont l’ID est header ne doit pas avoir de bordure. Vous allez devoir écrire le code pour annuler la propriété d’avant (une autre mauvaise habitude) :

.lien-special { border: none; }

D’après vous, cela va fonctionner ? La réponse est non, car l’ID de son parent est plus fort que les classes des éléments fils. Vous allez donc devoir écrire :

#header .lien-special { border:none; }

Imaginez encore qu’un autre lien ait besoin d’un autre style. Répétez cet enchaînement sur un site entier et cela résultera à avoir un code CSS beaucoup plus grand qu’il n’aurait dû l’être. Voilà pourquoi l’utilisation des IDs est une si mauvaise habitude. De plus, la plupart des IDs peuvent en général être modifiés en classes sans problème.

2/ La longueur des sélecteurs

#header #titre .cote-gauche img.logo { opacity:0.5; }

Ce sélecteur utilise non seulement des IDs (c’est mal), mais il est aussi très long. Si vous utilisez des sélecteurs qui sont plus grand que 3 niveaux de profondeur, vous êtes bien trop spécifique. Vous aggravez donc la situation d’autant plus que lors des mises à jours graphiques de votre site, il sera beaucoup plus compliqué de faire ça proprement.

3/ Inline CSS

L’Inline CSS est le CSS qui est présent en dur dans votre code HTML. C’est un crime ! La raison pour laquelle on utilise le CSS est de séparer le style de la structure du site. C’est depuis qu’on n’utilise plus les tables qu’on ne met plus de CSS directement dans le code source :

<a href="#" style="color:green;text-decoration:none;font-weight:bold;" class="style-lien">lien</a>

De plus, le problème avec ça est que c’est prioritaire par rapport au CSS externalisé, même en utilisant des IDs. Le seul moyen de passer outre l’Inline CSS est d’utilise le mot !important en fin de déclaration :

.style-lien { color:blue !important; }

4/ Les éléments parents

Ce que nous pouvons voir aussi est un style CSS codé comme si vous suiviez le DOM de la page. C’est à dire que le développement utilise toujours un éléments parent, souvent défini par un ID (bouuuh!) puis redescend petit à petit vers l’élément auquel il souhaite lui définir un style.

Je m’explique :

#header .menu ul li a { text-decoration:none; }

Imaginez vous devoir passer à travers un fichier CSS de 2000 lignes de code lors d’une refonte pour essayer de trouver quelle déclaration modifie le style d’un élément ? De plus, le fait d’être plus précis au niveau de votre sélecteur vous évitera de les répéter un certain nombre de fois :

#header .menu ul { ... }
#header .menu ul il { ... }
#header .menu ul li a { ... }

5/ Les répétitions de code (DRY)

DRY (Don’t Repeat Yourself) est une philosophie en programmation informatique consistant à éviter la redondance de code au travers de l’ensemble d’une application afin de faciliter la maintenance, le test, le débogage et les évolutions de cette dernière. C’est ce qu’il faut appliquer ici. Si vous vous répétez, vous perdez votre temps (en gros).

.un-titre { font-weight:bold; }
.un-autre-titre { font-weight:bold; color:red; }

Devient :

.un-titre, .un-autre-titre { font-weight:bold; }
.un-autre-titre { color:red; }

Ou en Sass :

.un-titre { font-weight:bold; }
.un-autre-titre { @extend .un-titre; color:red; }

6/ Les unités de mesure

Les feuilles de style qui comportent des unités en px, em et rem sans aucune raison particulière sont à éviter. Les em et rem sont des unités relatives. Il y a beaucoup de densités de pixels différentes de nos jours avec le nombre de smartphones qu’il y a sur le marché, l’utilisation des ems permet d’avoir des feuilles de styles plus adaptables d’un média à un autre.

7/ Fallbacks et déclarations invalides

Avez-vous déjà joué avec les derniers attributs CSS3 ? Il y a des chances pour que certains de vos visiteurs aient besoin de fallback pour que cela fonctionne correctement.

Par exemple, si vous utilisez rgba(), ça ne fonctionnera pas pour les utilisateurs de IE8. Avez-vous utilisez tous les préfixes dont vous avez besoin (-moz, -o, -webkit) ? Avez-vous prévu le coup pour plus-tard, quand ces préfixes ne seront plus utiles ?

8/ Styles qui s’annulent

Illustrons cette problématique avec des exemples de code :

h2 {
    font-size: 2em;
    margin-bottom: 0.5em;
    padding-bottom: 0.5em;
    border-bottom: 1px solid #ccc;
}

.no-border {
    padding-bottom: 0;
    border-bottom: none;
}

Il est préférable de changer votre code par :

h2 {
    font-size: 2em;
    margin-bottom: 0.5em;
}

.headline {
    padding-bottom: 0.5em;
    border-bottom: 1px solid #ccc;
}

L’idée est que si vous rédigez des règles de styles que vous devez sans cesses annuler, c’est qu’il y a un problème. En fin, vous allez finir par écrire plus de CSS pour appliquer moins de style. Vous commencez à comprendre ? ;)

9/ Les bidouilles CSS

Les marges négatives, !important, la position absolute avec des valeurs négatives, vous connaissez tous ça. Ce sont des bidouilles CSS. Dans certaines situations, il sera difficile de les éviter. Une pratique courante reste néanmoins de mettre tous ces hacks dans un fichier hack.css (ou shame.css).

Cela présente plusieurs avantages : vous gardez le code principal propre et le fait de les isoler permet de les corriger plus facilement avec le temps.

10/ Oublier de commenter son code

La documentation est l’aspect le plus ennuyeux (je l’admet) mais le plus important de votre code en terme de maintenabilité. Il simplement à comprendre votre code.