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.

Hugo Giraudel

À propos de Hugo Giraudel

Hugo Giraudel est un développeur front-end pris d'affection pour le pré-processeur Sass. Il est l'auteur de Browserhacks et SassDoc et écrit régulièrement sur SitePoint, Tuts+, The Sass Way, CSS-Tricks ainsi que son propre site. Vous pouvez le retrouver sur Twitter et GitHub.

Vous pouvez partager cet article sur Facebook, Twitter ou Google+.

Faites un don pour soutenir l'association Les B-A des Satellites

L'association Les B-A des Satellites aide à offrir une école aux enfants de Niellé en Côte d'Ivoire.

Les fonds récoltés vont directement sur le compte PayPal de l'association. En cliquant sur le bouton « Faire un don » ci-dessus, vous allez être redirigé vers PayPal. Vous n'êtes pas obligés de créer un compte PayPal pour faire un don.

9 commentaires sur “Quand Sass ne rend plus service

  1. DaWeeD31, le lundi 1 décembre 2014 à 02:42

    Très bon article !
    Totalement d'accord avec toi pour @extend, je ne l'utilise pratiquement plus pour les mêmes raison. Je rajouterai que pour moi la feuille de style générée (avant minification) devrait pouvoir être compréhensible et le problème des extends c'est que, comme tu le dis, l'ordre de déclaration n'est plus du tout logique.

    Il y a un plugin grunt pour autoprefixer, c'est sans doute l'outils le plus utile de mon workflow !

    Pour finir, les intégrateurs ne devraient pas utiliser abusivement les rem mais plutôt avoir des cascades maitrisées. Ces dernières sont en effet souvent très utiles (et plus logique) car les dimensions dépendent très souvent de la taille de la police du conteneur.

    Bonne continuation,

    David

  2. MoOx, le lundi 1 décembre 2014 à 07:13

    Je rajouterais en conclusion, ma petite touche pour ouvrir sur un autre sujet:
    c'est pour ces raisons (et peut-être d'autres encore) que je travaille sur l'outil cssnext

    https://cssnext.github.io/

    Plutôt que de partir sur un superset de CSS (comme Scss), on préfère regarder plus loin dans le future et utiliser aujourd'hui la syntaxe CSS demain (basé sur les drafts des spécifications CSS).

    Ainsi, résoudre la problématique de rem en px est beaucoup plus facile à aborder puisqu'on va instinctivement agir sur le CSS et non pas faire du templating (générer une sortie qui va bien) pour résoudre ce type de problème.
    Je me rappelle encore de la tête de Kaelig lorsque je lui ai montré ce concept pour ne pas avoir un mixin spécifique pour les rem/px aux ateliers de SudWeb 2013 !

    Petite note: pour suivre de près les travaux de necolas (ingénieur front-end chez Twitter), il me semble que Twitter va dans l'approche que j'explique ci-dessus et n'utilisera plus (si ce n'est pas déjà entièrement le cas) de préprocesseur classique. Ils tournent actuellement avec postcss (et passeront même peut-être sur cssnext quand l'outil aura une API mature).

  3. Arnaud B., le lundi 1 décembre 2014 à 09:27

    J'avais suivi les précédent en anglais, très bon récapitulatif.

    De mon avis personnel ca que je surveille le plus avec Sass, c'est les css générés, on peut vite se retrouver avec un code css, qui prend du poids, inutilement, des sélecteurs imbriqués et redondants (notamment avec l'utilisation des & ... ou ...&). Généralement je commence un composant dans un outil comme sassmeister ou codepen pour avoir une vue instantanée sur ce qui est réellement produit comme code css.

    Concernant le post-processing, un outil que j'utilise c'est "combine-mediaqueries", suivant la manière dont on travaille ça peut être très utile, notamment quand on utilise un bibliothèque de composants partagés, et que les media-queries sont écrites en ligne dans le corp du composant.

  4. Gaël Poupard, le lundi 1 décembre 2014 à 09:32

    Excellent article Hugo, c’est tellement utile de rappeler ce qui devrait être du bon sens.

    J’ai depuis longtemps la sensation que les utilisateurs de pré-processeurs ne vérifient que rarement le CSS qu’ils génèrent. L’intérêt croissant des post-processeurs va dans le sens de l’amélioration progressive - puisqu’on part d’un socle CSS stable et maîtrisée pour l’améliorer ; contrairement aux pré-processeurs qui génèrent des risques de diverses intensités.

    Merci !

  5. piouPiouM, le lundi 1 décembre 2014 à 11:49

    Tu introduis ton article par la citation « Un mauvais ouvrier blâme toujours ses outils ». Je regrette d'avoir lu un billet qui souligne parfaitement cet état de fait. Je m'explique.

    Il nous est d'abord expliqué que la problématique des préfixes devrait être confiée à un outil tierce comme Autoprefixer parce que ce dernier est paramétrable comparé à Sass. Or, l'intégrateur peut très bien intégrer cette notion de configuration dans ses mixins (ben ouais, ce n'est pas Sass qui fait le job tout seul). C'est justement ce qu'a fait Compass avec son nouveau module Cross-Browser Support qui, par la même occasion, en a profité pour s'appuyer sur les statistiques de Can I Use pour des résultats plus pertinents. Nous pouvons grâce à lui produire des feuilles de styles adaptées à notre cible d'utilisateurs en quelques lignes de configuration.
    Par ailleurs, tu nous conseilles de remplacer un outil (Sass) par un autre (Autoprefixer) pour des raisons à mon sens erronées. En revanche, dire qu'il est préférable d'utiliser un outil tel que Autoprefixer parce que l'intégrateur n'a plus à se soucier des préfixes pour se concentrer uniquement sur la syntaxe CSS3 est un réel argument. La démarche d'inclure un post-processeur dans son workflow de travail prend tout son sens : CSS3 dans son plus simple appareil pour écrire ses styles, Sass pour les aspects DRY et KISS, puis, les feuilles de styles générées passent dans les mains de Autoprefixer pour les rendre compatibles avec le parc de navigateurs cible.

    Le paragraphe sur l'unité rem m'a fait tomber de ma chaise. À nouveau tu nous proposes de remplacer un mixin Sass par une notation en pixels convertie plus tard par un autre outil qui accomplira exactement la même tâche que le mixin. Quel intérêt ? Tu justifies cela avec l'exemple du Guardian où certains développeurs oubliaient d'utiliser un mixin. Si, à l'avenir, au lieu de renseigner des pixels ils renseignent directement des rem, qu'en sera-t-il des fallbacks ? Ils ne seront tout simplement pas appliqués par px_to_rem.
    On en revient à l'origine du problème à savoir qu'il faut éduquer les intervenants du projet. Car remplacer un outil par un autre ne garantit pas que les travers constatés avec le premier disparaîtront. De nouveaux usages vont naître, et, avec eux, de nouveaux travers.

    Dernier élément, les @extend. Oui, il faut utiliser la fonctionnalité avec parcimonie et justesse. Nous sommes plusieurs à le rabâcher depuis quelques années, que ce soit dans des articles, des livres ou à l'occasion de formations. C'est à l'utilisateur de maîtriser son outil : il est le seul à blâmer s'il perd le contrôle de ses styles.

    Avec de grands outils viennent de grandes responsabilités : Sass n'est pas à blâmer pour de mauvaises intégrations. On peut, à la rigueur, se demander s'il ne propose pas trop de fonctionnalités, et si celles-ci n'engendrent pas un certain laxisme : au mieux, un manque de rigueur (il faut vérifier, et vérifier encore, le code généré après compilation), au pire, une certaine paresse intellectuelle.
    Enfin, j'ajouterais un point sur le fait que ce qui peut fonctionner pour une équipe et pour un contexte projet donné n'est pas forcément la solution miracle qui fonctionnera pour tous.

    Tu fais bien de soulever les mauvais usages qui sont fait avec Sass, toutefois il serait tentant pour des utilisateurs moins experts de penser que jeter Sass au profit d'outils tel que Autoprefixer est la solution miracle qu'il faut implémenter immédiatement.

    Une prise de recul sur les outils est absolument nécessaire, et ne me semble possible qu'au bout de plusieurs années d'utilisation. Qui sait quels travers nous découvrirons après des années d'utilisation des post-processeurs ?

  6. Nico, le lundi 1 décembre 2014 à 12:27

    Très bon article, merci :)

    > Une prise de recul sur les outils est absolument nécessaire, et ne me semble possible qu'au bout de plusieurs années d'utilisation. Qui sait quels travers nous découvrirons après des années d'utilisation des post-processeurs ?

    Je suis pas d'accord, c'est assez facile de voir certaines conditions limites (pour cela que je faisais déjà ces remarques il y a déjà un bail) :

    - est-ce que si l'outil disparait, je suis encore capable de mettre à jour la CSS ? (exemple bidon-bateau : pour cela que je ne le fais jamais minifier les CSS par Sass, j'ai besoin de pouvoir la lire quoi qu'il arrive)

    - est-ce que l'outil peut être remplacé facilement ? Quel est la « criticité » de l'outil ?

    - de combien l'outil m'éloigne du cœur du problème ? Typiquement, si Sass génère un truc non-sensique en CSS => mauvaise utilisation.

    Personnellement, je suis adepte de limiter la dépendance aux outils le plus possible (et j'ai bien dit « la dépendance », PAS limiter les outils : je me vois pas faire à la main un site où j'ai 50 icônes en sprites).

    D'ailleurs les dévs, plus globalement : vous DEVEZ être capables d'évaluer les conditions limites de tout/vos choix (j'ai bien dit « évaluer », pas tout deviner l'in-maitrisable). Sinon vous êtes condamnés à courir perpétuellement… et sûrement à souffrir.

  7. Dotpeach, le lundi 1 décembre 2014 à 13:46

    Personnellement je trouve que l’article porte très mal son nom.
    À vrai dire, c’est même tout le fil rouge que tu construis autour de Sass ne tient pas la route.

    En supprimant la conclusion (qui n’apporte rien) et en présentant la chose comme une "présentation d’outils front / alternatives pour ceux qui ne souhaitent pas utiliser Sass", on aurait eu un article beaucoup plus appréciable, avec le même contenu.

    Certes, l’enrobage aurait été moins vendeur, surtout sans le titre qui appelle à la polémique, mais le rendu final aurait été plus honnête.

  8. Anthony, le mercredi 3 décembre 2014 à 13:49

    Merci pour cet article qui fait du bien, très instructif, très bien écrit. Les pré-processeurs et leur hype, on en a mangé pendant un certain temps, c'est très puissant, les doc sont bien trop remplies et j'ai l'impression de nager le crawl avec une combi d'astronaute.
    Les post-processeurs ont un fonctionnement beaucoup plus logique sur le long terme. C'est l'outil qui s'adapte, pas le code. L'article porte très bien son nom, quoi qu'en diront les fanboys.

  9. Mems, le mercredi 3 décembre 2014 à 14:53

    L'utilisation d'une fonction qui gèrent les `rem` (`rem(10px)`) permet de l'utiliser sur toutes les propriétés qui utilisent une taille [``](https://developer.mozilla.org/en-US/docs/Web/CSS/length). Genre `margin: 1.25rem 20px;`. L'outil "px_to_rem" ne saura pas quand faire la convertion.
    A l'inverse, un outil "rem_fix" pourrai doubler les propriétés qui utilisent l'unité "rem" pour une version fallback en fonction des navigateurs utilisés : toutes les propriétés pour IE8, seulement `font` pour IE9-10 et `line-height` pour IE9-10-11 pour les pseudo elements `::before` et `::after`

Laisser un commentaire

Les commentaires sont modérés manuellement. Merci de respecter l'auteur de l'article, les autres participants à la discussion, et la langue française. Vous pouvez suivre les réponses par flux RSS.