Damian Le Nouaille est développeur Freelance (Frontend et Ruby). Actuellement, il travaille sur Mayathebuzz et essaie d’utiliser les meilleures pratiques frontend pour rendre son métier plus agréable. Il propose également une formation Sass et Compass pour Human Coders Formations. Vous pouvez le suivre sur Twitter (@damln) et en savoir plus sur son site http://www.damln.com.
Avant tout, qu’est-ce qu’un préprocesseur CSS ?
C’est un outil permettant de transformer un langage (avec une syntaxe semblable à CSS), en CSS valide. La syntaxe du langage est souvent tellement proche de celle du CSS qu’on voit à peine la différence. Les préprocesseurs apportent une aide à l’écriture de vos feuilles de styles. Aujourd’hui, les deux préprocesseurs les plus utilisés sont Sass et Less. Quelques préjugés persistent sur ces technologies, voici mes explications pour les préjugés les plus courants :
“Ils complexifient CSS.”
CSS est simple : selecteur { propriété: valeur ; }
Ajouter des “mots clés” comme @include border-radius(5px); et autres fonctions de Sass n’est pas une destructuration de CSS, ni une complexification, c’est simplement un niveau d’abstraction qui vous permet de vous décharger de responsabilités inutiles à ce stade de votre code. Un jeune intégrateur devra comprendre cette abstraction pour évoluer dans sa carrière. Aujourd’hui, nous ne sommes plus seulement intégrateur Web, mais développeur frontend. Pourquoi ?
Nos projets se complexifient, s’agrandissent, intègrent du JavaScript, des modules et autres briques que nous, développeurs, devons comprendre. Dans développeur frontend, il y a développeur. C’est-à-dire une personne capable d’utiliser des outils simples pour résoudre des problèmes complexes.
Tout intégrateur aujourd’hui connaît au moins 2 ou 3 langages de programmation (c’est-à-dire autre que HTML et CSS), juste un hello world, mais les notions de variables, fonctions et conditions sont tellement fondamentales qu’elles devraient vous sauter aux yeux à la lecture de fichiers Sass. Si vous avez du mal avec ces notions, prenez le temps de les maitriser avec un autre langage comme Ruby, Python ou PHP. Vous verrez que Sass implémente celà de manière simple et naturelle.
“Ils n’ajoutent pas de fonctionnalités CSS aux CSS.”
CSS n’a pas besoin de plus de fonctionnalités durant votre développement, le W3C est là pour ça. Ce sont les standards qui ajouteront des fonctionnalités. Votre responsabilité n’est pas d’en créer, mais de suivre les standards. Personne n’attend des préprocesseurs (comme Sass) de nouvelles fonctionnalités, mais de la simplification et de l’optimisation. Ils sont là pour poser une base de travail stable pour suivre les évolutions de CSS. D’ailleurs, oui on trouve de “nouvelles” fonctionnalités, voir plus bas.
“Ils ne font pas (toujours) gagner du temps”
Pour reprendre le contexte et les propos d’un article récent:
N’oubliez pas que vous voyez les préprocesseurs CSS avec vos yeux d’experts web. [Les novices] ne seront pas capables de vous comprendre et perdront du temps.
Exact, c’est ce que nous voulons, aller de l’avant. Nous essayons d’être experts pour proposer des sites de qualité, une expérience utilisateur meilleure que la moyenne. Pour le reste, il y a MasterCard le Site du Zéro et Alsacréations. Ce sont les premiers liens que je donne aux novices. Je n’ai aucun problème avec ces sites ni leurs auteurs que je respecte beaucoup pour avoir structuré et partagé leurs connaissances, ils devraient en faire de même avec leurs feuilles de style. Remettez-vous dans le contexte. Nous parlons ici de dévelopement Web moderne et intelligent. Pas de tutoriels débutants pour comprendre CSS. L’usage des préprocesseurs vient naturellement avec l’élégance et la taille du projet. Un code de qualité est la première brique à poser pour espérer avoir un site rapide et bien pensé. Si vous voulez proposer une expérience à vos clients/utilisateurs, alors soignez vos méthodes de travail et vos outils.
“Ils peuvent être dangereux pour le standard CSS”
Relevons un point intéressant. L’article nous propose de nous intéresser aux “nouvelles” fonctionnalités de SCSS comme rgba(), saturate(), desaturate(). La question qui se pose est : Si, demain, le W3C veut introduire ces fonctionnalités dans CSS3, et bien, les feuilles de style SCSS ne comprendront pas s’il faut utiliser la version “native” ou la version Sass. Deux réponses à ce problème simple :
CSS doit-il faire ça ?
N’oubliez pas que CSS est un langage côté client et qu’il doit faire le minimum de chose dans le navigateur. Calculer des valeurs hexadécimales, appliquer des transformations sur une couleur, ou autre, font partie des choses qui peuvent être précalculées par les préprocesseurs. Donc inutile de faire tourner le CPU des visiteurs alors que vous pouvez le faire pour eux.
Peut-on utiliser la version native dergbasans tout casser dans Sass ?
Bien sur, il suffit d’utiliser l’interpolation de string (arf, concept trop compliqué pour un intégrateur). démonstration rapide :
Pur CSS RGBA:
body {
background-color: rgba(0,0,0,0.5);
}
Sass RGBA:
body {
background-color: rgba(#000, 0.5);
}
Pur CSS RGBA dans un fichier Sass:
body {
$rgba: "rgba(0,0,0,0.5)";
background-color: #{$rgba};
}
$rgba est une string pour Sass dans le dernier cas donc pas de précompilation. Cette méthode marche avec toutes les fonctions Sass.
“Ils sont inutiles grâce au technique OOCSS et aux frameworks CSS”
Bootstrap est écrit en Less, Foundation en Sass. Ce sont les meilleures façons d’approcher vos styles et simplifier votre code. Les auteurs de ces frameworks (les deux plus utilisés) le savent et l’appliquent. Vous pouvez très bien utiliser un préprocesseur CSS dans votre code et suivre ces bonnes pratiques. Vous verrez même que OOCSS prend encore plus de sens avec les nested et les import que Sass fourni (voir plus bas).
“Ceux qui utilisent les préprocesseurs ne connaissent pas bien CSS.”
Connaître CSS, c’est comprendre que ce “langage” est très bête. Comment est-ce possible qu’un langage de présentation ne contienne ni variable, ni boucle, ni condition, ni mixin et ni fonction ? Comment espérer gérer un projet lourd et complexe sans aide ?
Je ne connais aucun développeur frontend utilisant un préprocesseur CSS, qui ne connaisse pas bien CSS. Les développeurs “pur CSS” surestiment leur capacité à faire du “joli” code. Si la pureté vous titille : faites de l’assembleur. En 2013, faire du code propre sur un gros projet avec du pur CSS, c’est du suicide. “Oui mais j’ai 10 ans d’expérience en intégration Web, je suis expert”. Vous savez comment on reconnaît un expert CSS ? C’est justement parce qu’après en avoir écrit beaucoup trop, aujourd’hui, il le génère. Les meilleurs l’approuvent et l’utilisent :
“Il faut comprendre la cascade CSS, pas les préprocesseurs.”
Bien sûr que la cascade est importante, mais le Web change, notre vision d’une “page web” est complètement obsolète. Aujourd’hui, pour faire du code réutilisable et maintenable, on travaille en modules. Les modules doivent correctement implémenter leur cascade interne mais Sass et les préprocesseurs CSS n’ont rien à voir dans tout ça. Bien utiliser la cascade c’est simplement une bonne architecture de sélecteurs. Sass permet de faire du “nested selectors” et c’est très pratique pour mieux encapsuler les modules. A vous de ne pas en abuser. La documentation “The Sass Way” est très claire sur ce point : Nested Selectors: The Inception Rule.
“La ligne de commande, trop compliquée.”
N’importe quel intégrateur Web qui travaille sur des projets ambitieux a probablement dû installer l’application en local pour intégrer le design. Parfois du PHP, du Ruby, du NodeJS, du .NET, du Java ou autre. Je vous propose de compter le nombre d’heures que vous avez passées sur votre dernier projet à juste l’installer : 34 coups de fil au développeur backend, configurer les dépendances dans Eclipse, Visual Studio, installer Ruby, MySQL, et j’en passe. Ouvrir un shell et taper deux commandes est surement l’action la plus simple que vous avez dû effectuer dans votre vie de développeur. Si vous n’avez jamais ouvert votre terminal dans votre carrière de développeur, c’est probablement que vous n’avez jamais eu à gérer un site assez intéressant qui nécessite l’usage de préprocesseurs CSS.
La ligne de commande est l’outil le plus vieux qui existe, et existera toujours.
Bonus
Aujourd’hui, plein d’applications desktop avec une UI sympathique ont fait leur apparition. Pour n’en citer quelques-unes :
“C’est une tendance éphémère.”
CSS3 est une mode ? Non. C’est un standard, qui met du temps à rentrer en production. Tous les navigateurs convergent vers CSS3 mais on en a encore pour quelques années avec les -vendors-prefix. Sass (ou autres préprocesseurs) permet de suivre un mouvement stable. C’est loin d’être une mode. C’est notre futur à tous. Vous n’avez qu’à regarder les futures spécifications techniques de CSS4 pour voir qu’elles convergent vers une approche “préprocesseur”. Par exemple, Le draft “variables” W3C (que je n’approuve pas car je pense que cette responsabilité doit venir aux préprocesseurs, pas au navigateur).
“Nos IDE sont suffisamment puissants.”
“Hey, mais il y a un plugin SublimeText pour générer les vendor-prefix !”. Un IDE/éditeur se configure, s’installe, s’apprivoise. Dans une équipe hétérogène, il faut respecter l’environnement de chacun. Se baser sur un IDE est la solution la plus intrusive pour un développeur. Je me vois bien appeler tout les collaborateurs pour leur dire : “J’ai une solution géniale, on va tous installer le même IDE !”. Il faut raisonner de manière plus globale, il vaut mieux avoir un langage puissant, qu’un IDE malin. Nous n’avons pas juste besoin de vendor-prefix, nous avons besoin d’un langage puissant pour combler les vrais manques de CSS. De plus, lorsque vous voudrez éditer le code généré par ces éditeurs, vous devrez le faire à la main. Les IDE changeront plus vite que les préprocesseurs. Il suffit de changer de version de SublimeText pour que votre plugin vendor-prefix ne marche plus. Alors qu’un simple gem install compass règle tout ça et vous donnera une force de frappe sans précédent.
“Je n’ai pas de contrôle sur ce qui est réellement interprété par le browser.”
Libre à vous d’ouvrir et de comprendre les *.css générés par Sass.
“La compilation est lente”
Je compile des projets de 3000 lignes en 1.5 seconde, sur un (vieux) MacBook Pro de 2010. Si lors du refresh de votre localhost, vous n’avez pas encore la dernière version de votre feuille de style générée, et que vous devez faire un deuxième refresh pour voir les modifications : posez-vous des questions sur votre façon de travailler plutôt que sur la rapidité de compilation. Ecrire une ligne de code, ALT-TAB puis CMD-R pour voir les modifications dans la même seconde, c’est un workflow très mal pensé. Revoyez votre manière de coder, prenez plus de temps dans votre éditeur pour mieux réfléchir à la structure de vos styles. Faites moins de refresh, c’est inutile. Non, en fait arrêtez de faire des refresh. On a maintenant plein d’outils pour auto-reload une Tab Chrome lors d’un changement de fichier (LiveReload, cité plus haut).
Bonus
Le créateur de Sass a publié une version C de Sass : libsass. 4000% plus rapide que la version actuelle (Ruby).
“Les tutoriels qui ne sont pas rédigés en pur CSS mais utilisant un préprocesseur.”
Un tutoriel est justement là pour condenser un concept. Pas pour être copier/coller en production. Un préprocesseur CSS permet de réduire le code, améliorer la visibilité, pour se concentrer sur le concept essentiel enseigné dans le tutoriel. Si vous n’êtes pas capable de comprendre une variable, une boucle ou une condition, posez-vous aussi de sérieuses questions sur votre métier de développeur. Si vous ne comprenez pas le fond du tutoriel, alors c’est qu’il vous sera inutile, avec ou sans préprocesseur.
“Le CSS est un langage côté client”
Exact. Le CSS est fait pour être interprété par le client. Cette interprétation doit être optimisée en amont (préprocesseur CSS) pour améliorer les performances de l’interprétation navigateur.
[Avec du pur CSS] Je vais sur n’importe quel site pour voir comment est fait une inté, clique droit, inspecter l’élément, j’ai le code, parfait”
Allez sur n’importe quel site utilisant Sass, faites un clique droit, inspecter l’élément, vous avez le CSS généré. C’est transparent pour le navigateur, et donc pour le “lecteur”.
“[Le code final est] compilé du coup, impossible d’accéder à leur code source. AH”
Voir le point précédent.
“Sass c’est open-source, donc instable.”
Sur Github, le projet Sass a 1880 stars, 260 forks, dernier commit il y a sûrement moins d’une heure. Actuellement en version 3.2.7, regardez les chiffres :
Le projet Compass a 4280 stars, et 668 forks.
“La documentation est moche”
Oui. Mais elle est complète. J’ai toujours trouvé ce que je cherchais dans la documentation. Si vous avez une question, n’hésitez pas, go : Sass Reference
Bonus
C’est open source, vous voulez la redesigner la documentation Sass ? Proposez votre style.
Cet article vous a donné envie d’apprendre Sass ? La formation Sass et Compass de Damian est faite pour vous !