HTeuMeuLeu

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.