Ange Chierchia

Développeur Web full-stack

Notes

  • Un-Sass’ing my CSS

    Bookmarked Un-Sass’ing my CSS | Always Twisted.

    Ça m’a fait sourire. On a tous eu notre période Sass : mixins partout, variables, nesting à outrance. C’était grisant, ça donnait l’impression d’être plus « pro ». Mais le temps passe, le CSS a grandi, et beaucoup de ces artifices ne servent plus à grand-chose.

    L’article raconte ce cheminement : désapprendre Sass pour réapprendre le CSS brut. Pas comme une régression, mais comme un gain de clarté. Quand tu enlèves la couche intermédiaire, tu te rends compte que ton code respire mieux, que le navigateur fait déjà pas mal de choses tout seul.

    Ça m’a fait réfléchir à ma propre boîte à outils. On accumule, on optimise, on complexifie… et puis un jour on redécouvre que la simplicité, c’est aussi une forme de puissance. Peut-être qu’au fond, le vrai luxe en dev, c’est d’avoir moins à maintenir.

    Un rappel utile : parfois, coder mieux, c’est surtout coder moins.

  • CSS-only scrollspy effect using scroll-marker-group and :target-current

    Bookmarked CSS-only scrollspy effect using scroll-marker-group and :target-current.

    On connaissait les “CSS Carousels”. Voilà le pendant qui m’intéresse vraiment : un scrollspy lisible et accessible, sans JavaScript. L’idée : garder une table des matières sémantique (une liste de liens vers les sections), activer scroll-target-group sur le conteneur, puis utiliser :target-current pour styler le lien dont la section est visible. Résultat : un état actif natif, pas de classes à bidouiller, et moins de code à maintenir.

    Ce que j’aime : on n’invente rien côté HTML. Le <nav> reste un vrai <nav>. Les liens, de vrais liens. Le comportement “actif” vient de CSS et du navigateur. C’est propre, ça respecte l’accessibilité de base, et ça colle à l’intention : guider la lecture, pas jouer au carrousel.

    Nuance utile : c’est neuf, support encore partiel, donc à prototyper avant de livrer en prod. Mais la direction est bonne. On remplace une logique JS souvent fragile par une API CSS pensée pour ça. Et ça, c’est le genre d’évolution qui rend le front agréable : moins de friction, plus de sémantique, meilleur UX par défaut

  • CSS Relative Colors

    Bookmarked CSS Relative Colors by Ahmad Shadeed.

    Le “Relative Color Syntax” change la façon dont on pense nos palettes : on ne stocke plus des variantes figées, on décrit des relations. En clair : une seule source (–brand) et des dérivés cohérents pour hover, focus, borders, badges… avec color(from …). Tu ajustes luminosité, saturation, alpha ou canal par canal sans bricoler des HSL magiques ni multiplier les tokens.

    Ce que j’aime dans l’article : il reste ancré dans le réel. Des exemples lisibles, des patterns qu’on rencontre tous les jours (états de boutons, overlays, dégradés, dark mode) et surtout une logique de design system : la couleur devient une fonction, pas une valeur. Tu peux faire évoluer ta teinte de base sans réécrire la moitié du CSS. Et les deltas (légèrement plus sombre, un peu plus saturé) gardent la cohérence de marque.

    Pragmatiquement, je vois trois gains : 1) moins de variables à maintenir, 2) des thèmes plus fiables, 3) une accessibilité plus maîtrisée (contrastes ajustables sans casser l’identité). Mon conseil : commence petit. Définis 1–2 couleurs sources, dérive –brand-hover, –brand-outline, –surface-elevated avec color(from …), et observe la simplification. Une base solide, des variantes “calculées”, et un design qui respire.

  • Creating CSS Theme Variables from a JS file

    Bookmarked CSS { In Real Life } | Creating CSS Theme Variables from a JS file.

    Les design tokens, c’est la promesse d’une cohérence. Mais dans la pratique, on se retrouve souvent avec un fichier SCSS, un fichier JS, un fichier Figma… et des incohérences qui s’accumulent. L’idée proposée ici est toute bête mais super efficace : un seul fichier JavaScript, qui définit tes tokens (couleurs, tailles, etc.), et qui crache directement des variables CSS prêtes à l’emploi. Plus besoin de jongler, tout le monde boit à la même source.

    Ce que j’aime, c’est la simplicité. Pas besoin de grosse usine à gaz ni de tooling lourd façon “style dictionary”. Tu écris tes valeurs une fois, tu génères les :root { –variable: valeur }, et basta. Côté dev, tu consommes les tokens en JS et en CSS sans jamais les dédoubler.

    Ça ne remplacera pas une infra complète pour une grosse équipe produit, mais pour un projet à taille humaine, c’est pile le bon compromis : un point de vérité unique, une synchro JS/CSS sans douleur, et une dette technique évitée dès le départ. Bref, ça mérite d’être testé sur ton prochain side project.

  • Why I’m Writing Pure HTML & CSS in 2025

    Bookmarked Why I’m Writing Pure HTML & CSS in 2025.

    Je suis tombé sur ce billet de Joel Dare qui explique pourquoi il écrit (de nouveau) des sites en pur HTML et CSS en 2025. Pas de build, pas de tooling, pas de JavaScript. Juste des fichiers statiques, lisibles, maintenables, pérennes.

    Et franchement, ça m’a parlé.
    Pas juste parce que je suis nostalgique du web d’avant, mais parce qu’au fond, on passe notre temps à complexifier des trucs simples. On ajoute des outils pour compenser d’autres outils, on encapsule des composants qui ne font qu’appeler d’autres composants, et on finit par passer plus de temps à lire la doc qu’à coder.

    J’ai eu ce déclic moi aussi, plus d’une fois. Cette envie de tout jeter, de repartir de zéro, avec juste un `index.html` et une feuille de style. Et ça fait un bien fou.

    On n’est pas obligé de tout faire simple tout le temps, mais savoir qu’on peut… c’est déjà une libération.

  • vendredi 15 août 2025 @ 21:34:53

    Premières armes sur GitHub Actions la nuit dernière et aujourd’hui. J’ai passé mon CV en Eleventy avec build, création de la version PDF et déploiement sur OVH automatique à chaque commit sur la branche `master`.

    Ça devait être relativement simple à la base, mais finalement non, pas mal de petites galères, notamment avec la génération de PDF, mais maintenant c’est réglé et ça fonctionne du feu de Dieu ! 🎉

  • jeudi 14 août 2025 @ 15:05:08

    Je crois que je deviens vieux, j’écoute Les Grosses Têtes en podcast… Et j’aime bien ! 😱

  • Bringing Back Parallax With Scroll-Driven CSS Animations

    Bookmarked https://css-tricks.com/bringing-back-parallax-with-scroll-driven-css-animations/.

    Franchement, j’avais enterré le parallax avec les carrousels autoplay et les splash pages en Flash. Mais là, j’ai été surpris.

    Avec les scroll-driven animations, le truc retrouve une seconde vie : fluide, natif, et surtout sans les usines à gaz JS d’avant.

    L’article de CSS-Tricks décortique la méthode avec pédagogie en mode : t’as une timeline liée au scroll, tu cales tes keyframes dessus, et roule ma poule.

    Ce que j’ai aimé, c’est qu’on n’est plus dans le « waouh » pour faire waouh.

    C’est clean, subtil, et ça s’intègre bien dans un design qui respecte l’utilisateur.

    Tu peux même jouer avec la perspective ou l’échelle d’un élément selon sa progression dans la page, sans flinguer les perfs.

    Bref, si t’avais lâché l’affaire avec le parallax, c’est le bon moment pour t’y remettre.

  • A Few Things About the Anchor Element’s href You Might Not Have Known

    Bookmarked A Few Things About the Anchor Element’s href You Might Not Have Known by Jim Nielsen.

    On croit tous connaître l’attribut href… jusqu’à ce qu’on se rende compte qu’il peut pointer vers bien plus que des URL classiques.

    Jim Nielsen explore ses usages “hors norme” : liens vers un téléphone (tel:), un email (mailto:), un fichier local, une ancre interne, un protocole personnalisé… et même des trucs qu’on n’utilise presque jamais, mais qui peuvent ouvrir des possibilités créatives (ou créer de sacrées failles si c’est mal géré).

    Petit rappel que même les balises HTML les plus banales ont des recoins insoupçonnés.

  • Web Components: Working With Shadow DOM

    Bookmarked Web Components: Working With Shadow DOM — Smashing Magazine.

    Je suis longtemps passé à côté du Shadow DOM. Trop abstrait, trop “spec moderne” pour mes besoins du quotidien.

    Mais cet article m’a recadré.

    Il explique comment le Shadow DOM te permet d’encapsuler un composant comme un vrai bloc isolé : pas de fuite de styles, pas de conflits de noms, pas de comportements JS qui partent en sucette.

    Et ça, dans une époque où chaque lib veut imposer sa logique, ça fait du bien de voir un truc standard qui tient la route.

    On n’est pas obligés de tout reconstruire avec Web Components demain matin, mais piger comment le Shadow DOM fonctionne, c’est clairement un level-up pour écrire du code plus robuste — et plus pérenne

  • samedi 09 août 2025 @ 15:20:54

    Voilà voilà. Ça changera pas ma vie, ni la vôtre d’ailleurs, mais au moins je peux partager une note rapidement comme ça 😅

  • samedi 09 août 2025 @ 15:16:26

    Bon bah mon raccourci iOS pour publier à la fois sur mon blog et Mastodon fonctionne ✌️