Originellement conçu pour des web designers, CSS se veut être un langage de description et non de programmation.
Mais ça c'était avant.
Le Web a évolué, nos usages et consommations également. CSS s'adapte petit à petit au contexte actuel et se complexifie pour devenir "un vrai langage" (avec variables, calculs et fonctions, notamment).
En attendant une hypothétique stabilisation du langage, nous en sommes aujourd'hui à déplorer des feuilles CSS de taille astronomique et de moins en moins maintenables en production.
Par exemple, sur le site alsacreations.com (hors forum), sur un fichier CSS de 32ko, l'outil StyleStats ne dénombre pas moins de :
-
46 occurences de
!important
-
41
float
inappropriés -
402 sélecteurs d'
ID
- 28 tailles de polices différentes
- 36 couleurs de texte différentes
- etc.
Une convention pour éviter la bidouille
Pour améliorer notre quotidien d'intégrateur, l'agence Alsacréations s'est constitué une mini Convention CSS contenant toutes les bonnes pratiques qui nous paraissent essentielles à ce beau langage qu'est CSS.
Ne nous lançons pas de fleurs : nous n'avons rien inventé, uniquement compilé les conseils et astuces de multiples autres sources.
Remarque : il s'agit d'une convention correspondant à nos besoins internes de petite agence web, vous devrez bien entendu l'adapter à votre environnement.
Lien vers la présentation : https://speakerdeck.com/goetter/mini-convention-css
Les bonnes pratiques CSS
Voici le contenu de cette mini convention CSS.
- Généralités
-
Bonnes pratiques générales
-
Modèle de boîte :
Opter pour le modèle de boîte CSS3 (box-sizing: border-box
) en début de la feuille de style -
Tailles de polices :
Opter pour des tailles de polices fluides (de préférence enrem
). -
Flux :
Éviter de sortir les éléments du flux (float
,position
) sans nécessité. -
Positionnement :
Positionner les éléments en choisissant de préférencedisplay
(block
,inline
), puisflexbox
, puisinline-block
outable-cell
-
Lecture :
Écrire des syntaxes compréhensibles par des êtres humains et des collègues. -
Namespaces :
Préfixer les classes par « namespace » pour les regrouper et les distinguer aisément.
-
Modèle de boîte :
-
Maintenance et lisibilité
-
Poids des sélecteurs :
Éviter de surcharger un sélecteur, car cela lui ajoute du poids inutilement. -
Sélecteur
#ID
:
Éviter d’utiliser le sélecteur d’id
, son poids est trop important et difficile à maintenir, éviter également le bazooka!important
-
Sélecteurs de structure :
Éviter les sélecteurs associés à la structure HTML, un élément doit pouvoir être ciblé quel que soit son conteneur ou son emplacement dans le DOM. -
Structure et apparence :
Séparer la structure de l’apparence dans les sélecteurs pour faciliter la factorisation. -
Factoriser les propriétés :
Toujours tenter de rassembler les propriétés identiques. -
Surcharge :
Éviter d’écraser une règle par une autre. -
Redondances :
Utiliser des pré-processeurs (Sass, LESS, Stylus) pour éviter les répétitions de code. -
Réutiliser les blocs :
Grouper les éléments par composants réutilisables. -
Ne pas trop réutiliser :
Se limiter à 4 noms de classes au maximum par élément HTML. Si l’on pense qu’il en faut davantage, il est temps d’envisager une classe personnalisée.
-
Poids des sélecteurs :
-
Performances
-
Animations gourmandes :
Éviter d’animer des propriétés autres quetransform
ouopacity
, ou alors ajouter la propriétéwill-change
et/ou le hack detranslateZ()
. -
@font-face performant :
N’imposez pas de chargements aux anciens navigateurs (IE8). Privilégiez.woff2
. Conservez l’astuce du#iefix
-
Propriétés raccourcies :
Préférer les propriétés raccourcies. -
Unités :
L’unité est inutile si la valeur est nulle. Ne pas donner d’unité àline-height
. -
Préfixes vendeurs :
Automatiser la gestion des préfixes à l’aide de Autoprefixer, ne pas le faire à la main et ne pas utiliser un mixin Sass/LESS pour cela.
-
Animations gourmandes :