| can't go), so it
needs its own selector to pick up the same colors rather than a real
header cell inheriting them automatically. */
/* :not(.row-header-cell) (2026-09-15, accessibility-fix regression, per
the user: "Individual standings & wall chart: Player names incorrectly
have the inverted background of a header") -- the 2026-09-14
accessibility pass turned each Individual Standings/Wall Chart row's
own player-name cell from a | into a | 's default bold/background back to looking like its sibling
| cells -- but this rule's plain `.t-results-table th` selector has
higher specificity (class+element vs. .row-header-cell's class alone)
and was never meant to reach anything but a real column
header/.t-table-title/.t-prize-group-heading row to begin with, so it
was winning that fight and painting every row-header cell with the
inverted column-header look instead. */
.t-results-table th:not(.row-header-cell),
.t-prize-group-heading td {
background: #2a2a2a;
color: #52e077;
}
/* .t-table-title (2026-09-03, per the user, same request as above,
extended to every table on this page's own title row, not just the two
Prize List ones): centered, and no border-bottom against the ordinary
column-header row directly beneath it in the same -- the
sitewide `th, td { border-bottom: ... }` rule would otherwise draw a
thin line across the middle of what reads as one solid two-line header
bar. The column-header row's own border-bottom (separating it from the
body rows below) is untouched. */
.t-results-table th.t-table-title {
text-align: center;
border-bottom: none;
}
/* Dark mode's own inverted-header background toned down from an earlier
near-white #f4f4f4 (2026-09-06, per the user: "too bright") to #e6e6e6
-- still light enough to read as a real inversion against the page's
dark surroundings, and still >4.5:1 (WCAG AA) against the #29723C text,
just not glaring. */
@media (prefers-color-scheme: dark) {
:root:not([data-theme]) .t-results-table th:not(.row-header-cell),
:root:not([data-theme]) .t-prize-group-heading td {
background: #e6e6e6;
color: #29723C;
}
}
:root[data-theme="dark"] .t-results-table th:not(.row-header-cell),
:root[data-theme="dark"] .t-prize-group-heading td {
background: #e6e6e6;
color: #29723C;
}
/* TEST (2026-09-03, per the user: "a green gradient background for the
page ... dark mode would be black fading to dark green and light mode
would be white fading to light green") -- both green tints are mixed
from the same logo green (#29723C) as the header-text test just above,
not independently chosen (light: white + 18% green; dark: black + 40%
green). Scoped to this page's own
(results.php) rather than the shared `body { background: var(--color
-bg) }` rule (high-school-league/style.css) -- another one-off look
test, not a site-wide change. Gated on [data-theme] the same way that
file's own :root color blocks are (theme.js sets it on before
first paint; the @media block is the matching no-JS progressive
-enhancement fallback for the same reason theirs has one).
REVISED 2026-09-04, per the user: a single top-to-bottom fade "doesn't
quite work on large pages" -- this page's real length (a full
tournament's worth of team standings/cross table/wall chart per
section) means most of any one fade's own length is spent near
whichever end color it started at, barely visible, with the actual
color change only apparent over a page far longer than any one screen.
repeating-linear-gradient instead of linear-gradient tiles the same
two-color fade indefinitely down the whole page, so it stays a visible,
consistent "back and forth" at any scroll position regardless of the
page's own total length. Per the user's own sizing spec ("the moving
diagonal being 1xwidth and 2xlength of standard viewport width"): a
135deg diagonal band, one full white/black -> green -> white/black
cycle every 200vw traveled along that diagonal (2x viewport width),
reaching the opposite (green) color at the halfway point, 100vw in (1x
viewport width) -- both in real vw units, so it's tied to the actual
viewport rather than this page's own (narrower, max-width: 1040px)
content column.
REVISED 2026-09-05, per the user: "The light mode background gradient
could get a bit darker" -- light mode's own green endpoint was white +
18% green (#d8e6dc); bumped to white + 28% green (#c3d8c8), same logo
green, just a stronger mix.
REVISED AGAIN 2026-09-05, per the user: "Not quite so dark" -- 28% was
too much; settled on white + 22% green (#d0e0d4), between the original
18% and the overshot 28%. Dark mode's own endpoint wasn't mentioned
either time and is unchanged. */
.t-results-page {
background: repeating-linear-gradient(135deg,
#ffffff 0,
#d0e0d4 100vw,
#ffffff 200vw);
/* Covers the full viewport even when the page's own content is shorter
than it (2026-09-10, per the user: "the background gradient doesn't
work" on a short page) -- without this, the box (this
gradient's own background) only extends as tall as its content, and
the sitewide `body { margin: 40px auto }` rule means it never reaches
the viewport's own bottom edge on its own either way, leaving a plain
white/black gap below it down to wherever the real page ends. Some
slight extra scroll room past 100vh (the sitewide rule's own 40px
top+bottom margins, outside this box) is harmless and unnoticeable --
simpler and more robust than hardcoding that 80px into a `calc()`
here, which would silently drift out of sync if that margin ever
changes. */
min-height: 100vh;
}
@media (prefers-color-scheme: dark) {
:root:not([data-theme]) .t-results-page {
background: repeating-linear-gradient(135deg,
#000000 0,
#102e18 100vw,
#000000 200vw);
}
}
:root[data-theme="dark"] .t-results-page {
background: repeating-linear-gradient(135deg,
#000000 0,
#102e18 100vw,
#000000 200vw);
}
/* The sitewide default (8px 12px) reads as too much vertical whitespace on
these longer tables (2026-09-02, per the user) -- same reasoning Team
Standings/Prize List already got tightened for below, extended here to
the Individual Standings/Cross Table (no more specific class of its own)
and the Wall Chart (its own .t-wallchart-row1/row2 rules below trim one
side further per row so a player's two lines sit close as a pair). Team
Standings/Prize List each have their own slightly different value below,
which (equal selector specificity, later in the file) wins over this. */
.t-results-table th,
.t-results-table td {
padding: 4px 9px;
}
/* Every cell in a row shares one text baseline (2026-09-02, per the user:
the mono numeric columns kept looking vertically off against the
proportional-font columns beside them) -- the browser's own per-row
baseline alignment handles this correctly for whatever font actually
loads (the ui-monospace stack below resolves to a different real font
per OS/browser, so a fixed px/em nudge tuned against one of them drifts
on another), which a fixed offset can't. Default td vertical-align is
middle, which is what let the taller mono font-size visibly ride
higher/lower than the surrounding text in the first place. */
.t-results-table td {
vertical-align: baseline;
}
.t-results-table .t-num {
text-align: right;
}
/* Grade is a small plain integer, not a stat worth right-alignment or the
monospace treatment (2026-09-02, per the user) -- centered instead. */
.t-results-table .t-center {
text-align: center;
}
/* Board tournaments' own Players column (2026-09-08, per the user, mirroring
the same change already made to the printable output) -- left-justified
under a left-justified header, matching printable's own td.print-left/
print-indent (printable_generator.php), rather than this table's usual
.t-num right-alignment. */
.t-results-table .t-left {
text-align: left;
}
.t-results-table .t-indent {
text-align: left;
padding-left: 1em;
}
/* white-space: nowrap (2026-09-05, per the user) -- "(Rating, Grade)" now
sits on an expanded cross-section team member's own second line (a
before this span in results.js), and that line itself must never
break mid-parenthetical once .t-team-member-detail's own white-space:
normal (needed so the *name* above it can still wrap on a long one)
would otherwise let it wrap between "Rating," and "Grade" on a narrow
column. */
.t-results-table .t-muted {
color: var(--color-muted-text);
font-weight: normal;
white-space: nowrap;
}
/* Same reasoning as .t-prize-table's own width: auto (2026-09-02, per the
user: "do not stretch wall charts") -- the sitewide table default is
width: 100%, which stretched this table's own columns out across the
full page width even though it already scrolls horizontally past a
handful of rounds. */
.t-wallchart {
width: auto;
}
/* Wall Charts: every cell vertically centered (2026-09-25, per the user),
overriding .t-results-table td's baseline alignment above -- with two-line
players and rowspan cells, middle keeps each cell centered against its
neighbors. */
.t-wallchart td,
.t-wallchart th {
vertical-align: middle;
}
.t-wallchart-row1 td {
border-bottom: none;
padding-bottom: 2px;
}
.t-wallchart-row2 td {
border-top: none;
padding-top: 0;
color: var(--color-muted-text);
font-size: 0.9em;
}
.t-round-cell {
text-align: center;
}
/* Reduced vertical padding on every Score/tiebreak-value cell, across
every results table except the Wall Chart (2026-09-05, per the user:
"All tables except wall charts: Reduce the vertical padding between
the scores and the tiebreak columns"). Every Score/tiebreak on
this page consistently carries plain .t-num with no .t-mono-num --
every *other* plain-integer numeric column (Place/Rate/Players/chart
number/USCF ID) gets .t-num *and* .t-mono-num together instead -- so
:not(.t-mono-num) reliably targets only Score/tiebreak cells without
needing to name every table. The Wall Chart never has a td.t-num
without .t-mono-num at all (its own running-cumulative cells use
.t-round-cell, not .t-num), so it's naturally excluded here too,
without an explicit :not(.t-wallchart). Higher specificity than both
the sitewide .t-results-table td rule above and .t-team-table/
.t-prize-table's own td overrides below, so this wins regardless of
source order. */
.t-results-table td.t-num:not(.t-mono-num) {
padding-top: 2px;
padding-bottom: 2px;
}
/* Cross Table's own per-round cells, same reduction -- but NOT the Wall
Chart's (2026-09-05, per the user: "Cross tables: Also reduce the
vertical padding between rounds") -- both tables' round cells share
.t-round-cell, so this is scoped by the containing table's own class
rather than .t-round-cell alone. */
.t-crosstable td.t-round-cell {
padding-top: 2px;
padding-bottom: 2px;
}
/* Alternate-row shading (2026-09-03, per the user: "Use the alternate
shading rows for all tables like what you did for wall charts"), plain
tr:nth-child on every results table's own tbody -- :nth-child counts
DOM position regardless of a row's own visibility, so a Team Standings/
Team Prize List row's expanded member rows (visibility: collapse when
closed, results.js's teamMemberRowsHtml()/teamPrizeMemberRowsHtml())
fall into this same alternation automatically, without needing their
own team-aware logic -- confirmed this is what the user actually wanted
after an earlier version shaded a whole team + its members as one flat
block instead: "Expanded team members should also have alternating
shading" too, same as every other table's own rows.
--t-row-shade is a translucent black/white *overlay*, not a flat
--color-surface-alt like this rule's first version (2026-09-04, per the
user: with the .t-results-page gradient test above now in play, a flat
color only contrasts well against the one gradient position it happens
to be closest to -- light mode's #fafafa read as basically invisible
near the page's own near-white top and only became visible much further
down once the gradient had drifted away from that tone, and in dark
mode the gradient's own ending color could coincide with a flat shaded
-row tone outright). A percentage overlay instead darkens/lightens
*relative to whatever's directly underneath it*, so it reads as the
same consistent step at any scroll position and can never land on
the exact same value as the gradient itself.
REVISED 2026-09-04, per the user: light mode's overlay was neutral
black (rgba(0,0,0,...)), which read as "a reddish shade" against the
.t-results-page gradient's own green -- a true neutral grey placed
next to a saturated color visually shifts toward that color's
complement (simultaneous contrast), and green's complement is red, so
a mathematically-neutral overlay perceptually picked up a red cast
from its own green surroundings. Tinting the overlay itself green
(the same #29723C logo green as the rest of this page's tests) instead
of neutral black removes the clash outright rather than fighting the
perceptual effect. Dark mode's overlay is untouched (white, not
flagged as an issue). */
:root {
--t-row-shade: rgba(41, 114, 60, 0.08);
}
@media (prefers-color-scheme: dark) {
:root:not([data-theme]) {
--t-row-shade: rgba(255, 255, 255, 0.08);
}
}
:root[data-theme="dark"] {
--t-row-shade: rgba(255, 255, 255, 0.08);
}
/* A row-header cell (a | holding a player/team name) must not
paint its own copy of the row's translucent shade (2026-09-25, per the
user: "the player name ... is a different background color") -- the shared
.row-header-cell rule's `background: inherit` (high-school-league/
style.css) copies the | 's rgba shade onto the cell, which then stacks on
the row's own already-painted shade, so the name cell rendered darker than
its neighbors. Transparent lets the row's one shade show through, same as
every sibling | . */
.t-results-table .row-header-cell {
background: transparent;
}
.t-wallchart tbody tr:nth-child(4n + 1),
.t-wallchart tbody tr:nth-child(4n + 2),
.t-crosstable tbody tr:nth-child(even),
.t-prize-table tbody tr:nth-child(even) {
background: var(--t-row-shade);
}
/* Team Standings' own shading can't be plain tr:nth-child at all
(2026-09-04, per the user: "Unexpanded teams need to be alternate
color row") -- a collapsed team's own member rows still count toward
:nth-child's position even though they take no visible space
(visibility: collapse), so a team's own row lands on whatever parity
its *predecessors' own member counts* happened to add up to, not a
clean alternation by team position. results.js now stamps a team's own
row with .t-row-shade directly (by team index, not DOM position), and
its member rows with .t-member-shade-a/-b -- "The first expanded player
changes from that color and alternates from there" (2026-09-04, per the
user): member 1 is deliberately the opposite of its own team row, then
alternates normally from there, independent of every other team's own
member count.
This does mean an odd-sized team's own last member and the next team's
row land on the same *logical* alternation slot ("if the number of
players is odd the last player and the next team will be the same
color" -- 2026-09-04, per the user, describing the inherent conflict
between "clean per-team alternation" and "members keep alternating
from their own team's color": the two can't both hold when a team's
member count is odd). Per the user's own mitigation ("make the
expanded player colors slightly different than the overall alternating
colors"), --t-row-shade-member-a/-b are a *different* pair of overlay
strengths from --t-row-shade/transparent, not a re-use of the same
two tones -- so even when a member row and the following team row
share the same logical slot, they never render as the exact same
color, just two visibly different, deliberately-adjacent tones.
Light mode's pair is green-tinted (rgba(41,114,60,...)), not neutral
black, same reasoning and same fix as --t-row-shade just above (a
neutral overlay against this page's own green gradient read as
reddish; dark mode's white overlay wasn't flagged as an issue). */
:root {
--t-row-shade-member-a: rgba(41, 114, 60, 0.03);
--t-row-shade-member-b: rgba(41, 114, 60, 0.13);
}
@media (prefers-color-scheme: dark) {
:root:not([data-theme]) {
--t-row-shade-member-a: rgba(255, 255, 255, 0.03);
--t-row-shade-member-b: rgba(255, 255, 255, 0.13);
}
}
:root[data-theme="dark"] {
--t-row-shade-member-a: rgba(255, 255, 255, 0.03);
--t-row-shade-member-b: rgba(255, 255, 255, 0.13);
}
.t-team-row.t-row-shade {
background: var(--t-row-shade);
}
.t-team-member-row.t-member-shade-a {
background: var(--t-row-shade-member-a);
}
.t-team-member-row.t-member-shade-b {
background: var(--t-row-shade-member-b);
}
/* Numeric columns get a monospaced font, close in shape to the sitewide
system-ui but with fixed-width digits (2026-09-02, per the user) --
Grade is deliberately excluded (it's a plain small integer, not a stat
worth this treatment). ui-monospace/-apple-system-ish stack is the
standard "monospaced sibling" of a system-ui sans stack, so digits stay
visually close to the surrounding text rather than jumping to a
noticeably different typeface like Courier. Score/tiebreak values (via
.t-score-int/.t-score-half below) get it through that shared span pair;
every other plain numeric cell (Place, #, Rate, Players, a Wall Chart
round's own cumulative total) carries this class directly instead. */
.t-score-int,
.t-score-half,
.t-mono-num {
font-family: ui-monospace, 'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, monospace;
/* This stack's digits render visibly smaller than system-ui's at the
same font-size (2026-09-02, per the user) -- a small bump brings
their apparent size back in line with the surrounding proportional
text instead of looking like a shrunken afterthought. Vertical
baseline alignment against the surrounding proportional text is
handled by .t-results-table td's own vertical-align: baseline above
-- not a fixed px/em nudge here, since which real font this stack
resolves to (and therefore its baseline position within its line
box) varies by OS/browser. */
font-size: 1.08em;
}
/* ½-glyph score/tiebreak display (results.js's scoreCellHtml()) -- same
fixed-width whole/half pair technique, and the same 32px/10px sizing, as
app.js's own .board-pts-int/.board-pts-half: a tiebreak sum here (Cum/
CumOp) reaches 3 digits just as easily as a season's board-point total
does there (e.g. "152"), and a narrower box let a 3-digit value overflow
into the ½ span right after it. Duplicated under this page's own name
per the usual per-page convention. */
.t-score-int {
display: inline-block;
width: 32px;
text-align: right;
}
.t-score-half {
display: inline-block;
width: 10px;
text-align: left;
}
.t-expand-col {
width: 1%;
white-space: nowrap;
}
/* Team Standings is usually a short table, and the sitewide default
padding (8px 12px) reads as too much whitespace on it (2026-09-01, per
the user) -- tightened the same way Grand Prix's own #cross-table-
container did for a different reason (a much wider table). Tightened
again 2026-09-02 (per the user) alongside the general .t-results-table
rule above.
width: auto (2026-09-06, per the user: "City/state is still too wide on
live results. Tables should be same as complete results") -- turned out
not to be enough on its own. .t-results-table sets white-space: nowrap
table-wide (real reasons elsewhere: numeric/tiebreak columns, the Cross
Table's own dense grid), which also forces every column here to size to
its longest single, unwrapped line -- including each expanded team
member's own roster row, which reuses the Team (Code)/Players column
slots to show "Name (rating, Section Title)" (teamMemberRowsHtml()/
teamDivisionMemberRowsHtml() in results.js). That text is long enough
on real multi-section tournaments (the Grade Tournament especially) that
width: auto alone still measured out to the full 1000px page width --
confirmed by force-setting `width: auto !important` directly on the
table element and finding the computed width unchanged, i.e. genuinely
content-driven, not a losing CSS rule. .t-team-name (Team (Code)) and
.t-team-member-detail (that same expanded-roster text) below opt back
into wrapping specifically, which is what actually lets width: auto
here mean something. Much more visible on a Live (not yet complete)
tournament specifically because Team Prize List is suppressed while
live (same "no prize lists" rule as the per-section one), leaving Team
Standings as the only, and therefore most obviously oversized, table on
the page -- though the same oversizing is really there on a complete
tournament's own Team Standings too, just less noticeable next to an
already-narrow Team Prize List sitting right above it. */
.t-team-table {
width: auto;
}
.t-team-table th,
.t-team-table td {
padding: 4px 9px;
}
.t-team-name {
white-space: normal;
}
.t-team-member-detail {
white-space: normal;
}
/* table-layout: fixed (2026-09-06) -- plain width: auto plus per-column
max-width/white-space: normal (the first attempt at this fix) still
didn't shrink the table: table-layout: auto's own column-width
algorithm uses each cell's *unwrapped* preferred width as an input and
only treats max-width as a ceiling on how much extra room a column can
be GIVEN, not a floor forcing it to actually wrap when the table has
room to spare -- confirmed by measuring the Players column still at its
pre-fix width even after every cell in it had both white-space: normal
and a real max-width. Fixed layout is what schools-players/index.php's
own nested roster table ended up needing for the exact same reason (see
that page's own style.css comment).
Per-column widths themselves used to live here too, keyed by column
position (:nth-child). Moved into a real
(teamTableColgroupHtml(), results.js) instead (2026-09-06, per the
user: City/State and Players are now three underlying grid columns,
not two -- a team row's own City/State spans the first two of them
while an expanded member row instead spans its own name/rating[/
section] detail across the last two, leaving only the first for that
row's own team_rank number). No single row has three separate,
non-spanning cells across that group any more for :nth-child to read a
per-column width off of (some rows span 1+2 there, others 2+1) -- a
declares each column's width directly instead, independent
of which cells in any given row span how many of them. */
.t-team-table {
table-layout: fixed;
}
/* A team standings row's own expanded roster (results.js's
teamMemberRowsHtml()) -- real sibling | s of the same table (2026-09-
02, per the user: its Score/tiebreak columns must align with the team
row's own), not a separate nested table, so this is row styling rather
than a second table's worth of rules. Muted color plus a slightly
smaller size is this page's own version of the progressively-denser-
per-nesting-level convention (schools-players/style.css's .sp-roster-
table/.player-games-table pair) applied to a row instead of a table. */
.t-team-member-row {
color: var(--color-muted-text);
font-size: 0.9em;
}
/* Collapsed state (results.js's attachTeamExpandHandlers()) -- visibility:
collapse, not display: none, so the row keeps counting toward this
table's own column widths while contributing no height (2026-09-02, per
the user: "columns should not adjust when a team is expanded"). */
.t-row-collapsed {
visibility: collapse;
}
.t-team-member-row td {
padding-top: 3px;
padding-bottom: 3px;
}
/* A board-based member row's own "Board N —" rank cell (results.js's
teamDivisionMemberRowsHtml()/teamDivisionPrizeMemberRowsHtml()) --
zeroes this cell's own right padding (2026-09-08, per the user: "Too
much space on the right side of the em-dash. Both sides should be the
same... check printable but that looks better"). The em-dash's LEFT-side
gap is just the one literal space character before it in the rank
string itself (~8px at this row's own 0.9em font) -- its RIGHT-side gap
used to be this cell's own right padding *plus* the name cell's left
padding (9px + 9px = 18px, this table's sitewide .t-team-table td
padding, far more than a single space character). Dropping this side's
share leaves just the name cell's own 9px on the right, close enough to
the ~8px on the left to read as symmetric. Printable's own version of
this same row never had the problem in the first place -- its cell
padding is only 3px each side (printable_generator.php's own |