Les crashs dev d'un passionné

Nous avons vu dans le précédent article les différentes possibilités pour faire du CSS maintenable et facilement compréhensible. Je vous ai dévoilé ma préférence pour BEM, nous allons maintenant voir comment le contenu de votre fichier CSS doit être écrit.

Comment puis je structurer mon fichier CSS pour qu'il soit lisible ?

idiomatic-css permet de définir une règle de construction du fichier CSS. On retrouve ces règles implémentées dans un linter comme stylelint

Nous allons voir quelques règles, elles ne sont bien entendue pas obligatoire vous pouvez vous les approprier. Le plus important est que vous respectiez la même convention dans tous vos fichiers CSS.

• Les espaces doivent être uniformes : tabulation ou espace. Ma préférence est de 4 espaces.
  Supprimez également les espaces fins de ligne
• Utilisez les commentaires pour décrire la fonction attendues et les subtilités.
  Maximum 80 caractères sur une nouvelle ligne au dessus de ceux que vous voulez décrire
• Utilisez des sections pour délimiter vos parties fonctionnelles
  /* ==========================================================================
  Section comment block
  ========================================================================== */
  
• Utilisez un seul sélecteur par ligne
• Ajoutez un espace avant {
• Utilisez une seule déclaration par ligne
• Augmentez votre indentation quand vous êtes dans un bloc d'attributs
• Utilisez un seul espace après : pour séparer les propriétés
• Utilisez les minuscules pour le code hexadécimal
• Utilisez toujours la simple quote ou double quotes (ma préférence)
• Pas d'unité quand la valeur est nulle comme margin: 0 .
• Un espace après chaque virgule dans les propriétés
• Toujours mettre un ; à la fin
• Fermez le bloc ruleset à la même colonne que le 1er caractère
• Séparez chaque RuleSet par une ligne vide
  
• Respectez l'ordre de déclaration des propriétés en regroupant par fonctionnement
  
• Un bloc avec une seule instruction peut être mise sur une ligne. Dans ce cas il faut mettre un espace après { et avant }
  
• Les valeurs de propriété qui sont longues peuvent être découpées avec un retour à la ligne comme cela :
  

Et pour les préprocesseurs

• Se limiter à un seule niveau d'imbrication
• Évitez les propriétés de plus de 20 lignes
• Toujours mettre @extend en 1er ligne du bloc
• Regroupez les @include juste après @extend quand cela est possible

Nous venons de voir la manière de structurer notre feuille de style, maintenant attaquons nous au choix des noms des classes

Quel nom choisir pour les classes CSS (quelque soit la méthodologie)

Ils peuvent prendre 3 catégories : fonctionnel, contenu ou présentation.

• Fonctionnel : décrit l'utilité derrière la classe utilisée. Cela est clair mais lie très fortement HTML et Design.
  Par exemple sur un bouton, si on souhaite modifier .signin-button il faut le faire sur chaque page du site qui le réclame...
• Le contenu : permet de décrire le contenu derrière le style. Ce type est pratique pour les sites de petite taille mais dès que celui-ci grandi il devient vite ingérable.
  En effet si on a un bouton avec une classe .submit-button et que l'on souhaite mettre le bouton avec un + à la place d'un personnage, cela impact tout le site. Cela peut être gênant si on veut appliquer un style particulier juste sur ce bouton
• La présentation décrit dans le nom de la classe son style, ex .blue-headline. Le choix de ce type est meilleur pour les sites importants car il mutualise au maximum le style.

La spécification W3C dit que le nom de la classe CSS doit décrire la nature du contenu plus que la présentation.
Selon W3C il faudrait opter soit pour des noms de classes fonctionnelles ou de contenu. La frontière entre l'aspect fonctionnel et la description du contenu est parfois très mince.

Quelles sont les performances dans tout ça ?

En CSS l'utilisation d'une classe par rapport à un ID n'apporte pas de gain.
En CSS : le nom de classe longue impact la quantité de donnée à télécharger, le fichier html sera plus important
En JS l'utilisation de nom de classe très longu n’entraîne pas de perte de performance énorme, comme le montre ce benchmark

En lisant les recommandations de Mozilla pour l'écriture des sélecteurs CSS on se rend compte que moins de hiérarchie d’élément imbriqué entraîne une performance meilleur e:
En effet la multiplication des classes, clé de sélection (élément à l'extrémité droite du sélecteur), ID ... dans un élément HTML augmente l'analyse du navigateur qui parse les classes de droite à gauche pour trouver le bon élément HTML
Attention lors de l'utilisation du CamelCase car les sélecteurs CSS sont insensibles à la case mais pas les noms de classe en HTML. Il faut préciser le "document language" car en XML il sera sensible à la case mais pas en HTML

Quand plusieurs éléments subsistent dans le sélecteur il faut suivre la règle specificity : par exemple .c2.c1 est prioritaire à .c1

Cependant ces gains de performances sont vraiment minimes, ils dépendent plus du navigateur.

Si vous voulez des meilleurs performances, optimisez images, feuille de style et vos scripts JS

En conclusion

Vous avez vu que le choix est plus à destination d'un code clair, lisible et maintenable.
L'impact des performances sur ce choix est quasi nulle.
Il est libre à vous de choisir ce qui correspond le plus à vos projets (habitudes, taille du projet, utilisation d'un framework CSS...)