retour

🕰️ Des détails sur encemoment.site

Je viens d’ajouter un truc en bas de ma page 🪴 En ce moment. Celleux d’entre vous qui naviguent depuis longtemps auront reconnu la forme de cet élément de navigation : comme à la fin des années 90’, j’ai rejoint un webring. Et pas n’importe quel webring, celui-ci regroupe des pages /en-ce-moment.

Samedi, devant le temps maussade et le froid à l’avenant, je n’avais que le ménage comme perspective pour m’occuper. Depuis quelques semaines je discute sur Mastodon du sujet des pages /now (ou /en-ce-moment) avec tout un tas de gens sympa qui ont aussi un site perso ; la liste de leurs pages en fin de mon billet sur le sujet faisait penser à une blogroll, ou en remontant plus loin, à un webring. Tout à coup, j’avais un truc pour m’occuper.

Pour moi faire un site web, c’est comme un céramiste qui se fait un nouveau bol pour tester un émail, une forme. C’est comme une menuisière qui fabrique une boîte pour les simples plaisirs de l’exploration ou d’utiliser ensuite un objet fait par soi. “Scratching an itch” comme on dit en anglais, gratter quand ça démange.

On pourrait croire que j’ai une obsession spécifiquement pour les pages /en-ce-moment. C’est pas le cas, j’utilise ce concept pour revenir à l’usage des sites perso. Y revenir moi-même, et peut-être diffuser la bonne parole. Le but était avant tout de m’amuser et d’expériementer. Voilà quelques détails d’implémentation, si vous êtes curieux·se.

Eleventy

La base de cette idée, c’était de faire une liste, un peu comme sur nownownow.com, avec moins d’autopromo et plus de fun. Je voulais que tout le monde puisse proposer l’ajout de son site.

Ce genre de page n’a pas besoin d’une infrastructure incroyable. Une simple page HTML fait l’affaire, à condition d’être mise à jour pour chaque ajout de lien. Une bonne solution pour ça, c’est d’utiliser un générateur de site statique : les données sont stockées dans des fichiers texte, le HTML est généré une fois de la même manière pour tous les visiteurs, et peut être servi par un serveur très basique.

Le générateur que j’ai choisi pour ce site, c’est Eleventy. Il tourne dans un environnement node, il est rapide et laisse une très, très grande liberté pour concevoir un site. De base, on part de rien, et on construit exactement ce dont on a besoin. Voilà quelques principes que j’ai utilisés, je ne pense pas les détailler (ce billet sera assez long comme ça), mais je suis ouvert aux questions et demandes de précision.

  • chaque site est stocké dans une page .md, dont on utilise seulement le frontmatter
  • en plus des données spécifiques à chaque lien, j’utilise un fichier de données communes à tous les liens, notamment pour gérer le réglage de la date et l’absence de génération de page spécifique à chaque lien (permalink: false)
  • j’utilise la date de premier commit d’un fichier comme date d’ajout du lien, via l’option date: "git Created"
  • les styles CSS sont au plus simple :
  • pas de JS, pas de tracking, pas de bannière de cookie (on n’est pas des bêtes)
  • la liste est générée dans 11ty par un shortcode, ça aurait peut-être été l’occasion de plonger dans WebC ou autre, mais j’ai préféré ne pas trop compliquer les choses. Les complications doivent provenir d’une limite atteinte, pas d’une envie de complexifier les choses (sinon on arrive à l’art Rococo, c’est pas trop mon truc)

Au final, 11ty fait très bien le boulot : c’est flexible et rapide, ça correspond pile à ce que j’attendais.

Webcomponent du Widget de Webring (WcWW)

Le widget de Webring, celui dont je parle au début de ce billet, est aussi généré par 11ty.
Plus exactement, la liste des pages est peuplée lors de la compilation 11ty, le reste du script est du JS.

La méthode qui m’a parue la plus pertinente pour insérer un contenu un peu complexe dans une page a été via un Web Component isolé du DOM. Son isolation (via le Shadow DOM) permet que les styles de la page ne viennent pas le polluer, et réciproquement que les styles du widget ne transpirent pas sur la page.

J’ai cependant eu un problème : si je voulais ajuster les styles du widget pour correspondre à ceux de mon site perso, il fallait que je puisse exposer les éléments au CSS externe au Shadow DOM. J’ai pu découvrir l’attribut part en HTML et le sélecteur CSS ::part(), qui permettent de cibler et styler chaque élément du widget.

Les WebComponents c’est bien, mangez-en utilisez-en.

Mise à jour des updates, update des mises à jour

Le dernier élément que je souhaiter intégrer au site, c’était la mise à jour automatique de la liste, et le tri des pages en fonction de la date de dernière modification.

Pour ça, pas de secret, il faut aller regarder toutes les pages et chercher s’il y a une date de dernière modification. Le script fait juste ça. L’algo est très (peut-être trop ?) simple :

  • on recherche la valeur de l’attribut content des balises meta suivantes :
    • property="og:updated_time"
    • itemprop="dateModified"
    • property="article:modified_time"
  • ainsi que les valeurs de tous les attributs date ou datetime des éléments qui en portent

On trie cette liste de dates, et on prend la plus récente. Le problème pourrait être si quelqu’un configure un de ces attributs pour retourner la date de l’instant de la requête. Ce genre de choses est idiot (la preuve, j’y ai pensé) et inacceptable (vu que je l’ai prévu) et résulterait dans la suppression du lien du site.

Pour l’instant le script est déclenché par une Github Action chaque jour à 10h du matin (heure de Paris), et il ouvre une PR s’il y a des changements à appliquer aux dates. Ça me permet de contrôler que tout se passe bien.

Dans les évolutions :

  • si tout se passe bien je pourrai brancher l’action pour qu’elle ajoute directement les nouvelles dates (sans vérification de ma part)
  • en cas d’erreur de chargement (erreur 404, serveur qui n’existe plus…) je pourrai ralentir la fréquence de vérification, et lister différemment les pages en erreur

On en discute ?…

Billets liés