HTeuMeuLeu

Shel Silvertstein, 1981

J’ai découvert il y a quelques mois que GitHub supporte les alertes en Markdown (« une extension Markdown basée sur la syntaxe blockquote que vous pouvez utiliser pour mettre l’accent sur des informations essentielles »). Ça permet concrètement de faire des blocs de citations colorés avec une icône spécifique. Et comme je suis incapable de me souvenir de la syntaxe, en voici un rappel.

> [!NOTE]
> Useful information that users should know, even when skimming content.

> [!TIP]
> Helpful advice for doing things better or more easily.

> [!IMPORTANT]
> Key information users need to know to achieve their goal.

> [!WARNING]
> Urgent info that needs immediate user attention to avoid problems.

> [!CAUTION]
> Advises about risks or negative outcomes of certain actions.

J’ai arrêté de suivre Gruber depuis un moment. Mais j’ai exceptionnellement écouté le dernier épisode de son podcast avec Louie Mantia. Et à environ 2:24, il raconte un truc sur Alan Dye (le Vice President of User Interface Design à qui l’on doit l’horreur qu’est Liquid Glass qui va nous tomber dessus le mois prochain) auquel je n’arrête pas de repenser.

J’ai eu un briefing avec Alan Dye et une poignée d’autres membres de la presse, la deuxième ou troisième année de l’Apple Watch. […] Et j’avais une question, parce que je pense qu’ils venaient de peaufiner dans la dernière version de watchOS la façon dont ils faisaient le rendu graphique.

Quand vous regardez une montre analogique, avec l’aiguille des heures, l’aiguille des minutes et l’aiguille des secondes, il y a un axe Z, même si watchOS a toujours été relativement plat. Et même si vous achetez une montre à quartz à 7 $ dans un magasin discount, sur chaque montre physique avec des aiguilles, les aiguilles sont superposées dans le même ordre. L’aiguille des minutes est au-dessus de l’aiguille des heures. Et s’il y a une aiguille des secondes, elle est au-dessus de l’aiguille des minutes. Ainsi on a les heures, minutes et secondes dans cet ordre. Et l’Apple Watch affiche les aiguilles dans le même ordre.

Mais ce n’est pas parfaitement plat. Et ils affichent une sorte d’ombre autour de choses pour que vous puissiez voir quand l’aiguille des minutes est légèrement au-dessus de l’aiguille des heures. Ce n’est pas tout à fait à la minute où elles se superposent. C’est genre une minute avant. Il y a une petite ombre pour les distinguer. Et j’avais une question à propos de la source lumineuse de cette ombre.

Et je me suis dit « oh, enfin, je vais pouvoir poser cette question à Alan Dye ». Et lui était comme : « Ah bon ? On affiche une ombre ? » Et je me suis dit : « Oh, il n’a jamais regardé. » J’ai immédiatement réalisé qu’il n’avait jamais regardé ça de près. Quelqu’un chez Apple l’avait fait. Mais ce n’était pas Alan Dye. Et je me souviens d’avoir pensé, à ce moment précis : « Oh, il ne fait pas ce que je pensais qu’il faisait. »

Nicolas pose une colle intéressante sur Mastodon. Pourquoi dans l’exemple suivant, sur Firefox, la première déclaration est ignorée mais pas la seconde ?

input[type="range"]::-webkit-slider-thumb {
  background-color: red;
}

input[type="range"]::-webkit-slider-thumb,
input[type="range"]::-moz-range-thumb {
  background-color: blue;
}

Les préfixes -webkit– sont normalement réservés aux navigateurs utilisant WebKit (Safari, ou tout autre navigateur sur iOS) et dérivés (Chrome et toute sa clique). On pourrait donc se dire que Firefox ignore simplement la première déclaration parce qu’il ignore les préfixes -webkit- et applique la seconde parce qu’il connaît les préfixes -moz-.

Oui, mais… (Parce qu’il y a forcément un mais sinon c’était trop facile.) En CSS, dixit MDN :

Un inconvénient des listes de sélecteurs est la non-équivalence des deux blocs suivants :

h1 {
  font-family: sans-serif;
}
h2:maybe-unsupported {
  font-family: sans-serif;
}
h3 {
  font-family: sans-serif;
}

h1,
h2:maybe-unsupported,
h3 {
  font-family: sans-serif;
}

En effet, un seul sélecteur vous manque et tout est dépeuplé. Enfin, un seul sélecteur invalide rend l’ensemble de la règle invalide.

Dans notre exemple initial, cela signifie que notre seconde déclaration (avec deux sélecteurs, dont un -webkit- inconnu pour Firefox) devrait aussi être ignorée.

Que se passe-t-il donc ?

Après quelques recherches, j’ai fini par trouver ! Dans la spécification CSS « Selectors Level 4 » :

Tout autre pseudo-élément dont le nom commence par la chaîne « -webkit- » et qui ne soit pas une notation fonctionnelle doit être traité comme valide au moment de l’analyse. (Cela signifie que ::-webkit-asdf est valide au moment de l’analyse, mais pas :-webkit-jkl().) S’ils ne sont pas reconnus et supportés, ils doivent être traités comme ne correspondant à rien, et sont des pseudo-éléments -webkit- inconnus.

CQFD.

Après avoir enchaîné plusieurs projets utilisant Tailwind CSS, je démarre en ce moment un nouveau projet n’utilisant que Sass. Et c’est assez libérateur. Mais il y a un petit truc de Tailwind CSS qui me manque : son fichier de config (tailwind.config.js).

L’idée n’a rien de nouveau et on n’a pas attendu Tailwind pour créer des variables. Mais jusque là, mes fichiers de variables en Sass ressemblaient plutôt à un fichier monolithique avec une queue leu-leu de variables, un peu comme celui de Bootstrap.

Voici comment j’ai procédé pour imiter le fichier de configuration de Tailwind CSS v3.0 en Sass.

Lire la suite de « Imiter le fichier de config de Tailwind en Sass »

S’il y a bien un truc qui m’énerve, ce sont les sites soit disant « éco-conçus » qui appliquent un effet de « dithering » (diffusion d’erreur en français, aussi parfois désigné comme un effet de tramage) sur leurs images.

Lire la suite de « Éco-conception et dithering »

Via cet article très intéressant de Robin Whittleton sur l’utilisation de polices personnalisées sur le site d’IKEA, je découvre la notion de « Tofu ».

Ce qu’il nous fallait était une nouvelle police de caractères qui accomplirait à la fois l’objectif de changer de la Verdana — une police qui fonctionnait bien sur les plateformes numériques — et qui pourrait aussi fonctionner dans n’importe quelle langue où nous offrons nos services. Par chance, il existe un choix facile pour une telle police : Noto Sans. Noto a été conçue par Google comme « une police pour le monde », avec le but ambitieux d’encoder tous les caractères de toutes les langues dans une police moderne. Le nom vient de « no tofu », où « tofu » désigne le nom donné aux carrés blancs qui s’affichent quand un caractère est manquant dans une fonte.

Nintendo a dévoilé la Switch 2 cette semaine. Dans la bande-annonce de présentation, j’aime beaucoup cette image pour expliquer la différence entre 60 FPS et 120 FPS.

Et après un mois de travail, le voici en ligne : https://unwebarchiver.hteumeuleu.com.

Tout a commencé en septembre dernier, lorsque j’ai commencé à donner des cours sur WordPress à des étudiant·es en première année de marketing. (Oui, j’ai bien choisi mon année.) En décembre arriva l’heure d’une première évaluation (qui consista à recréer une page sur WordPress d’après une maquette fournie).

Je me suis longtemps demandé sous quelle forme récupérer le travail réalisé, sachant qu’il me fallait non seulement pouvoir juger du rendu visuel final mais aussi de certaines particularités du code (comme la bonne utilisation de balises de niveaux de titres ou la présence de texte alternatif sur certaines images). J’ai finalement opté pour demander aux étudiant·es de m’envoyer une version de leur page web « Enregistrée sous » depuis leur navigateur.

Ma surprise fut totale lorsqu’en dépouillant les travaux reçus, la plupart était dans un format qui m’était inconnu : .webarchive.

Et le problème, c’est que je peinais parfois à ouvrir certains fichiers particulièrement lourds. J’ai alors cherché un outil pour extraire le contenu des dits fichiers. Je suis tombé sur WebArchiveExtractor, un utilitaire pour macOS, que je me suis empressé d’acheter mais qui ne fonctionne malheureusement plus sur les dernières versions de macOS. Pressé par le temps, j’ai fini par trouver des bidouilles où j’arrivais à afficher un aperçu visuel des fichiers problématiques dans le Finder et à obtenir le code HTML en ouvrant le fichier dans Xcode.

Tout est bien qui fini bien et j’ai pu rendre mes évaluations à temps en janvier.

Mais un petit truc me chiffonne quand même et me revient régulièrement en tête : c’est quoi, en fait, ce format .webarchive ?

Et c’est comme ça que je suis tombé sur cet article (« What’s inside a Safari webarchive? ») qui explique : un fichier .webarchive est un fichier .plist binaire. C’est le format proposé par défaut par Safari quand on « Enregistre sous » une page web. Et qu’est-ce qu’un fichier .plist ? C’est simplement une liste de propriétés. (C’est notamment ce qu’on obtenait quand on exportait sa bibliothèque iTunes — mais alors au format XML. #vieux)

J’étais alors motivé pour essayer de créer un lecteur de fichier WebArchive. Et après un mois de travail, de lecture d’octets gros-boutistes, d’appels récursifs infinis, le voici en ligne : https://unwebarchiver.hteumeuleu.com.

Et je suis content parce que du haut de mes vagues souvenirs de cours d’architecture informatique, ce projet m’a permis de… :

• Comprendre le format d’un fichier .plist binaire. (Cet article et cet autre article m’ont été d’une aide précieuse.) Et je trouve toujours la manipulation de données binaire aussi amusante.
• Apprendre qu’Apple a son propre « Epoch » défini au 1er janvier 2001. Et que les dates dans un fichier .plist binaire sont définies par rapport à cet Epoch. Et en secondes ! (Là où en JavaScript, les dates sont définies en millisecondes par rapport à l’Epoch du 1er janvier 1970.)
• Faire un outil web qui tient en 3 requêtes et moins de 8 Ko gzippés. Et ce, encore une fois, sans chercher à faire la moindre partie de golf.
• Utiliser la fonction CSS light-dark(). Je ne suis vraiment pas fan de cette fonction qui sonne résolument Googlesque et limite à deux options une préférence CSS (prefers-color-scheme) qui pourrait théoriquement s’éteindre à d’autres critères (sepia, niveaux de gris, …). Mais dans le cas d’un petit projet comme celui-ci, ça fait le taf.
• Apprendre comment convertir un entier décimal en sa version binaire ou hexadécimale en JavaScript. (Respectivement (1985).toString(2) et (1985).toString(16), qu’on peut coupler à un padStart(8, "0") pour avoir un bel affichage sur 8 bits.)
• Corriger une faute de frappe sur MDN.

Je ne sais pas si ce projet est voué à évoluer vu qu’il a atteint son objectif principal d’assouvir ma curiosité. Mais par contre, ça me donne très envie d’écrire un tutoriel pour lire des fichiers binaires en JavaScript tellement j’ai trouvé ça prenant.

Vu sur Mastodon : cette illustration de Gemma Correll en référence à La Princesse au petit pois.

Dans sa dernière vidéo, Technology Connections développe la notion de « complaisance algorithmique » (« algorithmic complacency » en anglais) : l’idée que le grand public utilise sciemment des réseaux sociaux aux flux algorithmiques parce que c’est plus simple.

Il donne l’exemple de Youtube, qui propose un flux d’abonnement, mais qui représente moins de 5 % des sources de vues de sa chaîne Youtube. (Contre près de 93 % pour la page d’accueil de Youtube et son flux algorithmique.)

J’aime beaucoup sa conclusion (à partir de 36:56) :

Soyons honnête : l’informatique est un problème résolu.

Je peux utiliser mon ordinateur de bureau de 2017 et faire ces vidéos pour vous et ça ne me gênerait pas du tout. Et le Mac Mini M2 de base à 600 $ que j’ai acheté pour traîner peut faire tout aussi bien.

L’encodage de vidéo devient plus efficace et nous avons besoin de moins de bande-passante et de stockage pour envoyer des vidéos comme ça à travers le monde. Et tout ça en dépit du fait que les connexions à Internet deviennent de plus en plus rapides.

Je pense que c’est assez clair que cette réalité est la raison pour laquelle la Silicon Valley fait les choses qu’elle fait aujourd’hui. Elle doit se justifier d’être un centre d’innovation dans un monde à court de piste. Et la meilleure réponse qu’elle a à offrir est… « euh les ordinateurs peuvent faire semblant de penser ».

Désolé, mais je veux penser par moi-même.
Et je pense que vous devriez également.

J’aime bien les sites web. Et je trouve qu’il y a un truc assez merveilleux de pouvoir naviguer sur un site conçu il y a vingt à trente ans. Il y a par exemple la toute première page web (1991) et le célèbre site du premier Space Jam (1996).

En 2023, Neal Agarwal a mis en ligne Internet Artifacts, une sorte de musée en ligne exposant différents artefacts marquants de l’Internet et du Web. Et chaque page web intégrée est « vivante », fonctionnelle et interactive. (Sans les éventuelles erreurs et manques laissés parfois par Archive.org.) Et je trouve ça fabuleux.

Je me suis demandé ce que ça ferait de restaurer un site web que j’ai connu dans mon enfance. Et, peut-être parce que je me suis remis à beaucoup jouer à la Playstation récemment, j’ai repensé au site du jeu Crash Bandicoot 3 (1998). J’étais déjà retombé sur le site, émerveillé, en 2015. Le site de 1998 était toujours en ligne, intact, dans son jus. Mais il avait malheureusement ensuite été supprimé à la résurrection de la licence en 2017.

Alors je me suis mis en tête de le restaurer.
Et voici le résultat.

Techniquement, ce n’était pas très compliqué. J’ai recherché chaque URL des quelques soixante-dix pages du site sur Archive.org. J’ai fait « Fichier > Enregistrer sous… » dans mon navigateur. J’ai nettoyé les fichiers HTML pour retirer les traces de Archive.org. Et j’ai réparé les liens pour que tout soit fonctionnel.

J’ai également ajouté une feuille de styles liée sur chaque page pour réduire la taille du texte. (J’imagine que le rendu de la police de base utilisée est légèrement différent de nos jours et rendait les textes trop grand pour leurs conteneurs.) Et j’ai appliqué un vilain hack pour centrer le site et le rendre facilement consultable sur mobile.

Je me suis limité à la restauration du site dans sa version HTML, et uniquement en anglais.

Et je suis plutôt content du résultat. Loin de me plonger dans une nostalgie réactionnaire (« C’était mieux avant »), ce site me fait réaliser les progrès réalisés depuis, que ce soit en terme de conception et d’ergonomie (je vous met au défi de représenter l’arborescence du site), de code (bonjour les balises <frameset>, <frame>, <font>, …) ou tout simplement de contenus (la galerie d’images avec les miniatures en 67×50 et la vidéo archi-compressée en 320×240).

Je trouverai ça très très chouette que la « restauration de site » devienne un concept en soi-même. Alors si vous avez le souvenir d’un site de votre jeunesse, essayez !

Lu via Jeff Atwood sur Mastodon :

Nous nous trouvons maintenant au sein d’un autre changement de communication de masse. Un changement où les algorithmes ont remplacé l’encre et les ondes. Et, tout comme les médias de masse du vingtième siècle ont créé le concept de consommateur il y a un cent ans, ce nouveau changement a redéfini comment nous interagissons avec le monde. Et accepter que ce changement est permanent, dans le sens où nous ne pouvons plus faire marche arrière, est, j’en suis convaincu, la seule voie à suivre. Nous sommes soit des influenceurs soit des influencés. Trump et ses copains comprennent ça très bien. Les Démocrates, clairement, ne le comprennent toujours pas.

[…]

C’est comme ça que les Démocrates sont arrivés somnambules dans la dernière élection, supposant qu’ils étaient toujours en train de vendre un produit — l’ancienne Vice Présidente Kamala Harris — à des consommateurs (nous). Alors que Trump et les Républicains ont très bien compris qu’ils mettaient en avant un influenceur — Trump — soit à d’autres plus petits influenceurs ou des membres de leurs publics (qui, bien sûr, rêvent probablement de devenir influenceurs eux-mêmes).

Voici trois faits concernant WordPress.

1. D’après un rapport quotidien du site W3Techs, WordPress est utilisé par 43,6 % des sites web au monde.
2. Le 12 octobre 2024, Matt Mullenweg (à la tête de WordPress.org — la solution open source — et WordPress.com — la solution privée d’hébergement) a unilatéralement repris le contrôle de l’extension Advanced Custom Fields (ACF). L’extension est développée par WP Engine, une autre solution d’hébergement de WordPress, concurrente de WordPress.com. Depuis septembre, Mullenweg est parti complètement en vrille contre WP Engine, initialement pour un litige autour de l’utilisation de la marque « WordPress ».
3. Le 20 janvier 2025, en commentaire à un tweet de Matt Mullenweg se félicitant que le nouveau site de la maison blanche du gouvernement de Donald Trump tourne sur WordPress, le compte officiel @WordPress déclare « We stand ready to serve. 🫡 » (ce qui peut se traduire par « Nous sommes à votre service. », affublé d’un emoji de salut militaire).

Qu’est-ce qui pourrait mal tourner ?

En 2010, en créant ce blog et le feu-compte Twitter qui allait avec, je m’étais aussi créé un compte Google Apps gratuit pour avoir une adresse mail associée à mon domaine. Peu de temps après, je m’étais aussi créé un compte Youtube avec mon adresse e-mail de mon propre domaine. (À l’époque, les comptes Google et Youtube n’étaient pas unifiés.)

Avance rapide jusqu’en janvier 2022 où Google annonce l’arrêt de sa versions gratuite de G Suite. Je bascule alors mes mails chez Migadu (et j’en suis très content). Et je n’ai alors plus aucune utilité de mon compte G Suite, que je compte laisser mourir de sa belle mort quand Google en aura ainsi décidé.

Avance rapide jusqu’en novembre 2024. Après des mois de relance et de rappel de Google pour m’avertir de la fermeture prochaine et définitive de mon compte G Suite, Google m’informe que ça y est, c’est fait. « Tant mieux », me dis-je, n’en ayant plus aucune utilité.

Sauf que dans le tas, tous les services Google associés à l’adresse e-mail que j’utilisais sont eux aussi supprimés. Et ça vaut donc pour mon compte Youtube.

Je m’en servais assez peu. Mais j’aimais bien avoir ce petit espace où je rassemblais toutes mes représentations en conférence, des rediffusions de mes rares lives sur Twitch, quelques enregistrements pour illustrer certains articles, et un essai infructueux de carrière de Youtuber.

Ce qui m’embête le plus, c’est que je n’ai pas vraiment de sauvegarde de tout ça. En creusant, je peux probablement retrouver certaines conférences diffusées ailleurs. Mais je ne suis pas sûr du tout d’avoir conversé les fichiers sources de tout le reste. Et j’ai aussi un peu la flemme et la fatigue de rechercher tout ça.

J’ai bien tenté de contacter le service client de Youtube qui m’a gentiment expliqué qu’il n’y avait rien à faire.

Ainsi soit-il.

Cette fausse couverture issue du numéro 41 de février 2025* de MAD Magazine est formidable.

*Je suis toujours émerveillé devant l’absurdité des dates de publication américaines, où la course à être le premier à sortir son édition du mois pousse à sortir son numéro de février 2025 en décembre 2024.

Aujourd’hui, j’ai appris que le « My » de « MySQL » n’est pas un article possessif mais une référence au prénom de la fille ainée de son créateur, Michael Widenius. « My », comme « Little My » (Petite Mu en français) dans les Moomins.

Suite à une conversation avec un collègue, la question « pourquoi ces fichiers tout nuls s’appellent .DS_store ? » est survenue. Et je me suis souvenu de cet article de 2006 :

En 1999, j’étais le technical lead pour le Finder de Mac OS X chez Apple. À cette époque, la base de code du Finder avait huit ans et avaient atteint sa fin de vie. Faire le moindre changement demandait d’énormes efforts d’ingénierie, et le moindre changement cassait généralement deux ou trois trucs sans rapport en apparence. Pour Mac OS X, nous avons décidé de réécrire le Finder de zéro.

Une partie du travail impliquait de séparer son interface utilisateur de ses fonctionnalités, son back-end. Le back-end du Finder énumérait les fichiers, regardait les changements dans le système de fichier, gérait les métadonnées, comprenant l’emplacement des icônes et les réglages des dossiers. En interne, ces deux composants étaient connus sous les noms de Finder_FE et Finder_BE (Front-end et back-end).

Cependant, on s’est vite rendu compte que le back-end du Finder allait être utile en dehors du Finder. Ainsi est né le plan de le rendre un jour disponible en tant qu’API publique. Vu que j’étais responsable des noms « Icon Services » et « Navigation Services », on a décidé de partir sur « Desktop Services ». (À l’époque, on envisageait de renommer le Finder en « Desktop »). D’où le nom de .DS_store, pour « Desktop Services Store ».