Le document présente les préprocesseurs CSS, outils facilitant la transformation de syntaxes semblables à CSS en CSS valide, avec une préférence pour SASS sur LESS. Il aborde les défis de leur adoption en production, tels que la résistance au changement et les workflows inadaptés, notamment en remote editing. Enfin, il suggère des solutions pour intégrer ces préprocesseurs dans divers workflows, en tenant compte des limitations techniques et des préférences des utilisateurs.

1. Préprocesseurs CSS et remote editing
Quelles solutions ?

2. Romain SAUGER
Chef de projet WEB
MEDIAPILOTE - Laval

3. Sommaire
● Que sont les préprocesseurs CSS ?
● Comment intégrer les préprocesseurs CSS à son workflow
en Remote Editing ?

4. Que sont les préprocesseurs CSS ?

5. Les préprocesseurs CSS
● Ce sont des outils permettant de transformer un langage
(avec une syntaxe semblable à CSS), en CSS valide.
● Les deux préprocesseurs les plus utilisés sont Sass et Less.
● Les préprocesseurs apportent une aide à l’écriture de vos
feuilles de styles (Gain de temps : DRY)
A lire sur humancoders.com : Les idées reçues sur les préprocesseurs CSS (Sass, Less…)

6. Encore trop peu utilisés
1. Nouvelle syntaxe à apprendre
2. La résistance au changement
3. Workflow inadapté

7. Une nouvelle syntaxe

8. Ce dont on dispose en plus (par rapport aux CSS)
● Variables
● Mixins
● Règles imbriquées (Nested rules)
● Calcul (Operation)
● Portée (Scope)
● Conditions (Conditional Statement)

9. Variables
Less Sass

10. Mixins

11. Règles imbriquées (Nested rules)
Less Sass

12. Calcul (Operation)

13. Portée (Scope)

14. Conditions (Conditional Statement)

15. Sources
http://www.hongkiat.com/blog/less-basic/
http://www.hongkiat.com/blog/getting-started-saas/

16. Less VS Sass, lequel choisir ?
● Réponse courte : Sass
● Réponse légèrement plus longue : Sass est meilleur par bien
des aspects, mais si vous êtes content de Less, pas de
problème, c’est déjà une très bonne chose d’utiliser un
préprocesseur.
● Réponse détaillée (EN) : https://css-tricks.com/sass-vs-less/

17. Constat
Malgré toutes leurs qualités, les préprocesseurs peinent parfois
à s’imposer en production, pour 2 raisons* :
● Résistance au changement
● Workflow inadapté : le remote editing
*d’après une étude empirique sur un panel pas représentatif, mais que je côtoie :)

18. Le résistance au changement
Ce qu’il faudrait (au moins) éviter :
● Des outils propres à un seul OS
● Imposer un nouvel éditeur de texte
● Être obligé d’utiliser les lignes de commande
Ce qui n’est parfois pas négociable : le remote editing

19. le Remote editing, mais pourquoi au juste ?
● Une seule version à maintenir
● Pas de maintenance d’un serveur local.
● Immédiateté des interventions en prod.
MAIS AUSSI : il est parfois impossible d’installer une version
locale du site pour des raisons technique et de licence.

20. Workflow “full remote”
● Editeur de texte λ associé à Transmit, WinSCP ou Filezilla.
● Dreamweaver, Coda & notepad ++ : gestionnaire de site et
FTP intégré.
Incompatible avec des outils de préprocessing “en local”
Solution : installer le préprocesseur sur le serveur, compilation à
la demande : LessPHP ou Sass si le serveur le permet…

21. Workflow “half remote”
On travail sur une copie locale, mais on upload les fichiers
modifié après chaque sauvegarde.
● Sublime Text + Package SFTP
● Dreamweaver et son gestionnaire FTP intégré
● Editeur de texte λ + Task runner (Grunt, Gulp)
Solution idéale mais incomplête selon l’éditeur :
Recours à un preprocesseur externe

22. Workflow half remote
Fichier locaux
Liberté du choix de préprocesseur
Comment gérer l’upload lors de la sauvegarde ?

23. Comment intégrer
les préprocesseurs à son workflow
en remote editing ?
Surtout si en plus c’est sur du mutualisé,
donc sans librairies exotiques sur le serveur…

24. Prérequis
● Les fichiers devront être présent en local.
● Il faut trouver un moyen d’envoyer sur le FTP les fichiers
compilés (CSS) aussitôt après qu’ils aient été généré.

25. Cahier des charges (anti-résistance au changement)
● Pas d’OS Spécifique
● Pas de ligne de commande
● Pas de nouvel éditeur
● Pas de nouveau workflow

26. Solution n°1
Sublime Text + Packages

27. Sublime Text + Packages

28. Node.js + Less + Package Lessc
et aussi l’installation des preprocesseurs

29. Ruby puis les gem Sass, Compass, Susy, etc.
et aussi l’installation des preprocesseurs

30. Sublime Text + Package SFTP
Avantages :
Solution multi OS
Workflow presque sans faille.
Sublime Text

31. Sublime Text + Package SFTP
Inconvénients :
● Pas mal de chose à installer, dont parfois en ligne de
commande.
● Et si j’aime pas Sublime Text ?

32. Solution n°2
Editeur de texte λ + Task runner (Grunt, Gulp)

33. Editeur de texte λ + Task runner (Grunt, Gulp)

34. Avantage :
Liberté du choix de l’éditeur (même Dreamweaver !)
Accès à tout un tas de fonctionnalités complémentaires, dont :
● Compression
● Concaténation
● Upload FTP
Editeur de texte λ + Task runner (Grunt, Gulp)

35. Inconvénients :
● Courbe d’apprentissage importante
● Ligne de commande là encore quasi indispensable
● Upload FTP “Build & save” moins stable que ST + SFTP
Editeur de texte λ + Task runner (Grunt, Gulp)

36. Solution n°3
Les outils “tout en un”

37. Livereload
Codekit
Mixture
Prepros
Les Outils “tout en un”

38. Livereload
Support très complet
Pas de gestion FTP

39. Codekit
Mac OS uniquement
Support ultra complet
Pas de gestion FTP

40. Mixture
Support ultra complet
Pas d’upload FTP “on save”

41. ● Win & Mac
● Liberté de choix d’éditeur de texte
● Richesse des bibliothèques :
o CSS : LESS, SASS, Stylus
o HTML : jade, haml, slim, markdown, kit
o JS : Coffeescript, Livescript
● FTP intégré :
o Build & Upload on save
o File filters
Prepros

42. Conclusion

43. Conclusion
Ne (presque) rien changer : Prepros + n’importe quel editeur
Si déjà sous Sublime Text : pas besoin de task runners : package
Less, Sass et SFTP.

44. Ouverture
Les fichiers sont de retour en local…
…et si on se mettait à Git ?

45. 2 OS utilisés à égalité

46. 2 vieux outils encore très utilisés

54. Merci de votre attention
romain.sauger@gmail.com