/* ── Programs redesign — design tokens + primitives ── New Swiss/institutional visual system for the /programs view (cards default, table toggle) and the shared header, per the 2026-08 redesign brief. Token names are prefixed --prog- because they collide by name with the existing app-wide palette (index.html's own --ink/--accent/etc mean different colors and are consumed by hundreds of rules across the untouched Institutions/Admissions/Map/Calculator views) -- this file coexists with that system rather than replacing it. Same "classic multi-file, one global scope, no build step" convention as layout-tokens.css and search.js/detail-modal.js/etc. Dark mode: follows the EXACT mechanism already established at index.html:107-326, not a new one -- a plain :root{} for light defaults, a plain :root{} inside @media(prefers-color-scheme:dark) for the OS case, and :root[data-theme="dark"]/[data-theme="light"] manual overrides that win on attribute-selector specificity alone (no :not() guard needed -- [data-theme] is specificity (0,0,2,0) vs plain :root's (0,0,1,0), and being inside @media doesn't add specificity). Because this file has no build step, the three blocks must be kept in sync by hand on every edit -- index.html:240-249 already documents one real incident from getting that wrong (a token accidentally self-referencing another dark-mode token and resolving to the same color as its own background, going invisible). */ :root { /* #285 Phase 12: retargeted to mobile's exact lightColors palette (mobile/src/theme.js) -- see docs/design/mobile/MOBILE_BRIEF.md §7. --prog-ink-60/-45 keep the OLD ink's rgb triple's ratio logic (just re-based on the new ink's rgb) rather than being recomputed from scratch -- the .66/.60 alphas were hand-verified against the sRGB relative-luminance formula for WCAG AA (#285 Phase 9) and the new base ink (#14161A vs old #16181c) is close enough in luminance that the same alphas should still clear AA, but this needs a real contrast re-check during verification, not just an assumption. */ --prog-ink: #14161A; --prog-ink-60: rgba(20,22,26,.66); --prog-ink-45: rgba(20,22,26,.60); --prog-rule: rgba(20,22,26,.12); --prog-rule-soft: rgba(20,22,26,.08); --prog-surface: #ffffff; --prog-surface-2: #F5F6F8; --prog-canvas: #EDEEF0; /* Single accent, used once per region: active nav item, primary button, selected checkbox, current bar in a chart. If two things on screen are blue, one of them is wrong. Already identical between web and mobile before this phase -- #2A5DB0 was never a web/mobile divergence to begin with. */ --prog-accent: #2A5DB0; --prog-accent-fill: #2A5DB0; /* Mobile has one tint tier (navySoft), not web's prior two (accent-bg/ accent-tint) -- both point at the brief's own explicit #EEF3FB rather than inventing an in-between shade with no spec basis. */ --prog-accent-bg: #EEF3FB; --prog-accent-tint: #EEF3FB; --prog-good: #1F7A4D; --prog-good-bg: #e1f0e7; --prog-warn: #B4451F; --prog-warn-bg: #f7e4da; --prog-font-ui: 'Golos Text', system-ui, -apple-system, 'Segoe UI', Roboto, sans-serif; --prog-font-mono: 'JetBrains Mono', ui-monospace, monospace; } @media (prefers-color-scheme: dark) { :root { /* #285 Phase 12: mobile's OWN dark palette was flagged by its own author comment as "derived... not sourced from a mockup... not treated as verified" (mobile/src/theme.js). Web's dark values here are already shipped and WCAG-verified (#285 Phase 9) -- and turn out nearly identical anyway, since mobile derived its dark accent/good/warn from the SAME light accent via the same lighten-for-text/punchy-fill-for-buttons logic web already used. Kept as the source of truth for this direction rather than overwritten by mobile's admitted guess; mobile's darkColors gets updated to match THESE afterward instead (see mobile side of this phase). Only good-bg/warn-bg move from a derived rgba to mobile's explicit solid goodSoft/warnSoft, for the same reason light mode's did. */ --prog-ink: #e9eaec; --prog-ink-60: rgba(233,234,236,.62); /* #285 Phase 9: .48 computed to only ~4.18:1 against --chart-surface (#1c2027) -- narrowly failed AA too, not just the light theme. .54 clears ~4.9:1. ink-60 was already ~6:1, untouched. */ --prog-ink-45: rgba(233,234,236,.54); --prog-rule: rgba(233,234,236,.14); --prog-rule-soft: rgba(233,234,236,.09); --prog-surface: var(--chart-surface); --prog-surface-2: var(--chart-bg); --prog-canvas: #0f1114; /* Same dual-role split index.html's own --navy/--navy-fill comment already solved once (index.html:219-231): one hex can't be both readable-as-TEXT on a dark surface and dark-enough to carry white button text. --prog-accent lightens for the text/active-state role; --prog-accent-fill stays a punchier mid-blue for the fill role. Do not collapse these back into one token. */ --prog-accent: #6ea1f2; --prog-accent-fill: #3568bc; --prog-accent-bg: #17273f; --prog-accent-tint: #121b2c; --prog-good: #3fae82; --prog-good-bg: #16281f; --prog-warn: #e2604a; --prog-warn-bg: #3a1a1a; } } :root[data-theme="dark"] { /* Kept in sync with the @media block above by hand -- see this file's top comment for why. */ --prog-ink: #e9eaec; --prog-ink-60: rgba(233,234,236,.62); --prog-ink-45: rgba(233,234,236,.54); --prog-rule: rgba(233,234,236,.14); --prog-rule-soft: rgba(233,234,236,.09); --prog-surface: var(--chart-surface); --prog-surface-2: var(--chart-bg); --prog-canvas: #0f1114; --prog-accent: #6ea1f2; --prog-accent-fill: #3568bc; --prog-accent-bg: #17273f; --prog-accent-tint: #121b2c; --prog-good: #3fae82; --prog-good-bg: #16281f; --prog-warn: #e2604a; --prog-warn-bg: #3a1a1a; } :root[data-theme="light"] { --prog-ink: #14161A; --prog-ink-60: rgba(20,22,26,.66); --prog-ink-45: rgba(20,22,26,.60); --prog-rule: rgba(20,22,26,.12); --prog-rule-soft: rgba(20,22,26,.08); --prog-surface: #ffffff; --prog-surface-2: #F5F6F8; --prog-canvas: #EDEEF0; --prog-accent: #2A5DB0; --prog-accent-fill: #2A5DB0; --prog-accent-bg: #EEF3FB; --prog-accent-tint: #EEF3FB; --prog-good: #1F7A4D; --prog-good-bg: #e1f0e7; --prog-warn: #B4451F; --prog-warn-bg: #f7e4da; } /* ── Type scale ── Rule from the brief: every NUMBER is mono, every WORD is Golos Text. Never bold a heading above 19px -- size carries hierarchy, not weight. */ .prog-label { font: 600 10px var(--prog-font-mono); letter-spacing: .08em; text-transform: uppercase; color: var(--prog-ink-45); } .prog-title { font: 400 21px var(--prog-font-ui); letter-spacing: -.015em; color: var(--prog-ink); margin: 0; /* #285 Phase 9: this class now also lands on real

/

elements (was div-only before), which carry a UA-stylesheet default margin a plain div never had -- zero it explicitly so using a heading tag doesn't change existing layout. */ } .prog-title-lg { font: 400 26px var(--prog-font-ui); letter-spacing: -.015em; color: var(--prog-ink); } .prog-num { font-family: var(--prog-font-mono); font-weight: 500; font-variant-numeric: tabular-nums; color: var(--prog-ink); } .prog-num-lg { font: 600 26px var(--prog-font-mono); letter-spacing: -.02em; font-variant-numeric: tabular-nums; color: var(--prog-ink); } /* ── Primitives ── */ .prog-btn { display: inline-flex; align-items: center; gap: 6px; padding: 9px 16px; font: 500 12.5px var(--prog-font-ui); border: none; cursor: pointer; background: none; color: var(--prog-ink); } .prog-btn--primary { background: var(--prog-accent-fill); color: #fff; } .prog-btn--secondary { border: 1px solid var(--prog-rule); color: var(--prog-ink); } .prog-btn--tertiary { color: var(--prog-ink-60); padding-left: 0; padding-right: 0; } .prog-btn--active { /* #285 Phase 10 follow-up: was `background: var(--prog-ink)`, a real, severe contrast bug caught by the user in dark mode -- --prog-ink is a TEXT-color token that intentionally flips between themes (dark ink in light mode, light ink in dark mode, so it always reads against its own surface). Using it as a filled button's background broke exactly because of that: in dark mode it resolves to near-white (#e9eaec), paired with this rule's own white text -- measured live at a 1.2:1 contrast ratio (WCAG AA needs 4.5:1 for normal text). The visual INTENT was a solid near-black chip, which is genuinely what --prog-ink already looked like in light mode (#16181c) -- so this is hardcoded to that same literal value, theme-invariant, rather than switched to a different color: same look as before in light mode, now correct in dark mode too. */ background: #16181c; color: #fff; } .prog-input { height: 40px; padding: 0 13px; font: 400 13.5px var(--prog-font-ui); /* #285 Phase 10 follow-up: was a literal rgba(22,24,28,.22) per the brief's original spec -- authored when dark mode was still listed as a non-goal (Phase 1-2's own decision #2 overrode that), so this one border was never revisited for it. Theme-invariant near-black at low opacity reads as a barely-there border in light mode and an essentially invisible one in dark mode (dark-on-dark). Swapped to the token every other input-like border in this file already uses. */ border: 1px solid var(--prog-rule); background: var(--prog-surface); color: var(--prog-ink); } .prog-input::placeholder { color: var(--prog-ink-45); } .prog-checkbox { width: 15px; height: 15px; flex: none; display: flex; align-items: center; justify-content: center; font: 600 9px var(--prog-font-mono); /* #285 Phase 10 follow-up: same theme-invariant-border issue as .prog-input above -- a checkbox's own outline is its whole visible affordance when unchecked (its "✓" is intentionally color:transparent until .checked), so an invisible-in-dark-mode border effectively made every unchecked checkbox invisible. */ border: 1px solid var(--prog-rule); color: transparent; background: none; cursor: pointer; padding: 0; margin: 0; box-sizing: border-box; } .prog-checkbox.checked { background: var(--prog-accent-fill); border-color: var(--prog-accent-fill); color: #fff; } .prog-badge { display: inline-block; font: 600 9px var(--prog-font-mono); letter-spacing: .06em; padding: 2px 5px; background: var(--prog-accent-bg); color: var(--prog-accent); } /* Track 56x3px, fill width computed in JS as min(competition/9, 1); fill color: --prog-good <=2.5, --prog-ink 2.6-4.9, --prog-warn >=5 -- see programs-view.js's competitionBarColor(). */ .prog-competition-bar { display: inline-block; width: 56px; height: 3px; background: #e6e6e2; } .prog-competition-bar__fill { display: block; height: 100%; } .prog-table-row { position: relative; display: grid; grid-template-columns: 30px 40px 1fr 120px 96px 84px 120px 110px; align-items: center; padding: 12px 24px; border-bottom: 1px solid var(--prog-rule-soft); } /* #285 Phase 11 follow-up: reported live as "not visible edge" in dark mode -- measured, not assumed: --prog-rule-soft's dark value (rgba(233,234,236,.09)) against --prog-surface's dark value (#1c2027) computes to a ~1.27:1 contrast ratio, far under WCAG 1.4.11's 3:1 minimum for UI-component boundaries -- basically imperceptible. Raising the token itself would ripple into every other consumer (headers, card borders, inputs) that nobody flagged as broken; a background stripe on alternate rows is the standard, robust fix for "which row am I looking at" that doesn't depend on a hairline border's contrast at all. Applies to both Programs' and Institutions' tables (.prog-table-row is the shared base class) since both share the exact same underlying border. */ .prog-table-row:nth-child(even) { background: var(--prog-surface-2); } /* Stacks the compare checkbox above .prog-table-row__hitarea (see that rule's own comment) -- the checkbox is a normal grid cell, not absolutely positioned, so without this it would paint BELOW the absolutely-positioned hitarea and become unclickable. */ .prog-table-row .prog-checkbox { position: relative; z-index: 1; } .prog-table-header__sortbtn { border: none; background: none; padding: 0; font: inherit; color: inherit; text-align: left; cursor: pointer; } .prog-table-header { display: grid; grid-template-columns: 30px 40px 1fr 120px 96px 84px 120px 110px; padding: 0 24px 9px; /* #285 Phase 10 follow-up: same theme-invariant-border issue -- see .prog-input's own comment above. */ border-bottom: 1px solid var(--prog-rule); font: 600 9.5px var(--prog-font-mono); letter-spacing: .07em; color: var(--prog-ink-45); } .prog-table-header__sorted { color: var(--prog-accent); } /* Logo: 1:1 on a white square, 1px --prog-rule border, object-fit: contain, 4px inner padding -- never cropped. 44px on cards (overlapping the photo band), 28px in table rows. Missing logo falls back to the same square carrying the institution's initials -- reuses the existing instInitials() helper and its onerror-swap idiom (index.html:6582, 7907-7910), just restyled square/mono instead of the current rounded/bold treatment. */ .prog-logo { display: flex; align-items: center; justify-content: center; background: #fff; border: 1px solid var(--prog-rule); flex: none; overflow: hidden; } .prog-logo img { width: 100%; height: 100%; object-fit: contain; padding: 4px; box-sizing: border-box; } .prog-logo--card { width: 44px; height: 44px; position: absolute; left: 14px; bottom: -18px; } .prog-logo--table { width: 28px; height: 28px; } .prog-logo-fallback { font: 600 11px var(--prog-font-mono); /* #285 Phase 10 follow-up: was var(--prog-ink-45), a real, severe contrast bug in dark mode -- .prog-logo's own background is a theme-INVARIANT #fff (deliberate: real institution logo images assume a white tile), but ink-45 is a TEXT token that flips to a LIGHT color in dark mode, giving light text on white -- measured live at 1.2:1 (WCAG AA needs 4.5:1). This is the primary visual identity for ~98.6% of institutions (logos populate only ~1.4%, per Phase 1-2's own research), so it's not a minor case. Fixed to the literal value ink-45 already correctly resolved to in LIGHT mode -- same reasoning as the .prog-btn--active fix above: the background doesn't change with theme, so neither should this. */ color: rgba(22,24,28,.60); } .prog-logo--table .prog-logo-fallback { font-size: 8px; } /* Photo band: 16:9, object-fit:cover, no rounding, no overlay gradient. 112px desktop. Missing photo -> --prog-surface-2 fill with initials, never a broken image or stock substitute. */ .prog-photo { position: relative; height: 112px; background: var(--prog-surface-2); display: flex; align-items: center; justify-content: center; overflow: hidden; } .prog-photo img { width: 100%; height: 100%; object-fit: cover; display: block; } .prog-photo-fallback { font: 500 11px var(--prog-font-mono); letter-spacing: .05em; color: var(--prog-ink-45); } /* ── Shared header (rebuilt, used by every view) ── */ .prog-header { display: flex; align-items: center; gap: 22px; padding: 0 24px; height: 56px; /* #285 Phase 10 follow-up: same theme-invariant-border issue -- see .prog-input's own comment above. This one's site-wide (every view shares this header), so worth the same fix even though a missing bottom rule is more cosmetic than the checkbox/input cases. */ border-bottom: 1px solid var(--prog-rule); background: var(--prog-surface); position: relative; /* anchors .prog-header__mobile-menu (Phase 8) */ } .prog-header__wordmark { display: flex; align-items: baseline; gap: 7px; flex: none; } .prog-header__wordmark-main { font: 700 16px var(--prog-font-ui); letter-spacing: -.02em; color: var(--prog-ink); } .prog-header__wordmark-sub { font: 500 10.5px var(--prog-font-mono); letter-spacing: .1em; color: var(--prog-accent); } .prog-header__nav { display: flex; gap: 22px; margin-left: 6px; } .prog-header__nav-item { font: 400 13px var(--prog-font-ui); color: var(--prog-ink-60); padding-bottom: 2px; border-bottom: 2px solid transparent; background: none; border-left: none; border-right: none; border-top: none; cursor: pointer; } .prog-header__nav-item.active { font-weight: 500; color: var(--prog-ink); border-bottom-color: var(--prog-accent); } .prog-header__right { display: flex; align-items: center; gap: 16px; margin-left: auto; } .prog-header__lang { font: 500 11px var(--prog-font-mono); color: var(--prog-ink-45); cursor: pointer; } .prog-header__lang .dim { color: var(--prog-ink-45); opacity: .6; } /* Restyled for the new light header (the old .lang-btn rule was tuned for the OLD dark #14171c header bar -- #b7bfcc text on THIS header's white background would be near-invisible). Only usage site left after the redesign is this header's lang switcher. */ .lang-btn { padding: 3px 2px; border: none; background: transparent; color: var(--prog-ink-45); cursor: pointer; font: 500 11px var(--prog-font-mono); } .lang-btn:hover { color: var(--prog-ink); } .lang-btn.active { color: var(--prog-accent); font-weight: 600; } /* Theme toggle / follows / NMT-quick-access -- icon-only buttons in the header's right cluster. Square, no fill, hover darkens per the "no shadows/gradients, hairline separation" rule. */ .prog-header__icon-btn { position: relative; display: inline-flex; align-items: center; justify-content: center; width: 32px; height: 32px; border: none; background: none; color: var(--prog-ink-45); cursor: pointer; } .prog-header__icon-btn:hover { color: var(--prog-ink); } .prog-header__icon-btn .ic { width: 16px; height: 16px; } .prog-header__icon-btn .my-follows-count { position: absolute; top: 2px; right: 2px; background: var(--prog-accent-fill); color: #fff; font: 600 9px var(--prog-font-mono); min-width: 14px; height: 14px; border-radius: 7px; display: flex; align-items: center; justify-content: center; padding: 0 3px; } /* ── Programs view layout ── */ #programs-view { max-width: var(--content-max); margin: 0 auto; background: var(--prog-surface); color: var(--prog-ink); } .prog-searchbar { display: flex; align-items: center; gap: 14px; padding: 16px 24px; border-bottom: 1px solid var(--prog-rule); background: var(--prog-surface-2); } .prog-layout { display: grid; grid-template-columns: 264px 1fr; } /* #285 Phase 11: Institutions' own sidebar layout -- same two-column grid as .prog-layout above (264px rail + flexible results panel), kept as its own class rather than reusing .prog-layout directly since the two wrap genuinely different results-panel contents (#tabsContainer + the Institutions #resultsContainer, vs Programs' own results header + sort bar + #programsResults). */ .inst-layout { display: grid; grid-template-columns: 264px 1fr; /* #285 Phase 11 follow-up: reported live -- the rail/results grid started flush at the viewport edge while the search bar above it (.controls/.search-card, index.html's own OLD centered-max-width container) stayed inset and centered, so the two rows had different left edges and never lined up. Programs' own .prog-layout avoids this because it and .prog-searchbar are both children of the SAME already-centered #programs-view wrapper (programs.css:495-499); Institutions has no equivalent shared wrapper -- .controls and .inst-layout are siblings -- so this needs the identical max-width centering applied here directly instead, matching .controls' var(--content-max) + margin:0 auto exactly (index.html:536-540). */ max-width: var(--content-max); margin: 0 auto; /* .controls (the search bar's own wrapper) applies `padding: 16px 16px 0` -- .search-card's actual left/right edges sit 16px INSIDE .controls' own max-width box, not flush with it. Matching only max-width+margin above got .inst-layout's OUTER edge to line up with .controls' outer edge, but left it 16px wider than .search-card on each side. This closes that gap so the rail/results grid's edges land exactly where the search bar's own content does. */ padding: 0 16px; } /* #tabsContainer/#resultsContainer keep their own pre-existing padding (index.html:880-884/1272-1276), but their max-width+margin:auto self-centering (designed for when they were standalone full-width blocks, each independently centering itself in the viewport) actively fights their new role as .inst-layout GRID CHILDREN -- a block trying to center itself at up to 1320px wide inside a ~1000px grid track overflows the track rather than filling it, which is what actually produced the "not aligned" report: the results column's right edge landed well past the search bar's own right edge. Dropping max-width/ margin here lets each simply fill its grid column instead. */ .inst-layout #tabsContainer, .inst-layout #resultsContainer { max-width: none; margin: 0; } /* The actual remaining cause of the misalignment (confirmed by measuring computed grid-template-columns directly -- neither of the two rules above moved it): the classic CSS Grid "1fr overflow" gotcha. Grid items default to min-width:auto, which means a track can never shrink below its content's min-content size -- #resultsContainer's card grid has plenty of cards whose combined min-content width exceeds the 1fr column's fair share, so the column (and everything in it) expanded to fit the content instead of respecting 1fr, pushing the results panel's right edge out past the search bar's own. min-width:0 on the grid ITEM is the standard fix -- lets it shrink to its assigned track width and wrap/scroll its own content instead of blowing out the track. */ .inst-layout > .prog-results-panel { min-width: 0; } /* #285 Phase 11b: Cards/Table view toggle, table half. Reuses .prog-table-header/.prog-table-row directly (border/padding/font/ checkbox-stacking/hitarea-z-index all come from those base rules) -- only the column widths differ from Programs' own 8-column layout, since an institution row has a different field set (no NMT-min/ chance columns; adds a funding-type column instead). overflow-x:auto on the wrapper is a safety net at the narrow end of the desktop-only range this view is shown in (1000px-1200px-ish) rather than a real mobile treatment -- table view is already hidden below 1000px (see renderResults()'s own isMobile check + .prog-view-toggle's mobile CSS), so this only ever has to cover genuine desktop widths. */ /* #285 Phase 11 follow-up: reported live ("filters not used any more?") and confirmed with the user -- #filtersToggleBtn (the "Фільтри ▾" button next to the search box) only ever toggled the OLD collapsible filter panel, since replaced by the always-visible #institutionsFilterRail sidebar; toggleInstitutionsFilterSheet() only has a real effect at the rail's own mobile-sheet breakpoint (max- width:1000px), so on desktop the button was a dead click that looked interactive. Hidden here at the same breakpoint the sheet mechanism itself uses -- unchanged on mobile (still the real, functional sheet toggle, badge included). #filterCountBadge lives inside this button, so it's invisible on desktop too now; that's fine -- each facet's own rail row already shows its own "N selected" there, and the aggregate count still shows on mobile plus in #scrollTopFilterBadge once scrolled. (Tests that asserted this badge's visibility were updated to check its text content instead, which #updateFilterCountBadge() sets regardless of the button's own display state.) */ @media (min-width: 1001px) { #filtersToggleBtn { display: none; } } .inst-table { overflow-x: auto; } .inst-table-header, .inst-table-row { grid-template-columns: 30px 40px 1fr 130px 90px 130px 120px; } .prog-rail { border-right: 1px solid var(--prog-rule); padding: 20px; background: var(--prog-surface-2); display: flex; flex-direction: column; gap: 20px; } /* #285 audit P2: as a plain grid item the rail was stretched to the full row height -- measured at 10,055px with its content ending around 1,297px, so the left third of the window was blank for ~8,700px and changing a filter meant scrolling back to the top of an 11-viewport page (Region alone sits ~1,143px down). align-self:start stops the stretch; sticky keeps the filters on screen while the results scroll. max-height + overflow-y so a rail taller than the viewport scrolls within itself rather than clipping. Deliberately behind min-width, NOT on the base .prog-rail rule. Below 641px this element is not a sidebar at all -- it is the off-canvas bottom sheet, anchored with left/right/bottom and hidden by translateY(100%). Those #id rules override `position`, so `sticky` was harmless, but nothing there resets `top`: an over-constrained fixed box resolves in favour of `top`, so a stray `top: 0` re-anchored the sheet to the TOP of the viewport and translateY(100%) then parked it across the bottom 146px -- directly over the bottom tab bar, swallowing every tap on it. That took out 27 mobile e2e tests before this was scoped. */ @media (min-width: 641px) { .prog-rail { position: sticky; top: 0; align-self: start; max-height: 100vh; overflow-y: auto; } } .prog-rail__divider { height: 1px; background: var(--prog-rule); } /* #285 Phase 9: .prog-rail__row is now a real