Comment répartir ses fichiers partials sous Sass

En s’appuyant sur les diverses approches définies durant les premiers articles, nous allons pouvoir mettre en place un flux de travail, et, en tirer quelques directives principales

Entrevoir les possibilités de SassScript

Le préprocesseur Sass, au travers de son langage SassScript, apporte un grand nombre de souplesse d’écriture digne d’un réel langage de programmation.

L’utilisation de variables, l’encapsulation des déclarations simplifiant l’écriture des groupements, l’usage de fichiers importés qui ne seront pas compilés, assouplissent grandement la génération des styles.

Par ailleurs, la mise en place de Mixins et l’utilisation de fonctions natives provenant de librairies annexes, l’extension avec l’héritage et l’emploi de fonction garde place, la mise en place d’argument et passage de paramètres permettent de mutualiser un grand nombre de ressources et de centraliser ainsi le cœur logique de notre approche.

L’usage d’opérateurs algébriques et booléens, l’usage de nombreuses fonctions natives sur les chaînes de caractères, les couleurs, les listes, l’emploi d’@Rules et de directives sans oublier les classiques expressions qu’elles soient de boucle, de comptage ou encore de conditions… donnent la souplesse attendue afin d’optimiser la personnalisation des pages et des contenus.

Bref nous avons là toutes les souplesses attendues pour développer nos CSS dans des conditions optimales de développement, de maintien et d’évolution.

Sass sous WordPress

Autre point à ne pas négliger, tient au fait que le CSS produit devra être optimisé, et donc, concaténé, compressé et minimisé. Bien entendu cela sous-entend, entre autre, que l’ensemble des commentaires, qu’il est conseillé d’avoir en abondance, devront être retirés.

De ce fait, si vous travaillez avec WordPress, et afin de préserver le commentaire d’introduction obligatoire pour son identification, pensez à employer le point d’exclamation juste après l’ouverture des commentaires.

  /*!
  Theme Name: Thème Enfant
  Template: slug_theme_parent
  */

Réellement employer sass

L’idée de cette approche est de prendre conscience qu’utiliser un outil comme Sass, ne se résume pas à l’emploi de variables, de fonctions, de directives ou toutes autres expressions de contrôle, mais bien l’esprit et la méthode dont ceux-ci vont être utilisés et orchestrés.

Fort des diverses méthodes vues jusqu’à présent, nous allons pouvoir les assembler et mettre en place

• Une découpe purement objet basée sur les besoins de la charte graphique,
• Définir un concept de nommage répondant à un cahier des charges mis en place en amont
• Combiner tout cela avec une découpe répondant à une granularité très fine distinguant d’une part les couches d’abstractions nécessaires (base, layout, module, états et thème) et d’autres part un Atomic Design qualifiant les éléments, les molécules et les organismes.
• Prévoir un ensemble de fichier qui puissent faire office de la gestion pure, et indépendante, du thème
• Ajouter la prise en compte d’utilités, aussi bien de débogage que d’aide à la production

Maintenant, il ne suffit pas alors d’écrire, ou d’employer Sass, comme nous le ferions pour écrire du CSS en mode traditionnel.

Bien au contraire, et c’est là une des principales erreurs classiques des débutants en ce domaine qui se focalise uniquement sur les variables et les @mixins. User d’un préprocesseur tel que Sass, c’est également entrer dans une logique non linéaire, orientée objet et tirant partie au mieux des possibilités qui nous sont offertes.

C’est pour cela que l’article What is Sass –  Introduction and présentation n’aborde ni Sass, ni SassScript, au niveau du code, mais simplement sous forme d’une introduction de présentation large, qui explore les divers outils à disposition et les diverses possibilités d’installation.

Donc maintenant, au travers de ce présent article, intéressons-nous, d’une manière plus verticale, à l’utilisation et au déploiement de Sass en production, en évitant de tomber dans une banale utilisation de variables, qui nous détournerait de la réelle puissance de Sass.

Afin de pouvoir mettre en application un flux de travail avec un préprocesseur, il est très important de prendre le temps de bien étudier le prototype (ou la maquette du site) sur laquelle nous devons travailler.

Un grand nombre d’informations vont pouvoir ainsi être dégagées, telles que l’arborescence DOM, l’arborescence BEM et enfin l’arborescence des _partials.

En ce qui concerne l’aspect OOCSS et Atomic Design, il est également important de pouvoir distinguer l’ensemble des mutualisations que nous allons devoir gérer (fonds de blocs, gestion des éléments récurrents, patterns, composants, formulaires, médias, …)

Intégrer et imbriquer des fichiers _partials

Sass propose la possibilité de travailler avec des fichiers _partials, ces fichiers ont la particularité d’être importés au moment de la compilation, mais de ne pas produire de fichiers issus de ces _partials, qui d’ailleurs seraient inutiles et surtout encombrant.

Pour définir et distinguer un fichier partial, il suffit d’utiliser le caractère underscore, ou souligné (_), au début de son nom. Lors de l’importation, ni le underscore, ni l’extension ne sont nécessaire. Le compilateur comprendra qu’il a à faire à un fichier partials.

Concrètement, les fichiers suivant, à savoir d’une part le fichier styles.scss contenant

@import ‘autre’;

Et d’autre part, le fichier _autre.scss contenant

.module{}

Produiront, lors de la compilation le seul et unique fichier styles.css qui contiendra alors :

.module{}

Il est possible d’utiliser autant de fichier _partials que nécessaires, et les fichiers _partials peuvent eux-mêmes faire référence à d’autres fichiers _partials. Attention, à ce niveau, à respecter une certaine cohérence dans l’ordre des fichiers importés.

Au même stade que nous avions mis en place une arborescence BEM, nous pouvons complétement parler d’arborescence de _partials, et ce sans soucis de granularité du fait que lors de la compilation, nous allons obtenir un seul et unique document CSS compressé, et, minimisé.

À titre d’exemple, voici une bribe d’arborescence partials qui peut être envisagé et décliné.

styles.scss
  _base.scss
  _variables.scss
  _utilites.scss
  _layout.scss
  _modules.scss

Il est également possible de s’appuyer sur le framework inuitcss qui propose un travail de départ assez intéressant. N’hésitez pas à créer votre branche afin d’adapter le découpage à vos besoins.

Mise en place des _partials de base

Comme nous l’avions vu dans un article précédent, il vous est donc possible de récupérer une arborescence préparée https://github.com/mehmetkose/skeleton-itcss, ou encore vous inspirer de celle proposée sur l’article https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/.

En ce qui me concerne, et depuis plusieurs projets qui concernent aussi bien des sites que des applications web, je travaille avec une approche un tantinet différente.

D’une part, en nombre de couches, et, d’autres part en terme de groupage. Il est vrai que je n’ai découvert ITCSS que bien plus tard, et donc si on reprend le principe du triangle inversé, par contre sous forme de carré, vu que dans ce cas l’usage des ID est autorisé, notamment au niveau des dialogs, UIs, comps et pages, voici la représentation que cela peut donner.

• Sass, 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és par le thème, mais également les divers @mixins, %garde-place, couche de débogage, réinitialisation de CSS, gestion globale des sprites, … bien sur tout au niveau global.Par exemple des variables propres à certaines balises, se retrouveront aux niveaux de ces balises en question.
• Blocs, encadre les principaux blocs de la page (<header>, <footer>, <aside>, <main>…), en faisant la distinction entre les classes .main et .content, voire .container. La présence d’un bloc spécial comme _blocs-layout.scss, pouvant lui-même être décliné (_blocs-layout-tablet, _blocs-layout-phone…), qui permet de gérer la disposition en fonction des devices, ou encore _blocs-print.scss qui gère la diffusion des blocs vers l’impression.
• Tags, comme son nom l’indique regroupe les sélecteurs de bas niveau en les regroupant par familles autant que faire se peut, liens, listes, médias, typo… et en prenant soin d’ajouter un _tags-singles.scss qui permet de regrouper tous type de singlette type <hr>, <br> et autres éléments de ce type et un _tags-blocs.scss (pour les <div>, <span>).
• Comps, est une première distinction de composants à la frontière des éléments d’interface, et concerne plus particulièrement des éléments HTML distincts, comme les <table>, les <figure>, les <form> (au niveau form et fieldset, concrètement les fiches elles-mêmes). Cette couche peut également inclure quelques éléments formatés propres au site, ou à l’application, comme les notes, les encadrés, les informations diverses, les fiches spécifiques… etc (sous forme de classes, .notes, .frames, .infos, .sheets…)
• UIs, second élément de composants moins orientés contenu, mais plus considérés comme éléments d’interaction utilisateur récurant au site ou à l’application, tels que le fil d’Ariane, les barres de navigation, les boites de recherche, les boutons d’interaction, les éléments et groupes de formulaires… etc (également sous forme de classes .breadcrumb, .nav, .search, .buttons, … ou d’élément HTML comme <input>, <select>, <textarea>…).
• Dialogs, attention à ne pas confondre avec les composants d’interface, nous ne parlons là que de boite de dialogue qui sont généralement flottantes, modales ou non. Ce type d’objets est récurrent, et nombreux, dans les applications web, et avoir un document .scss par dialogue n’est pas superflus.
• Pages, ce groupe de codage s’aligne bien avec le concept de CSS signatures introduit par Eric Meyer, en 2002, et qui permet de distinguer la nature de la page (template ou non). De plus, au niveau de la page, le concept de thème, et de peau, peut complètement prendre son sens.
• Accessibility, cette couche est purement dédiée à la prise en charge de l’accessibilité, donc d’éventuelles feuilles CSS alternatives, (_accessibility-audio.scss, _accessibility-aria.scss , _accessibility-print.scss …), peuvent également y être déclinées.

Vous trouverez, si vous le souhaitez, un ensemble de fichiers, en tant que base de départ, sur le github SCSS-Bare-partials.