/* skins-live.css — bridges the LIVE app to the skin variables. - Claude 7/16/26 * * Loaded LAST (after desktop.css + skin-base + skin + modes + buttons) by * skinswitch.js. With the stripped, the body#bodyN company rules are * off and skin-base already re-themes the tokenized selectors; this sheet mops up * the remaining hardcoded DataForce colors in desktop.css base rules that * skin-base doesn't have a matching selector for. v1 — expect to iterate from * screenshots of real pages. Colors all resolve from the active skin/mode. * * body.dfx-darkpanel = "the content panel is DARK". Every on-dark adjustment below keys off THIS, * not [data-theme="dark"]. They mean the same thing for the Light/Dark toggle, but Classic renders * each skin's OWN surfaces — and Onyx is a dark skin, so in Classic its rows were dark while the * stylesheets' hardcoded #000 cell text stayed black-on-dark (Lee 7/26: mobile Free Agent / Waiver * / Draft history grids). skinswitch.js sets the class for Dark mode OR a dark skin in Classic; * add future dark skins to DARKSKINS there and they inherit all of this. The class selector has * the SAME specificity as the attribute selector it replaced, so no cascade changed. - Claude 7/26/26 */ /* ══ SEMANTIC STATUS PALETTE (go / warn / stop) ═══════════════════════════════════════════════════ The live-draft timer already established this vocabulary (--dfx-go green, amber, --danger) but declared it inside body.dfx-fullpage, so nothing else could use it. Lee 7/26 asked for the same three colors on the Trade History statuses and the Trade Bar, so hoist them to body level. These are deliberately SEMANTIC, not the skin accent: "approved" must read as approved on every skin. Each has a value tuned for a light panel and one for a dark panel (same pattern as --attention / --attention-ink), because a green dark enough to read on white is too dark to read on #161b22. Values are unchanged from the live-draft block, so the draft timer renders identically. FILL vs INK is a real split, not tidiness: --dfx-go is the live-draft box FILL (used at 20% over the panel, plus as a border), so it must stay exactly as it was or the draft timer changes. Text needs a much darker value to clear 4.5:1 — a green readable on white is far too dark to use as a box fill. Same relationship --attention / --attention-ink already has. The INK values are tuned against the DIMMEST light row surface (SBFFC #dcdcdc), which is the binding case: a slightly darker background demands darker text, not lighter, because contrast = (Lbg+.05)/(Lfg+.05). - Claude 7/26/26 */ body { --dfx-go:#1a8f57; /* FILL: live-draft box + trade bar */ --dfx-warn-fill:#e0a400; --dfx-warn-line:#c58a00; /* FILL: amber box + its border */ --dfx-stop-fill:var(--danger); /* FILL: trade-bar red segment */ --dfx-go-ink:#0f6b3f; /* TEXT on a light panel */ --dfx-warn-ink:#7d4e00; --dfx-stop-ink:#9b2c22; --dfx-info-ink:color-mix(in srgb, var(--complementary) 45%, black); } /* STATUS CHIPS — the lobby's paid / held / dropped buttons and the draft-vote yes/no buttons and legend. Found 7/26 by auditing desktop.css's color legend: nothing in the harness touched them, and their specificity (#main table#leagues button.paid ~ 2 ids + class) buries skin-base's #main button, so they stayed DataForce green/pink on EVERY skin and both modes. These are pale CHIPS carrying black text, not solid bands — mapping them straight onto --dfx-go would put black text on a mid-green and wreck the contrast. So they get their own tint pair: a light wash of the semantic color with dark ink, flipping to a deeper wash with light ink on a dark panel. They stay recognisably green/red on every skin, so nobody has to relearn what "paid" looks like. Consumed by the base sheets as var(--chip-go, #4AE371) etc., so production keeps today's exact colors until the tokens ship. - Claude 7/26/26 */ body { --chip-go:color-mix(in srgb, var(--dfx-go) 28%, #ffffff); --chip-go-ink:#0d3b26; --chip-stop:color-mix(in srgb, var(--danger) 20%, #ffffff); --chip-stop-ink:#4a1712; --chip-neutral:color-mix(in srgb, var(--ink) 6%, #ffffff); --chip-neutral-ink:#333333; } body.dfx-darkpanel { /* headings: the base sheets pin #003333 ("Headings" in desktop.css's legend), which is 3.80:1 on a dark content panel. modes.css lifts --heading for data-theme=dark but NOT for a dark skin in Classic (Onyx), so set it for every dark panel. - Claude 7/26/26 */ --heading:color-mix(in srgb, var(--accent) 60%, white); /* link hover has to move AWAY from the surface: darkening is the right direction on a white panel, the wrong one here. - Claude 8/3/26 */ --link-hover:brightness(1.35); --chip-go:color-mix(in srgb, var(--dfx-go) 40%, #161b22); --chip-go-ink:var(--ink); --chip-stop:color-mix(in srgb, var(--danger) 42%, #161b22); --chip-stop-ink:var(--ink); --chip-neutral:color-mix(in srgb, var(--ink) 14%, #161b22); --chip-neutral-ink:var(--ink); --dfx-go:#3fbd7e; /* FILL lifts on a dark panel */ /* --danger #c0392b is dark, so on a dark panel the trade-bar red segment sat almost on top of its own track (onyx/classic measured 1.32x) and read only by hue. Lift it like green and amber already are. The live-draft pink/redBox keep plain --danger — they are 26-30% TINTS over the panel, a different problem. */ --dfx-stop-fill:color-mix(in srgb, var(--danger) 62%, white); --dfx-go-ink:#3fbd7e; /* TEXT lifts to match */ --dfx-warn-ink:#e0a400; --dfx-stop-ink:color-mix(in srgb, var(--danger) 55%, white); --dfx-info-ink:color-mix(in srgb, var(--complementary) 60%, white); } /* content-panel edge: in Dark (and Light) mode #main is a dark/near-white panel on a same-toned page, so it needs an outline to separate from the page. Only Light/Dark set --border; Classic leaves it transparent (its light-on-dark panel needs none, so today's look is untouched). A subtle surface tone — NOT off-white, which glares. */ /* The visible panel's OUTER edge is #background (it wraps #main with an ~8px inset), so the separating border belongs HERE, not on #main — a border on #main floats ~8px inside the real edge. Also match #background's fill to the content surface so no white strips show. Classic leaves --border transparent => no outline (today's look untouched). */ #background { background-color:var(--content-bg); border:1px solid var(--border, transparent); } #main { border:0; } /* Buttons (league chips in the lobby/marketplace, etc). Consume the MODE-ONLY tokens and fall back to the skin's --btn-* — so Classic is untouched but Light/Dark actually win. (Naming them --btn-bg in modes.css tied the cascade with body.skin-*{--btn-bg} and lost.) The .join/.paid/.dropped buttons keep their own higher-specificity semantic colors. */ #main button, #home button { background-color:var(--btn-surface, var(--btn-bg)); border-color:var(--btn-line, var(--btn-border)); color:var(--btn-ink, var(--btn-text)); } /* LOBBY ACTION BUTTONS LOST THEIR EDGE (Lee 8/6/26, reported on Gridiron: "the JOIN and PAY buttons have lost their borders or background colors"). Both halves of that sentence are right, and it is NOT a Gridiron bug — Gridiron is just the worst case. The carve-out noted three lines above is the cause. desktop.css:803-816 pins these six classes to a hardcoded #F8F8F7 fill with black text at 2-ids-plus-a-class, which outranks everything the skin system has to say about their COLOUR. Before skins that was fine, because desktop.css never set `border` on them either, so they were drawn with the BROWSER'S default button border — a grey bevel that gave the chip its silhouette for free. skin-base.css:135 then replaced that UA border with `1px solid var(--btn-border)`, and ten of thirteen palettes set --btn-border:transparent (correct for a FILLED button, fatal for one whose fill is hardcoded near-white). So the silhouette went, and the fill had nothing to fall back on. MEASURED, fill vs the row behind it: ember dE 0.4 · gridiron 1.7 · midnight 1.7 · primetime 1.7 · varsity 2.2 — all under 3, i.e. the same colour to the eye, with no border. Five more sit at 6.0-6.7. Only dataforce, sbffc and tailgate escaped, and only because they set a real --btn-border. FIX: give the edge back, anchored to currentColor rather than to --btn-border. That is exactly the precedent Lee approved on 7/27 for button.secondary, for this same defect and the same reason — a token that is transparent in most palettes cannot be an outline. currentColor is the label, which every skin already guarantees is readable on this fill, so the edge cannot vanish. 40% lands it at ~#959594: dE 24.9 from the button fill and worst-case 19.1 from the row across all 13 skins, both far above this project's 8 floor. NO LAYOUT CHANGE: skin-base already reserved 1px of transparent border, so this only colours space that was always there. The widths in desktop.css and the yellow :hover are deliberately untouched. paid/held are included so the column does not show bordered JOIN beside unbordered PAID — they were legible only because --chip-go is green. - Claude 8/6/26 */ #main table#leagues button.join, #main table#leagues button.pay, #main table#leagues button.hold, #main table#leagues button.leaveShow, #main table#leagues button.paid, #main table#leagues button.held { border:1px solid color-mix(in srgb, currentColor 40%, transparent); } /* The lobby's ID-column chips are NOT buttons — they're (admin.php:1539) hardcoded #8DC7BC / #4A9586, which is why the #main button rule never reached them. */ #main table#leagues a.myLeagues { background-color:var(--btn-surface, var(--btn-bg)); border-color:var(--btn-line, var(--btn-border)); color:var(--btn-ink, var(--btn-text)); } /* :focus-visible, NOT :focus, throughout this section (Lee 8/7/26). A mouse click FOCUSES the thing it clicked, and focus does not go away when the pointer does, so on `:focus` the lift stayed switched on after the customer moved the mouse away — most visibly on the live draft page's CLEAR button, which has no state class of its own and so just sat there lit. :focus-visible matches only focus the browser judges worth showing (keyboard/tab, not a mouse click), which kills the stickiness while KEEPING the affordance for keyboard users — and that matters here because a button has no other focus indicator: skin-base.css:148 draws the accent focus ring for textarea/input/select only, so for a button this lift IS the entire focus signal. Deleting :focus outright would have stranded keyboard navigation. EACH PAIR IS SPLIT INTO TWO RULES ON PURPOSE. A browser that doesn't know :focus-visible discards the WHOLE selector list it appears in — so keeping it in one comma-list with :hover would take the hover styling down with it on anything older than ~2022. Split, such a browser drops only the focus rule and hovering still works. - Claude 8/7/26 */ #main table#leagues a.myLeagues:hover { background-color:var(--btn-surface, var(--btn-bg)); filter:var(--hover-lift); } #main table#leagues a.myLeagues:focus-visible { background-color:var(--btn-surface, var(--btn-bg)); filter:var(--hover-lift); } /* Links column buttons (RULES / ROST / PICKS / MFL) are — hardcoded #8DC7BC teal with a yellow hover, same as the myLeagues chips. Give them the button tokens. */ #main table#leagues a.enabled { background-color:var(--btn-surface, var(--btn-bg)); border-color:var(--btn-line, var(--btn-border)); color:var(--btn-ink, var(--btn-text)); } #main table#leagues a.enabled:hover { background-color:var(--btn-surface, var(--btn-bg)); filter:var(--hover-lift); } #main table#leagues a.enabled:focus-visible { background-color:var(--btn-surface, var(--btn-bg)); filter:var(--hover-lift); } /* HOVER: desktop.css turns buttons yellow (#F4FA58, its documented "Buttons (hover)"). Replace with the brightness lift so each button shifts its OWN color. */ #main button:hover, #home button:hover, #searchDisplay button:hover { background-color:var(--btn-surface, var(--btn-bg)); filter:var(--hover-lift); } #main button:focus-visible, #home button:focus-visible, #searchDisplay button:focus-visible { background-color:var(--btn-surface, var(--btn-bg)); filter:var(--hover-lift); } /* the league action buttons keep their semantic white base — just lift it instead of yellow */ #main table#leagues button.join:hover, #main table#leagues button.buy:hover, #main table#leagues button.pay:hover, #main table#leagues button.hold:hover, #main table#leagues button.leaveShow:hover { background-color:#F8F8F7; filter:var(--hover-lift); } #main table#leagues button.join:focus-visible, #main table#leagues button.buy:focus-visible, #main table#leagues button.pay:focus-visible, #main table#leagues button.hold:focus-visible, #main table#leagues button.leaveShow:focus-visible { background-color:#F8F8F7; filter:var(--hover-lift); } /* SELECTED BEATS HOVER (Lee 8/7/26). The lift above is a brightness FILTER layered over whatever background a button has, so on a button that carries a persistent selected state it sits on top of the selected fill: click one and, with the cursor still parked on it, you keep seeing the BRIGHTENED version of the new colour. :hover is only re-evaluated when the pointer moves, so the state change appears to wait for you to move the mouse — the actual complaint. Cancel the lift once a button IS the selection: there is nothing left to preview, and the real selected colour shows the instant you click. :focus IS INCLUDED DELIBERATELY, and is the part that's easy to miss — the rules above fire on `:hover, :focus` both, and a clicked button KEEPS focus, so cancelling only :hover would leave the lift stuck on anyway until the customer clicked something else. An ALLOW-LIST, not a blanket `[class*=elected]`, because three families would be hurt by it: - jQuery dialog buttons: .ui-state-active is the PRESSED state, not a selection, and it shares one rule with hover/focus (line ~368) — a blanket rule would flatten every dialog button. - Wonk icon buttons (.iconSelected/.tinyIconSelected): selection there is a BORDER-colour change with no fill, so there is no masked colour to reveal — cancelling hover would be pure loss of feedback. Lee 8/7/26 had no preference; left excluded on those grounds. - Misc Interfaces .on — see the carve-out immediately below. NOT handled here, on purpose: the nav menubar has the same annoyance but via a background OVERRIDE (desktop.css:317 `:hover` at (1,2,1) out-ranks :318 `.menuSelected` at (1,1,1)), not the filter, so filter:none would do nothing for it. Lee 8/7/26: menubar doesn't need it. */ #main button.selectedButton:hover, #main button.selectedButton:focus, #main button.on:hover, #main button.on:focus, #main table#friends button.friendSelected:hover, #main table#friends button.friendSelected:focus, body.dfx-wonk #main table.wonk button.menuSelected:hover, body.dfx-wonk #main table.wonk button.menuSelected:focus, body.dfx-wonk #main table.wonk button.statsSelected:hover, body.dfx-wonk #main table.wonk button.statsSelected:focus { filter:none; } /* .Done — the "already sent" state on the draft engine's Message 1-7 buttons (draftengine.js:223) and on the commish send-message / filler-message buttons (commish.js:540, 8768+). Needs the BACKGROUND restated as well as the lift cancelled, which is what makes it different from the states above. fullpage.css:76 and desktop.css:1215 declare `#main button.Done {background-color:var(--content-bg)}` at specificity (1,1,1) — but the blanket hover rule up at line ~144 is `#main button:hover`, ALSO (1,1,1), and this sheet loads last. Equal specificity, later wins: while the button was hovered OR focused the hover rule re-set background-color to --btn-surface, so .Done never turned white at all under the cursor, and :focus kept it that way after the pointer left (Lee 8/7/26: "clicked Message 1, moved the mouse to Message 2, still showed the hover colour"). Restating the white here at (1,2,1) settles it: hover still lifts the button BEFORE it's sent, and the instant it's clicked it goes white and stays white, cursor parked on it or not. - Claude 8/7/26 */ #main button.Done, #main button.Done:hover, #main button.Done:focus, #main a.Done button, #main a.Done button:hover, #main a.Done button:focus { background-color:var(--content-bg); filter:none; } /* CARVE-OUT: Miscellaneous Interfaces (mfl.php) deliberately NEUTRALISES the .on fill (line ~622, Lee 8/6/26) so its data-source toggles don't read as primary — .on there is bold but otherwise identical to .off. With no distinct fill to reveal, killing the lift would leave two buttons that look the same and behave differently on hover, so .on keeps normal feedback on that page. Wins on id count (2 vs 1). */ /* :focus-visible here too — this rule RESTORES the lift, so leaving it on plain :focus would put the post-click stickiness back for exactly these buttons. The cancel rules above can stay on the broader :focus, because cancelling on a mouse click is the outcome we want anyway. - Claude 8/7/26 */ #main:has(#scoringAudit) button.on:hover, #main:has(#scoringAudit) button.on:focus-visible { filter:var(--hover-lift); } /* EDITING A FIELD: desktop.css washes inputs pale yellow (#FFFBDF) on hover/focus, which fights every skin. Use the skin's own affordance instead: hover = accent border only; focus = a faint accent tint + the accent focus RING that skin-base already draws. */ /* NOTE: border-color alone is useless as a hover cue in Classic — there --input-border and --accent are the SAME color (#4A9586), so the border never visibly changed. Use a faint tint + a soft halo instead, which reads in every skin/mode. Focus keeps a stronger ring, and is declared AFTER hover so it still wins while the field is focused. */ #main textarea:hover, #main input.lineEntry:hover, #main select.lineEntry:hover, #main input.topLineEntry:hover, #main input.bottomLineEntry:hover { background-color:color-mix(in srgb, var(--accent) 6%, var(--input-bg)); border-color:var(--accent); box-shadow:var(--input-shadow), 0 0 0 2px color-mix(in srgb, var(--accent) 22%, transparent); } #main textarea:focus, #main input.lineEntry:focus, #main select.lineEntry:focus, #main input.topLineEntry:focus, #main input.bottomLineEntry:focus { background-color:color-mix(in srgb, var(--accent) 11%, var(--input-bg)); border-color:var(--accent); outline:none; box-shadow:var(--input-shadow), 0 0 0 3px color-mix(in srgb, var(--accent) 40%, transparent); } /* HOST distinction in the lobby (Leagues.host): desktop.css rows are tr.DFF (#CFE7E2) vs tr.MFL (#F7FBFA, washed out) — but those are (1,1,2), same as skin-base's `#main tr.detail td {background:var(--row-bg)}`, so tokenizing row-bg flattened them into one color and the cue was lost. REBASED 8/3/26 (Lee: make the lobby read like the Locker Room sample). The sample's detail rows are plain var(--row-bg), so the DataForce rows — the default, and the bulk of the lobby — are now exactly that, and the lobby's body reads like every other table on the site. That leaves MFL as the deviation, which is the right way round: the thing that needs pointing out is the one that looks different. MFL takes a --complementary tint rather than a weaker --accent one. Two shades of the same mint is a difference you have to be told about; a different HUE is one you can see, and --complementary is the palette's designated second identity, so it stays on-brand in all 14 skins. 14% keeps it soft enough to read as a row rather than a highlight. THE LEGEND SWATCHES MUST TRACK THESE. They are the only thing on the page that says which is which, so they carry the same two expressions verbatim — change one pair, change the other. */ #main tr.DFF td { background-color:var(--row-bg); } #main tr.MFL td { background-color:color-mix(in srgb, var(--complementary) 14%, var(--row-bg)); } /* keep the legend swatches identical to the rows they describe */ #main table#legend td.DFF { background-color:var(--row-bg); border-color:var(--panel-border); } #main table#legend td.MFL { background-color:color-mix(in srgb, var(--complementary) 14%, var(--row-bg)); border-color:var(--panel-border); } /* APEX: NO MFL TINT, BECAUSE ON APEX IT DISTINGUISHES NOTHING (Lee 8/6/26 — he sent the Apex lobby beside Tailgate's and asked for Tailgate's cell colour). The tint above is right on DataForce, where it marks the rare MFL league: 382 DFF against 5 MFL in the 2026 lobby. On Apex it fires on EVERY row — 284 of 284 open 2026 leagues are host=2 (checked on prod) — so it stops being a highlight and just becomes the table's background colour, a greyer one than the palette actually specifies. That is what Lee was looking at. Sampled from his screenshots: Apex cells rendered #cad9cd, Tailgate #e1e8d3. Apex and Tailgate declare the SAME --row-bg (#e1e8d3) — the whole difference was this rule, and the arithmetic matches to the byte: Apex's --complementary #3f7fa6 at 14% over #e1e8d3 gives exactly #cad9cd. Nothing was wrong with the palette; a highlight was covering it. Scoped on co-apex, the company IDENTITY class (never user-changeable), so it cannot follow anyone who picks a skin. DataForce and SBFFC keep the tint and its meaning. ⚠ THE LEGEND: the note above says the swatches must track the rows, so the DFF/MFL swatches are deliberately left alone here — on Apex the legend explains a distinction the table no longer draws. Whether Apex should show that legend row at all is a CONTENT question, not a colour one, so it is Lee's call rather than something to bury in a stylesheet. - Claude 8/6/26 */ /* ⚠ :not(.swatch) IS THE WHOLE POINT OF THIS SELECTOR — it is not tidying. Written first as a plain `td`, this rule PAINTED OVER THE LEVEL COLOUR SWATCHES and Lee lost the entire left column (8/6/26). The swatch cell is a td in the same row, and it takes its colour from `#main tr.allLeagues td.copper` and friends at (0,1,2,2) — while this selector, with body + .co-apex + #main + tr + .MFL + td, is (0,1,2,3). One element more specific, so it won every swatch in the lobby and flattened it to the row colour. Excluding the cell is what keeps this rule aimed at the row background it was written for. Any future variant of this rule needs the same exclusion. - Claude 8/6/26 */ body.co-apex #main tr.MFL td:not(.swatch) { background-color:var(--row-bg); } /* "This is your team" highlight rows (tr.myTeam) on Free Agent History / Waiver History (and any other myTeam list) were a hardcoded #C0E0DA teal that ignored the skin. Emphasise them per skin with an accent-tinted row surface (same accent-over-row-bg family as the DFF highlight rows, a touch stronger so the current team clearly stands out from the plain --row-bg rows) — follows every skin + dark mode. - Claude 7/18/26 */ #main tr.myTeam td { background-color:color-mix(in srgb, var(--accent) 30%, var(--row-bg)); color:var(--ink); } /* TOGGLE BUTTONS (.on / .off) — e.g. the marketplace "and / or" pair (#orphanand/#orphanor). desktop.css styles ONLY .off, and lumps it in with :disabled (#F5F5F0), so an unselected toggle looks *disabled* while .on has no rule and looks like an ordinary button — there's no signal for which is active. Give the pair a real state: ON = solid accent (bold), OFF = the normal muted button. (:disabled keeps its own grey — we only touch button.off.) */ #main button.on { background-color:var(--accent); color:#fff; border-color:var(--accent); font-weight:bold; } #main button.off { background-color:var(--btn-surface, var(--btn-bg)); color:var(--btn-ink, var(--btn-text)); border-color:var(--btn-line, var(--btn-border)); font-weight:normal; } /* ...EXCEPT ON MISCELLANEOUS INTERFACES, WHERE .off MEANS SOMETHING ELSE ENTIRELY (Lee 8/6/26: "the buttons for some of these, like Fantasy Guru, used to be white — meaning, not ready for use yet this year"). He is right and the rule above is what took it away. ONE CLASS, TWO MEANINGS. On the marketplace and/or pair, .off = "not the selected half of a toggle", and making that look disabled was wrong — which is what the rule above fixed. On views/mfl.php, .off = "this feed is not available this season", which IS a disabled state, and desktop.css:710 was right to group it with :disabled at #F5F5F0. Restyling .off site-wide fixed the toggle and silently broke the availability flag; the only surviving difference on this page was font-weight, which is not a signal anyone would read as "unavailable". Scoped by #loadGuru — the Fantasy Guru LOAD button itself, which renders and appears in no other view (checked). NOT #getPlayers, which I used first and which never matched anything: that id is inside an HTML COMMENT in views/mfl.php, so it is in the source but never in the DOM. Confirm a hook is RENDERED, not merely present in the file. Same :has() page-scoping used for #scoringAudit further down this file. Treatment: the muted panel-neutral chip with faded ink and a dashed edge. Dashed because colour alone should not carry it — these sit beside .on buttons in the same row and the page is read at a glance, so the edge style says "not available" even before the fill registers. --chip-neutral is already the skin-aware "nothing here" surface (it is what the lobby's dropped chip uses) and it follows dark panels, which a hardcoded #F5F5F0 would not. NOT :disabled and not pointer-events:none — the buttons still work if Lee wants to run one, and this is a status hint, not an enforcement. - Claude 8/6/26 */ #main:has(#loadGuru) button.off { background-color:var(--chip-neutral); color:color-mix(in srgb, var(--chip-neutral-ink) 55%, transparent); border:1px dashed color-mix(in srgb, var(--chip-neutral-ink) 45%, transparent); font-weight:normal; } /* button.selectedButton = the ACTIVE item of a toggle group (e.g. the ALL/PAYPAL/ACH/PAPER mode picker on Withdrawal Requests). desktop.css hardcodes it #4A9587 green — map the selected state to the skin accent so it matches (same treatment as the .on toggles). - Claude 7/18/26 */ #main button.selectedButton { background-color:var(--accent); color:#fff; border-color:var(--accent); } #main button.selectedButton:hover { background-color:var(--accent); filter:var(--hover-lift); } #main button.selectedButton:focus-visible { background-color:var(--accent); filter:var(--hover-lift); } /* "My Watch List" is a TOGGLE (.off / .on), but desktop.css gives it #8DC7BC when OFF and #F5F5F0 when ON — two arbitrary fills where neither reads as "active". Make the state obvious and skin-aware: OFF = the normal muted button; ON = solid accent, bold. */ #main button#myWatchList.off { background-color:var(--btn-surface, var(--btn-bg)); color:var(--btn-ink, var(--btn-text)); border-color:var(--btn-line, var(--btn-border)); font-weight:normal; } #main button#myWatchList.on { background-color:var(--accent); color:#fff; border-color:var(--accent); font-weight:bold; } /* Links column (marketplace): "Contact Owner" / "Make an Offer" / "Watch" are anchors (a.contact / a.watch) — pin them to the link color so they follow the skin. The disabled chip beside them is hardcoded #F5F5F0 with a #4A9586 border. */ #main table#leagues a.contact, #main table#leagues a.watch { color:var(--link, var(--accent)); } #main table#leagues span.notEnabled { background-color:var(--btn-surface, var(--btn-bg)); color:var(--btn-ink, var(--btn-text)); border-color:var(--btn-line, var(--btn-border)); } /* ===================== COMPLEMENTARY "info / aside" surfaces ===================== A soft companion color — --complementary, one hand-picked hue per skin (DataForce = the existing package-deal blue) — for the app's ASIDES: help text, training popups, dialogs, and the marketplace package-deal / buyer's-guide boxes. One identity, distinct from the primary accent and from danger/attention. Pattern (per Lee): a tinted background + a border shade that ALSO colors the text. --complementary-ink is that border+text color (mode-aware: deepened on light panels, lightened on dark); bg is a light tint of --complementary over the content surface. All of these previously hardcoded yellow/blue with no skin awareness. */ /* shared "callout" box: help panel, popups + popup-list page, dialog body, the blue boxes */ #main div.narrative, #home div.narrative, #popup, #main table#popupTable td, #orphanGuide, #packageDeals, #openOrphanGuide, #openPackageDeal, .ui-dialog { background-color:color-mix(in srgb, var(--complementary) 14%, var(--content-bg)); border-color:var(--complementary-ink, var(--complementary)); color:var(--complementary-ink, var(--complementary)); } /* Headings INSIDE the callout follow the box's OWN text colour, not the page heading colour, so they always contrast with the box tint. Two rules outrank the plain `#main h1` and had to be beaten: `#main h1` (~805, var(--ink)) AND, on mobile Classic, `body.dfx-mobile[data-theme="classic"] #main h1` (~1849, var(--page-text) — light, meant for the dark Classic #main box). The narrative is a LIGHT island inside that dark box, so on Classic the heading went light-on-light; the third selector below (specificity 1,3,3) beats the 1,2,2 Classic rule. The box's body text already uses --complementary-ink and is readable, so the heading matches it. - Claude 8/13/26 */ #main div.narrative :is(h1,h2,h3,h4), #home div.narrative :is(h1,h2,h3,h4), body.dfx-mobile[data-theme="classic"] #main div.narrative :is(h1,h2,h3,h4), body.dfx-mobile[data-theme="classic"] #home div.narrative :is(h1,h2,h3,h4) { color:var(--complementary-ink, var(--complementary)); } /* …except the TEXT in the two popup surfaces, which goes to --ink (Lee 8/3/26). The callout pattern above colors its text with the same --complementary-ink it uses for the border, which reads as a tinted block — fine for a short aside, harder work for the paragraphs these two carry. --ink, not #000: it is the mode-aware black (#111 in Classic, #1b222a in Light, #e6edf3 in Dark), so this stays black where black is right and does not go black-on-dark in Night Game. It also brings them into line with .ui-dialog .ui-dialog-content, which has taken --ink since 7/21. Background and border are deliberately left on the callout rule — these are still asides, they just read as text now. Links are unaffected: #popup a is a hardcoded #FF9933 (desktop.css:172), so they stay distinguishable from the body copy. - Claude 8/3/26 */ #popup, #main table#popupTable td { color:var(--ink); } /* Training Popups (table#popupTable) on MOBILE: mobile.css:856 sets each cell to display:table-row so the three cells stack vertically — but `padding` does NOT apply to table-row boxes, so the 1em padding is dropped and the text jams against the cell edges. Make the stacked cell a block (still full-width, still stacked) so its padding applies again, with a small gap between boxes. - Claude 7/25/26 */ body.dfx-mobile #main table#popupTable td { display:block; padding:1em; margin-bottom:12px; } /* solid-complementary headers: help-panel header + dialog titlebar (the "Hey!" bar) */ div#narrHeader, .ui-dialog .ui-dialog-titlebar, .ui-dialog .ui-widget-header { background:var(--complementary); color:#fff; } /* Dialog BODY text: jQuery UI's .ui-widget-content pins it dark (#333), so in dark mode it went dark-on-dark — unreadable. Pin the content to the mode-aware --ink, and drop the hardcoded white button pane so the tinted dialog surface shows through. Skin-wide (all dialogs). - Claude 7/21/26 */ .ui-dialog .ui-dialog-content { color:var(--ink); } .ui-dialog .ui-dialog-content a { color:var(--complementary-ink, var(--complementary)); } .ui-dialog .ui-dialog-buttonpane { background:transparent; border-top:1px solid color-mix(in srgb, var(--complementary) 30%, transparent); } /* buttons living inside these asides -> solid complementary */ #popup button, #main #orphanGuide button, #main #packageDeal button { background-color:var(--complementary); color:#fff; border-color:var(--complementary); } #popup button:hover, #main #orphanGuide button:hover, #main #packageDeal button:hover { background-color:var(--complementary); filter:var(--hover-lift); } #popup button:focus-visible { background-color:var(--complementary); filter:var(--hover-lift); } /* DIALOG BUTTONS (the OK / Yes / No in .ui-dialog-buttonpane) — Lee 8/3/26. They take the same solid --complementary the other callout buttons above already take, so a dialog's button matches its own titlebar instead of sitting there as the pale #8DC7BB legacy button. THE SPECIFICITY HERE IS NOT DECORATION. A first attempt used `.ui-dialog .ui-dialog-buttonpane button` (0,2,1) and silently lost, twice, to a sheet nothing else in the skin layer touches: css/dialog.css:44 .ui-dialog .ui-dialog-buttonpane .ui-dialog-buttonset button.ui-button { border:1px solid #4A9586; background:#8DC7BB; color:#fff; } That is (0,5,1) and outranks it whatever the load order. It was invisible from the markup too — the dialog is appended to BODY, not inside #main, so none of the #main button rules were involved at all; the matching-rule dump on the live page is what actually found it. Matching dialog.css's selector shape and adding .ui-widget (which every .ui-dialog carries) puts this at (0,6,1), so it wins on specificity rather than on being loaded later. The .ui-state-* variants are listed because ui-lightness styles buttons through those classes and `.ui-widget-content .ui-state-hover` would otherwise take the hover — that theme's hover is a YELLOW #fdf5ce glass PNG, thoroughly off-skin. background-image:none kills the PNG. Not touching dialog.css:40 `.ui-dialog .ui-button-icon-only{display:none}` — that is what hides the titlebar close X, and it is deliberate, not a casualty of the navy titlebar. - Claude 8/3/26 */ .ui-dialog.ui-widget .ui-dialog-buttonpane .ui-dialog-buttonset button.ui-button { background:var(--complementary); background-image:none; color:#fff; border:1px solid var(--complementary); } /* DELIBERATELY still :focus, not :focus-visible, unlike the button rules higher up (Lee 8/7/26). Two reasons. jQuery UI also adds its OWN .ui-state-focus CLASS on focus, listed right below, so swapping the pseudo would only half-change the behaviour and leave the class doing the same thing. And there is no stickiness to cure here anyway: these buttons dismiss the dialog they live in, so the element is gone immediately after the click. - Claude 8/7/26 */ .ui-dialog.ui-widget .ui-dialog-buttonpane .ui-dialog-buttonset button.ui-button:hover, .ui-dialog.ui-widget .ui-dialog-buttonpane .ui-dialog-buttonset button.ui-button:focus, .ui-dialog.ui-widget .ui-dialog-buttonpane .ui-dialog-buttonset button.ui-button.ui-state-hover, .ui-dialog.ui-widget .ui-dialog-buttonpane .ui-dialog-buttonset button.ui-button.ui-state-focus, .ui-dialog.ui-widget .ui-dialog-buttonpane .ui-dialog-buttonset button.ui-button.ui-state-active { background:var(--complementary); background-image:none; color:#fff; border-color:var(--complementary); filter:var(--hover-lift); } /* ---------- APEX DIALOGS IN OLIVE (Lee 8/6/26, on Apex's request that popups match their headers) ---- RE-POINTS THE TOKEN INSIDE THE DIALOG ONLY, rather than restating the six dialog rules above. Every one of them already reads var(--complementary) / var(--complementary-ink); custom properties inherit, so declaring the pair ON .ui-dialog re-colours the titlebar, the tinted body, the border, the links and the OK/Yes/No buttons together, and cannot leak past the dialog's own subtree. A value set directly on the element also beats the one apex.css sets on body, so no specificity games. NOTHING ELSE MOVES — checked against the other 33 selector groups that read --complementary: #narrHeader (which SHARES the titlebar rule), #popup, the narrative boxes, #orphanGuide, #packageDeals, #searchDisplay, the MFL legend swatch, and every Wonk / live-draft / auction surface all sit outside .ui-dialog and keep Apex's blue. DataForce and SBFFC are untouched via co-apex. WHY --nav-base AND NOT THE HEADER THEY POINTED AT. The titlebar rule hardcodes color:#fff, and white fails on both pale header olives — 2.10:1 on --header-bg #a6bb7b and 2.43:1 on --major-bg #97af65. Matching those literally would have meant flipping the titlebar to dark ink, i.e. restructuring the dialog's look rather than re-hueing it. --nav-base #44611f is the darkest olive Apex already uses AS a header band (the site nav), so it satisfies "match the headers" while keeping the white-on-colour pattern intact — and it is a token they already own, not a new colour invented for them. MEASURED, all passing: white on the titlebar 7.06:1 (the blue it replaces managed only 4.38, so this is a contrast IMPROVEMENT); titlebar against the tinted body 5.73:1 light / 5.64 classic; links 7.55:1 light and 5.59:1 dark; body copy 15.34:1 light and 13.29:1 dark. Written as var(--nav-base), not a literal, so the dialogs keep tracking the nav if Apex ever re-tints. Dark mode needs the lifted ink, exactly as modes.css:97 does for the blue. ⚠ Known and accepted: anything rendered INSIDE a dialog that also reads --complementary (a .dfx-pill, say) turns olive within that dialog. That is consistent for the popup rather than a leak. - Claude 8/6/26 */ body.co-apex .ui-dialog { --complementary:var(--nav-base); --complementary-ink:color-mix(in srgb, var(--nav-base) 80%, black); } body.co-apex[data-theme="dark"] .ui-dialog, body.co-apex.dfx-darkpanel .ui-dialog { --complementary-ink:color-mix(in srgb, var(--nav-base) 60%, white); } /* The competitors-page callout (div.yellowBox) is hardcoded #FFFF99 with a DataForce-teal #8DC7BB border and — again — NO text color, so it would go light-on-yellow in Dark. PROMOTED TO THE EMPHASIS TREATMENT (Lee 8/5/26: "make that banner attention"). It was a 12% accent tint — safe, but it read as just another panel, and this is the one line on the page doing the selling ("Because we also have the biggest payouts!"). Now the filled --attention with its paired --attention-text, the same pairing the Locker Room shows as the Emphasis sample, so what a customer sees here is a colour they can already name. Border set to --attention as well rather than kept as a contrasting edge: at 1px against a filled block it only muddied the corner radius. The box reads as one solid banner. The pairing is designed to be legible, and measures 6.3-9.7:1 on thirteen palettes. DataForce is the exception at 4.46:1 (white on #E82510) — a hair under the 4.5 body-text line, and exactly what its badges already ship. Acceptable here because the text is bold, but it is the palette to look at if this ever needs to carry longer copy. NOT the live-draft warning box: body.dfx-fullpage #main div.yellowBox further down this file is a different thing (the countdown's amber state) and outranks this on specificity, so the draft engine is untouched. - Claude 8/5/26 */ #main div.yellowBox { background-color:var(--attention); border-color:var(--attention); color:var(--attention-text); } /* Search-results popup (#searchDisplay) restyled to match the HELP-text callout: the same --complementary tint background + --complementary-ink border/text as the help panel above, in place of its hardcoded #F8F8F8 white / teal border / black text. Section date-headers and the black player-name body text ride the same complementary-ink so the whole box reads as one aside; article links stay on --link like everywhere else; Close button already skinned. - Claude 7/17/26 */ #searchDisplay { background-color:color-mix(in srgb, var(--complementary) 14%, var(--content-bg)); border-color:var(--complementary-ink, var(--complementary)); color:var(--complementary-ink, var(--complementary)); } #searchDisplay div.section { color:var(--complementary-ink, var(--complementary)); } #searchDisplay a, #searchDisplay a:visited { color:var(--link, var(--accent)); } /* Third-party page logo chips (FantasyPros / Footballguys). The class is called "blackbackground" but it's actually #4A9586 — DataForce's --accent — so it stayed teal on every other skin. These logos are white artwork that needs a mid-tone chip behind it, and --accent is exactly that (and is literally the same value today, so DataForce is unchanged). --accent is a BRAND token, so it stays mid-tone in Light/Dark too and the white logos keep their contrast in every mode. */ #main div.blackbackground { background-color:var(--accent); } /* Shopping cart: the only hardcoded color on the page is the cell fill — a pale peach #F5E8E2 with a #DAAC96 tan border, unrelated to any skin, and (again) with no text color so it would go light-on-peach in Dark. It's a plain listing table, so give it the standard row surface: consistent with every other table in the app and correct in all three modes. */ #main table#cart td { background-color:var(--row-bg); border-color:var(--panel-border); color:var(--ink); } /* GOLD CTA STARBURSTS — NO CSS RULE. div.spin wraps join.png, firstteam.png and referafriend-att2.png; the last was already orange-red and the other two were legacy gold. They are now BAKED into refer-a-friend's own colors (claude-work/recolor_cta.js, originals kept as images/*.gold.bak.png), so there is nothing for this sheet to do. A CSS filter was tried twice and abandoned. join.png and referafriend-att2.png are the SAME artwork — identical alpha on 100% of pixels, differing only in the lettering — and no single hue-rotate/saturate/brightness reproduces one from the other, because that is one linear map applied to every pixel and this gold->red relationship is not linear. Solved against the --attention token it went muddy brown; re-solved against refer-a-friend's own nine tonal quantiles it was closer but still not it. Baking learns the map per color instead and lands 74% of pixels within 30/255 of refer-a-friend, with the remainder confined to rows 41-131 — the lettering, which is meant to differ. If new gold art appears, recolor it; do not reach for a filter. - Claude 8/3/26 */ /* shopping cart: skinswitch.js swaps the gold cart for this masked . The cart PNG is the alpha MASK (its color is ignored) and --accent fills the silhouette, so the cart becomes the skin color and follows light/dark for free. (First of the "gold images" moved onto the palette; HELP/VIDEO/refer come later.) */ .dfx-cart { display:inline-block; width:50px; height:50px; vertical-align:middle; background-color:var(--accent); -webkit-mask:url(/images/cart.png) center/contain no-repeat; mask:url(/images/cart.png) center/contain no-repeat; } /* ALERT BELL — skinfx.js swaps the gold alarm.png for this masked , same trick as the cart: the PNG is the alpha mask and the palette fills the silhouette. Takes --complementary, the HELP button's color (Lee 8/3/26). aspect-ratio carries the 88x103 art, so only the height needs setting and skinfx.js can pass through whatever height the markup asked for. The shake and the header's 16px both come from desktop.css rules written as `img#alarm`, which a cannot match — re-hung here rather than edited there. @keyframes shake is global, so this references desktop.css's own definition. - Claude 8/3/26 */ /* BRUSHED SILVER 8/4/26 (Lee). Was var(--complementary) — a flat fill, which is what made it read dull: shine is a gradient, not a colour. The ramps are defined in skin-base and are the same on every skin. background-color stays as the fallback under the gradient, so a browser that cannot paint the gradient still gets a solid silver bell rather than an invisible one. - Claude 8/4/26 */ .dfx-alarm { display:inline-block; height:20px; aspect-ratio:88/103; vertical-align:middle; background-color:#6b6b71; background-image:var(--alarm-metal-dark); -webkit-mask:url(/images/alarm.png) center/contain no-repeat; mask:url(/images/alarm.png) center/contain no-repeat; animation:shake 4s ease-in-out 1; } /* ...and the LIGHT ramp wherever the surface under it is dark. dfx-darkpanel is the signal bodyAttr() already sets for "this page's surface is dark" — Night Game, and Onyx even in Classic. Without this the in-prose bell would be dark silver on a dark panel. - Claude 8/4/26 */ body.dfx-darkpanel .dfx-alarm { background-color:#c0c0c6; background-image:var(--alarm-metal-light); } /* ON THE DARK HEADER FRAME the bell is an ALERT, and --complementary is 2.38:1 on the near-black page top — it would all but disappear exactly where it has to be noticed. --complementary-bright is the answer this sheet already gives for "the help color, on a dark band" (see #fullPageHeader .dfx-pill), so the bell follows the HELP button rather than diverging from it. 16px matches the old img#alarm rule: the bell is bigger than the 14px hub picture and crowds the loading spinner. - Claude 8/3/26 */ #title #titleCenter .dfx-alarm { height:16px; background-color:#c0c0c6; background-image:var(--alarm-metal-light); } /* HELP / VIDEO rebuilt as real skin pills by skinswitch.js (were gold text-buttons). They're help/learning affordances, so they take --complementary (matching help panel/popups/dialogs). VIDEO keeps its clapperboard picture. The wrapping still carries the click handler. */ /* SCOPED TO #main 7/28/26. Unscoped, this also caught the mobile top bar: its "Page Help" button is an a.pageText too (common/mobiletopbar.php), so it picked up float:left AND the 8px bottom margin. That grew the Page Help CELL, and because those buttons are one table ROW, all six grew with it — icon, label and padding alike. Lee reported it as "elongated buttons" and it dated from the day the harness first injected this sheet. It took a rule-by-rule bisection to find, because nothing here matches the button you are LOOKING at — the offender is a sibling cell, and table rows share their height. Worth remembering the next time a cell is the wrong size and no rule seems to touch it. The pills these rules style all live inside #main, so scoping costs nothing. - Claude 7/28/26 */ #main a.pageText, #main a.playVideo { float:left; margin:0 8px 8px 0; } .dfx-pill { display:inline-flex; align-items:center; gap:5px; cursor:pointer; background:var(--complementary); color:#fff; font-weight:bold; font-size:13px; line-height:1; padding:2px 11px; border-radius:13px; border:1px solid var(--complementary); /* shadow tied to the complementary color, not the skin's brand --shadow (which is e.g. Pill's violet glow) */ box-shadow:0 2px 5px color-mix(in srgb, var(--complementary) 40%, transparent); transition:filter .12s ease; } .dfx-pill:hover { filter:var(--hover-lift); } /* pills rendered inside body text as an ILLUSTRATION of a button (skinfx.js .dfx-static) — no click handler, so no pointer cursor and no hover lift. - Claude 8/3/26 */ .dfx-pill.dfx-static { cursor:default; } .dfx-pill.dfx-static:hover { filter:none; } /* …and SMALLER than the real button (Lee 8/3/26, on About DFF -> Training Popups). At the button's own 13px text and 16px icon a pill stands about 22px tall inside a ~21px line box, so it forces the leading apart wherever it appears mid-sentence — views/popups.php puts HELP and VIDEO in the middle of two tips, right beside a 12px tooltip bubble, which is what makes the mismatch obvious. Sized in em, not px, so they track whatever text they land in — desktop, mobile, and popup.php's tip text all render these at different base sizes. The real buttons are untouched: they keep the px sizes above, because a control you aim at should not shrink with its surrounding copy. */ .dfx-pill.dfx-static { font-size:.8em; padding:1px 7px; gap:4px; border-radius:9px; vertical-align:baseline; } .dfx-pill.dfx-static .dfx-q, .dfx-pill.dfx-static .dfx-vicon { width:1.1em; height:1.1em; } .dfx-pill.dfx-static .dfx-q { font-size:.85em; } .dfx-help .dfx-q { display:inline-flex; align-items:center; justify-content:center; width:16px; height:16px; border-radius:50%; background:#fff; color:var(--complementary); font-size:11px; } /* HELP briefly took the skin's accent instead of --complementary (8/3/26) and came out green in DataForce, no longer matching VIDEO. Reverted the same day (Lee): HELP and VIDEO are the same family of affordance and must be the same shade, which is the plain .dfx-pill --complementary above. Nothing skin-specific here on purpose. - Claude 8/3/26 */ /* 18px -> 16px, 8/3/26 (Lee): the pill's height is set by its icon, not its 13px/1 label, so an 18px icon made VIDEO exactly 2px taller than HELP, whose .dfx-q is 16px. Matching the two makes the pills the same height everywhere they appear — the real buttons AND the copies rendered inline in prose (popups.php, videos.php, popup.php's tip text), which skinfx.js rebuilds as pills from the same CSS. TWEET shares .dfx-vicon and comes into line too. The SVGs are viewBox 24 so they just scale. - Claude 8/3/26 */ .dfx-vicon { width:16px; height:16px; display:block; } /* loading indicator: the old wait.gif is a dated 2017 barber-pole bar. skinswitch.js swaps it for this skin-colored CSS spinner — crisp at any size, follows --accent, no image. */ .dfx-spinner { display:inline-block; width:18px; height:18px; box-sizing:border-box; vertical-align:middle; border:3px solid color-mix(in srgb, var(--accent) 22%, transparent); border-top-color:var(--accent); border-radius:50%; animation:dfx-spin .7s linear infinite; } @keyframes dfx-spin { to { transform:rotate(360deg); } } /* header loading spinner relocated (by skinswitch.js) to spin as a ring AROUND the centre hub icon (#alarm) while a page loads. Anchored to the STABLE #titleCenter cell (NOT #alarm, whose innerHTML is rewritten on every page switch). #titleCenter is the positioning context; left is fixed at 50% (the icon is horizontally centred) and skinswitch.js sets top to the icon's vertical centre. The ring is sized larger than the ~16px icon so it encircles it; pointer-events:none so it never blocks the icon's click. - Claude 7/18/26 */ #title #titleCenter { position:relative; } #title #titleCenter #pleaseWait { position:absolute; left:50%; transform:translate(-50%,-50%); margin:0; padding:0; line-height:0; z-index:5; pointer-events:none; } /* ⚠ THIS SIZE IS A FALLBACK ONLY — IT IS NOT WHAT YOU SEE. skinfx.js centerHeaderSpinner() writes width/height INLINE on every sweep (icon size + 10), and inline wins over this sheet at any specificity. This value governs only the instant before that runs, and the case where no hub icon is found to measure. It sat at 34px while the page rendered 30px, so "shrink the ring" was edited here once with no visible effect — change skinfx.js instead. 26px matches what the JS now produces for the 16px bell, so the fallback no longer disagrees with the page. - Claude 8/12/26 */ #title #titleCenter #pleaseWait .dfx-spinner { width:26px; height:26px; border-width:3px; } /* the alert bell (img#alarm, 20px) is a touch bigger than the plain hub picture (14px) and crowds the spinner ring — shrink it slightly so it sits comfortably inside. Only the bell carries id="alarm", so the normal hub icon is untouched. - Claude 7/18/26 */ #title #titleCenter img#alarm { height:16px; } /* Commissioner hub icon is a WHITE fedora (commish.png) — reads great on the dark frame, but the white body vanishes on the light-mode header (only the black band shows). A thin dark outline defines the hat + band on any background; invisible on the dark frame. - Claude 7/18/26 */ #title #titleCenter img[src*="commish"] { filter:drop-shadow(0 0 1px rgba(0,0,0,.7)) drop-shadow(0 0 1px rgba(0,0,0,.5)); } /* "USE MOBILE VERSION" — the button title.php emits into #titleCenter when a phone loads the desktop site. Lee, 8/8/26: "The button pushes the Admin Hub and icon too high. It also could be highlighted the complementary color." ⚠ MEASURED, AND THE CAUSE IS NOT WHAT IT LOOKS LIKE: the button does NOT move the hub title. Measured on beta at 1319px and forced to 412px, with and without the button, in all three modes — the title and its icon stay at top 10.7 either way. What the button actually does is grow the header by 17.1px (#title 99.5 -> 116.6), because it is in normal flow inside a cell whose padding-top (7.5mm, desktop.css:209) was hand-tuned to align the hub with the BOTTOM of the ADMINISTRATION button back when the h2 was the ONLY thing in that cell. So the title is pinned high while the cell grows underneath it, and the group reads as top-heavy — which on a phone, where the whole fixed-width header is scaled down to fit, leaves the icon a few px from the top edge and looking clipped. FIX: take the button OUT OF FLOW. #titleCenter is already position:relative for the spinner above, so the button can hang in the 62.7px of dead space under the title. Header growth measured 17.1px -> 0, title unmoved, button 29px in a 45.6px gap. LABEL IS NOW ONE LINE — "Use Mobile", shortened in title.php (Lee 8/8/26: "what if we just decreased the text?"). Measured: the full "Use Mobile Version" on one line is 123px against a 104px cell and overhangs 10px each side, so the short label is the only one that fits without escaping the cell. Height 29px -> 18px, and the freed room pays for a 12px font instead of 10px, which matters because a phone renders this fixed-width header scaled down. `> br` NOT `br` is kept deliberately even though title.php no longer emits the leading
: the two dead title variants (classictitle.php, title-with-fadeout.php — 0 includers today) still carry the old "
" markup, and an unscoped `br` rule would kill the br INSIDE the button so the label reads "Use MobileVersion" with no space. That exact bug shipped in my first test and was caught by asserting on rendered innerText, not by reading the CSS. Colour: --complementary-bright is the documented on-dark-band variant (header pills), but ONLY dataforce.css defines it — the other 13 palettes have --complementary alone, so the fallback is load-bearing, not decoration. - Claude 8/8/26 */ #title #titleCenter #mobileVersionSection { position:absolute; left:50%; bottom:4px; transform:translateX(-50%); margin:0; padding:0; line-height:0; } #title #titleCenter #mobileVersionSection > br { display:none; } #title button#useMobileVersion { background-color:var(--complementary-bright,var(--complementary)); color:#fff; border:0; border-radius:6px; padding:3px 8px; font-size:12px; line-height:1.15; white-space:nowrap; cursor:pointer; box-shadow:0 1px 2px rgba(0,0,0,.35); } /* ⚠ THE CELL MUST BE TOP-ALIGNED WHENEVER THE BUTTON SHOWS, AND THE DISCRIMINATOR IS THE BANNER, NOT THE THEME. I first shipped this as a light-mode-only rule and it was wrong — Lee: "you already position it correctly when the skin uses a banner image", which is the whole diagnosis in one line. Only `body.has-banner` gets `vertical-align:top; padding-top:7.5mm` (desktop.css:209). WITHOUT a banner the cell falls to `vertical-align:bottom` with no padding, so the hub title sits LOW (measured top 58.6, bottom 92.2) and the out-of-flow button at bottom:4px lands right on top of it (button top 66) — the title and the button occupying the same space. That is the case Lee was looking at, and it is why my first fix "didn't work": my whole test page carried has-banner, the one state where nothing was wrong. Top-aligning the cell whenever the button is present makes all SIX states identical — banner and no-banner x classic/dark/light: hub top 10.7, button top 66.1, 21.8px clear between them, header height unchanged at 99.5. It also supersedes the light-mode-only rule that was here, because light+banner is just one of the six. Anchoring the button to the cell's TOP instead was never an option: the header table sits at `top:-28px` and overflows its container by 20px, so the cell's own top is at viewport -18 and a top-anchored button would render off-screen. 4 ids (:has() counts #mobileVersionSection) beats desktop.css's 3, so this wins regardless of load order, and :has() keeps every ordinary desktop page untouched. - Claude 8/8/26 */ #title table#topLeft tr td#titleCenter:has(#mobileVersionSection) { vertical-align:top; padding-top:7.5mm; } /* Elements retired in the redesign — hidden via the harness (source unchanged): - the breadcrumb "← Go Back" link on every page (bread.php:70, #gobackbutton wraps #goback; hide the wrapper so the JS $("#goback").show() toggle can't reveal it) - the "PLACE BIDS" / "NOMINATE" tab buttons on the Email Auction and Nominate Player pages (views/auction.php:5-6 and views/nominate.php:3-4; #auctionBidButton / #auctionNominateButton). REFRESH PAGE (#refreshPage) is intentionally left in place. - Claude 7/18/26 */ #gobackbutton { display:none; } #main #auctionBidButton, #main #auctionNominateButton { display:none; } /* ⚠ MOBILE REUSES THESE TWO IDS FOR SOMETHING ELSE ENTIRELY, and the rule above was hiding those too (Lee 8/7/26: "I don't see a button on either"). On DESKTOP (views/auction.php, views/nominate.php) they are the retired PLACE BIDS / NOMINATE tab buttons, correctly hidden. On MOBILE (mobile-v2/auction.php, mobile-v2/nominate.php) the same ids are the ONLY navigation between the two pages — "Nominate a Player" and "Bid On Players" — and hiding them strands the user on whichever page they landed on. Same id, opposite meaning, and the selector above never distinguished them. Written as an addition rather than by rescoping the rule above, so desktop cannot be affected by this at all. body.dfx-mobile is set by skinfx.js from #zoomlevel2, so these appear once it runs. - Claude 8/7/26 */ body.dfx-mobile #main #auctionBidButton, body.dfx-mobile #main #auctionNominateButton { display:inline-block; } /* - the "MISC MFL" / "FETCH ROSTERS" tab buttons on the Miscellaneous Interfaces / Fetch Rosters pages (views/mfl.php:2-3, views/mflrosters.php; #mflMiscButton / #mflRostersButton). */ #main button#mflMiscButton, #main button#mflRostersButton { display:none; } /* - the "FUNCTIONS" / "WAIVERS" / "LOCK TEAMS" tab buttons on the Process Waivers page (views/runwaivers.php:2-4; #specialFunctions / #runWaivers / #lockTeams). ⚠⚠ QUALIFIED WITH `button` BECAUSE #runWaivers IS TWO DIFFERENT ELEMENTS (fixed 8/8/26). Lee: "why isn't it listing leagues for me on this page" — Team Emails showed no league list. The data was never missing: 689 rows and 84,855 characters of table were sitting in #data. This rule was hiding them, because `id='runWaivers'` is BOTH the WAIVERS tab button here AND the league that commish.php emits in SIX places — fetchTeamEmails, fetchGuillotine, fetchWaivers, fetchSaveKeepers, fetchLapse and fetchOrphanValues. An unqualified #id selector cannot tell them apart, so a rule written to hide one button silently blanked the league list on six commissioner pages, and had been doing so since it went in between 17 and 20 July. Worst case is fetchWaivers(): the button and the table carry the SAME id IN ONE DOCUMENT, so no id-based selector can ever separate them — the element type is the only thing that can, which is why this is `button#` and not something cleverer. The other five ids in this block resolve to exactly one
s). Same two bugs, one fix, DESKTOP + MOBILE, every mode: (1) No cell borders anywhere (desktop.css only sets column widths, mobile.css nothing), so with just skin-base's row backgrounds the near-white Light-mode header/rows blended into a borderless block. (2) mobile.css:535/539 hardcode tr.header/tr.detail text to #000; skin-base flips the background dark in Dark mode but that black text stayed -> black-on-dark, unreadable (desktop has no such hardcode, so it read fine). Restate the token text pairing at a specificity that beats mobile.css, and add a themed grid. - Claude 7/25/26 */ /* table.centerMe = the mobile hub's League/Message alarms table (core.php:4036 adds the class only on mobile; desktop is a bare table). Same bare-table symptoms as the rules pages, so give it the same grid treatment. - Claude 7/25/26 CORRECTED 7/26 (Lee: the mobile LIVE DRAFT grew borders it never had). `.centerMe` is a CENTERING class, not a grid marker — ~20 tables carry it and only ONE is a data grid: the alarms table. All the others are layout (the Wonk's #wonkTable / #siteButtons / #wonkSlider, and #topTicker on mobilelive.php, which is what Lee saw). Bordering every .centerMe cell was wrong in principle, and it had already drawn blood once — the body.dfx-wonk exemption further down this file was the first patch. So gate the grid on the table ACTUALLY being one: the alarms table is the only .centerMe with tr.header / tr.detail rows; every layout one uses bare . Child combinators keep the :has() cheap and stop a nested table's rows from qualifying the outer one. - Claude 7/26/26 */ #main table.scoring, #main table#schedule, #main table.ruleGrid { border-collapse:collapse; } #main table.scoring td, #main table#schedule td, #main table.ruleGrid td { border:1px solid var(--panel-border, var(--accent)); } #main table.centerMe:has(> tbody > tr.header, > tbody > tr.detail) { border-collapse:collapse; } #main table.centerMe:has(> tbody > tr.header, > tbody > tr.detail) td { border:1px solid var(--panel-border, var(--accent)); } #main table.scoring tr.header td, #main table#schedule tr.header td, #main table.ruleGrid tr.header td, #main table.centerMe tr.header td { background:var(--header-bg); color:var(--header-text); } #main table.scoring tr.detail td, #main table#schedule tr.detail td, #main table.ruleGrid tr.detail td, #main table.centerMe tr.detail td { background:var(--row-bg); color:var(--ink); } /* MOBILE TEAM-MANAGER HUB team cards (table#appLeagues td.appTeam). Each card is a little table: td.roundtop (level-colored band, rounded top) + td.appPic (pink #ECD5CA helmet panel) + td.roundbottom /div.appLeague (the level+lineup band, e.g. "Dynasty Deep", rounded bottom) + the team name/status below. (2) The bottom band carried a tan-marble TEXTURE in production; that image was dropped for the skins work (Lee doesn't want the marble back) — but the band went transparent, so the card looked unclosed ("bottom missing"). Refill it with a light, warm, skin-TINTED fill (sandstone base + a touch of --accent) so the card closes with its rounded bottom exactly like production. Kept light in every mode (dark text) to match the always-light helmet panel above it. (3) span.teamStatus is hardcoded #F8F8F8 (near-white) — invisible on the light page in Light mode. Hand it the mode-aware --ink so it reads in every mode (it sits on the page surface, not the card). - Claude 7/25/26 */ body.dfx-mobile #main span.teamStatus { color:var(--ink) !important; } body.dfx-mobile #main table#appLeagues td.roundbottom, body.dfx-mobile #main table#appLeagues div.appLeague { background-color:color-mix(in srgb, var(--accent) 20%, #e8dfd2) !important; color:#1b222a !important; border-radius:0 0 8px 8px; } /* CLASSIC mode: the mobile hub #main box is DARK (#161b22), so the team-card text below the cards must be LIGHT (Light/Dark modes already handle this via --ink / the mode --link rules). (1) team-name links fell through to the classic TABLE-link rule (--accent-bg, which is tuned for the light contest cells) -> too dark on the dark box. Use the lifted --link (the same lightened shade Dark mode uses) so they read light, on-brand. (2) span.teamStatus was pinned to --ink, which stays #111 in Classic -> dark-on-dark, unreadable. Use --page-text, the light on-box text Classic already gives #main. - Claude 7/25/26 */ body.dfx-mobile[data-theme="classic"] #main a.appTeamName { color:var(--link) !important; } /* table#preferences (Setup) is the same case: it is fully TRANSPARENT in Classic, so its links sit on the dark box, but the Classic table-link rule hands them --accent-bg, which is tuned for the LIGHT contest cells. Gridiron made that #475569 on #161b22 = 2.28:1. Use the lifted --link, exactly as a.appTeamName above. NOTE the general shape of this whole family of bugs: a rule picks a token for "tables", but whether a given cell is light or dark is not something the selector can know. Each transparent-on-dark table has to be named. The contrast scanner (claude/contrastscan.js) is how they get found — they are invisible, so reading the page will not surface them. - Claude 7/28/26 */ body.dfx-mobile[data-theme="classic"] #main table#preferences a { color:var(--link) !important; } body.dfx-mobile[data-theme="classic"] #main span.teamStatus { color:var(--page-text) !important; } /* ...but the lifted --attention-ink that mobile Classic sets for its DARK #main box is wrong INSIDE the light table cells that sit on that box. "Select keepers" came out #f2814d on a --row-bg of #f8fafc: 2.5:1. Custom properties inherit, so re-setting the token on the light row surfaces hands their descendants the deepened variant without touching anything on the dark box. Same fix shape as the league-level pairing: the token follows the SURFACE, not the page. - Claude 7/28/26 */ /* MOBILE CLASSIC puts its #main box on a DARK surface, so --link and --attention-ink are lifted to read on it. But the TABLE CELLS sitting on that box are LIGHT (--row-bg is light in Classic for every palette except Onyx, which is a dark-content skin by design), and the lifted variants are far too pale there: "Select keepers" 2.5:1, the bracketed projections 2.03:1, the (Q) status flags 2.5:1. Custom properties inherit, so re-declaring both tokens on the cell hands every descendant the DEEP variants — the same expressions modes.css Light uses — without disturbing anything drawn directly on the dark box. Onyx is excluded because its cells really are dark. Scoped to the row types that actually CARRY a surface (--row-bg / --header-bg). It was briefly widened to every td, which was wrong: transparent cells sit on the DARK box and need the lifted variants, so the blanket rule pushed the Setup and Player News links back under AA. The token has to follow the SURFACE, and only these rows have one. - Claude 7/28/26 */ body.dfx-mobile[data-theme="classic"]:not(.skin-onyx) #main table.rounded:not(#options), body.dfx-mobile[data-theme="classic"]:not(.skin-onyx) #main table#news, body.dfx-mobile[data-theme="classic"]:not(.skin-onyx) #main table#injuries { --attention-ink:#a83c12; --link:var(--link-light, color-mix(in srgb, var(--accent) 85%, black)); /* per-skin on-light link - Claude 8/3/26 */ /* the base ink too. Making these tables opaque without this just inverts the bug: text that used to inherit the light --page-text from the dark box now sits on a LIGHT table at 1.21:1. NOT !important, so any cell that sets its own color still wins. - Claude 7/28/26 */ color:var(--ink); } /* Tips & Tricks "The Wonk" (images/wonk1.jpg) is a JPG, so its white background is baked in and reads as a hard white rectangle — especially jarring on the dark page. Clip it to an OVAL cameo (Lee) with a themed frame; the ellipse trims only the white corners, leaving the character. Affects desktop too. - Claude 7/25/26 */ /* $= exact file so this hits the Tips page's wonk1.jpg ONLY, not the Wonk-button wonk1-t.png (Lee 7/25) */ #main img[src$="wonk1.jpg"] { border-radius:50%; background:#fff; padding:6px; box-sizing:content-box; border:2px solid var(--panel-border, var(--accent)); box-shadow:var(--shadow, 0 2px 6px rgba(0,0,0,.35)); } /* ...but NOT inside the Wonk page's tiny tab buttons. The note above says the $= selector hits the Tips page only; that was never true — wonk.php's four tabs use the same wonk1.jpg — it just never showed, because wonk.php did not load the skin layer until 8/4/26. fullpage.css:215 pins those buttons to a fixed width:60px, so the cameo's 6px padding + 2px border (+16px each way) pushed the label out of its box: "Waiver" wrapped, that one button grew to 52px tall while its siblings stayed 36, and the text spilled past the rounded edge. The cameo is decoration for a portrait, not for a 24px icon in a fixed box, so switch it off there rather than widening a button the base sheet owns. - Claude 8/4/26 */ #main button.tinyWonkIcon img[src$="wonk1.jpg"] { border-radius:0; background:none; padding:0; border:0; box-shadow:none; box-sizing:border-box; } /* Weekly-schedule "Date/Time" column (td.highlightColumn) is hardcoded #C0E0DA with NO text color, so in Dark the text inherits light --ink onto a pale teal cell. #C0E0DA is really DataForce's --row-bg with extra accent, so derive it the same way the DFF rows are done: Classic stays ~identical, every skin gets its own tint, and Dark gets a readable pairing. */ #main table#schedule td.highlightColumn { background-color:color-mix(in srgb, var(--accent) 22%, var(--row-bg)); color:var(--ink); } /* Roster / dashboard / standings / draft-board colored cells use HARDCODED light pastels (position colors QB..DE, team red/blue, start/bench, standings rows) with NO text color, so the text inherits --ink and goes WHITE-on-light in Dark mode -> unreadable. Those cells are ALWAYS light, so pin the text dark in every mode. (Headers keep their own white.) */ #main table.roster td.QB, #main table#roster td.QB, #main table#draftBoard td.QB, #main table.roster td.RB, #main table#roster td.RB, #main table#draftBoard td.RB, #main table.roster td.WR, #main table#roster td.WR, #main table#draftBoard td.WR, #main table.roster td.TE, #main table#roster td.TE, #main table#draftBoard td.TE, #main table.roster td.PK, #main table#roster td.PK, #main table#draftBoard td.PK, #main table.roster td.DE, #main table#roster td.DE, #main table#draftBoard td.DE, #main table.roster td.redTeam, #main table.roster td.blueTeam, #main table.roster td.positionBoxRed, #main table.roster td.positionBoxBlue, #main table#roster td.positionBoxRed, #main table#roster td.positionBoxBlue, #main table.roster td.startPos, #main table.roster td.benchPos, #main table.dashboard tr.startPos td, #main table.dashboard tr.benchPos td, #main table.roster tr.highlighted td { color:#111; } /* ⚠ `#main table.roster tr.standings td` WAS IN THE LIST ABOVE AND DOES NOT BELONG THERE — removed 8/15/26 after a customer sent screenshots of the League Standings page unreadable on three different skins (Onyx, Primetime, Red Zone). The list above is "cells that are ALWAYS LIGHT". Standings rows are not: desktop.css:975 paints them `background-color:var(--row-bg)`, a SURFACE token that follows the mode — #161b22 in Night Game, #1e293b on Onyx in Classic. Pinning #111 on top of that measured **1.09:1** in Night Game and **1.29:1** on Onyx Classic. Letting the cells inherit --ink instead gives 14.64:1 and 11.82:1. Day Game is effectively unchanged (18.88:1 -> 16.04:1), which is why this is a straight removal rather than a dark-only override. THIS HIT EVERY PALETTE, not the three reported — any skin in Night Game, plus Onyx in Classic. ⚠ THE TRAP IS THAT `tr.standings` MEANS TWO DIFFERENT TABLES, and only one of them was ever fixed. play.php emits it in the Season Schedule (line 1157) AND on the League Standings page (2125/2135/ 2142). The Season Schedule's cells are ALL classed — weekBox / oppoBox / scoreBox / winnerBox — and lines 1274-1277 below already re-theme those four with `!important`, so the schedule never showed the bug and is untouched by this removal. The Standings page's cells are UNCLASSED (`
`, .center, .right, .visitData), so nothing overrode the pin and they stayed #111. That is also why rule (8) at ~line 2139 excludes `.standings` with the note "pinning them #111 made them dark-on-dark (Lee 7/25)" — the same defect, found from the schedule side, fixed there with a `:not()` on an `!important` rule that could never reach this earlier non-important one. The level-9 red/blue team cells inside these rows ARE hardcoded light pastels and keep their own pin on the `td.redTeam, td.blueTeam` line above, so they are unaffected. - Claude 8/15/26 */ /* starter-slot labels (QB/RB/... on the dashboard's start rows) are a hardcoded light teal #C0E0DA. Derive from the accent so they match the skin — kept ALWAYS light (mix over white, not the surface) so the dark label text stays readable in every mode. ~34% ≈ today's teal on DataForce, and each other skin gets its own tint. */ #main table.dashboard tr.startPos td, #main table.roster td.startPos, #main table.roster tr.highlighted td { background-color:color-mix(in srgb, var(--accent) 34%, white); } /* bench = a LIGHTER shade of the starter tint (declared AFTER startPos so bench cells that also carry the startPos class win). Pin the label text dark too, now that it's a light cell. */ #main table.roster td.benchPos, #main table.dashboard tr.detail td { background-color:color-mix(in srgb, var(--accent) 14%, white); color:#111; } /* rosters-page player names are LINKS inside the light position cells; keep them DARK in every mode (--link lightens in Dark -> unreadable on the pastels). */ #main table.roster td.QB a, #main table.roster td.RB a, #main table.roster td.WR a, #main table.roster td.TE a, #main table.roster td.PK a, #main table.roster td.DE a, #main table#roster td.QB a, #main table#roster td.RB a, #main table#roster td.WR a, #main table#roster td.TE a, #main table#roster td.PK a, #main table#roster td.DE a { color:#111; } /* SEASON SCHEDULE / results tables (team-name header + weekly opponent rows) were hardcoded #4A9586 header / #8DC7BB number / #E7F3F1 cells. Make them proper skin SURFACES so they follow the skin AND dark mode. Targeted at the schedule cell classes, so the standings red/blue-team cells (which stay light with dark text) are untouched. NOTE: the Season Schedule table is table.rosterS (plural), the roster page is table.roster (singular) — cover BOTH or the schedule falls back to #111 dark-on-dark in Dark mode (Lee 7/25). - Claude 7/25/26 */ #main table.roster td, #main table.rosters td { border-color:var(--panel-border); } #main table.roster tr.header td, #main table.rosters tr.header td { background-color:var(--major-bg); color:var(--major-text); } #main table.roster tr.standings td.oppoBox, #main table.rosters tr.standings td.oppoBox, #main table.roster tr.standings td.scoreBox, #main table.rosters tr.standings td.scoreBox { background-color:var(--row-bg) !important; color:var(--ink) !important; } #main table.roster tr.standings td.weekBox, #main table.rosters tr.standings td.weekBox, #main table.roster tr.standings td.winnerBox, #main table.rosters tr.standings td.winnerBox { background-color:var(--header-bg) !important; color:var(--header-text) !important; } /* Sortable column headers (Player Listing / Fantasy Points) are in tr.header. skin-base only tokenised header , so these stayed the hardcoded #8DC7BB teal. Cover the headers, the default sort-label color (was #003333, unreadable on a dark header), the hover cue, and the active-sort state. */ #main tr.header th, #main tr.subHeader th, #main tr.safeGuardHeader th { background-color:var(--header-bg); color:var(--header-text); } #main table.sortable th[data-sort] { color:var(--header-text); } #main table.sortable th[data-sort]:hover { } #main table.sortable th[data-sort].sorting-asc, #main table.sortable th[data-sort].sorting-desc { } /* Player Listing body cells (#report table.sortable td) were hardcoded #000 -> dark-on-dark in Dark mode, and had no cell borders in any mode. Same recurring data-table pattern: token text + themed grid. - Claude 7/25/26 */ #main #report table.sortable td { color:var(--ink) !important; } #main #report table.sortable td, #main #report table.sortable th { border:1px solid var(--panel-border, var(--accent)) !important; } /* Draft Boards left sidebar column (the vertical "Single Year / Startup / Rookie/Free Agent" labels) is td.header — a class on the cell, inside a normal row — NOT tr.header td, so skin-base's header tokenisation missed it and it kept the hardcoded #8DC7BB teal. Give it the same skin header surface as the Drafts/Auctions header row. - Claude 7/18/26 */ #main table#boards td.header { background-color:var(--header-bg); color:var(--header-text); } /* Trade tables — Trade Bait, Offer Trade, Trades Offered To Me, Trades I Am Offering, Trade History. The team-name+date header rows (tr.tradeHeader) and the notes/player rows (tr.tradeDetail / tr.tradeSubHeader) were hardcoded teal/#E7F3F1 and never followed the skin (7/18). THREE-BAND HIERARCHY, now applied to BOTH layouts (Lee 7/26 — was mobile-only): tr.tradeHeader -> --major-bg / --major-text (strong band; --major-bg is a BRAND token that modes.css leaves alone, so it stays the skin color on a dark panel instead of collapsing toward --row-bg the way --header-bg does) tr.tradeSubHeader -> --header-bg / --header-text (mid band) tr.tradeDetail -> --row-bg / --ink (pale rows) NOTE the two layouts started from DIFFERENT production colors, so this means different things: MOBILE (mobile.css:673-675) really has 3 bands — #4A9586 white / #8DC7BB / #E7F3F1 — and the 7/18 mapping had flattened them to 2. There this RESTORES production. DESKTOP (desktop.css:1038-1040) only ever had 2 — header #8DC7BB, sub-header AND detail both #E7F3F1 — so this is a deliberate visual CHANGE: the header deepens to the strong band and the sub-header gains the mid band it never had. Same fix Lee wanted for the same reason (sub-header was indistinguishable from the rows), but flagged because desktop production will look different, not merely more skin-aware. - Claude 7/26/26 */ #main tr.tradeHeader td { background-color:var(--major-bg); color:var(--major-text-aa, var(--major-text)); } #main tr.tradeSubHeader td { background-color:var(--header-bg); color:var(--header-text); } #main tr.tradeDetail td { } /* Classic gets its sub-band separation free from the skin's own palette (DataForce #8DC7BB over #E7F3F1 = 1.68x), but Light/Dark swap in modes.css's NEUTRAL surfaces, where --header-bg and --row-bg are near-identical (#eef1f5/#ffffff = 1.13x, #20272f/#161b22 = 1.15x) and the band disappears. Tint it with the skin accent in those two modes only, so Classic keeps exact production fidelity. Keyed to the MODE, not .dfx-darkpanel — this is about the neutral mode surfaces being too close together, not about the panel being dark. - Claude 7/26/26 */ body[data-theme="light"] #main tr.tradeSubHeader td, body[data-theme="dark"] #main tr.tradeSubHeader td { background-color:color-mix(in srgb, var(--accent) 24%, var(--header-bg)); } /* ── MOBILE-ONLY frame + grid for table.tradeList ─────────────────────────────────────────────── The three-band color mapping above is now SHARED with desktop; only the box treatment stays mobile-scoped. mobile.css pins `border:none` on all three row types and puts a lone hardcoded #4A9586 frame on the table (which clashed on non-teal skins), so mobile gets the same themed frame + separate-borders/rounded-corner recipe as table.mobileTable. Mobile rows are single-cell, so the grid is horizontal rules only. Corner radii are set explicitly because Trade History emits tr.tradeHeader WITHOUT class='rounded' — see the border-collapse note on table.mobileTable. NOT carried to desktop: those tables are 3-column and Lee has not asked for a grid there. - Claude 7/26/26 */ body.dfx-mobile #main table.tradeList { border-collapse:separate !important; border-spacing:0 !important; background-color:transparent !important; border:1px solid var(--panel-border, var(--accent)) !important; border-radius:6px; } body.dfx-mobile #main table.tradeList td { border:0 !important; border-bottom:1px solid var(--panel-border, var(--accent)) !important; } body.dfx-mobile #main table.tradeList > tbody > tr:last-child > td { border-bottom:0 !important; } body.dfx-mobile #main table.tradeList > tbody > tr:first-child > td:first-child { border-top-left-radius:6px; } body.dfx-mobile #main table.tradeList > tbody > tr:first-child > td:last-child { border-top-right-radius:6px; } body.dfx-mobile #main table.tradeList > tbody > tr:last-child > td:first-child { border-bottom-left-radius:6px; } body.dfx-mobile #main table.tradeList > tbody > tr:last-child > td:last-child { border-bottom-right-radius:6px; } /* ── TRADE HISTORY status words (Lee 7/26) ────────────────────────────────────────────────────── Were fixed colors that ignored the skin: only two of the six were colored at all — "Approved" hardcoded CSS `green` (#008000) and "Under Review" as span.red — and the other four (Pending Approval / Overturned / Declined / Retracted) were plain text. Put them on the go/warn/stop palette, mapped by MEANING rather than blanket-red-for-negative: green = Approved (the good terminal state) amber = Pending Approval, Under Review (in flight — "Under Review" was red, which read as an error when it is really a caution) stop = Overturned, Declined (actively reversed or rejected) muted = Retracted (you withdrew it yourself — not a bad event, so no alarm color) trade.php keeps its original `red`/`green` classes ALONGSIDE the new semantic ones, so production is unchanged until Lee promotes the CSS. These are declared AFTER the span.red rule at the top of this file (same specificity) so the semantic color wins here. - Claude 7/26/26 */ #main span.statusApproved { color:var(--dfx-go-ink); font-weight:bold; } #main span.statusPending, #main span.statusReview { color:var(--dfx-warn-ink); font-weight:bold; } #main span.statusOverturned, #main span.statusDeclined { color:var(--dfx-stop-ink); font-weight:bold; } #main span.statusRetracted { color:var(--ink); opacity:.7; font-weight:bold; } /* "Agreed to Prepay" was span.red — it is a commitment, not a warning; make it an informational note on the complementary (aside/info) color instead of alarm red. */ #main span.statusPrepay { color:var(--dfx-info-ink); font-weight:bold; } /* ── TRADE BAR (table.balancer, built by tradecalculator.php) ──────────────────────────────────── A 5-segment gauge: the lit cell moves from either end (lopsided) to the centre (fair). Colors were the CSS keywords red / yellow / green plus a #F5EFE0 cream for the unlit cells and a hardcoded #4A9586 teal border — none skin-aware, and pure `yellow` on a white panel is nearly unreadable. Move to the same go/warn/stop palette. The unlit cells become a neutral surface tone so the lit one carries all the signal. NOT scoped to mobile: the bar renders on the desktop trade pages (the mobile branches of loadRespond/loadMyOffers don't emit it), and Lee asked for the bar itself. - Claude 7/26/26 */ #main table.balancer td { border-color:var(--panel-border, var(--accent)); } /* ⚠ THE UNLIT CELLS ARE OPAQUE. They were `color-mix(--ink 14%, TRANSPARENT)` from 7/26 to 8/7/26, so the tint composited onto whatever sat behind the bar. That reasoning was half right and it produced a real bug (Lee 8/7/26: "the trade bar on the Approve Trades page is not the same color as it is on the Offer a Trade page"). The bar has two homes: #balancerBox on the content panel, and — desktop only — INSIDE the tr.tradeHeader band. Translucent meant the SAME rule gave two different results: Offer a Trade behind #fafefb -> track #d9ddda lit-vs-track 2.99 reads as a gauge Approve Trades behind #4A9586 -> track #428376 lit-vs-track 1.08 reads as one green square The 7/26 note optimised for "is the track visible against the backdrop" and never checked "is the LIT cell visible against the track" — which is the only thing the gauge actually communicates. Measured across all 14 palettes, translucent bottoms out at 1.04 (onyx/Dark): the lit cell becomes invisible. Opaque instead. Worst lit-vs-track is now 2.99 Classic / 3.11 Light / 4.94 Dark. THE COST IS REAL AND IS ACCEPTED: on a dark band the opaque track can approach the band's own lightness (1.14 on midnight/Dark), so the track stops reading as a separate strip. That is the lesser failure — the cells keep their own border (the rule above), which carries the 5-segment structure, and the lit cell stays emphatic. Losing the track outline costs you the frame; losing the lit cell costs you the answer. - Claude 8/7/26 */ #main table.balancer td.grey { background-color:color-mix(in srgb, var(--ink) 14%, var(--content-bg)); } #main table.balancer td.green { background-color:var(--dfx-go); } #main table.balancer td.yellow { background-color:var(--dfx-warn-fill); } #main table.balancer td.red { background-color:var(--dfx-stop-fill); } /* the disabled-bar messages ("Trade bar disabled until…") ride in a td.grey — keep them readable */ #main table.balancer td.grey { color:var(--ink); } /* League Chat page: the message box (#chat) and emoji tray (#emoji) were #4A9586-bordered white (#F8F8F8) panels, and the entry field (#chatEntry) a #4A9586-bordered #E7F3F0 box with teal text — none followed the skin or dark mode. Move them onto skin surfaces (background-color only, so the football watermark image on #chat survives). Team-name color (span.team, #4A9586) -> mode-aware --link; the commish-red message color stays as its alert cue. - Claude 7/18/26 */ #main #chatRoom div#chat, #main #chatRoom div#emoji { background-color:var(--content-bg); border-color:var(--accent); color:var(--ink); } #main #chatRoom div#chat span.team { color:var(--link, var(--accent)); } #main input#chatEntry { color:var(--input-text); border-color:var(--accent); } /* Action-tier buttons on real app pages: buttons.css gives .primary/.danger padding:9px 18px, but the app's plain buttons (e.g. League Maintenance's unclassed leagueButtons) carry no author padding — just the browser default — so the tiered pair rendered taller than their neighbours. Revert the tier padding to the UA default so primary/danger match the norm height. - Claude 7/18/26 */ #main button.primary, #main button.danger, #main button.secondary { padding:revert; } /* SIDE padding scales with the CORNER dial (Lee 8/4/26: "in Cuddly the buttons look crowded"). desktop.css:687 gives every plain button a flat .2em all round, which was chosen for square corners. It does not survive rounding: MAKE A DEPOSIT is 22px tall, so Cuddly's 14px radius CLAMPS to 11px and each end cap eats ~11px of the button's own width — against 2.56px of padding, the label ends up sitting right where the curve starts. So derive the side padding from --radius instead of picking a number: Chiseled (0) is byte-identical to today, Curvy gains 1.8px a side, Cuddly 4.2px (MAKE A DEPOSIT 119px -> 127px). TOP/BOTTOM are left alone — the caps only eat horizontally, and height is what the rule above is protecting. FACTOR was .45, cut to .30 the same day (Lee: "a little too much, take away about 1/3 of what you just added"). .30 is exactly two thirds of the added amount, not of the total — Chiseled still gains nothing and the .2em base is untouched. The three tier classes are listed so this still reaches them past that `padding:revert`; it only sets the two side longhands, so their reverted height is untouched. Audited on the lobby (455 buttons): no button overflows its parent and the document does not gain any horizontal scroll, in either state. - Claude 8/4/26 FACTOR CUT AGAIN .30 -> .24 (Lee 8/5/26, the squeezed lobby HOLD button). The overflow audit above was the wrong test for that button, and this is why: the lobby's action buttons carry an EXPLICIT width (desktop.css:797-811, join 3.6em / hold 3.5em / buy + pay 3.2em ...), and a