Closed Scriptura closed 1 month ago
Hello Olivier,
Je ne pensais pas que quelqu'un tomberait un jour sur ce repo, mais après tout pourquoi pas puisqu'il est public :)
Merci pour ton info à propos de @import
, on va effectivement mettre nos guidelines à jour même si on utilise Sass de moins en moins.
J'ai fait la correction sur la feuille de styles de ce site perso et ça s'est très bien passé. Par contre, quand j'ai voulu faire la même manip (changer tous les @import
en @use
sur le repo Bretzel la compilation a foiré car il cherche des variables perdues. Il va falloir que j'investigue.
Merci pour les retours sur la refonte. Il y a d'autres "easter eggs" caché en terme d'animations liées au scroll, je te laisserai les découvir (surtout sur desktop).
Bonne continuation,
Raphaël
la compilation a foiré car il cherche des variables perdues. Il va falloir que j'investigue.
Pas besoin, je te le donne en mille : il y a un scope car chaque fichier se comporte comme un espace de nom. En début de chaque fichier il faut importer la feuille des variables globales:
@use "variable";
.maClasse {
color: variable.$colorW;
}
Perso je mets un alias:
@use "variable" as _;
.maClasse {
color: _.$colorW;
}
Oui c'est relou, il faut retoucher tous les fichiers...
même si on utilise Sass de moins en moins.
Et bien moi je viens juste de m'y mettre... pour éviter le plus possible de m'écarter de la syntaxe CSS de base ! En effet, je ne compte pas utiliser toutes les subtilités de Sass (les mixins et autres fonctions j'évite autant que je peux, désormais avec les variables CSS la répétition devrait être limitée, ou alors il y a un problème de conception), mais j'aime pouvoir, par exemple compiler plusieurs feuilles de styles avec la même code base. Par exemple pour un dark theme, ou encore pour une feuille dédiée à l'impression. Et puis il manque encore quelques trucs à CSS les variables CSS ne sont toujours pas disponibles pour les Medias Queries par exemple, on attend toujours env() sur ce créneau.
J'ai longtemps été un aficionado de Stylus, mais je dois reconnaître que, avec les dernières implémentations CSS, sont arrêt de développement le rend complètement obsolète...
Il y a d'autres "easter eggs" caché en terme d'animations liées au scroll, je te laisserai les découvir (surtout sur desktop).
J'ai vu, mais je ne m'y suis pas encore penché dessus. Ce sera fait en temps et en heure, compte sur moi !
Bonne soirée.
PS: j'ai oublié de te dire que si tu utilises une astérisque comme alias tu peux utiliser tes variables préexistantes tel quel. Bien sûr, cela n'a un intérêt que pour les projets déjà existants. À terme c'est mieux de garder l'avantage du concept d'space de nom. Pour les gros projets tout au moins.
Encore merci pour les explications. Cela me donne encore moins envie de faire du Sass, mais tu as raison : il n'est pas encore possible de se limiter à du seul CSS notamment en raison des custom media non supportées par les navigateurs.
En attendant, une lecture intéressante : https://frontendmasters.com/blog/fine-ill-use-a-super-basic-css-processing-setup/
Ah... ce Chris Coyier... je ne savais pas qu'il restait actif malgré la vente de son site à DigitalOcean...
Merci pour l'article, je l'ai lu. L'introduction de ce dernier ne fait que refléter une pensée que je sais être aussi la tienne. Et je suis tout à fait d'accord avec ça. Là où je divergerais serait plutôt les moyens à utiliser pour rester "léger".
J'ai opté pour la deuxième solution.
En effet, bien que PostCSS ait la côte (cf. npm trends) ses plugins ne sont pas toujours maintenus comme ils le devraient. Il n'est pas rare de devoir switcher de plugins au cours du temps pour maintenir une fonctionnalité. Je préfère donc utiliser un mammouth entretenu tel que Sass qu'un truc léger dont on ne connait pas l'avenir. Le monde du web est un cimetière d'outils, bien que certains aient un bref instant connus leur heure de gloire (pour React se sera plus long mais pas moins inexorable, j'entends de plus en plus de voix qui s'élèvent contre la complexité de sa stack). Moi j'ai eu mes déboires avec Stylus, je fais éviter de remettre ça. Mon critère principal étant de rester au plus près du CSS vanilla, donc l'inverse de ce que je faisais jusqu'à présent...
Au final j'ai fais : CSS vanilla > SCSS > Stylus > et retour à SCSS... Prochaine étape espérée : CSS vanilla (avec de la minification quand même).
PS : le link(rel=''preload') dédié à ta font provoque une erreur 404. Ton chemin /assets/fonts/calendas.woff2
devrait être /fonts/calendas.woff2
. Il y a eu confusion entre les dossiers "assets" et "public".
Bon week-end à toi également (enfin... ce qu'il en reste), et merci pour la coquille dénichée.
D'ailleurs en corrigeant cette erreur d'URL je me suis motivé à... laisser tomber Scss et passer à du CSS natif, il ne manquait vraiment plus grand chose puisque ViteJS concatène automatiquement les imports de fichiers CSS.
Mes deux seules frustrations à l'heure actuelle :
@layer
(ce qui m'aurait permis de supprimer tous les !important
de mon fichier de classes utilitaires). Mes essais foirent totalement et je ne vois pas pourquoi... j'en viens à croire que ce soit Vite qui ne soit pas compatible avec cette "techno".Bon, au final, après avoir passé deux ans sur Sass, 10 ans sur Stylus et cette semaine 3-4 jours sur Sass, j'ai jeté l'éponge des préprocesseurs pour toujours et suis passé sur PostCSS.
La raison fondamentale ? Pas une question de variables ou de fonctionnalités qui feraient défaut. Le nesting m'a fait prendre conscience d'une chose : on ne contrôle rien de la sortie. Je le savais déjà bien sûr (sur la transformation des couleurs par exemple, des nombres si constantes, faire attention au rendu des mixins, etc) et je faisais avec. Mais maintenant je me dis qu'il est dommage de ne pas pouvoir paramétrer la sortie (autrement qu'une histoire de décimales max. pour le nombres) : elle est déjà préétablie par le préprocesseur et ce paramètre n'est pas configurable. Mince.
Mais avec PostCSS si, on peut (avec son plugin "postcss-preset-env," le nouveau NextCSS). Et pour moi ça change tout.
D'autre part j'avais lu des articles de dev's proches du W3C, des community group, notamment l'un d'entre eux (elle, j'ai oublié qui...) qui disait de mémoire que "les minificateurs CSS ne devraient pas faire plus que de supprimer les espaces blancs et les sauts de lignes". Je suis en passe d'être d'accord, surtout lorsque je vois qu'avec un minificateur plus intrusif on ne gagne pas grand chose de plus au final (de l'ordre de 2%, il faudra que je teste).
Salut Raphaël,
Ah Ah ! Tu as mis ton site à jour...
Juste en passant, toi qui aime bien être au top : as-tu vu que Sass recommande depuis quelques temps d'éviter d'utiliser
@import
au profit de@use
? C'est surtout pour scoper la portée des variables d'un fichier à l'autre.@import
sera deprecated à terme (la dernière fois que j'ai consulté vos guidelines Alsa il était encore d'actualité).Chouette refonte. Quand j'ai lu que tu n'avais pas utilisé JavaScript je me suis empressé de chercher comment tu avais procédé pour faire apparaître la flêche
.to-top
au scroll :animation-range: 0 150dvh
. Merci pour l'astuce.Je mon côté, depuis quelques mois, je m'emploie moi aussi à utiliser Grid layout, les opérateurs logiques et les Container Queries . Pour ces deniers, contrairement à ce que je t'avais dis sur Alsacreations, je n'ai pas trouvé de bugs pour l'instant : mon problème provenait d'une utilisation à mauvais escient de variables CSS sur des containers parents qui impactaient sur les containers enfants.
Au plaisir de te lire sur les internets, Olivier C