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 !

erreurs-css

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; }

css-inline

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; }

dry

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.

bidouille-css

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.

Memo GIT en ligne de commande
Réduire le contenu dupliqué dans Prestashop

5 Comments on “10 erreurs CSS à éviter”

  1. 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 ?
    Pour cela, il y a Firebug. :)

    Merci en tout cas pour l’article, il y a tellement de choses à dire sur l’intégration. Ca dépend, ça dépasse…

  2. 11eme erreur à éviter, suivre ces conseils. Ils sont tous plus faux les un que les autres… Tu n’as rien compris à l’optimisation…

    1/ FAUX
    2/ OK
    3/ FAUX
    4/ VRAI ET FAUX ca se discute et ca dépend du type de page
    5/ VRAI
    6/ VRAI ET FAUX la aussi ca dépend de la structure de la page
    7/ SINON tu peux aussi charger un fichier css spécifique IE <= 8
    8/ OK
    9/ BOF BOF ca rajoute une requête de plus pour seulement gagner en lisibilité côté développement
    10/ OUI mais pas en version de prod

    1. Merci de ton retour et excuse moi pour ne pas avoir validé le commentaire plus tôt, tu avais l’air très pressé de voir ma réponse ;)

      1/ Tu t’en rends compte quand tu tombes sur un site qui n’est codé qu’à base d’IDs. Tu termines par mettre des règles à rallonge que j’aborde dans le point 2. Bon, je ne suis pas le seul à le dire donc je ne pense pas passer pour un illuminé. Attention, je ne dis pas que c’est interdit mais qu’il faut faire attention quand on les utilise.
      3/ Ne me dis pas que tu codes encore tes styles en dur dans le code ! C’est le pire quand tu reprends le site d’un client et que tout est en dur. Pour moi, ces types passent plus pour des bricoleurs. Le W3School donne une raison de plus pour ne pas l’utiliser : http://www.w3schools.com/css/css_howto.asp
      7/ Oui.
      9/ Tu n’a pas de cache sur ton site ? La minification et concaténation des fichiers sert à ça ;)
      10/ Ok.

      1. 1/ Je ne dis pas de tout mettre en id sinon évidemment tu vas te retrouver avec un css énorme, mais pour des elements uniques et récurrents ex : header, logo, footer…
        les performances quand tu utilises des id sont maximales.

        3/ Prenons le cas d’une boutique en ligne de 3 pages principales : Accueil, Promotions, Tous les produits

        Dans la page promotions tu utilises un bloc unique pour tes articles ex : bgcolor: red.

        Penses-tu que c’est vraiment utile qu’il soit mis dans ton fichier css et chargé sur toutes les autres pages alors qu’elles n’afficheront pas l’élément. C’est plus moche dans le code je suis d’accord, mais après à l’affichage ca ne change rien et surtout niveau performance la encore ca ira plus vite, une dizaine de caractère par ci par là c’est toujours ca d’économisé sur le fichier css final. Donc pour les styles ne concernant qu’une page je recommanderai de les mettre dans le head ou en inline ca fera plaisir à ceux qui sont en Edge :)

        7/ La mise en cache n’évite en rien la requête mais évite de solliciter le serveur web

      2. Petite précision pour être bien clair la mise en cache réduit le nombre de requête mais ne l’évite pas

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *