Retour aux articles

L'agence

WanadevStudio

Bonnes pratiques CSS : pourquoi et comment s'organiser ?

Récemment je me suis penché sur les différentes méthodologies CSS existantes afin de faciliter la productivité et la maintenabilité de nos projets, c'est une problématique que bon nombre de développeurs rencontrent tôt ou tard.

^ Je ne vous détaillerai pas chacune des méthodes présentées car ce n'est pas le but, il existe déjà de nombreux articles très bien expliqués que je vous partagerai. En revanche, je vais vous présenter ma façon d'organiser mon CSS !

Pourquoi avoir une bonne méthodologie CSS : la carte d'anniversaire

Le CSS dans un projet c'est sympa, je le vois un peu comme une carte d'anniversaire !

Au début la carte est vide, on peut écrire où on veut. Au fur et à mesure que les participants écrivent, la place se fait de plus en plus rare, on écrit où on peut en essayant de placer notre petit mot tant bien que mal.

L'heureux élu se verra rempli de joie lorsqu'il recevra la fameuse carte écrite avec amour et qu'il va lire déchiffrer avec une attention particulière.

Dites-vous bien que celui qui reçoit la carte est celui qui récupère le genre de projet où chacun a fait son CSS de son coté.

^ Si vous n'avez pas de méthodologie CSS, votre projet doit sûrement ressembler à une belle carte d'anniversaire.

Enfin, pour finir cette introduction, je me permets de rappeler que, dernièrement, Baptiste a publié un article sur l'organisation de notre veille techno. Cet article est ainsi la suite logique de nos méthodes de veille.

Organiser son CSS : la problématique

Trêve de plaisanteries et rentrons dans le vif sujet, quelle que soit l'envergure de votre projet, il sera important de bien le structurer (là je ne vous apprends rien).

Et là où se compliquent les choses... c'est lorsque l'on est plusieurs à travailler sur le même projet (from scratch, en cours, déjà existant etc ...) !

Dans ce cas, vous risquez de rencontrer les problèmes suivants :

  • Duplication de classes et de composant (DRY pour Don't Repeat Yourself)
  • Modules pas assez génériques (pas réutilisables)
  • Conflits entre classes (voire annulation de certaines)
  • Difficile à maintenir / faire évoluer (surtout si on n’a pas travaillé dessus dès le début)

@ Que vous soyez freelance ou dans une équipe en édition. L'objectif est de toujours pouvoir travailler de manière méthodique, (ré)exploitable et dans le cas d'une prestation (faut pas se mentir), rentable. Transition directe vers l'article rédigé par Manuel où il explique comment réduire sa dette technique.

Prenons l'exemple d'un projet développé par une autre équipe sur lequel on devrait apporter des améliorations. S'il n'y a pas de méthodologies ni d'organisation du CSS, ça peut vite devenir l'enfer ! Dit plus grossièrement, ce que l'on souhaite, c'est que ça ne fasse pas casser le design juste parce qu'on a changé la couleur d'un bouton.

Pour résumer, voici ce que l'on souhaite sur nos projets :

  • Qu'il soit évolutif
  • Qu'il soit maintenable
  • Qu'il possède une logique facile/intuitive
  • Un nommage de classe simple et contextuel
  • Éviter les conflits de classes
  • Une ré-utilisabilité des composants / modules

Organiser son CSS : les différentes solutions

Au fil des projets on se fait sa propre méthodo : on avance, on progresse, on s'améliore, on fait de moins en moins d'erreurs... mais en creusant un peu, je me suis rendu compte qu'il existait pléthore de méthodologies CSS éprouvées sur la toile allant de la plus simple à la plus complexe.

D'autres se sont bien évidemment creusés sur le sujet avant nous, voici celles sur lesquelles je me suis penché :

  • BEM
  • OOCSS
  • MCSS
  • SMACSS
  • ITCSS
  • SEM BIO

La méthodologie BEM

Si vous avez commencé à vous intéresser aux méthodologies CSS vous avez certainement entendu parler de BEM (Bloc Element Modifier) qui est l'une des plus populaires.

On trouve de nombreux articles qui en parlent comme par exemple (css-tricks, alsacreation, ou putain de code, etc)).

@ BEM c'est surtout une convention de nommage permettant d'identifier rapidement vos blocs/éléments selon leur contexte et de faire un découpage simple pour réutiliser vos blocs (D.R.Y).

^ Il faut savoir qu'à ce jour il n'existe pas de méthodologie officielle, ces méthodes s'adressent surtout à un public de développeurs ayant une base en CSS dans un souci de lisibilité et de maintenabilité du code.

La méthodologie OOCSS (Object Oriented CSS)

L'approche orientée objet est intéressante, les classes CSS sont abordées comme des objets.

On repère les objets/patterns visuels pour en faire des classes réutilisables afin de rendre le CSS indépendant de la structure HTML. Voir la documentation de OOCSS

La méthode MCSS (Multilayer CSS)

Le CSS multicouche suggère de séparer les styles en plusieurs parties, appelées calques. Quatre couches vous permettent d'organiser vos fichiers selon leur catégorie. Voir la documentation de MCSS

La méthode SMACSS (Scalable and Modular Architecture CSS)

Comme pour MCSS, vos styles sont découpés en plusieurs parties, ici en 5 couches pour une meilleure répartition des fichiers. Cette méthode se veut souple et flexible. Voir la documentation en SMACSS et le Guide complet en PDF

La méthode ITCSS (Inverted Triangle CSS)

Un peu plus complexe : vous avez entre 7 et 9 couches (selon la méthode). La manière de découper vos fichiers change mais globalement le même principe est appliqué.

Voici un article sur ITCSS pour plus de détails.

SEM & BIO ( Scalable Evolutive maintable & BEM ITCSS OOCSS)

Et enfin plus corsée, SEM & BIO : une sorte de patchwork méthodologique car elle regroupe 3 méthodes.

Un article sur SEM&BIO par CSS Tricks.

Et moi ? Quelle méthodologie CSS ?

La plupart des méthodes présentées plus haut se basent toutes plus ou moins sur BEM en matière de nommage de classe. Peu importe la solution que vous choisirez, le plus important est de travailler tous de la même manière et sur les mêmes bases.

Ainsi, voici comment je m'organise :

L’architecture
  • mon-projet.scss (includes)
  • Base
    • fonts, mixin, variables, reset (ici pas de .class ni de #id)
  • Layout (header, footer)
  • Components (boutons, blocs réutilisables)
  • Patterns (pages spécifiques, comportement spécifique)
  • Dependencies (réservé au chargement des librairies et à leurs override)

Un peu plus de précisions sur mon découpage (5 parties) qui se veut être un compromis entre toutes les méthodes trouvées.

Base va principalement servir pour l'initialisation du projet. Import de nos fonts, variables et mixin pour le preprocessing (sass/less/stylus) et un reset pour initialiser mes éléments HTML (uniquement sur les balises - pas de .class ni #id)

Layout, réservé aux blocs principaux que l'on va retrouver sur toutes nos pages ou presque (header, footer, dashboard)

Components, les briques et tout type de composant servant à être ré-utilisés (rappelez-vous le D.R.Y) comme les boutons, les cards, les alertes, blocs propres à mon design...

Patterns pour les pages et les comportements spécifiques, ma page profil, page de connexion sont des pages uniques que l'on va retrouver qu'une seule fois.

Dependencies car il nous faut un dossier pour regrouper les dépendances. C'est également l'endroit où l'on override la variable ou le comportement de certaines dépendances (Bootstrap, select2).

Depuis mon-projet.scss je fais un appel à mes fichiers. C'est mon « entrypoint ».

Voici un exemple de ce que pourrait donner une arborescence de dossier :

image

Identification des éléments

Pour le découpage de mon design et de mes éléments, on ne ré-invente pas la roue. Ce que BEM propose répond à nos besoins. Ce sera à vous de bien faire votre découpage.

@ Idéalement et s'il vous est possible de le faire, prenez un moment pour analyser les maquettes à intégrer afin d'identifier les briques réutilisables de celles qui ne le sont pas, les patterns spécifiques, vos boutons etc.

C'est une partie délicate car la logique de votre découpage ne sera pas forcement celle de votre collègue.

méthodologie CSS et convention de nommage

Pour le nommage des classes, tout se fait en minuscule, un tiret en guise de séparateur pour les noms composés que ce soit un bloc, un élément ou un modificateur.

Ensuite, deux underscores devant le nom de notre élément et deux tirets devant le modificateur.

block__element--modifier

head-block
menu-block
menu-block__item
menu-block__item--is-active

Méthodologie CSS : pour résumer

  • Je construis une arborescence structurée et logique de mes fichiers CSS ;
  • J'importe les fichiers de base et j'applique les resets CSS ;
  • J'identifie mes différentes briques à travers les maquettes ;
  • Je fais mon découpage afin de le répartir dans la structure du dossier.

Cette solution est évolutive et non exhaustive, l’optique est de gagner en performance, maintenabilité et productivité. Il est évident que cette méthodologie évoluera, et qu'elle s'ajustera en fonction des projets et des équipes.

Et vous ? Quelle méthode CSS ?

Commentaires

Il n'y a actuellement aucun commentaire. Soyez le premier !

  • Tests automatiques fonctionnels d’applications 2D/3D

    Il y a 7 mois

    Comme nous le disions dans cet article, l’automatisation des tests dans le développement logiciel est indispensable : dès lors qu’une application commence à avoir un minimum d’importance, les tests automatiques permettront de gagner énormément de temps en évitant de reproduire ad vitam æternam les mêmes tests manuels, et éviteront beaucoup de régressions. Dans cet article, nous allons présenter différents types de tests automatiques dans le cadre plus spécifique d’applications 2D/3D, puisque c’est ce que nous faisons ! Cela va du test basique qui clique sur 3 boutons aux tests de plusieurs minutes reproduisant les actions comme un véritable utilisateur. Accrochez-vous, c’est parti !

  • Configurateur web à l'abonnement : forces et faiblesses

    Il y a 8 mois

    Aujourd’hui, si vous cherchez à mettre en place un configurateur sur votre site, deux grandes possibilités s'offrent à vous : les solutions par abonnement (du type SaaS) ou le développement sur mesure. Au premier abord, les solutions semblent proches, mais les enjeux sur le long terme eux, sont bien différents.

  • Les frameworks front, tous les mêmes !
    Méthodologie

    Il y a 9 mois

    C'est une phrase que j'ai osé sortir un jour dans la salle de pause de Wanadev. Je ne sais plus exactement avec quel collègue je discutais, j’essayais de le rassurer, il possédait déjà une certaine expérience avec React et allait devoir, en arrivant sur le projet sur lequel je travaille, se mettre à Vue.
    Il a malheureusement fallu qu'un autre collègue de passage nous entende pour ne pas trouver la conversation inintéressante et suggérer que j'en fasse un petit talk pour nos réu du lundi. Et, de fil en aiguille, me voilà en train d'en faire un article de blog. Comme quoi, note pour moi-même, il faut toujours se méfier des discussions dans les salles de pause.

  • [NOVEMBRE 2021] C'est la gazette de Wanadev !
    Méthodologie

    Il y a 12 mois

    Retrouvez ici les informations et actus du mois de novembre de l'Agence! Au programme de cette édition : découvrez le configurateur de fenêtre développé pour Caseo, recontrez François Deleglise, notre directeur communication et un nouvel espace de jeu pour les professionnels du loisir en VR. Bonne lecture !

  • Un peu d'ingérence dans votre infogérance ?
    Méthodologie

    Il y a 2 ans

    Même si les impacts sont difficiles à mesurer, on peut dire qu’il a eu un avant et un après incident OVH. Sans épiloguer sur l'incendie du 5 mars 2021 dernier, un petit vent de panique a soufflé sur les milliers de clients découvrant les problématiques de sécurisation des données. Les réactions à chaud d'une partie des utilisateurs (touchés ou non) montrent la méconnaissance et l'incompréhension qui existent dans les offres d'hébergement. Qui est responsable ? Qui fait quoi ? Comment vérifier mon offre ? Voici quelques clés de compréhension.

  • Améliorer la qualité avec les tests et la review

    Il y a 2 ans

    L’importance des tests et de la revue de code dans le cadre du développement logiciel est parfois négligée ou passée au second plan. Cet article a pour but de montrer que les tests logiciels constituent une étape cruciale qu’il faut considérer avec beaucoup de rigueur.