/* Loaded after css/vendor/pico.classless.min.css in every template's <head>, so these
   rules override Pico's own defaults. Pico styles bare HTML elements directly (this
   app's templates are almost entirely class-free already); this file layers Metric
   Halo's actual brand — colors/fonts pulled from https://mhsecure.com/products/software/
   Howies179/ and its linked stylesheets — on top, plus this app's own small set of
   structural helper classes (.edu-container, .edu-card, .table-scroll, .edu-honeypot). */

/* Raleway, variable weight 400–700 in one file (Google Fonts served the same physical
   file for both static weights requested — a variable-font woff2, the modern normal
   case). Latin subset only, matching this app's English-only UI; names with non-Latin
   characters fall through to the Avenir/Helvetica fallbacks in --edu-font below, which
   is an acceptable, deliberate scope limit rather than an oversight. */
@font-face {
	font-family: 'Raleway';
	font-style: normal;
	font-weight: 400 700;
	font-display: swap;
	src: url('vendor/fonts/raleway-latin.woff2') format('woff2');
}

:root {
	/* Metric Halo brand tokens — see the file-level comment above for where these came
	   from. Avenir is a commercial system font (present on Mac, where this company's
	   own product pages assume it), listed first purely as a fallback when available;
	   Raleway (vendored above) is the actual web font this app can guarantee loads. */
	--edu-font: 'Avenir', 'Raleway', 'Helvetica Neue', 'Arial', 'Helvetica', sans-serif;
	--edu-navy: #081927;
	--edu-accent: #4096ee;
	--edu-accent-on-dark: #bbf;

	/* Pico's own theme variables — set once here so its buttons/links/focus rings pick
	   up the brand automatically, rather than needing per-element overrides throughout. */
	--pico-font-family: var(--edu-font);
	--pico-primary: var(--edu-accent);
	--pico-primary-hover: #2a7bd6;
	--pico-primary-underline: var(--edu-accent);
}

.edu-honeypot {
	/* display:none, not off-screen positioning -- confirmed live 2026-09-02 that
	   position:absolute off-screen doesn't reliably stop browser/password-manager
	   autofill from filling this field anyway (unlike display:none, which autofill
	   engines universally skip), silently tripping the server's honeypot
	   fake-success path for a real user. Some very unsophisticated scraping bots
	   that blindly fill every visible field would be defeated by display:none too
	   (an actual honeypot-effectiveness tradeoff, not free), but blocking real
	   users from ever submitting the form is strictly worse than a marginally
	   weaker honeypot. */
	display: none;
}

/* Mobile-responsive baseline. Every full-page template's <head> also carries
   <meta name="viewport" content="width=device-width, initial-scale=1"> — without it
   none of this matters, since mobile browsers default to rendering at desktop width
   and scaling down. */
* {
	box-sizing: border-box;
}

body {
	margin: 0;
	font-family: var(--edu-font);
}

.edu-container {
	max-width: 720px;
	margin: 0 auto;
	padding: 1em;
}

/* Modifier for pages whose content is wide by nature (a many-column table, e.g.
   admin/index.php's request listing) rather than a form/card meant to stay narrow and
   centered -- overrides .edu-container's max-width only; the 1em padding above still
   provides the "bit of margin" on each side. */
.edu-container-wide {
	max-width: 100%;
}

/* The public wizard's dark-navy "card" treatment — matches the product pages' own
   .dark/.trybox sections (same background color, corner radius, and shadow). Applied
   only to public-facing templates, never admin ones — see css/edu.css's own header
   comment and the plan's "split by audience" decision: admin stays close to this
   codebase's existing plain internal-tool look (mhdirect/mhexport/admin), rather than
   introducing a new visual language nothing else internal shares. */
.edu-card {
	/* Overriding Pico's own color variables (not just the plain `color` property) is
	   what actually matters here: Pico's classless build sets `color: var(--pico-color)`
	   explicitly on elements like <legend> and <label> (and headings resolve their own
	   color from --pico-h1-color..--pico-h6-color), so plain inheritance from a `color`
	   property on this wrapper never reaches them — confirmed by inspecting a rendered
	   page, where the legend text was unreadable dark-on-dark until these were added. */
	--pico-color: #eee;
	--pico-h1-color: #fff;
	--pico-h2-color: #fff;
	--pico-h3-color: #fff;
	--pico-h4-color: #fff;
	--pico-h5-color: #fff;
	--pico-h6-color: #fff;
	--pico-muted-color: #aab4c4;
	--pico-form-element-color: #081927;

	background: var(--edu-navy);
	color: #eee;
	border-radius: 12px;
	padding: 1.5em;
	box-shadow: 0 10px 12px rgba(0, 0, 0, 0.25);
}

.edu-card a {
	color: var(--edu-accent-on-dark);
}

.edu-logo {
	display: block;
	height: 48px;
	width: auto;
	margin-bottom: 1em;
}

/* Logo + "Metric Halo" side by side on one line, e.g. the wizard's own header --
   the logo image itself is just a mark, not a full wordmark, so the text is spelled
   out next to it rather than stacked below. */
.edu-header-lockup {
	display: flex;
	align-items: center;
	gap: 0.5em;
	margin-bottom: 1em;
}

.edu-header-lockup .edu-logo {
	margin-bottom: 0;
}

.edu-header-lockup-text {
	/* Same size/weight/color as the h1 it was originally part of -- splitting it out
	   of the heading shouldn't change how it reads. font-size/font-weight are
	   Pico's own h1 values (2rem/700, confirmed from pico.classless.min.css); those
	   are set as custom properties scoped to the h1 element itself, so a sibling
	   span can't inherit them and they're hardcoded here instead. color does
	   genuinely inherit real values via --pico-h1-color, set on .edu-card. */
	font-weight: 700;
	font-size: 2rem;
	color: var(--pico-h1-color, #fff);
}

/* Centers a button or row of buttons within the card, without affecting the
   surrounding labels/inputs (which stay left-aligned) -- buttons keep their default
   inline-block sizing, so a pair wrapped together still sits side by side. */
.edu-button-row {
	text-align: center;
	margin-top: 1em;
}

input[type="text"],
input[type="email"],
input[type="password"],
input[type="url"],
input[type="file"],
select,
textarea {
	width: 100%;
	max-width: 100%;
	padding: 0.5em;
	margin: 0.25em 0;
	font-size: 1em;
}

button,
input[type="submit"] {
	min-height: 44px;
	padding: 0.5em 1em;
	font-size: 1em;
}

/* Admin action buttons: disable-type actions are yellow, remove/delete/revoke-type
   actions are red — a consistent visual warning for anything destructive or
   state-changing-away-from-normal, across manage-admins/manage-notifications/
   manage-boilerplate. Same specificity as Pico's own button color rules (element +
   class each), so load order (this file after Pico's) decides the tie in our favor —
   no !important needed. */
button.btn-warning,
input[type="submit"].btn-warning {
	background-color: #e6b800;
	border-color: #e6b800;
	color: #222;
}

button.btn-warning:hover,
button.btn-warning:focus,
input[type="submit"].btn-warning:hover {
	background-color: #cca300;
	border-color: #cca300;
}

button.btn-danger,
input[type="submit"].btn-danger {
	background-color: #c0392b;
	border-color: #c0392b;
	color: #fff;
}

button.btn-danger:hover,
button.btn-danger:focus,
input[type="submit"].btn-danger:hover {
	background-color: #a5301f;
	border-color: #a5301f;
}

/* Wraps every admin listing <table> — the simplest robust fix for wide tabular data on
   narrow screens, rather than a full responsive-table reflow. */
.table-scroll {
	overflow-x: auto;
}

.table-scroll table {
	width: 100%;
}

/* admin-index.html's header row -- hamburger menu to the left of the "EDU requests"
   heading, same line. */
.admin-header {
	display: flex;
	align-items: center;
	gap: 0.5em;
	position: relative;
}

.admin-nav {
	position: relative;
}

.admin-nav-toggle {
	font-size: 1.5rem;
	line-height: 1;
	padding: 0.25em 0.6em;
	min-height: auto;
}

.admin-nav-menu {
	/* Pico's own nav{display:flex} (row direction by default) would otherwise override
	   this menu's intended vertical stacking regardless of the <a> tags' own display --
	   flex-direction:column keeps display:flex (harmless either way) but forces the
	   items into a real one-per-line column. Confirmed live 2026-09-02 that omitting
	   this laid the items out horizontally instead. */
	display: flex;
	flex-direction: column;
	position: absolute;
	left: 0;
	top: 100%;
	margin-top: 0.25em;
	background: #fff;
	border: 1px solid var(--pico-muted-border-color, #ccc);
	border-radius: 8px;
	box-shadow: 0 4px 12px rgba(0, 0, 0, 0.15);
	padding: 0.5em 0;
	min-width: 240px;
	z-index: 10;
}

.admin-nav-menu a {
	display: block;
	padding: 0.5em 1em;
	white-space: nowrap;
	color: inherit;
	text-decoration: none;
}

.admin-nav-menu a:hover {
	background: var(--pico-secondary-background, #f0f0f0);
	color: #fff;
}

/* admin-create-request.html's mode selector -- same radio-then-reveal behavior as the
   review page's Accept/Deny toggle (only one form visible at a time), but as two large
   buttons instead of actual radio inputs. No color by default; the clicked one takes on
   the accent color to show which mode is active. */
.mode-choice {
	display: flex;
	gap: 1em;
	margin: 1em 0;
}

.mode-btn {
	flex: 1;
	padding: 1em;
	font-size: 1.1em;
	/* Hardcoded, not var(--pico-color) -- that variable flips to a light color under
	   prefers-color-scheme:dark (Pico assumes its own background flips dark too), but
	   this button's background is deliberately staying a fixed white regardless of
	   scheme, so the text needs to stay fixed dark to match, not follow the theme. */
	background: #fff;
	color: #222;
	border: 2px solid var(--pico-muted-border-color, #ccc);
	border-radius: 8px;
	min-height: auto;
	cursor: pointer;
}

.mode-btn:hover {
	border-color: var(--edu-accent, #4096ee);
}

.mode-btn-selected,
.mode-btn-selected:hover {
	background: var(--edu-accent, #4096ee);
	color: #fff;
	border-color: var(--edu-accent, #4096ee);
}

/* admin-create-request.html's paired fields (First/Last name, Phone/Email,
   Institution type/Account type) -- side by side on one line, wrapping to their own
   lines once the row gets too narrow to fit both comfortably (each label's flex-basis
   is the wrap threshold, not a fixed breakpoint). */
.field-row {
	display: flex;
	flex-wrap: wrap;
	gap: 0 1em;
}

.field-row label {
	flex: 1 1 220px;
}

/* admin-create-request.html's lookup status message (js/admin-lookup-customer.js) --
   reserves space for its longest real message (the not-found warning, which can wrap to
   2 lines) so the fields below it don't shift position as the text changes from empty
   to "Looking up..." to the final result. */
#existing-lookup-status {
	min-height: 2.4em;
	text-align: center;
}

/* admin-index.html/admin-manage-admins.html/admin-manage-notifications.html's listing
   tables -- replaces the legacy <table border="1" cellpadding="6"> HTML attributes with
   real CSS. border-collapse is what actually matters here: without it, a cell whose
   content (a submit button, which Pico gives a bottom margin) is taller than the row's
   nominal height can end up with its own border-bottom rendered above that overflow
   instead of below it, in some browsers -- looking like the table's bottom border is
   "clipped" right through the last row. Confirmed live 2026-09-02 on manage-notifications.
   Collapsed borders don't have this ambiguity: there's exactly one border between any two
   cells, computed from the actual final row height. */
.admin-table {
	width: 100%;
	border-collapse: collapse;
	/* Path/Status labels got more descriptive (e.g. "Awaiting email verification"),
	   which started wrapping cells to two lines at a normal window width -- 80% of the
	   inherited size buys back enough room without a full column-width redesign.
	   Buttons inside these cells use rem, not em, specifically so this doesn't also
	   shrink them (see .notification-actions button below). */
	font-size: 0.8em;
}

.admin-table th,
.admin-table td {
	border: 1px solid var(--pico-muted-border-color, #ccc);
	padding: 6px;
	text-align: left;
}

/* Pico gives every [type=submit] a margin-bottom (spacing between stacked buttons in
   normal flow) -- inside a table cell that's just unwanted empty space under the last
   button, pushing the cell (and the row) taller than the visible content needs. */
.admin-table td button[type="submit"] {
	margin-bottom: 0;
}

.admin-table td form + form {
	margin-top: 0.5em;
}

/* manage-notifications.php's action cell -- flex row keeps the two buttons reliably side
   by side (rather than depending on inline-block wrapping behavior), and a smaller
   padding/font-size than the account-wide button default (which is sized for the
   public wizard's touch targets, overkill for a compact internal admin action) lets both
   comfortably fit on one line instead of wrapping. */
.admin-table td.notification-actions {
	display: flex;
	align-items: center;
	justify-content: center;
	gap: 0.5em;
	white-space: nowrap;
}

.admin-table td.notification-actions form + form {
	margin-top: 0;
}

.notification-actions button[type="submit"] {
	min-height: auto;
	padding: 0.3em 0.75em;
	/* rem, not em -- .admin-table's own 0.8em font-size shouldn't also shrink these
	   buttons; rem is relative to the document root, unaffected by that cascade. */
	font-size: 0.85rem;
}

/* Pico's own fieldset default is border:0 -- with several of these stacked on the page
   (one per boilerplate row) there was no visual separation between them at all. */
.boilerplate-tile {
	border: 1px solid var(--pico-muted-border-color, #ccc);
	border-radius: 8px;
	padding: 1em;
	margin-bottom: 1em;
}

/* admin-manage-boilerplate-row.html's Active/Delete/Save row -- these three controls
   belong to two different <form> elements (Active+Save submit the edit form via the
   HTML5 form="..." attribute, Delete is its own form; forms can't nest, so they can't
   all be one literal form), but read as one action row regardless of that split. */
.boilerplate-actions {
	display: flex;
	align-items: center;
	gap: 1em;
	margin-top: 0.5em;
}

.boilerplate-actions label {
	white-space: nowrap;
}

/* admin/review.php's request-details table -- label column right-aligned, value column
   left-aligned, no visible borders (this is a label:value layout, not tabular data).
   width: auto overrides Pico's own table{width:100%} (a zero-specificity :where()
   selector, so a plain class easily wins) -- without it, the label column gets stretched
   with unused space instead of hugging its widest label. */
.review-info {
	border-collapse: collapse;
	width: auto;
}

.review-info th {
	text-align: right;
	white-space: nowrap;
	width: 1px;
	padding: 0.2em 0.75em 0.2em 0;
	font-weight: 600;
	border: none;
}

.review-info td {
	text-align: left;
	padding: 0.2em 0;
	border: none;
}

.review-documents {
	list-style: none;
	padding-left: 1.5em;
}

.review-documents li {
	margin-bottom: 1em;
}

.review-document-link {
	display: flex;
	align-items: center;
	gap: 0.75em;
}

.doc-thumbnail {
	max-height: 80px;
	max-width: 80px;
	object-fit: cover;
	border-radius: 4px;
	border: 1px solid var(--pico-muted-border-color, #ccc);
}

.doc-pdf-preview {
	display: block;
	width: 100%;
	max-width: 500px;
	height: 200px;
	margin-top: 0.5em;
	border: 1px solid var(--pico-muted-border-color, #ccc);
	border-radius: 4px;
}

/* admin/review.php's Decision section: only one of #accept-form/#deny-form is ever
   visible at a time (see js/admin-decision-toggle.js). Only the Accept/Deny radio
   options themselves are indented -- the legend and the forms/fields stay flush left. */
#decision-choice {
	margin-bottom: 1em;
}

#decision-choice label {
	margin-left: 1.5em;
}