Un point de vue sur les mixins Sass / LESS

Plus je lis d’articles techniques présentant des mixins Sass ou LESS, plus dubitatif je suis au sujet de ces fonctionnalités. J’ai parcouru récemment des billets faisant l’apologie de certains mixins censés faciliter la vie au point qu’il paraît difficile de concevoir comment on pouvait bien procéder avant. Et pourtant, je suis convaincu que les mixins sont plus néfastes que bénéfiques à long terme.

À quoi sert un mixin ?

Un mixin est une fonctionnalité inhérente à un préprocesseur (LESS, Sass, Stylus) permettant à des bouts de code d’être inclus (et réutilisés) dans d’autres bouts de codes. Il est même possible d’embarquer des arguments et d’en faire une véritable fonction.

Les mixins procurent au-moins deux avantages indéniables 
– allègement du code (car les mixins sont réutilisables)
– extension des possibilités natives de CSS

Quelques exemples de mixins

Voici mes trois dernières lectures sur ce sujet :
DRY-ing Out Your Sass Mixins
REM to PX Browser Function with Sass
Handy Sass Mixins

Au sein des deux articles sus-cités, j’ai repéré les quelques exemples de mixins suivants :

.header  {
    @include rempx(margin, 1rem 2rem);
}
.main-header {
    margin:u(1rem 2rem 20px 3rem);
    padding-bottom:u(0.25rem);
    font-size:u(0.875rem);
}
.foo {
    color: map-get($properties, color);
}
div.logo {
   background: url("logo.png") no-repeat;
   @include image-2x("logo2x.png", 100px, 25px);
 }
.abs {
  @include abs-pos(10px, 10px, 5px, 15px);
}

Une question de maintenabilité

Les mixins sont prônés pour leur apport dans la maintenabilité d’un projet (cf. avantages cités précédemment).

Le fait est que les mixins posent un problème de maintenabilité et de pérennité. Du fait même de leur nature.

Plongeons-nous dans un vrai projet, avec plusieurs intervenants sur le code, voire des nouveaux venus et des stagiaires qui ne vont rester que deux mois…

Alors tu te souviens, il faut que tu écrives @include font-size:u(0.875rem);, ou encore @include abs-pos(10px, 10px, 5px, 15px); et puis pour les retina, n’oublie pas de rajouter un @include image-2x("logo2x.png", 100px, 25px);, et sinon pour tes polices en rem c’est @include rempx(margin, 1rem 2rem); qu’il faut écrire, hein.

La question n’est pas de savoir si la syntaxe des ces mixins est pertinente ou non. Elle est plus simple que cela : quelle que soit la syntaxe, elle ne repose sur aucun standard établi.

CSS est un langage standardisé (W3C), avec des règles et une syntaxe que l’on peut obtenir, vérifier et valider via un organisme faisant foi.

Alors oui, un mixin est une bénédiction pour alléger le code, mais il demeure un « hack » dans tous les sens du terme :
– sa syntaxe est interne à une équipe, à un projet, à… une personne.
– son nommage est empirique, peu pérenne, voire « aléatoire » (?)
– il nécessite un apprentissage non nul, une documentation (qui n’existe souvent pas, ou qui n’est pas mise à jour)
– le risque d’erreur dans une syntaxe non standard est élevé (il y a 10 façons différentes de se tromper dans un mixin aussi simple que @include font-size:u(0.875rem);)
– etc.

Bon maintenant, vous pouvez taper 🙂

Une réflexion au sujet de « Un point de vue sur les mixins Sass / LESS »

  1. Je comprends ton point de vue sur la question, personnellement je découvre le métier du web depuis 2 mois (début de ma formation) et il est vrai que les @mixin m’ont tout de suite plu.
    Ma question est la suivant : La W3C a mis quelques années à se mettre en place j’imagine, pourquoi n’en serait-il pas de même pour les pré-pros ?
    Je pense que c’est à force de faire murir ce genre de fonctions que des standards ou autres conventions en découleront… Non ? Il y’a déjà bon nombres d’ouvrages sur le sujets comme celui de kaelig qui sont vraiment intéressants… Mais je sais que tu en as déjà connaissance 😛

Les commentaires sont fermés.