Skip to main content
The RFFL Knowledge Base visual system is a working standard for a member-facing league reference. It should be compact, readable, and predictable for repeated lookup across rules, seasons, scorebooks, KORM, finance, and source-status pages. This page is the source of truth for visual and editorial language decisions. Token edits below update the local docs shell immediately, so the sidebar, page canvas, search, and component previews can be judged together. Those browser edits are preview state; committed defaults still live in docs.json, style.css, and rffl-design-system.js.

RFFL Editorial Voice

Version: 2026-05-15 The RFFL Knowledge Base is the league’s memory, organized for people who actually use it. It is not a marketing site, a generic fantasy football blog, or an agent instruction manual. It is the place RFFL members go when they need to understand what happened, what the rule says, who won, what changed, what a team code means, how KORM works, how money was structured, or why a decision was made. The site should feel like a clean league reference built from years of real competition, rules, arguments, payouts, draft stories, side games, and records. It should respect the history without making the experience feel dusty or overly formal. It should be easy to scan, easy to compare, and easy to trust. The voice is direct, league-specific, and useful. It should sound like someone who knows the league explaining the record clearly to another member. Use RFFL terminology naturally: Alpha Bowl, Beta Bowl, KORM, FAAB, team codes, divisions, rulings, payouts, scorebooks, drafts, trades, rosters, lineups, and season results. The language should feel familiar to the league, not imported from a generic sports site. Every page should help a member do something. Confirm a result. Check a payout. Understand a rule. Compare seasons. Resolve a team alias. Follow a ruling. Revisit a draft story. Look up a KORM finish. Understand what a record does and does not cover. When exact details are known, keep them exact. Scores, weeks, team codes, dollar amounts, placements, rule names, and season labels are part of the value of the site. Precision should feel practical, not performative. When a record is incomplete, say so clearly and keep moving. Uncertainty should help the reader understand the page, not take over the page. The site should make gaps visible without making gaps the personality. Lore has room for more character, because the league has character. Rules, finance, rulings, and results should stay cleaner and more direct. The whole system should still feel like one RFFL knowledge base, with different levels of warmth depending on the page type. The design should support repeat use. This is a lookup tool, a comparison surface, and a league memory system. Dense tables, scorebooks, timelines, registries, and decision records should feel organized and readable. The interface should help members move quickly across rules, seasons, scorebooks, drafts, trades, waivers, rosters, lineups, finance, KORM, lore, governance, rulings, inquiries, teams, and registries. The story is simple: RFFL has decades of real league history. docs.rffl.dev turns that history into a clear, useful reference for the people who lived it and still need to use it.

Live Site Workbench

RFFL Visual System

Archive Night

Use this workbench to tune the real docs shell and the future scorebook UI at the same time. Changes apply instantly in this browser and persist locally until reset.

Live site preview on
Page canvas#211F28
Sidebar surface#2A2832
Panel surface#3D3A46
Accent system#B04E78 / #62929E

Foundations

Design Tokens

Each token has a visible role. Use surface tokens to separate layout layers; use accents only for state and data.

RFFL Knowledge BaseSearch…

2024 Regular Season

The active visual language must support long source pages, scorebook tables, owner histories, and future detailed boxscores.

Source boundaryValidated records are separated from missing ESPN-era detail.

Component Specimen

Boxscore Detail Preview

Bracket validated
PCX118.68
GFM117.02
Margin+1.66
Projected PF114.20
Actual PF118.68
Delta+4.48
Source statevalidated
SlotStarterProjActualState
QBStarter row19.824.6final
RBStarter row14.38.1reviewed
FLEXMissing source rownot readynot readysource gap
CanvasPage background#211F28
NavigationSidebar surface#2A2832
ContentPanel surface#3D3A46
StateRosewood accent#B04E78
DataPacific Cyan#62929E

Implementation

Live Token Output

Accessibility

Contrast Checks

Foundations

TokenCurrent defaultRolePromotion target
Page background#211F28Root canvas for dark modedocs.json background.color.dark
Sidebar surface#2A2832Navigation surface distinct from the pagestyle.css shell layer
Panel surface#3D3A46Scorebook modules, cards, controlsstyle.css component layer
Raised surface#464151Inputs, selected states, table hoverstyle.css component layer
Border and rules#546A7BDividers, table rules, focus boundariesstyle.css component layer
Reading text#C6C5B9Long-form copy and table valuesMintlify default unless promoted
Strong text#E8E6DCHeadings, key scores, active labelsMintlify default unless promoted
Rosewood accent#B04E78Current state, warnings, primary emphasisdocs.json colors.primary
Data accent#62929EDeltas, projections, validationdocs.json colors.dark

Component Specimens

ComponentStandard
SidebarMust be visibly separate from page background, but still quiet. Use a close surface step, not a saturated color.
Active nav itemUse Rosewood as shape first: left rail, background tint, or underline. Avoid Rosewood-only small text.
SearchUse raised surface, one-pixel border, compact height, and restrained placeholder text.
ScorecardUse panel surface, large tabular score values, and a single validation badge.
Boxscore tableUse fixed columns, tabular numbers, restrained row dividers, and badges only for source state.
Data emphasisUse Pacific Cyan for deltas, projections, and validated states. Do not color every number.
Source-boundary badgeUse Rosewood for warnings and missing data, paired with text.

Type And Density

RoleStandard
Page titleMintlify default. Do not override globally.
Section titleMintlify default. Keep headings compact inside tools and panels.
Dense panel title15-18px, depending on hierarchy.
Metadata11-13px, uppercase only for short labels.
NumbersTabular figures for standings, PF, PA, records, and money.
TablesDense but not cramped. Prefer horizontal scroll over broken wrapping for scorebook detail.

Drift To Avoid

DriftWhat it looks likeCorrection
Debug panel UIControls dominate the page and labels disappearUse structured token rows with visible role, hex, and swatch
One-note rosewood themeEvery active element becomes pinkUse Rosewood for state and warnings only
Low-contrast navSidebar and page collapse into one layerKeep sidebar one surface step away from canvas
Table decorationBoxscore rows become color-coded noiseReserve color for source state, deltas, and validation
Fake save behaviorUsers can edit tokens but cannot tell what happenedApply preview immediately and show implementation output
Viewport-scaled typographyHeadings become oversized on wide screensUse fixed type roles, not viewport-based font sizes

Design Authority

docs.json owns the Mintlify theme, public palette defaults, and canonical URL. style.css owns table readability, approved shell surface adjustments, and this design-system workbench. rffl-design-system.js owns live token preview, local browser persistence, contrast checks, and implementation output. There is no hidden in-page commit button because Mintlify pages cannot write back to repo files from the browser. When a token set is approved, promote it into the files listed above.
Last modified on May 15, 2026