Déployer Sass de manière efficace

Comme nous l’avons vu précédemment écrire en Sass ne revient pas à écrire du CSS traditionnel, mais ceci n’empêchant pas cela, il nous incombe néanmoins de produire des CSS de qualité, et, de respecter au final, un ensemble de bonnes pratiques.

Je vous invite donc, avant de commencer, à vous rapprocher de Principles of writing consistent, idiomatic CSS.

Ensuite, il est important que nous nous intéressions à quelques approches, et méthodologies, de conception de styles CSS.

Chacune d’entre elles explore une manière d’utiliser les classes et la mutualisation de descriptions.

Il est vrai que de prime abord cela peut aller à l’encontre d’une certaine idée des CSS, et notamment sur l’emploi abusif de classe, autrement connue sous le nom de classite aigüe.

Si vous prenez le temps de les analyser une à une, vous comprendrez vite que quel que soit la nature de votre projet, qu’il s’agisse du maintien d’un site personnel, ou d’un site d’envergure beaucoup plus large, que l’usage unique de sélecteur peut très vite devenir bloquant au niveau des spécificités, et soit relativement lourd à gérer quant à son évolutivité.

OOCSS (Object Oriented CSS)

L’approche objet donnée à OOCSS est une révolution dans l’approche de base des CSS. L’idée est simple, il suffit de penser à bien distinguer la structure et l’apparence, et donc à séparer le contenu du conteneur, à ne pas employer de spécificités fortes, et donc à éviter les ID, de continuellement penser flexibilité avant tout, flexibilité et responsive, et à ne pas hésiter à minimiser l’impact d’un seul module sur un élément et donc, si nécessaire, à multiplier les modules sur un même objet afin de lui appliquer plusieurs objectifs…

…bref favoriser la réutilisation en optant pour la transversalité, et non pas, se limiter, et s’embourber dans une verticalité trop forte. Penser global et non pas unitaire et spécifique.

Un petit exemple… disons que le titre <h1> d’un article soit stylé d’une certaine manière, et que le titre d’un tableau <caption> emploie une large base commune avec le titre précédent, de même pour le titre <h3> d’un module particulier… L’approche CSS pourrait être

  article h1, caption, .module h3 {}

Une révision à la mode OOCSS équivaudrait à implémenter une classe spécifique au rendu de ce titre et à l’ajouter à chacun des éléments directement au niveau du DOM HTML

  .titre_emergeant {}

L’avantage évident reste qu’il ne sera pas nécessaire d’isoler le sélecteur caption, dans le cas où diverses modifications soient nécessaires, et l’évolution sera beaucoup plus souple, y compris si une particularité intervient sur un des éléments, il suffit d’ajouter une classe à cet élément

  .titre_emergeant_particularite    {}

Il est vrai qu’en Sass l’emploi de l’héritage, et/ou du garde place, pourrait laisser penser être une alternative assez souple d’utilisation. Attention, comme nous le verrons plus tard, à ne pas tomber dans cette apparente facilité.

  %titre_emergeant {}
  article h1, caption, .module h3 { @extend %titre_emergeant; }

BEM notation, ou SUIT CSS, méthodes

BEM (Block, Element, Modifier), est une méthodologie, ou une convention, de nommage, et de découpage par Blocs, des éléments de la page. Cela n’apporte rien au niveau purement structurel bien que cela le précise, mais cela permet de rapidement définir un bloc, chacun de ses éléments et de leurs éventuels états.

Contrairement à OOCSS, BEM va plutôt s’intégrer dans une verticalité par module et moins s‘imposer au niveau d’une transversalité inter modules.

Si nous prenons l’exemple d’un module, BEM nous permet de définir diverses classes, en ayant une première classe pour définir le module en lui-même, et, diverses classes qui vont qualifier chacun des éléments le composant, et des classes ‘modifier’ précisant les états, aussi bien du module, que de ses éléments.

Les classes correspondantes aux divers éléments usent d’un unique séparateur tiret, alors que les classes ‘modifier’ emploient un double tiret séparateur.

  .module
  .module-titre, .module-icone, .module-barre, .module-bouton
  .module--inactif, .module-bouton--inactif, module-bouton--on

Approche de base

Nous verrons que cela peut être améliorée en usant également d’un @mixin dédié. Mais déjà, ce genre de nommage peut simplement et rapidement être implémentée au sein de Sass, notamment au travers de l’utilisation du caractère référentiel du parent, &.

  .module    {
    &-titre {}
    &-bouton {
      &--on {}
    }
  }

Approche plus complexe

Depuis Sass 3.4 l’amélioration du sélecteur parent (&) permet en couplant avec la directive @at-root d’user d’une réelle encapsulation. Pour mettre ce point en évidence appuyons-nous sur l’excellent article de Marc mintel – Pushing BEM to the next level with Sass 3.4

BEM et librairies dédiées

BEM ne s’arrête pas à être seulement une convention de nommage, il peut également être complété par des librairies JavaScript notamment i-bem.js, des packages de composants prêts à l’emploi, et quelques autres travaux notamment autour de jQuery.BEM ou d’un package bem-js, ainsi que de jQuery BEMHelpers.

Nous pourrions, si vous le souhaitez, approfondir ces usages au cours d’une nouvelle série.

Suit CSS, une autre alternative

En parrallèle de BEM, nous pourrions également évoquer SUIT CSS (Style tools for UI components), qui est une méthode basée sur le même principe mais qui fait appel à un découpage différent. Nous parlons cette fois ci de Component, de Descendent, de Modifier, de State et d’Utility.

  .Module
  .Module-titre, .Module-icone, .Module-barre, .Module-bouton
  .Module.is-on, .Module.is-off, .Module.is-expanded
  .Module--default, .Module--theme

SMACSS

À la différence des deux premières approches, qui, proposent une méthodologie d’implémentation des CSS, SMACSS (Scalable and Modular Architecture for CSS) redéfinis plutôt une méthodologie de travail, (une grande partie de l’ouvrage est en accès gratuit).

Jonathan Snook livre un grand nombre de clés importantes qui nous permettent une fois rassembler de bien organiser le déploiement des CSS, mais surtout d’en garantir l’évolutivité, et la maintenabilité, de manière très simple.

Ce que nous retiendrons, pour ce qui nous concerne, c’est la déclinaison des CSS en catégories :

• Base
• Layout
• Module
• State
• Theme

Sass, nous permet de décliner, et d’augmenter, autant que faire se peut cette granularité de découpe, du fait qu’au final tout peut être très simplement regroupé au sein d’un seul et unique fichier.

  @import 'base';
  @import 'layout';
  @import 'module';
  @import 'state';
  @import 'theme';

N’oublions pas que SMACSS, propose une architecture qui se veuille évolutive et modulaire pour nos CSS.

ITCSS

ITCSS, (pour Inverted Triangle CSS), propose une répartition par degré de spécificités et de cascades, évitant ainsi des surcharges importantes, et, souvent bloquantes.

• Settings, permet de regrouper l’ensemble des paramétrages aussi bien au niveau du préprocesseur (paramètres, variables et map au niveau global, environnement…), que la définition des typos et autres couleurs utilisées par le thème.
• Tools, contient aussi bien l’ensemble des utilités applicatives (convertisseurs, adaptateurs… encore une fois au niveau général) que les @mixins, %garde-place et autres fonctions nécessaires à l’ensemble des autres couches.
• Generic, propose le premier niveau des CSS avec à la fois la réinitialisation des valeurs par défaut des navigateurs, les propriétés de boites et la première définition des différents layouts propres à chaque périphérique.
• Elements, peut inclure l’ensemble des balises HTML de base, et en ce qui concerne une approche Atomic Design cela permet de définir les particules élémentaires, à savoir les atomes. Attention à ne pas confondre avec les couches d’éléments qui sont assimilés à des objets d’interface et donc font partie d’un organisme plus complexe (molécules et organismes dans une convention Atomic Design), eux-mêmes usant de classes, donc référencés en tant qu’objets de la couche suivante.
• Objects, regroupera l’ensemble des identifications par classe, représentant les objets (en philosophie OOCSS), ou molécules (Atomic Design).
• Components, niveau supérieur des objets, également basés sur des classes, avec une approche de nommage orientée BEM, et principalement constitué d’organisme (Atomic Design), objets complexes (OOCSS) et composants d’interface (UI)
• Trumps, dernier niveau pouvant surpasser tous les précédents et maintenant principalement l’ensemble des utilités, helpers, les états et autres forces du thème. Il ne faut pas craindre l’usage de la propriété !important pour certaines déclarations.

Le nommage des fichiers _partials.scss peut donc utiliser la racine de ces couches, comme par exemple :

  _settings.colors.scss
  _settings.sass.scss
  _tools.mixing.scss
  etc…

N’hésitez pas à vous rapprocher de ce github qui propose une bonne arborescence de départ https://github.com/mehmetkose/skeleton-itcss.

Atomic Design

Dès 2013, Brad Frost, a commencé de publier un travail sur une méthodologie particulière, et proche de la constitution atomique des éléments. Il a d’ailleurs donner ce nom à son étude Atomic Web Design, rapidement complétée et étoffée par son livre Atomic Design.

À l’instar de BEM et SUIT CSS, Atomic Web Design propose une découpe partant de l’atome, la molécule, l’organisme, le modèle et la page.

La métaphore est tout à fait appropriée, et si on remplace avec des éléments de contenus, on se retrouve avec :

• Un label, un bouton ou un titre (dans le rôle des atomes),
• Un composant d’outil de recherche (du côté de la molécule),
• Une barre de menus assez complète (au niveau de l’organisme),
• Un gabarit de remplissage (pour incarner le modèle, et, rassembler l’ensemble des organismes)
• Et enfin, une page de site (étant une instance issue du gabarit précédent).

Pour appuyer ce principe de mise en place, et de construction, Create atomic design systems with Pattern Lab propose un ensemble d’outils (Node et PHP).

Cette approche peut nous permettre d’englober l’ensemble des méthodes précédentes, à savoir OOCSS, SMACSS, ITCSS et BEM.

On peut donc avoir recours à des partials,

  @import 'atomic';
  @import 'molecule';
  @import 'organism';
  @import 'template';
  @import 'page';

Utiliser une convention de nommage, orientée BEM, ou SUIT CSS. L’idée restera de définir une réelle arborescence BEM, en lieu et place de l’arborescence classique du DOM.

  .module{}
  .module-titre{}
  .module-bouton{}
  .module-bouton--on{}

Et si on souhaite aller plus loin en couplant par exemple BEM et ITCSS cela donne BEMIT et il y a un excellent article sur le sujet, BEMIT: Taking the BEM Naming Convention a Step Further.

Conclusions

Au travers de ces diverses méthodologies, nous avons pu voir que l’emploi de classe devient donc une solution, certes nature à débat chez les plus puristes d’entre nous, mais ô combien adapté au maintien d’une grande souplesse dans la gestion quotidienne de nos projets.

L’approche modulaire, et la découpe en plusieurs fichiers _partials.scss apporte rapidement une grande souplesse au maintien des sites.

En conclusion, nous pourrons retenir trois maîtres mots,

• Modules, objet, réutilisation, regroupement
• Nommage, catégories, utilités, définitions
• Découpe, fichiers, spécificités, granularité

Et cela est bien sur ces trois points qu’il va nous falloir axer notre utilisation des préprocesseurs.