/* ---------------------------------------------------------------------------------------
 * Hand-written CSS for this build.
 *
 * This is the ONLY colour file that is safe to edit by hand. `css/colors.css` and
 * `css/skins/default.css` are both generated by the Sagentic Dashboard Color System and any
 * change made there is silently discarded on the next regeneration.
 *
 * Load order (later wins):
 *   colors.css -> theme.css -> theme-admin-extension.css -> sidebar.css -> custom.css
 *   -> skins/default.css
 *
 * So this file overrides theme.css, but NOT skins/default.css. If a rule here is being
 * ignored, check whether the generated skin sets the same property with !important.
 * ------------------------------------------------------------------------------------- */


/* Semantic colour aliases
 * ---------------------------------------------------------------------------------------
 * `colors.css` is generated by the Sagentic Dashboard Color System and names its variables
 * after the COLOURS (`--calypso-light`), not their roles. That means a rule written against
 * `--calypso-light` breaks the moment this tree is copied to an association with a different
 * palette, because the variable simply won't exist there.
 *
 * This block is the ONLY place in the site that names a palette colour. Everything below —
 * and every rule you add — uses the role name instead. Copying this build to a new
 * association means re-pointing these seven lines, not hunting through the stylesheet.
 *
 * Porto's own `primary` / `secondary` / `tertiary` / `quaternary` classes (from the
 * generated skin) still cover the four base colours; these fill the gaps the skin has no
 * slot for — the light and dark variants, and the fifth palette colour. */
:root {
	--color-primary:         var(--rhino);              /* #284557 */
	--color-primary-light:   var(--rhino-light);        /* #406e8b */
	--color-secondary:       var(--calypso);            /* #376589 */
	--color-secondary-light: var(--calypso-light);      /* #528cb9 */
	--color-accent:          var(--yellow-green);       /* #c0ea86 */
	--color-accent-strong:   var(--chelsea-cucumber);   /* #81a949 */
	--color-accent-deep:     var(--verdun-green);       /* #2a4200 */
}

/* A light-blue text utility, since the generated skin only produces the four base slots. */
html .text-secondary-light {
	color: var(--color-secondary-light) !important;
}


/* Outline buttons
 * ---------------------------------------------------------------------------------------
 * The generated skin defines the SOLID variants (`html .btn-primary` … `.btn-quaternary`)
 * but **no outline variants at all**. So `.btn-outline-primary` fell straight through to
 * Bootstrap's default #0d6efd — a generic blue that appears nowhere in this palette. Every
 * secondary button on the site was rendering in the wrong colour and nothing flagged it,
 * because the class exists and "works", just with the framework's colour.
 *
 * Bootstrap 5 buttons are driven by CSS custom properties, so the fix is to re-point those
 * rather than restate the whole rule. `html .btn-outline-primary` is (0,1,1) against
 * Bootstrap's (0,1,0), so it wins on specificity without needing !important.
 *
 * If a solid variant is ever needed in outline form — secondary, tertiary, quaternary —
 * copy this block and swap the alias. */
html .btn-outline-primary {
	--bs-btn-color:                 var(--color-primary);
	--bs-btn-border-color:          var(--color-primary);
	--bs-btn-hover-color:           #fff;
	--bs-btn-hover-bg:              var(--color-primary);
	--bs-btn-hover-border-color:    var(--color-primary);
	--bs-btn-active-color:          #fff;
	--bs-btn-active-bg:             var(--color-primary);
	--bs-btn-active-border-color:   var(--color-primary);
	--bs-btn-disabled-color:        var(--color-primary);
	--bs-btn-disabled-border-color: var(--color-primary);
	--bs-btn-focus-shadow-rgb:      40, 69, 87; /* #284557 */
}


/* Outline buttons — secondary
 * ---------------------------------------------------------------------------------------
 * The counterpart to the primary block above, needed by anything using the secondary-led
 * colour scheme (the home page's announcement column, §3o). Bootstrap's own
 * `.btn-outline-secondary` is grey and appears nowhere in this palette.
 *
 * #376589 on white is 5.74:1, so the label passes AA on its own. */
html .btn-outline-secondary {
	--bs-btn-color:                 var(--color-secondary);
	--bs-btn-border-color:          var(--color-secondary);
	--bs-btn-hover-color:           #fff;
	--bs-btn-hover-bg:              var(--color-secondary);
	--bs-btn-hover-border-color:    var(--color-secondary);
	--bs-btn-active-color:          #fff;
	--bs-btn-active-bg:             var(--color-secondary);
	--bs-btn-active-border-color:   var(--color-secondary);
	--bs-btn-disabled-color:        var(--color-secondary);
	--bs-btn-disabled-border-color: var(--color-secondary);
	--bs-btn-focus-shadow-rgb:      55, 101, 137; /* #376589 */
}


/* card-featured on a modal
 * ---------------------------------------------------------------------------------------
 * A modal can wear the card treatment, but NEVER add `.card` to `.modal-content` —
 * `theme.css:8997` sets `.card { background: transparent }`, which is harmless on a page-level
 * card and makes a modal see-through over its backdrop. The `card-featured*` classes carry the
 * whole look on their own.
 *
 * Two things then need correcting, and they are the same for every modal, so they live here
 * rather than being re-scoped per modal id (this started life as an `#eventModal` block in
 * calendar.css and was generalised when the home announcement modals needed it too):
 *
 *   1. `card-featured-*` sets `border-color` on ALL edges and Bootstrap gives `.modal-content`
 *      a 1px border all round, so the whole modal outlines in the accent colour and reads
 *      heavy. Only the top edge should carry it.
 *   2. The header and footer need the card-header grey, or it reads as a plain dialog rather
 *      than as one of the site's cards. */
.modal-content.card-featured {
	border-color: rgba(0, 0, 0, 0.175);   /* Bootstrap's default; the top edge is re-set below */
}

.modal-content.card-featured-primary   { border-top-color: var(--color-primary); }
.modal-content.card-featured-secondary { border-top-color: var(--color-secondary); }

.modal-content.card-featured .modal-header,
.modal-content.card-featured .modal-footer {
	background-color: #f6f6f6;
}

.modal-content.card-featured .modal-header {
	border-bottom: 1px solid #dadada;
}


/* Page titles
 * ---------------------------------------------------------------------------------------
 * `theme.css` sets `.page-header h2 { color: #fff }`, and individual templates then fought
 * it with their own `text-white` / `text-primary` / `text-secondary` classes — so page
 * titles came out white on some pages and dark blue on others.
 *
 * This forces one colour for every page title regardless of what a template asks for.
 * `html .page-header h2` is specificity (0,1,2), which beats the `html .text-primary`
 * (0,1,1) rules in the generated skin even though that file loads later — so templates do
 * not need editing. #528cb9 on the #171717 header bar is 4.96:1, passing AA for normal text.
 *
 * If a page ever genuinely needs a different title colour, give it an id or a dedicated
 * class rather than weakening this rule. */
html .page-header h2 {
	color: var(--color-secondary-light) !important;
}


/* Font aliases
 * ---------------------------------------------------------------------------------------
 * `alt-font0` .. `alt-font5` are NOT part of Porto — every Sagentic site defines its own
 * set here, mapped to whatever families that site loads in `includes/fonts.php`. They are
 * plain aliases, so the same class name means a different typeface on every site. Until
 * this block existed, every `alt-font*` in this build's markup was a no-op and everything
 * rendered in the default face.
 *
 * The convention for this build:
 *   alt-font1  titles and headings
 *   alt-font2  subtitles, eyebrows, kickers
 *   alt-font3  data and monospace
 *   alt-font4  UI labels, badges, buttons
 *   alt-font0 / alt-font5  fallback — both point at Poppins
 *
 * Change a family here and it changes everywhere at once — but add the matching weights to
 * `includes/fonts.php` at the same time, or bold text gets synthesised and looks smeared.
 *
 * `alt-font0` exists because carried-over templates use it (e.g.
 * includes/public/calendar/calendar-mini-agenda.php). It is aliased rather than left
 * undefined so those files fall back to a real face instead of the browser default. */
.alt-font1 { font-family: "Exo", sans-serif; }               /* titles */
.alt-font2 { font-family: "Google Sans Flex", sans-serif; }  /* subtitles, eyebrows */
.alt-font3 { font-family: "Chivo Mono", monospace; }         /* data */
.alt-font4 { font-family: "Saira", sans-serif; }             /* UI labels, badges, buttons */
.alt-font0,
.alt-font5 { font-family: "Poppins", sans-serif; }           /* fallback */


/* Linked card titles
 * ---------------------------------------------------------------------------------------
 * `card-featured-primary` colours `.card-title`, but only the element carrying that class —
 * an <a> inside it is still a link, so it falls through to Bootstrap's own link colour and a
 * clickable card title comes out a different blue from every non-clickable one.
 *
 * Handling it here rather than per instance keeps the rule in §3i intact: the `.card-title`
 * still takes no extra classes, and a linked title needs no special markup. Hover goes to the
 * secondary blue, matching the `text-hover-secondary` behaviour used on list titles elsewhere.
 *
 * `color: inherit` deliberately, not a named colour — so this follows whichever
 * `card-featured-*` variant the card uses instead of hard-coding primary. */
.card-title a {
	color: inherit;
	text-decoration: none;
}

.card-title a:hover,
.card-title a:focus {
	color: var(--color-secondary);
	text-decoration: none;
}


/* Vertical rhythm
 * ---------------------------------------------------------------------------------------
 * Two things drive the gaps between blocks on a page, and neither is obvious from the markup:
 *
 * 1. theme.css:72 — `.content-body:not(.card-margin) > .row + .row { padding-top: 40px }`.
 *    Every top-level `.row` after the first gets 40px above it, automatically. That is the
 *    site's rhythm for unrelated blocks and should generally be left alone. But note it only
 *    fires between ADJACENT rows: put a `<section>` between two rows and the match breaks and
 *    the gap collapses to whatever margin that section carries. Search bars exploit this
 *    deliberately — see the WRAPPER note in includes/search/audit-search.php.
 *
 *    The trap is adding `mt-3` "to space things out" on a row that is already receiving the
 *    40px. That reads as 56px and is why the audit log looked so airy.
 *
 * 2. `.card-tight`, below.
 *
 * `card-tight` is used in six templates here and, until now, was defined in NO stylesheet on
 * this build — a silent no-op, same as the `alt-font*` classes were. It is carried over from
 * briaroaksfire and goldbeltbyway, where it collapses the gap between stacked cards.
 *
 * On THIS build it is currently inert either way: theme.css:8997 strips `.card` back to
 * background/box-shadow/border and gives it no margin at all, so there is nothing to collapse.
 * It is defined anyway, matching the sibling sites exactly, because this is the master build —
 * the same markup copied to an association whose skin does give cards a margin has to behave
 * the same there as it does here. Both forms are covered: on the card itself (how this build
 * writes it) and on a wrapper (how brioakfd/golbelby write it). */
.card-tight,
.card-tight .card {
	margin-bottom: 0 !important;
}


/* Body copy on dark alert banners  (soccer trivia, and any future dark alert)
 * ---------------------------------------------------------------------------------------
 * `theme.css` line 17335 sets a global `p { color: #777 }`. WYSIWYG content arrives wrapped
 * in <p>, so it takes that mid-grey and the `.text-white` on the wrapping div never applies
 * — the text renders dim-grey on dark blue and fails contrast badly.
 *
 * Setting the colour on the element that actually carries the text fixes it. Light green
 * (#e1f5c7) on the primary blue (#284557) is about 8.4:1, comfortably past AAA.
 *
 * Headings inside keep their own colour: the generated skin declares `.text-tertiary` with
 * !important, so it still wins here. */
.alert-primary p,
.alert-primary li,
.alert-primary td,
.alert-primary th {
	color: var(--yellow-green-light);
}

/* The last paragraph of a WYSIWYG block shouldn't push the banner open with theme.css's
 * default `margin: 0 0 20px` on <p>. */
.alert-primary p:last-child {
	margin-bottom: 0;
}