fix(docs): paint the landing page's marks on its translations, and its buttons anywhere

[lens0021]

The file-type marks are missing from the diagram on index/ko. Chasing that turned up two separate faults: one that hits the translations, and one that hits every language.

The translations: a page class that is not there

The marks, the caret, the button's night colours and the clipped page title were all scoped to .rootpage-index, on a claim written into the stylesheet: "the body of index/ko is page-index_ko, and only rootpage-index catches both." The first half is right and the second is not.

Title::getRootText() returns the whole title unless the namespace has subpages turned on, and the main namespace does not — this site sets no NamespacesWithSubpages, and MediaWiki's default omits NS_MAIN. So index/ko is one title, not a page with a subpage. The body element of the deployed page confirms it, class list quoted verbatim:

skin--responsive skin-vector skin-vector-search-vue mediawiki ltr sitedir-ltr
mw-hide-empty-elt ns-0 ns-subject mw-editable page-index_ko rootpage-index_ko
skin-vector-2022 action-view

.rootpage-index matches neither page-index_ko nor rootpage-index_ko. Module:Sequence states the same fact in its own comment and matches the sidebar's names as prefixes rather than asking a title for its root, for exactly this reason — the claim contradicted something the repository had already written down. The same page also renders its firstHeading unclipped, which is the fourth rule failing.

The button was the one thing that still looked right, which is why this went unnoticed: styles.css reads the tokens with fallbacks, so light mode painted from the fallback whatever the tokens did. Night mode kept the brand teal at 3.2:1 instead of switching to the pale teal.

The marks and the caret lose the page scope rather than gain a better one. The wikven-home- classes are written by the landing page's templates and by nothing else, so the class is already the scope; the page selector on top of it bought nothing and added a way to be wrong.

The button's colours turned out to be the accent written twice. --wikven-cta-bg and --wikven-cta-bg--hover held byte-identical values to --color-progressive and --color-progressive--hover, in both themes. The fill now reads the accent. Only the foreground stays a token — it cannot be read off the accent, white being 5.6:1 on the light theme's teal and 2.07:1 on night's — and it is declared beside the accent, site-wide, in the block that already defines the brand for all three theme states.

The page title keeps a page selector, because the heading is outside the content and has no class of its own. It matches a substring of the body class, catching page-index, rootpage-index and both _ko forms. It can catch nothing else: the class is case-sensitive, so only a page whose title begins index reaches it.

Every language: three declarations the sanitiser was dropping

The built stylesheet on the deployed site carries an error block, which is how these were found:

Errors processing stylesheet [[:Template:home/styles.css]] (rev 90):
- Invalid or unsupported value for property border-color at line 91 character 16.
- Invalid or unsupported value for property border-color at line 104 character 16.
- Invalid selector list at line 111 character 1.

border-color takes one to four values, so a var() in it is not a colour the sanitiser can check and the declaration is dropped. Both hover rules used it, so neither button's border followed its background on hover — while the rule directly above, writing the same colour through the border shorthand with a width and style stated, passes and always has. The hover rules now say it the same way.

The focus ring moves to MediaWiki:Common.css. :focus-visible is not a pseudo-class the sanitiser knows, so the rule was dropped whole and the ring was never drawn, on any page, in any language. It had been put in a rule of its own so the unknown selector could not take the hover rules down with it; that much worked, but surviving was not something it could do there.

Checked

biome check clean at the version biome.json pins (2.5.8). No reference to the two removed tokens survives anywhere in the repository. Template:home/doc carries no translate units, so its rewrite makes no translation stale.

The diagnosis is confirmed against the deployed HTML, quoted above. The fix is not verified in a browser — the site is unreachable from this environment and the Docker daemon is not running here, so the preview deployment is its first render. Worth a look at the preview before merging, in both themes.