My reference file for EVA CSS stated that font sizes are written var(--24). It is var(--fs-24). Both exist, they do not clamp the same way, and I published that sentence for months.

I found out while writing something else: a documentation, ten chapters, in place of the llms.txt the site was pointing at. 31 outgoing links to .md and .txt files, eight pages carrying a « For your AI assistant, open /llms.txt » callout. The site documented nothing, it pointed at the exit.

Nobody proofreads a file written for machines

I am not going to pretend I was forced into it: that solution suited me. A CSS framework is a scale of tokens and utility classes, regular material that a model swallows well. And whoever installs EVA CSS today rarely opens a documentation page, they describe what they want to an assistant. Writing for the machine that will write the code felt like writing to the source.

Except that a file meant for machines has no reader. Nobody proofreads it, nobody comes to say that sentence 40 is wrong. It drifts, and nothing comes back. « Paste this file into your AI, it will explain » is not a documentation, it is a way of getting out of writing one.

CSS ignores what it does not understand

The same file documented utility prefixes m-, mx-, my-. They do not exist. And my own site uses maw-768 and lh-1-5 on dozens of elements, two classes that are nowhere in the framework. They have never done anything.

Nothing ever protested, and that is normal. An undefined custom property produces no error: substitution fails, the declaration becomes invalid at computed-value time, the property falls back to its inherited value. An absent class matches no selector. CSS is designed to ignore what it does not understand, which is what lets browsers move forward without breaking the web behind them. The price is that a wrong documentation produces no symptom.

Three CSS declarations and what the browser does with them A three-column table. On the left what is written in the code, in the middle what the browser applies, on the right what the console reports. The right token gives the right curve, the wrong token gives another curve, the non-existent class gives nothing. The third column stays empty in all three cases. WRITTEN APPLIED REPORTED var(--fs-24) the right curve var(--24) another curve maw-768 nothing
Two of these three lines are bugs. The console says the same thing about all three.

A model reading that documentation reproduces it faithfully. It does not test, it writes var(--24) because that is what the official reference says. The page renders, the sizes are almost right, and nobody opens an empty console. I had written a file made to be read by machines, and I had filled it with errors no machine can detect.

Three bugs that came out of building the pages

The rest came while building the chapters. A documentation asks a site for things no presentation page ever asks.

A global pre { white-space: pre-line !important } rule was crushing the indentation of every code block, which does not show until you display an example with several levels. A global nav { position: fixed } rule was capturing the documentation’s <nav> elements: the table of contents and the pagination went to stick at the top of the page. And container-type: inline-size on <body> cuts overflow propagation to the viewport, which left the sticky columns with no scrollport on mobile. That last one is a spec detail I did not know, and without two long columns to make cohabit I would never have run into it.

Every sentence must say where it is written in the code

A documentation written seriously forces you to answer « where is this written in the code? » for every statement. Not from memory, not by feel: the file, the line. That constraint turns the writing into a verification pass over the whole product, and it is what found the bugs, not me.

A file dumped for a model asks for none of that. You write what you think you know, the model rephrases it cleanly, and the cleanness of the rephrasing gives the illusion of correctness. The text is never confronted with the code.

/llms.txt has not disappeared for all that. It became a build artefact, generated from the same markdown as the pages: still served to crawlers, no link to it from the site any more, and unable to diverge. Links between chapters are written doc:chapter#anchor and validated at compile time, a non-existent anchor breaks the build. The documentation is treated as code, because that is what it is.

Two documentation circuits, only one closes the loop Two stacked chains of boxes, each doubled by a return path drawn underneath. On top, four boxes linked by arrows: the file, a model, the code, the page. Their return path leaves the last box, runs under the row and aims at the first one; it is dashed and cut in the middle by two slanted strokes, and the words « nothing comes back » are written in the cut. Below, three boxes linked by arrows: ten chapters, then every statement, then the file and the line. Their return path follows the same route but it is solid, drawn in the accent colour, and its arrow reaches the first box; the words « breaks the build » are written in its middle. WRITTEN FOR MACHINES NO READER the file a model the code the page nothing comes back TREATED AS CODE VALIDATED AT COMPILE TIME ten chapters every statement the file, the line breaks the build
The difference is not in the steps, it is in the return path.

Since then, no documentation sentence goes out without my having opened the file it describes. The ten chapters are on eva-css.xyz/doc/.