Catégorie : Bookmarks

phpMyAdmin, c’est un peu l’outil qu’on oublie jusqu’au moment où tout part en vrille. L’article rappelle trois trucs super pratiques : corriger les URL cassées après une migration (parce qu’on a tous déjà galéré avec ça), nettoyer les révisions qui bouffent la base, et réparer les tables corrompues en deux clics. Ce qui me plaît, c’est que c’est direct et sans bullshit. Pas de plugin miracle à installer, juste une connexion à la base et quelques requêtes SQL bien senties. C’est le genre de conseil qu’on donne à un pote qui flippe devant son site planté. Bon, évidemment, faut pas jouer avec la base les yeux fermés. Backup d’abord, explore ensuite. Mais franchement, phpMyAdmin reste un couteau suisse indispensable quand WordPress fait sa crise. Ça rassure de savoir qu’on peut encore mettre les mains dans le cambouis.

Alors là, je dois dire que @scope me parle vraiment. J’ai passé des années à jongler avec BEM, SMACSS, et toutes ces conventions de nommage qui finissent par te donner l’impression d’écrire du morse plutôt que du CSS. L’idée de pouvoir scoper du CSS natif sans avoir à préfixer chaque classe avec le nom du composant trois fois, c’est exactement ce qu’il me fallait.

Ce qui me botte, c’est que ça reste lisible. Pas de .card__header–modifier à rallonge. Juste du CSS qui dit clairement “ça s’applique dans ce contexte, point final”. Et le support navigateur est déjà là pour une bonne partie. Bon, évidemment, il faut un peu de temps pour que tout le monde suive, mais l’approche progressive me va bien.

Je pense tester ça sur mon prochain side project, histoire de voir comment ça se comporte dans la vraie vie. Parce qu’en vrai, les conventions c’est bien, mais si le langage peut gérer le problème nativement, pourquoi se compliquer la vie ?

Andy Bell propose une solution élégante pour contourner l’interdiction HTML d’imbriquer des éléments interactifs : créer une fausse zone cliquable qui reste accessible. L’idée, c’est d’utiliser un pseudo-élément positionné en absolu qui couvre toute la card, tout en gardant les vrais boutons ou liens interactifs au-dessus via z-index. Ça évite le balisage dégueu avec des <div> cliquables partout.

Ce qui me plaît, c’est que ça reste propre côté DOM et que l’accessibilité n’est pas sacrifiée sur l’autel du design. Pas de role="button" sur des trucs qui n’en sont pas, pas de JavaScript tarabiscoté pour gérer les clics. Juste du CSS malin et un peu de réflexion sur la hiérarchie des interactions.

Bon, faut quand même faire gaffe : si tu multiplies les zones cliquables imbriquées, ça peut vite devenir le bordel pour l’utilisateur. Mais pour une card avec un lien principal et quelques actions secondaires, c’est nickel. Andy donne même un exemple concret avec du code commenté, ce qui aide à bien piger la mécanique. Bref, une technique à garder dans un coin.

On a tous galéré avec `Date()` en JavaScript. Les fuseaux horaires qui décalent tout, les calculs foireux, les librairies tierces pour compenser. Bref, un bordel.

Temporal arrive enfin pour régler ça. Une API moderne, pensée dès le départ pour gérer proprement les dates, heures, durées et fuseaux. Fini de bidouiller avec des +86400000 pour ajouter un jour, fini les bugs silencieux quand on change de timezone.

Ce qui me plaît surtout, c’est la clarté : `Temporal.PlainDate`, `Temporal.ZonedDateTime`, `Temporal.Duration`… Chaque type a son rôle, pas d’ambiguïté. Tu sais ce que tu manipules. Et les méthodes sont intuitives, cohérentes.

Le support navigateur progresse doucement, mais ça vaut le coup de s’y intéresser maintenant. Parce que franchement, quand ça sera là partout, on se demandera comment on a pu vivre avec l’ancien système.

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”.