Architecture CSS avec ITCSS & InuitCSS

Maintenance CSS d’un design custom

Comment bien organiser son CSS ? Question que se pose régulièrement l’intégrateur souhaitant rendre son projet maintenable et performant. La gestion du CSS peut rapidement devenir un casse tête lors du développement de grosses applications. Retour sur 6 années de travail la tête dans le CSS…


2012 : premiers pas…

2012 - début d’aventure avec le HTML et CSS

2012 marque l’année où j’appréhende pour la première fois l’intégration web. Dans le cadre de mes études en design graphique, une matière est dédiée aux nouvelles technologies. C’est un véritable coup de foudre pour le webdesign !

2013 : Sass, Compass, Bootstrap, Foundation & cie…

Sass, Compass, Bootstrap, Foundation

Après une année, je m’intéresse aux outils permettant d’aller plus loin avec le CSS. Tout d’abord les pré-processeurs. Je commence à utiliser Sass et découvre petit à petit comment organiser mon code pour le maintenir plus efficacement. Notamment grâce aux variables, mixins et imbrication des règles de style. Compass est d’ailleurs une librairie de mixins Sass très utilisée à ce moment. Mon code se structure et j’ai la possibilité de le découper en différents fichiers. C’est un premier pas vers une meilleure organisation et un gain de productivité. Cependant cela reste basique et il manque la présence de classes utilitaires et un système de grille responsive.

Suite à cela, je me penche naturellement sur des solutions type Bootstrap et Foundation qui ont la promesse de vous offrir un ensemble d’outils prêt à l’emploi. Des classes utilitaires, une grille responsive, la possibilité d’utiliser Sass, et même un ensemble de composants UI tous prêts à l’emploi. Génial !

Sauf que la plupart des projets sur lesquels je travaille ont une charte graphique bien précise avec une UI personnalisée. Je me retrouve pour la plupart du temps à utiliser les classes utilitaires, la grille, et me battre contre les composants UI existants pour les styler comme je le souhaite. Une belle bataille de surcharge voit alors le jour, et la moitié voire les deux tiers du framework n’est pas utilisé car j’ai du implémenter des solutions sûr-mesure. C’est dommage de charger un tas de styles et javascript sur son site si on ne s’en sert pas non ? Je trouve ces outils pratiques pour réaliser des poc/prototypes.

2014 : Réflexion et recherches

Réfléchir à une manière efficace, maintenable et sûr-mesure d’implémenter du CSS devient alors primordiale. Pour cela, faire de la veille (beaucoup de veille ?) est évidemment une bonne chose. Mais il faut aussi comprendre le language en lui même et analyser ses défauts si on souhaite les contrer. De plus, il est intéressant de prendre en compte les problématiques du travail en équipe. La gestion humaine est un facteur important dans la réussite des projets. La réflexion est donc plus large que simplement relever les défauts du CSS, il faut comprendre les défauts des développeurs dans leur manière d’écrire du CSS.

Quelques défauts du CSS :
  • Cascade et héritage
  • Dépendance sur l’ordre d’inclusion dans le code
  • Global namespace
  • Spécificité
Quelques défauts du développeur :
  • Manque de documentation dans nos projets
  • Manque de structuration du code
  • Manque de rigueur dans les conventions collectives

Vous vous rappelez quand je parlai d’une bataille de surcharges un peu plus haut ? Et bien c’est sans doute le point essentiel à garder en tête pour rechercher une bonne façon d’architecturer son CSS. Le but étant d’éviter cela :

csswizardry — Harry Roberts — Managing CSS Projects with ITCSS

Des surcharges de vos styles dans tous les sens. Ce qui devient rapidement un casse tête à maintenir.

Avec tout cela en tête, la recherche de nouveaux outils, de nouvelles techniques, et nouvelles conventions peut (enfin) commencer.

BEM

BEM est une convention de nommage. Il s’agit ici de se mettre d’accord sur une rigueur logique et commune dans la définition des noms de class CSS :

.block {}
.block__element {}
.block — modifier {}
.block__element — modifier {}

Block représente le nom de l’élément parent ou du composant. Element correspond à une élément enfant du Block. Et Modifier sert a styler un état différent d’un Block ou Element. Exemple avec un composant avatar :

.avatar représente le block
.avatar__img représente un élément du block
.avatar__img — rounded représente un modifier de l’élément

Cette technique à plusieurs avantages :

  • Logique commune
  • Scope : éviter les surcharges indésirables et se faire surprendre par la cascade CSS
  • Lisibilité du code

OOCSS

OOCSS propose une approche orientée objet pour l’organisation du CSS. Il s’agit de séparer dans des classes différentes les styles de structure et les styles d’UI (entendre esthétique). En organisant vos styles de cette façon vous réduisez considérablement le nombre de lignes de votre CSS en créant des classes réutilisables. Exemple avec un composant button :

```
.button {
 width: 150px;
 height: 50px;
}

.button — small {
 width: 100px;
 height: 25px;
}

.button — primary {
 background: #FFF;
 color: #000;
}

.button — secondary {
 background: #000;
 color: #FFF;
}
```

SMACSS

SMACSS est une architecture CSS qui permet de découper son code en plusieurs répertoires et nous permet de maîtriser l’ordre d’inclusion des styles.

  • Base : éléments de base de votre HTML
  • Layout : éléments du layout (header, footer…)
  • Module : composants de votre application
  • State : états différents de certains éléments
  • Theme : thèmes différents de l’application

csswizardry-grids

L’utilisation d’une grille est un outil puissant et quasiment indispensable pour monter des pages HTML efficacement. Harry Roberts (csswizardry) propose une grille responsive et mobile first. Grille qui aujourd’hui a évolué au sein du framework InuitCSS que nous verrons un peu plus bas.

C’est à ce moment la que je découvre l’ensemble des travaux d’Harry Roberts à travers son site et ses articles sur le CSS. Outre la grille, il propose le développement d’un ensemble de modules formant le framework InuitCSS.

2015 : ITCSS & InuitCSS

Au fil de mes lectures et tests des solutions de csswizardy, je comprend vite qu’il planche depuis plusieurs années sur les mêmes problématiques : la maintenance CSS de gros projets web et ses performances.

On retrouve dans InuitCSS l’utilisation du pré-processeur Sass, une approche OOCSS et les conventions de nommages BEM. Une aubaine puisque ce sont des technos/techniques que j’appréhende depuis une année maintenant. Et surtout, l’argument phare, les modules sont entièrement dénués d’UI. C’est tout simplement un ensemble d’objets et d’utilitaires permettant une gestion flexible et réutilisable de son CSS.

En prime, une réflexion sur l’architecture globale est proposée au travers de ITCSS.

ITCSS

Retrouvez ici une présentation de l’architecture par Harry Roberts.

ITCSS = Inverted Triangle CSS

ITCSS permet de découper de manière logique son code CSS, et de maîtriser son ordre d’inclusion. Ce n’est pas un framework, mais plutôt un état d’esprit. Cette architecture peut-être utilisée avec toutes technos et n’a aucune dépendance. C’est complètement indépendant d’InuitCSS.

Découpage du code en 7 niveaux :

Illustration : Lubos Kmetko — ITCSS: SCALABLE AND MAINTAINABLE CSS ARCHITECTURE

Le principe est d’agencer et inclure les règles de styles des plus génériques vers les plus explicites, des moins spécifiques aux plus spécifiques :

Illustration : Lubos Kmetko — ITCSS: SCALABLE AND MAINTAINABLE CSS ARCHITECTURE

Tout cela dans le but, entre autre, d’éviter les problèmes de spécificité évoqués plus haut. Un ordre d’inclusion non maîtrisé peut entrainer un graphe comme celui-ci :

csswizardry — Harry Roberts — Managing CSS Projects with ITCSS

On se retrouve rapidement avec des pointes de spécificité tout le long du fichier CSS, probablement des surcharges non voulues et donc une maintenance et compréhension des comportements difficile. L’objectif d’ITCSS est d’arriver plutôt à un graphe comme celui-ci :

csswizardry — Harry Roberts — Managing CSS Projects with ITCSS

Une augmentation progressive de la spécificité de nos règles de styles. Souvenez-vous “des moins spécifiques aux plus spécifiques” de tout à l’heure.

Dans notre code, on retrouve donc un fichier Sass d’entrée avec l’import de nos dossiers dans le bon ordre :

Vous pouvez retrouver sur mon site des détails sur chacun des dossiers de l’architecture : https://www.kevinbizien.com/design-system/css-architecture

BEM + ITCSS = BEMIT

En adéquation avec l’architecture, il est utile d’étendre la convention BEM pour la greffer à ITCSS. Il s’agit de préfixer les noms de classes avec la première lettre du type de la classe :

  • .o-block__element — modifier pour les objets
  • .c-block__element — modifier pour les composants
  • .u-block__element — modifier pour les utilitaires
  • .js-[name] pour les hooks javascript (pas de styles)

Pour en savoir davantage : https://www.kevinbizien.com/design-system/css-architecture/conventions

InuitCSS

InuitCSS, initié par Harry Roberts, est un framework CSS qui a la particularité de ne prendre aucun parti UI. C’est un ensemble de styles suivant les bonnes pratiques, proposant des mixins Sass et des classes objets/utilitaires sur le modèle OOCSS. Parmi les classes objets se trouve le système de grille par exemple. Puisque l’idée est de construire son propre design, InuitCSS ne propose aucun composants. À nous d’intégrer nos composants UI à l’aide des outils à disposition.

Pour résumer, InuitCSS est un ensemble de config, mixins, resets, objets et classes utilitaires. On peut y retrouver entre autre :

  • Mixin responsive avec Sass-mq
  • Mixin pour la gestion des font-size et line-height
  • Bonne pratique de styles génériques
    - box-sizing
    - normalize
    - reset
  • Objet media
  • Objet layout (grille)
  • Utilities margin / padding / width
  • Extensible selon les besoins en créant sa propre bibliothèque de settings, tools, objects, components et utilities.
  • … et bien d’autres outils encore

Pour en savoir davantage : https://www.kevinbizien.com/design-system/css-architecture/inuit-css

Depuis 2016

Création d’un compte et repo GitHub dédié → https://github.com/inuitcss

  • Team “core” de 5 personnes
  • 17 contributeurs à ce jour
  • Première release hors bêta (v6.0.0) commit le 26 février 2018 !
  • Évolution de la base de code en un seul module npm à installer
  • Maintien de l’inclusion flexible des styles nécessaires pour son projet
  • Existance d’un slack pour la communauté : https://herzinger.typeform.com/to/h6e3Km

Slides de la conférence

Retrouvez les slides de ma conférence du cssflip sur le sujet :

https://speakerdeck.com/kbizien/architecture-css-avec-itcss-et-inuitcss

N’hésitez pas à me pinger sur twitter pour toutes questions ou échanges sur le sujet :) @kbizien.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.