Bookmarks

Quand j’ai lu le billet du gars de LapcatSoftware, j’ai eu ce petit frisson “yeah, ça, ça a du sens”.

Il explique qu’il vaut mieux désactiver les pointer-events sur les images utilisées comme liens — notamment les badges “Download on the App Store”. Sur iOS, la feature « Live Text » crée un bordel : quand tu tapes longuement sur l’image, tu tombes sur… la sélection de texte, pas le lien. Résultat, l’UX est foirée pour les utilisateurs de Safari iOS. 

Alors le taf, c’est simple : tu rends l’image non-clickable (pointer-events: none;) et tu t’assures que l’anchor parent a un display: inline-block — comme ça le lien est cliquable sur toute la surface de l’image, comme un lien normal. 

Moi ce que j’aime, c’est ce genre de petit coup de polish à la dev front-end : ça prend 2 secondes, mais ça améliore l’expérience utilisateur — surtout sur mobile. Si t’es comme moi, “pixel perfect” ça te parle. Le genre de détail qu’on zappe souvent, mais qui compte.

Andy Bell balance des principes solides pour les autodidactes du front. J’aime bien son approche parce qu’elle casse l’idée qu’il faut tout savoir pour être légitime. Il insiste sur la simplicité d’abord, les fondamentaux avant les frameworks, et surtout : résoudre des vrais problèmes plutôt que d’accumuler des technos sur son CV.

Ce qui me parle le plus, c’est son conseil de pas se laisser impressionner par la complexité des autres. On a tous tendance à croire que les devs « officiels » maîtrisent tout sur le bout des doigts, alors qu’en vrai, personne ne sait tout. L’impostor syndrome, ça touche tout le monde, diplômé ou pas.

Il rappelle aussi qu’être autodidacte, c’est souvent avoir développé une capacité d’apprentissage autonome qui vaut de l’or. Ça forge une débrouillardise que les cursus classiques n’offrent pas toujours. Bref, un article qui fait du bien à l’ego et qui recentre sur l’essentiel : construire des trucs qui marchent, proprement.

Coup de cœur pour cet article de Manuel Matuzović. Le gars attaque un vieux serpent de mer : “Pourquoi je ne peux pas utiliser mes variables CSS dans des media queries ?”. Réponse : parce que la spec dit non. Mais il montre une combine plutôt élégante : passer par les container style queries avec @property et une petite dose de min() ou max().

Ce que j’aime : ce n’est pas du bricolage crado, c’est presque une avant-première de ce que CSS pourrait nous offrir. On garde les variables, on les manipule, et soudain tes breakpoints deviennent bien plus souples. Pas besoin de réécrire tes valeurs partout, tu centralises, tu adaptes.

Évidemment, ça reste un workaround, pas encore une solution universelle (support limité, syntaxe pas anodine). Mais franchement, ça ouvre une porte. Et moi, dès qu’un article me fait entrevoir ce genre d’horizon pour le futur du CSS, je souris bêtement devant mon écran.

J’avais déjà commenté son article précédent sur la désintox de Sass, et voilà la suite logique : gérer ses CSS imports proprement. J’aime bien sa façon de montrer qu’on peut revenir à des solutions simples, natives, sans forcément réinventer la roue. Ce n’est pas un manifeste contre Sass, c’est plutôt une mise en avant du côté pratique d’`@import` moderne.

En lisant ça, je me dis que je passe encore trop de temps à sur-ingénier mes setups. Parce que oui, compiler dix fichiers dans un seul, ça paraît bête, mais c’est ce qu’on fait tous les jours. Et c’est rassurant de voir quelqu’un dire “tu peux le faire avec les outils du langage, sans mille dépendances”.

Ce qui me plaît le plus, c’est ce ton tranquille : pas de dogme, pas de “il faut faire comme moi”. Juste : regarde, ça marche, c’est plus simple, tu peux essayer. Et moi je me retrouve à hocher la tête bêtement en me disant : “ok, j’ai compris la leçon, less is more”.

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.