Mon fichier de référence pour EVA CSS affirmait que les tailles de police s’écrivent var(--24). C’est var(--fs-24). Les deux existent, ils ne clampent pas pareil, et j’ai publié cette phrase pendant des mois.
Je l’ai découvert en écrivant autre chose : une documentation, dix chapitres, à la place du llms.txt vers lequel le site pointait. 31 liens sortants vers des fichiers .md et .txt, huit pages qui portaient un encart « Pour ton assistant IA, ouvre /llms.txt ». Le site ne documentait rien, il indiquait la sortie.
Personne ne relit un fichier écrit pour les machines
Je ne vais pas faire semblant d’avoir été forcé : cette solution m’arrangeait. Un framework CSS, c’est une échelle de tokens et des classes utilitaires, de la matière régulière qu’un modèle avale bien. Et celui qui installe EVA CSS aujourd’hui ouvre rarement une page de documentation, il décrit ce qu’il veut à un assistant. Écrire pour la machine qui va écrire le code, ça ressemblait à écrire à la source.
Sauf qu’un fichier destiné aux machines n’a pas de lecteur. Personne ne le relit, personne ne vient dire que la phrase 40 est fausse. Il dérive, et rien ne remonte. « Collez ce fichier dans votre IA, elle vous expliquera » n’est pas une documentation, c’est une façon de se dispenser d’en écrire une.
Le CSS ignore ce qu’il ne comprend pas
Le même fichier documentait des préfixes utilitaires m-, mx-, my-. Ils n’existent pas. Et mon propre site utilise maw-768 et lh-1-5 sur des dizaines d’éléments, deux classes qui ne sont nulle part dans le framework. Elles n’ont jamais rien fait.
Rien n’a jamais protesté, et c’est normal. Une custom property indéfinie ne produit aucune erreur : la substitution échoue, la déclaration devient invalide au moment du calcul, la propriété retombe sur sa valeur héritée. Une classe absente ne correspond à aucun sélecteur. Le CSS est conçu pour ignorer ce qu’il ne comprend pas, c’est ce qui permet aux navigateurs d’avancer sans casser le web derrière eux. Le prix à payer, c’est qu’une documentation fausse ne produit aucun symptôme.
Un modèle qui lit cette documentation la reproduit fidèlement. Il ne teste pas, il écrit var(--24) parce que c’est ce que dit la référence officielle. La page s’affiche, les tailles sont presque bonnes, et personne n’ouvre une console vide. J’avais écrit un fichier fait pour être lu par des machines, et je l’avais rempli d’erreurs qu’aucune machine ne peut détecter.
Trois bugs sortis de la fabrication des pages
Le reste est venu en construisant les chapitres. Une documentation demande à un site des choses qu’aucune page de présentation ne demande.
Une règle globale pre { white-space: pre-line !important } écrasait l’indentation de tous les blocs de code, ce qui ne se voit pas tant qu’on n’affiche pas un exemple sur plusieurs niveaux. Une règle globale nav { position: fixed } capturait les <nav> de la documentation : le sommaire et la pagination partaient se coller en haut de la page. Et container-type: inline-size sur <body> coupe la propagation de l’overflow au viewport, ce qui privait les colonnes sticky de scrollport sur mobile. Ce dernier point est un détail de spécification que je ne connaissais pas, et sans deux colonnes longues à faire cohabiter je ne serais jamais tombé dessus.
Chaque phrase doit dire où c’est écrit dans le code
Une documentation écrite sérieusement oblige à répondre « où est-ce écrit dans le code ? » pour chaque affirmation. Pas de mémoire, pas au jugé : le fichier, la ligne. Cette contrainte transforme la rédaction en passe de vérification sur tout le produit, et c’est elle qui a trouvé les bugs, pas moi.
Un fichier déversé à l’intention d’un modèle ne demande rien de tel. On écrit ce qu’on croit savoir, le modèle reformule proprement, et la propreté de la reformulation donne l’illusion de la justesse. Le texte n’est jamais confronté au code.
/llms.txt n’a pas disparu pour autant. Il est devenu un artefact de build, généré depuis le même markdown que les pages : toujours servi aux robots, plus aucun lien vers lui depuis le site, et incapable de diverger. Les liens entre chapitres s’écrivent doc:chapitre#ancre et sont validés à la compilation, une ancre inexistante casse le build. La documentation est traitée comme du code, parce que c’en est.
Depuis, aucune phrase de documentation ne sort sans que j’aie ouvert le fichier qu’elle décrit. Les dix chapitres sont sur eva-css.xyz/doc/.
