Notes

Je suis tombé sur cet article de Karim Jedda et je suis resté scotché.

Voici le truc : on a construit Internet avec logins par e-mail, mots de passe, et formulaires bancaires archaïques. Tout paraît fragile, intrusif, mal foutu. Mais c’est pas juste technique : c’est un produit de commodité, de paresse collective. Comme si, au lieu de créer un outil simple, sécurisé, privé, on a préféré le moindre effort, ce qui coûte cher à terme.

Ce que je retiens le plus, c’est cette idée géniale que le bon système ne gagne pas parce qu’il est plus intelligent, mais parce qu’il est plus léger. On s’en fout de la tech la plus safe du monde si c’est une galère pour l’utiliser. Le vrai challenge est là : construire des outils qui te laissent maître de ton identité, sans te demander d’être un expert en sécurité ou crypto.

Pas de promo sauvage, pas de jargon de startup. Juste une question qui t’effleure la tête : et si, au lieu de taper des mots de passe, tu validais juste avec un toucher ? Un système où tu paies d’un geste, comme filer du liquide, mais numérique. C’est simple, léger, et puissant. L’idée n’est pas de faire de toi un pro de crypto, juste de rendre le bon choix confortable. Je trouve ça beau, et urgent.

On sous-estime la longueur de ligne. Dès que la ligne devient trop longue, l’œil se perd, on relit, on décroche. La règle pratique : rester sous ~80 caractères, idéalement dans la zone 60–70. En CSS, c’est bête comme max-width: 65ch sur le bloc de texte. Simple, robuste, lisible. 

Ensuite, je veux une taille qui s’adapte sans faire le yo-yo : font-size: clamp(1rem, 1.2vw + 0.2rem, 1.25rem). Ça donne une typo fluide, bornée, sans surprise. Et si l’UI est component-driven, j’utilise les unités de requête de conteneur (cqi, cqw) pour que chaque carte garde sa cohérence, indépendamment du viewport. 

Dernier point : “remplir” un container avec du texte. Il y a plusieurs approches : responsive type avec clamp(), requêtes de conteneur pour affiner par composant, et, en dernier recours, un peu de JS si tu dois vraiment auto-ajuster au pixel près (genre titres très courts qui doivent occuper toute la largeur). Le bon choix dépend du contexte, mais la base ne change pas : longueur de ligne confortable d’abord, micro-ajustements ensuite.

On sous-estime souvent le pouvoir des images dans un texte long. Pas seulement pour “illustrer” une idée, mais pour créer un rythme, installer des respirations, parfois même provoquer une surprise.

Un bloc de texte dense fatigue vite. Le cerveau décroche. Mais si on ose placer une image de travers, en plein milieu, ou dans un format qui casse la ligne, tout change : la lecture se relance, l’œil se réveille. C’est comme une ponctuation visuelle.

Ça demande un peu de culot, et surtout de sortir des habitudes “image centrée, légende en dessous”. Mais c’est là que ça devient intéressant : quand la mise en page raconte autant que le contenu.

Bref, jouer avec les images, c’est jouer avec la perception. Et pour un article long, c’est peut-être le meilleur moyen d’éviter qu’il reste… long.

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

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.