Quand Sass ne rend plus service

Avant de débuter la chasse aux sorcières, rappelons que Sass n’est jamais qu’un outil, et très performant de surcroît. Aussi n’est-il pas à blâmer pour les éventuels dommages et soucis de génération de CSS rencontrés au cours de vos projets. Comme on le dit si bien, « Un mauvais ouvrier blâme toujours ses outils », sous-entendu ce n’est pas l’outil mais l’usage que l’on en fait.

Tâchez donc de comprendre quand l’outil rend service, et quand il se trouve ne pas être approprié. C’est précisément de ces cas de figure dont nous allons parler dans l’article d’aujourd’hui, notamment :

• de l’utilisation de Sass pour les préfixes constructeurs ;
• de l’utilisation de Sass pour la conversion de px à rem ;
• de l’utilisation abusive de @extend.

Sass et les préfixes constructeurs

Quand bien même la décision d’abandonner les préfixes constructeurs au profit d’options aisément (dés)activables au sein des navigateurs a fait l’objet d’un consensus, il n’en demeure pas moins que les préfixes font partie du quotidien de l’intégrateur. De moins en moins à mesure que les navigateurs évoluent, certes ; néanmoins un grand nombre de propriétés et valeurs nécessitent toujours d’être préfixées.

Pour gérer l’écriture de ces préfixes, il existe un certain nombre de moyens, chacun avec leurs propres avantages et inconvénients. Le premier, et probablement le moins pratique, reste l’écriture manuelle. Quand l’occasion se présente, on vérifie le support de la propriété/valeur, les préfixes nécessaires, et on les écrit quitte à dupliquer quelques lignes de code à la main.

.selector {
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    -ms-hyphens: auto;
    hyphens: auto;
}

Mais l’intérêt d’utiliser Sass, c’est aussi de se faciliter la vie. La deuxième méthode consiste donc à mettre en place un mixin pour automatiser la duplication des lignes : on lui passe la propriété à préfixer, la valeur, les préfixes à générer et c’est le mixin qui va effectuer le travail de duplication au sein d’une boucle.

// Mixin destiné à automatiser la génération de préfixes
@mixin prefix($property, $value, $prefixes: webkit moz ms o) {
    @each $prefix in $prefixes {
        #{"-" + $prefix + "-" + $property}: $value;
    }

    #{$property}: $value;
}

// Exemple d'utilisation
.selector {
    @include prefix(hyphens, auto, webkit moz ms);
}

À partir de cette solution, on peut mettre en place une bibliothèque de mixins — à la manière des frameworks Compass et Bourbon par exemple — qui s’appuie sur ce mixin de préfixage pour alléger encore davantage l’API. Dans notre cas :

// Mixin destiné à automatiser la génération de préfixes pour `hyphens`
@mixin hyphens($value) {
    @include prefix(hyphens, $value, webkit moz ms);
}

// Exemple d'utilisation
.selector {
    @include hyphens(auto);
}

Comme vous pouvez le constater, nous retombons sur une syntaxe à la fois simple et permissive, qui se charge de la génération des préfixes sans pour autant que l’on ait besoin de spécifier lesquels afficher pour chaque propriété. Plutôt bénéfique sur le papier, n’est-ce pas ?

Ceci étant dit, tout n’est pas rose. J’ai mis longtemps à m’en rendre compte, mais avec le recul j’ai le sentiment que la génération de propriétés et valeurs préfixées n’est pas le rôle de Sass. C’est quelque chose qui doit être facilement configurable. Plus que ça, c’est quelque chose qui doit être toujours mis à jour.

Si demain le projet cesse le support d’Internet Explorer 8, ou que Chrome n’a plus besoin du préfixe pour les animations CSS, ce n’est pas à l’intégrateur d’aller mettre à jour les mixins pour retirer les préfixes obsolètes selon moi. C’est à l’outil de se mettre à jour automatiquement. En l’occurrence l’outil c’est Sass, et Sass ne peut mettre à jour ce genre de choses de manière automatique.

Si l’outil ne va pas, c’est qu’il faut en changer.

Or, un outil pour la gestion des préfixes constructeurs, il en existe un fabuleux : Autoprefixer. Autoprefixer est un post-processeur, c’est à dire que c’est un programme qui va lire des feuilles de style compilées (format .css) pour les modifier, en l’occurrence pour ajouter les préfixes aux endroits adéquats.

Si Autoprefixer est si performant, c’est bien parce qu’il est systématiquement mis à jour, puisant les informations dans les bases de données de la plate-forme CanIUse.com, site célèbre s’il en est pour connaître l’état de support des fonctionnalités HTML, CSS, JavaScript et bien d’autres au sein de la pléthore de navigateurs que l’intégrateur moderne doit supporter.

L’autre fort avantage d’Autoprefixer sur une version manuelle, c’est d’être configurable hors des feuilles de style. Mieux encore, la configuration de l’outil se fait de manière très intuitive, en intimant par exemple à Autoprefixer de générer les préfixes pour tous les navigateurs dont le pourcentage d’utilisation est supérieur à 3% (selon les statistiques globales), ainsi que les deux dernières versions de chaque navigateur. Il est bien sûr possible de définir une configuration plus aboutie, mais cet exemple simple montre à quel point Autoprefixer est plus à même de gérer la génération des préfixes constructeurs que Sass.

Sass et l’unité rem

L’unité rem est le célèbre successeur de l’unité em qui a l’avantage sur son ancêtre de ne pas rencontrer de douloureux soucis de cascade vis à vis des éléments imbriqués. L’unité rem se base donc sur la taille de police de la racine du document, à savoir l’élément <html> dans le cas d’un document HTML.

Les avantages des unités fluides telles que em ou rem sur les unités fixes comme px sont multiples. Le fait justement qu’elles cascadent et soient relatives à une autre valeur (taille de fonte, taille du parent, taille de fenêtre, etc.) font d’elles des atouts de taille dans le cadre de réalisations fluides (i.e. Responsive Web Design).

Le fait est aussi qu’Internet Explorer 9 et versions antérieures connaissent un problème d’accessibilité avec l’unité px qui empêche l’utilisateur de modifier la taille par défaut de la police de son navigateur. Il s’agit là d’un raccourci : en fait, l’utilisateur peut tout à fait procéder à cette modification, seulement les dimensions spécifiées en pixels ne seront pas altérées par cette configuration, chose qui peut s’avérer problématique.

En somme, l’unité rem est un petit bijou qui peut s’avérer très pratique ! Le souci, c’est que les designers ne pensent pas en rem, et c’est bien normal. C’est là un outil technique auquel les designers n’ont pas accès. Encore aujourd’hui, la majorité d’entre eux travaillent dans des outils graphiques (Photoshop, Gimp…) où le pixel est roi. Lors de l’intégration des maquettes, on doit donc convertir ces pixels en valeurs en rem.

Là encore, il y a plusieurs façons d’aborder le souci. La première, et encore une fois probablement la moins efficace, consiste à faire le calcul à la main. Si la taille de base de 16 pixels n’a pas été modifiée, et que la maquette intime une taille de titre de 24px, un rapide produit en croix nous offre le résultat de 1.5rem.

.title {
    font-size: 1.5rem;
}

Ceci étant dit, l’Homme n’est pas fait pour faire des calculs. Il n’est pas bon pour ça. En revanche, la machine l’est. C’est d’ailleurs ce qu’elle fait de mieux. On pourrait donc confier les calculs à Sass, avec une fonction qui se charge du produit en croix.

// Fonction destinée à calculer une valeur en `rem` à partir d'une valeur en `px`
    @function rem($value, $base: 16px) {
    @return $value / $base;
}

// Exemple d'utilisation
.title {
    font-size: rem(24px);
}

Petit souci néanmoins : Internet Explorer 8 ne supporte pas l’unité rem. Il faut donc lui fournir une valeur en px malgré tout. L’idéal serait une valeur en em pour éviter les problèmes sus-cités, mais celle-ci étant très dépendante du contexte, ce n’est pas quelque chose de facilement automatisable.

Quoi qu’il en soit, on peut tout à fait créer un mixin plutôt qu’une fonction pour gérer le fallback en pixels. Pourquoi pas en fonction d’une variable, de sorte que ce soit facilement activable / désactivable.

// Variable définissant si les valeurs en `rem` doivent avoir un fallback
$legacy-rem: true !global;

// Mixin destiné à calculer une valeur en `rem` à partir d'une valeur en `px`
@mixin rem($property, $value, $base: 16px) {
    @if $legacy-rem {
        #{$property}: $value;
    }

    #{$property}: $value / $base * 1rem;
}

// Exemple d'utilisation
.title {
    @include rem(font-size, 24px);
}

On peut même imaginer une version avancée qui accepte une map de déclarations (propriétés / valeurs), boucle sur celle-ci pour rem-ifier toutes les valeurs en pixels, mais dans le cadre de notre article nous n’irons pas si loin, d’autant que ce serait contre l’idée même de celui-ci.

Car là encore, bien que Sass soit tout à fait en mesure de gérer les calculs de conversion d’unité, ce n’est probablement pas le meilleur outil pour cela. A nouveau, il s’agit selon moi d’une tâche qu’il vaut mieux automatiser avec un post-processeur. Autrement dit, on écrit les valeurs en pixels telles qu’elles l’ont été demandées par les designers, et un outil va s’occuper de les convertir en rem afin d’éviter les soucis d’accessibilité sur Internet Explorer 9 et de pouvoir facilement mettre à l’échelle l’interface en modifiant la taille de police de l’élément racine.

Cet outil, c’est px_to_rem. Celui-ci fait ni plus ni moins que ce que l’on vient d’envisager : il parcourt les feuilles de style compilées pour convertir les valeurs en pixels en rem. Selon la configuration, il peut également dupliquer les règles pour définir les fallbacks en pixels pour Internet Explorer 8 et Opera Mini.

En somme, utiliser px_to_rem, ou un outil équivalent, pour la conversion des valeurs en pixels vers l’unité rem, c’est :

• faciliter l’intégration des maquettes pour s’épargner des calculs ;
• éviter d’encombrer son code de multiples appels à un mixin ou une fonction Sass ;
• déléguer la mise en place des fallbacks à une configuration, comme dans le cas d’Autoprefixer pour les préfixes constructeurs.

C’est entre autres pour ces raisons que les développeurs du Guardian ont décidé de cesser toute rem-ification au sein des feuilles de styles Sass pour traiter tout ceci lors du processus d’itération, grâce à px_to_rem. Kaelig est donc l’auteur d’une pull-request ayant retiré 3000 lignes (environ 10% de l’intégralité du code Sass) pour les remplacer par seulement quelques lignes de configuration au sein d’un fichier Gruntfile.

Point anecdotique, mais qui a le mérite d’être soulevé malgré tout : Kaelig m’a expliqué combien ce changement a également facilité les pull-requests contenant du code Sass. Il s’avère que bien souvent, les développeurs oubliaient d’utiliser le mixin rem, ce qui impliquait un correctif avant de pouvoir merger la PR.

À partir du moment où ce n’est plus le rôle du développeur que de penser à cet encombrement technique, mais bien celui de l’outillage, on diminue les risques d’échecs et améliore la qualité générale de développement.

Sass et la directive @extend

Le dernier point que je souhaite aborder dans cet article est celui de la directive @extend. Tout d’abord, un bref rappel pour ceux qui ne sont pas très au fait de cette fonctionnalité. La directive @extend permet d’intimer à Sass de faire en sorte qu’un sélecteur A hérite de tous les styles d’un sélecteur B. Par exemple (honteusement tiré de l’article de Harry Roberts à ce sujet) :

%brand-font {
    font-family: "Licorne Sans", sans-serif;
    font-weight: 700;
}

.logo {
    @extend %brand-font;
    // Autres styles pour `.logo`
}

article h2 {
    @extend %brand-font;
    // Autres styles pour `article h2`
}

.footer__title {
    @extend %brand-font;
    // Autres styles pour `.footer__title`
}

Ce code Sass aura pour résultat CSS :

.logo, article h2, .footer__title {
    font-family: "Licorne Sans", sans-serif;
    font-weight: 700;
}

.logo {
    // Autres styles pour `.logo`
}

article h2 {
    // Autres styles pour `article h2`
}

.footer__title {
    // Autres styles pour `.footer__title`
}

Pour plus d’informations sur le fonctionnement de @extend, je vous invite à lire cet article écrit par mes soins sur SitePoint.

Venons-en au fait : @extend est une fonctionnalité pour le moins délicate si vous voulez mon avis. À mon sens, le plus gros problème qu’impose cette directive est le manque de visibilité, ou devrais-je dire le manque de lisibilité. Le fait est qu’étendre un sélecteur n’a pas d’effet à l’endroit indiqué, mais aux endroits où se trouve le sélecteur étendu. Autrement dit, il n’est pas évident de deviner le rendu CSS à la lecture du code Sass, et c’est là que le bât blesse.

Sass n’est qu’un outil. Son but est de faciliter l’écriture des feuilles de styles d’une part, mais surtout d’en faciliter la maintenance d’autre part. Quand on inclut un mixin, on sait explicitement ce qui va se produire : des déclarations CSS vont être générées à cet endroit précis, rien d’autre.

Dans le cas de l’extension d’un sélecteur, en revanche, et à moins de connaître la codebase sur le bout des doigts, il est difficile de savoir :

• où le sélecteur courant va être téléporté (pour rejoindre le sélecteur étendu) ;
• si le sélecteur étendu est présent à divers endroits et dans divers contextes ;
• plus important encore, si l’extension du sélecteur ne va pas provoquer des effets de bord désastreux.

À tel point que j’en suis venu à ne plus utiliser @extend sauf dans des cas extrêmement spécifiques et bien maîtrisés. J’ai le sentiment qu’un mixin sera dans l’immense majorité des cas plus sage, offrant les mêmes fonctionnalités tout en limitant les éventuels effets de bord et soucis de spécificité.

J’en entends déjà parmi vous mentionner le sujet des performances, comme quoi utiliser des mixins pour des déclarations statiques (comprendre non altérées par des variables) est cause de lourdeurs, à cause des propriétés inutilement dupliquées. Sur le papier, c’est on ne peut plus vrai. En pratique maintenant, les feuilles de styles sont normalement servies compressées (ne pas confondre avec minifiées), notamment par Gzip.

Le fait est que Gzip compresse de mieux en mieux une chaîne de caractères à mesure qu’elle est répétée. Autrement dit, Gzip compresse le CSS généré par un mixin de mieux en mieux à chaque inclusion de celui-ci. De fait, la différence entre l’utilisation de @extend pour limiter la duplication de règles (en fusionnant les sélecteurs) et l’utilisation de mixins est microscopique (si existante) une fois le rouleau-compresseur Gzip passé sur le tout.

Harry Roberts a érigé une règle pour l’utilisation d”@extend que j’aime beaucoup :

Extend for same-for-a-reason. Mixin for same-just-because. Traduction : « On utilise extend quand on veut partager des traits pour une bonne raison, et mixin quand c’est simplement une coïncidence. »

Dans l’article Sass : Mixin or Placeholder ?, j’évoquais :

If you need variables, use a mixin. Otherwise, extend a placeholder. Traduction : « Si vous avez besoin de variables, utilisez un mixin ; sinon, étendez un placeholder. »

Cet avis demeure tout à fait vrai, mais les mois passants m’ont conforté dans l’idée que le mixin est une fonctionnalité globalement bien plus utile que @extend.

Aussi mon opinion est aujourd’hui plus tranchée : on évite d’utiliser @extend ailleurs que pour des helpers (type %clearfix, %hide-text…) (et encore) et/ou si on est sûr de ce que l’on fait. Dans le doute, on opte pour un mixin : même effet, aucun risque, et on s’épargne les soucis de @extend avec @media.

Alors Sass, c’est pourri ?

CSS n’est pas un mauvais langage, mais il se trouve actuellement « le cul entre deux chaises, » partagé entre son héritage pas toujours très glorieux, et les nouveaux challenges imposés par nos professions. Parce que nous aussi, nous devons souvent faire des merveilles tout en nous assurant que tout va bien partout et tout le temps, même dans les cas les plus extrêmes, nous avons besoin d’outils.

Sass en est un. Et un très bon de surcroît. Ce n’est pas pour rien qu’il est le préprocesseur CSS le plus répandu, et ce depuis 7 ans maintenant, utilisé par de très grands acteurs (GitHub, Google, Twitter, Ghost, Lonely Planet…).

Malheureusement, Sass n’est pas magique. Il ne corrige pas tous les problèmes, et quand il est sur-utilisé, il peut même en créer. Choisissez le bon outil pour la bonne tâche ; n’utilisez pas nécessairement le premier venu parce que c’est l’outil que vous aviez déjà en main.

En somme, Sass est un palliatif. Pour les problèmes les plus complexes, ce n’est probablement pas le bon médicament.