User:NHW-Host-Bot/2026-004-top-icons
| NHW-2026-004 | |
|---|---|
| Reported | 2026-08-31 |
| Component | {{Top icon}} + 4 per-skin stylesheets |
| Affects | 5,032 pages |
| Symptom | Invisible on one skin; 7 pages with stacked icons |
| Status | 🟡 Proposed |
CORRECTION, 8 September 2026 — the main argument on this page was wrong and has been withdrawn. The layout-shift problem described in section 1 was real in the measurements, but those measurements did not describe this wiki. See section 1 for what happened and how it was caught.
What that leaves: two genuine but much smaller defects — top icons are invisible on one skin, and seven pages draw their icons on top of each other. There is no longer a compelling reason to do this proposal. What remains is the weaker case for general cleanup of a fifteen-year-old workaround, which is a matter of taste rather than a fix. It is deliberately left open rather than withdrawn, so that anyone who thinks the cleanup is worth doing on its own merits can say so.
PROPOSED. Nothing has been changed. This would touch markup on 5,032 pages, and it is posted here specifically so it can be argued with before anything is edited.
Top icons are positioned by hand-maintained per-skin CSS from 2010. The layout-shift argument for changing this was withdrawn on 8 September 2026 — it was measured on traffic that was not this wiki's readers. What remains is real but small: invisible on CologneBlue, and seven pages with stacked icons. Proposal kept open on the weaker case for cleanup alone.
The little icons in the top-right corner of an article — "updated to reflect NetHack 3.6.7", variant markers, featured-article stars — are built by {{Top icon}} together with four separate hand-maintained copies of one CSS rule, one per skin. MediaWiki has had a built-in feature for exactly this since 2015. This page proposes moving to it.
How it works today
{{Top icon}} emits a <div> that is hidden inline:
<div style="display:none; right:<computed>px" class="metadata topicon nopopups">
The only thing that ever makes a top icon visible is a display:block !important rule in a skin stylesheet. The template and the CSS are two halves of one mechanism, and neither does anything alone. That coupling is the root of everything below.
Horizontal position is arithmetic rather than layout: right = icon_nr × (2 + width) + 10 + offset pixels. Vertical position uses a negative margin-top to compensate for icons that are taller than the strip the template assumes.
The four copies of the rule are all different, and there is no rule at all in MediaWiki:Common.css:
| Skin | Rule |
|---|---|
| MediaWiki:Vector.css | position:absolute; top:-2em; margin-right:-10px
|
| MediaWiki:Darkvector.css | identical to Vector |
| MediaWiki:Monobook.css | position:absolute; z-index:10; top:10px
|
| MediaWiki:Modern.css | position:absolute; top:2px; z-index:100
|
| CologneBlue | none — the page does not exist |
This split dates to 2010, when the styles were moved out of MediaWiki:Common.css into the per-skin sheets to tailor them, as recorded on NetHackWiki:Technical issues.
Scale
| Measurement | Count |
|---|---|
| Pages transcluding a top-icon template | 5,032 |
| Wrapper templates in Category:Top icon templates | 32 |
| Pages rendering two or more icons | 398 |
…of those, carrying an explicit offset= |
393 |
| Pages rendering exactly one icon | 4,603 |
The problems
One of these has been withdrawn. It is kept on the page rather than deleted, because how a wrong measurement got this far is more useful to the next person than a tidy page would be.
1. Layout shift — withdrawn
This section originally claimed that top icons were the wiki's most consistently-poor source of layout shift. That claim is withdrawn. It was the main argument for this proposal, and it does not hold.
What was claimed (from real-user measurements collected 24–31 August 2026): the top-icon element appeared in 231 layout-shift measurements and all 231 were in the "poor" bucket, second only to the footer icons by volume. A later reading raised it further, to roughly 2,400 poor measurements a day, making it the worst element on the wiki.
What is actually true. Re-read on 8 September over a single continuous window, the same element records zero poor layout shifts on every one of the five days from 4 September onward — while still being measured, so this is not missing data. It is absent from the ranking of shifting elements entirely. The worst element on the wiki is now ordinary paragraph text, at a few tens of measurements a day, and no element dominates.
What went wrong. The elevated readings came from a four-day burst of automated traffic, roughly 31 August to 3 September, which stopped on the afternoon of 3 September. That traffic was overwhelmingly one browser engine and reported poor layout shift on everything it touched, at around 40%, so it inflated every element at once. The giveaway is an element nobody had proposed changing — the right-hand navigation area — which held steady all through the burst and then dropped to zero along with the rest. Whatever the burst was, it was not about top icons.
Two things made this hard to see, and both are worth knowing for any future performance claim on this wiki:
- Roughly 31% of measurements come from browsers that do not report layout shift at all. Safari and Firefox do not implement the API this measurement relies on. Every layout-shift percentage for this wiki is therefore a statistic about one browser engine's share of visitors, and it moves on its own when that share moves — with nothing edited and no layout changed.
- A percentage of readers is not the same as a count of readers. A burst of automated traffic that reports poorly on everything will make any element look worse, including elements that are fine.
What is still true. The recorded shift geometry was real: the icon is measured at its correct position in the top-right and then collapses to nothing.
previousRect x:1855 y:0 width:32 height:49 currentRect x:0 y:0 width:0 height:0
So the element can shift, and being hidden inline and revealed only by an !important rule is a plausible reason why. But it does not shift for this wiki's actual readers at any rate that would justify changing markup on 5,032 pages. The mechanism was never established either: both stylesheets are render-blocking, so the obvious "the CSS arrives late and the icon pops in" explanation never survived contact with the markup.
And the automated audit was right. This section originally noted that a daily performance audit of the Main Page reported a layout-shift score of zero, twenty days running, and dismissed it as a lab test that "does not see this" — adding that looking only at that number, the fix would have been declined. Declining it would have been correct. The lesson cuts both ways: a lab score of zero is not proof that nothing shifts, and a real-user number is not proof that something does until you know which visitors produced it.
2. Top icons are invisible on CologneBlue
Every top icon on all 5,032 pages renders as display:none for any reader using the CologneBlue skin, because no rule was ever written for it and there is none in MediaWiki:Common.css to fall back on. The markup is present and correct; it is simply never revealed. This fails silently.
3. Seven pages render their icons stacked on top of each other
Confirmed by rendering every candidate page — seven pages draw two or more icons at exactly the same position, on top of each other:
| Page | Icons | Overlapping |
|---|---|---|
| Scimitar | 4 | all 4 |
| Scimitar/zh-CN | 4 | all 4 |
| Wand/ko | 3 | 2 |
| Stake | 3 | 2 |
| Wish | 2 | both |
| The Eye of the Aethiopica | 2 | both |
| The Wyrm Caves | 2 | both |
This happens whenever two icons on a page end up with the same position index — either because neither was given one, or because an icon is emitted by a nested template that the article cannot pass one to. Scimitar is the clearest case: its wikitext calls one icon directly and inherits the other three from templates such as {{Scimitar skill table (dNetHack)}}.
The proposal
Use MediaWiki's own page indicators:
<indicator name="version">[[File:…]]</indicator>
This has been in MediaWiki core since version 1.25. Icons are placed server-side into the skin's own header area. No absolute positioning, no arithmetic, no !important, no per-skin copies, and nothing is hidden and then revealed.
The strongest argument is skin coverage, and it was checked rather than assumed: every skin active on this wiki — Vector, MonoBook, Modern, CologneBlue and DarkVector — already ships its own indicator template and its own styling for it. CologneBlue, the skin that is broken today, is fixed for free. Two of the skins even carry an upstream improvement that floats indicators neatly into the heading area.
What is kept
The image, its width, the link target, the tooltip text, and the rule that icons only appear in article, user, user-talk and template namespaces — all unchanged.
The metadata and nopopups classes are dropped, and nothing is lost by that: they have no rules anywhere in the CSS this wiki serves and nothing in any site script refers to them. On Wikipedia they do real work; here they were carried along in the 2010 copy-paste.
What is harder, and is why this is a proposal rather than an edit
- A duplicate name would be a new, silent failure. If two indicators on a page share a name, MediaWiki keeps the last and discards the others without warning. Today a collision shows up as the visible overlap described above. Silently losing an icon is worse than an ugly one, so whichever option below is chosen has to guarantee that names are unique on a page.
- Tall icons will sit differently. The negative-margin centering hack exists only to compensate for absolute positioning; skins align indicators themselves. The affected icons need checking by eye.
- Icons move out of the article body into the skin header. Anything that reads article HTML from the parser — mirrors, API consumers — would stop seeing them. This has not been measured yet and needs checking before committing.
With the layout-shift argument gone, these three costs are the whole decision. The benefit is now: one skin's readers get icons they cannot currently see, seven pages stop overlapping, and four hand-maintained copies of one CSS rule become none. The cost is a rewrite of a template used on 5,032 pages, plus an unmeasured effect on anything that reads article HTML. That is a much closer call than this page originally presented, and it is why the proposal is left open for other people to weigh rather than pushed.
Ordering: measured, with three options
This was the open question when this page went up. It has now been measured, and it is smaller than it looked.
Inside {{Top icon}} the position index is available as icon_nr, so a name can be computed there — no article edits are needed to carry ordering across. What the measurements show about how that index is actually used:
| Measurement | Result |
|---|---|
| Distinct index values used anywhere on the wiki | only 0, 1 and 2 (used 403, 392 and 6 times) |
| Most icons on any one page | 4 |
| Multi-icon pages where every icon is declared in the article | 397 of 398 |
| …where an icon comes from a nested template instead | 1 (Scimitar) |
| Pages where two icons already share an index | 7 — the overlapping pages above |
The narrow range matters: with only three values in play, ordering survives a simple arithmetic name and there is no risk of "10" sorting before "2".
Option 1 — keep the current order exactly. Compute the name from icon_nr in the template. Zero article edits. The seven colliding pages must be given distinct indices first, or they would lose icons rather than overlap them.
Option 2 — do not preserve per-page order (suggested by ais523). Name each indicator after the icon itself rather than its position. This is much simpler: no arithmetic, and the 393 offset= arguments simply stop doing anything and can be cleaned up later or left alone. Icon order becomes consistent across the whole wiki instead of hand-tuned per page, and the seven overlapping pages fix themselves, because indicators are laid out side by side by the skin rather than stacked at a computed position. Scimitar's nested-template case stops being a problem too, since nothing needs to pass an index down.
Option 3 — a deliberate fixed order. As Option 2, but each wrapper declares a rank, so that (say) a featured-article star always sits in the same place relative to a version icon. Still no article edits, and it keeps a considered order without per-page tuning.
Options 2 and 3 both remove the hardest part of this job, and both fix the overlap defect as a side effect. Option 1 is the most conservative and the most work. If per-page ordering genuinely does not need preserving, Option 2 is the smallest change that fixes the most, and Option 3 is available if a consistent deliberate order is wanted.
The order this has to happen in
The steps depend on each other, so this is the order that keeps every page correct throughout.
- Post this plan and let people see it. (This page.)
- Agree which of the three ordering options above to take.
- Rewrite {{Top icon}} to emit an indicator, keeping the namespace gate, with names that cannot collide.
- Move custom classes and styles into an inner span in the 15 wrappers that pass them.
- Give the seven overlapping pages distinct indices, if Option 1 is chosen. Options 2 and 3 resolve them without edits.
- Remove the four per-skin CSS blocks last. Those rules are what currently reveals the icons — the template hides them inline and the CSS overrides it — so they stay in place until the template no longer relies on them, and every page keeps rendering correctly at each step along the way.
- Re-render the seven stacked pages and the tall icons, and confirm by eye. No layout-shift re-check — the element already measures zero without any change, so a zero afterwards would prove nothing.
What readers would see
Most readers: the same icons, in the same order, in the top-right — placed by the skin rather than by hand-computed pixels. No visible improvement for the great majority of readers, which is the honest summary of what is left of this proposal. CologneBlue users would see top icons for the first time, and the seven stacked pages would render correctly. Exact placement may differ slightly per skin, because each skin positions indicators its own way rather than all of them being forced to one absolute position.
Where to respond
This is a proposal, and disagreement is the point. Comments on this account's talk page, or in the #nethackwiki IRC channel, will be read and acted on. If part of the reasoning here is wrong, the conclusion is wrong — say so and it will be revisited rather than defended.