shortName (dashboard/frontend/js/leaderboard.js:107-109) truncates any label
over 18 characters to 17 plus an ellipsis:
return label && label.length > 18 ? `${label.slice(0, 17)}…` : (label || '');It feeds the board-frame endpoint labels at :1440 (name: shortName(ds.label)),
so both the Leaderboard tab and Home screen 0 render Nemotron 3 Nano 30B as
Nemotron 3 Nano 3….
On the Leaderboard tab that is fine and probably wanted — the tab's custom
legend carries full names, and a longer name would widen a rail the board
already wants to keep narrow.
On Home screen 0 it reads as an accident. The truncated pill sits directly
beside a rank list rendering the same name in full, so the ellipsis costs
recognisability of the exact thing the panel is ranking and buys nothing.
The obvious objection does not hold — measured, not assumed. The frame sizes
its gutter from a measured label block (boardLabelBlockWidth), and a block
wider than BOARD_GUTTER_MAX_FRACTION (0.5) of the canvas trips the arrow-only
degradation and drops every label. So one might expect the 18-character cut to be
what keeps screen 0 out of that degradation. From the rendered measurements taken
during this work (9 rows on screen 0, measured floor 211px):
| viewport |
screen-0 canvas |
0.5 × canvas |
measured floor |
headroom |
| 1920 |
618 × 260 |
309 |
211 |
98px |
| 1440 |
550 × 211 |
275 |
211 |
64px |
| 1280 |
482 × 211 |
241 |
211 |
30px |
| 390 |
253 × 219 |
126 |
211 |
already degraded |
The tightest desktop case has ~30px of headroom against roughly 6–7px of growth
for one extra character at Inter 600 11px. The 390px breakpoint already renders
zero labels by design, with or without truncation. The cut is not load-bearing at
any breakpoint.
Suggested shape. Make truncation an option on the label factory rather than a
property of shortName, so the tab keeps it and screen 0 passes the full label.
Do not simply delete the cut — :1721 uses shortName for the tab's legend and
:1876 for tooltip text, and both want it.
Confirm in a browser before merging a change. 30px at 1280 is comfortable but
not enormous, and the longest roster name may grow. This is the same gate the
original work used, and it is exactly the kind of question source-reading gets
wrong.
Found during the whole-branch review of the nof1 board frame work.
Surfaced by the whole-branch review of #382.
shortName(dashboard/frontend/js/leaderboard.js:107-109) truncates any labelover 18 characters to 17 plus an ellipsis:
It feeds the board-frame endpoint labels at
:1440(name: shortName(ds.label)),so both the Leaderboard tab and Home screen 0 render
Nemotron 3 Nano 30BasNemotron 3 Nano 3….On the Leaderboard tab that is fine and probably wanted — the tab's custom
legend carries full names, and a longer name would widen a rail the board
already wants to keep narrow.
On Home screen 0 it reads as an accident. The truncated pill sits directly
beside a rank list rendering the same name in full, so the ellipsis costs
recognisability of the exact thing the panel is ranking and buys nothing.
The obvious objection does not hold — measured, not assumed. The frame sizes
its gutter from a measured label block (
boardLabelBlockWidth), and a blockwider than
BOARD_GUTTER_MAX_FRACTION(0.5) of the canvas trips the arrow-onlydegradation and drops every label. So one might expect the 18-character cut to be
what keeps screen 0 out of that degradation. From the rendered measurements taken
during this work (9 rows on screen 0, measured floor 211px):
The tightest desktop case has ~30px of headroom against roughly 6–7px of growth
for one extra character at
Inter 600 11px. The 390px breakpoint already renderszero labels by design, with or without truncation. The cut is not load-bearing at
any breakpoint.
Suggested shape. Make truncation an option on the label factory rather than a
property of
shortName, so the tab keeps it and screen 0 passes the full label.Do not simply delete the cut —
:1721usesshortNamefor the tab's legend and:1876for tooltip text, and both want it.Confirm in a browser before merging a change. 30px at 1280 is comfortable but
not enormous, and the longest roster name may grow. This is the same gate the
original work used, and it is exactly the kind of question source-reading gets
wrong.
Found during the whole-branch review of the nof1 board frame work.
Surfaced by the whole-branch review of #382.