Organisation et convention de nommage CSS

Organisation et convention de nommage CSS

Tech web
Cloche d'abonnement aux notifications | |
  • Recevoir les notifications

Un problème récurrent dans le développement frontend est d’organiser et nommer les classes CSS d’une façon logique, qui fonctionne pour toute la durée de vie du projet. Ainsi, lorsqu’un collègue (ou vous-même dans quelques mois) reprendra votre travail, il s’y retrouvera facilement.

Dans cet article, nous allons passer en revue 3 méthodes très répandues pour organiser ses feuilles de styles et nommer les différents éléments qui s’y trouvent.

SMACSS

Pendant longtemps, j’ai essayé de m’inspirer des concepts décrits dans la méthode SMACSS (Scalable and Modular Architecture for CSS). Cette méthode ne définit pas seulement la manière de nommer les classes, mais aussi la façon de hiérarchiser les fichiers. Voici un petit résumé des principes de cette méthode :

SMACSS répartit les règles CSS en 5 catégories :

  • Base
  • Layout
  • Module
  • State
  • Theme

 

Les exemples partent du principe que vous utilisez le préprocesseur SASS et les fichiers sont donc des ".scss" en lieu et place des ".css" et les classes pourront s’imbriquer les unes dans les autres.

Le fichier base.scss définit le style des éléments basiques du site (html, body, form, input, etc). Cette catégorie ne doit pas contenir de classe, et pas non plus d’identifiant (ID).

layout.scss gère le style des différentes sections du site (aussi valable pour les balises header, footer, aside, etc). Une section peut contenir plusieurs modules. Si vous voulez utiliser des identifiants, c’est ici, et nulle part ailleurs. Pour rappel, chaque élément ne peut avoir qu’un seul ID, et les ID ne doivent être utilisés que pour des éléments qui sont uniques et qui n’apparaissent qu’une seule fois dans la page.

Un dossier Modules contient les partie réutilisables du design. Faites un fichier css par élément réutilisable (donc par module). Attention, ne tomber pas dans le piège de styliser ces éléments en fonction de l’endroit où ils se trouvent ! Le but des modules est de pouvoir les inclure n’importe où dans votre site et que le style fonctionne.

Les règles d’état ou "State rules" vont servir à définir le style des modules ou des sections lorsqu’ils sont dans un état particulier (par exemple un lien au survol de la souris). Faites donc un fichier state.scss.

Enfin, les règles de Thème ("Theme Rules") vont servir à définir le style des modules ou des sections pour un thème différent. La plupart des sites n’ont qu’un seul thème, mais parfois ce n’est pas le cas.

Attention : n’appliquez pas cette méthode en important chacun des fichiers séparément dans votre HTML. Vous feriez beaucoup trop de requêtes pour rien. Assurez-vous de fusionner les fichiers d’une manière ou d’une autre avant de les importer, en travaillant avec un préprocesseur comme SASS par exemple.

Convention de nommage spécifiques à SMACSS

Le fait de trier les règles CSS par catégorie facilite déjà beaucoup l’organisation et permet de retrouver facilement ce qui nous intéresse. Mais le créateur de SMACSS propose en plus d’y intégrer quelques conventions de nommage.

Voici quelques exemples :

Pour ce qui concerne les "layouts" (pour rappel, les sections du site), vous pourrez ajouter un "l-" devant le nom de la classe afin que l’on sache immédiatement que cela concerne un layout. 

.l-container {
}

Dans le cas des "modules", il est recommandé d’utiliser des noms de classes qui partagent la même racine que le module lui-même :

.btn {
    .btn-text {
    }

    .btn-search {
    }
}

Pour les "states", ajoutez "is-" devant la classe :

.btn {
    background-color: gray;

    .is-enabled {
        background-color: green;
    }
} 

Sans surprise, vous pourrez ajouter le préfixe "t-" devant les classes en lien avec un "theme" spécifique :

.t-sky {
}

.t-dark {
}

BEM

La méthode BEM repose sur trois éléments ; Block (bloc), Element (element), Modifier (modificateur). 

Un bloc est une entité indépendante qui doit pouvoir être déplacée sans que cela n’altère son apparence ou son fonctionnement. Un bloc peut aussi contenir d’autres blocs. Une interface peut englober plusieurs instances du même bloc (par exemple une liste d’articles contient plusieurs fois le bloc représentant un article). Voici quelques exemples de blocs :

utilisation BEM

[source : bem.info]

Un élément est une partie d’un bloc qui ne peut pas être utilisée en dehors de celui-ci.

 

élément

[source : bem.info]

Par exemple, un onglet de menu ne peut pas être utilisé en dehors d’un bloc menu. C’est donc un élément.

Un modificateur définit l'apparence et le comportement d’un bloc ou d’un élément. Un même bloc peut avoir avoir un style différent en fonction du modificateur qui lui est appliqué.

 

réutilisation bloc

[source : bem.info]

 

Sur l’image ci-dessus, on constate que le même bloc est utilisé pour le menu principal et dans le footer, mais stylisé de manière différente grâce au modificateur.

Convention de nommage spécifique à BEM

Les règles de bases pour le nommage des classes avec BEM sont les suivantes :

nom-block__nom_element_nom_modificateur_valeur_modificateur
  • les noms sont écrits en caractères latins et en minuscule
  • les mots sont séparés avec un tiret (-)
  • les noms des blocs définissent le “namespace” pour ses éléments et modificateurs -> traduction : utilisez le nom du bloc en guise de préfixe pour les éléments et les modificateurs de celui-ci
  • le nom d’un élément est séparé du bloc par un double underscore (__)
  • le nom d’un modificateur est séparé du nom du bloc ou de l’élément par un simple underscore (_)
  • la valeur du modificateur est séparée du modificateur par un simple underscore (_)
  • pour les modificateurs booléens, la valeur n’est pas incluse dans le nom

Le nommage des blocs n’est pas sorcier. Il s’agit de choisir simplement un nom en rapport avec la fonction du bloc comme ceci :

<div class="menu">
</div>

Si on ajoute un élément à ce bloc, la classe de ce dernier nommé "bloc__element"  (2 underscores) :

<div class="menu">
    <span class="menu__item"></span>
</div>

Et si l’on ajoute un modificateur au bloc, on ajoute la classe "bloc_modificateur"  (1 seul underscore) :

<div class="menu menu_hidden">
</div>

Un modificateur peut aussi s’appliquer sur un élément comme ceci :

<div class="menu">
    <span class="menu__item menu__item_visible menu__item_type_radio"></span>
</div>

En termes de CSS, la méthode BEM recommande d’éviter d’imbriquer les différentes classes, justement pour que les blocs puissent être déplacés en conservant leurs styles. De ce fait, il est un peu moins avantageux d’utiliser un préprocesseur.

Les seules cascades que vous ferez seront utilisées pour définir le style particulier du modificateur d’un bloc. Par exemple sur le HTML suivant :

<div class="login-form">
    <button class="login-form__btn login-form__btn_theme_dark">Login</button>
</div>

CSS :

.login-form__btn .login-form__btn_theme_dark {
    background-color: grey;
}

Une dernière chose, on évite d’utiliser les ID avec BEM. Cette méthode recommande de les réserver pour le Javascript.

OOCSS

Cette méthode est la plus récente des trois. Elle aborde le problème de façon assez différente des autres. En effet, le principe est d’analyser le design du site afin d’y repérer les éléments visuels qui se répètent et de définir ainsi des classes réutilisables. 

De ce fait, il peut être judicieux de discuter avec le webdesigner durant l’élaboration des maquettes, afin de s’assurer que les éléments soient réutilisés ou déclinés de façon optimale lorsque c’est possible.

OOCSS (Oriented Object CSS) repose sur deux principes majeurs :

1. établir une division claire entre la structure et l’apparence

L’idée de ce principe est de favoriser l’utilisation de classes, plutôt que les noms des balises (ou les ID).

<a class="small-btn"></a>
<a class="large-btn"></a>

Comme certains éléments seront identiques pour ces deux boutons, on peut les rassembler dans une classe "btn".

<a class="btn small-btn"></a>
<a class="btn large-btn"></a>

2. séparer le conteneur et le contenu

Pour faire cette séparation, il faut éviter de faire des cascades pour ne pas rendre le style d’un élément dépendant du conteneur dans lequel il se trouve, et ainsi pouvoir utiliser cet élément ailleurs comme bon nous semble.

OOCSS + SASS

Si vous utilisez SASS avec OOCSS, la fonctionnalité @extend pourra vous simplifier la vie.

Admettons que vous ayiez le code suivant :

%btn {
    width: 200px;
    padding: 1em;
}


.btn {
    &.share {
        @extend %button
        background: white;
    }
    &.like {
        @extend %button
        background: blue;
    }
}

Le signe "&" équivaut à écrire ".class-1.class-2 {}". Dans notre exemple, ce serait ".btn.share {}".

"@extend" permet, comme son nom l’indique, d’étendre un style CSS. Dans notre exemple, si un élément HTML possède une classe "btn" ET une classe "share", le style appliqué sera celui de "%btn" ET "&share".

Le signe "%" permet de créer un style qui ne peut pas s’appliquer du moment qu’il n’est pas utilisé avec un "@extend".

Conclusion

J’en conviens, il est difficile de choisir une de ces 3 méthodes et d'appliquer celle que l'on a sélectionnée à la lettre en étant parfaitement satisfait. Si vous êtes adepte de la hiérarchisation des fichiers, SMACSS devrait vous inspirer. Si vous préférez une structure plus libre mais une nomenclature plus stricte, ce sera plutôt BEM. Si vous souhaitez vous contenter d’une méthode moins contraignante et que les designs de vos sites comportent de nombreux éléments redondants, vous choisirez sans doutes OOCSS. Bien sûr, rien ne vous empêche de mélanger plusieurs méthodes. 

Quelques bonnes pratiques se rejoignent dans ces différentes méthodes. Si vous ne devez retenir qu’une chose de cet article, ce devrait être celles-ci :

  • éviter les cascades dans le CSS
  • ne pas appliquer de style en se basant sur l’emplacement d’un élément
  • préférer l’utilisation des classes aux IDs

À cela, nous pouvons ajouter ces quelques conseils :

  • toujours garder à l’esprit que votre code doit pouvoir être repris par un autre développeur
  • choisir des noms de classes courts et descriptifs dans la mesure du possible

 

Sources

Catégories :
Tech web

Tags :
CSS HTML

Vous avez aimé cet article ? Suivez-nous sur Facebook pour ne rien manquer !