/*
 * Agenda page - theme-owned rules.
 *
 * Every other visual on this page is ported from the live site's generated
 * Elementor stylesheet, vendored byte-for-byte in
 * assets/css/vendor/elementor-post-16528.css. Nothing in this file restates or
 * overrides any of those rules; the vendored sheet stays untouched so the port
 * keeps its fidelity guarantee.
 *
 * The one thing it cannot cover is the hero image placeholder. The vendored
 * sheet draws the frame with an `img` selector:
 *
 *   .elementor-16528 .elementor-element.elementor-element-1fceba03 img{
 *     width:700px; height:500px; object-fit:cover; object-position:center center;
 *     border-radius:25px 25px 25px 25px;
 *     box-shadow:5px 5px 10px 0px rgba(51,51,51,0.27058823529411763);
 *   }
 *
 * When an Agenda has no Featured Image the template emits a <div> in place of
 * the <img>, and that selector cannot reach it. So the placeholder is given the
 * identical frame here - same box, same radius, same shadow - which means
 * setting or clearing the Featured Image changes the picture but never the
 * layout.
 *
 * The gradient runs between the two colours the live site already defines in
 * its kit tokens (elementor-kit-post-6.css): --e-global-color-secondary
 * #002454 and --e-global-color-primary #6699D9. No new brand values.
 *
 * It has a second, quite different job: containing the Hello reset off this
 * theme's own header. See "Chrome containment" at the bottom.
 */

/* ---- Hero placeholder: desktop ---------------------------------------- */
.elementor-16528 .elementor-element.elementor-element-1fceba03 .wsa-hero-placeholder {
	width:700px;
	height:500px;
	border-radius:25px 25px 25px 25px;
	box-shadow:5px 5px 10px 0px rgba(51,51,51,0.27058823529411763);
	background-image:linear-gradient(135deg,#002454 0%,#6699D9 100%);
}

/* ---- Framework mobile gate: 767 -> 1024 -------------------------------- */
/* This is the rule that actually decides when the design stacks, and it is not
   in the page CSS - it is in the vendored Elementor framework:

     @media (max-width:767px){
       .e-con.e-flex{--width:100%;--flex-wrap:var(--flex-wrap-mobile)}
     }

   Moving only the page's own mobile block left the tablet band still flexing
   like a desktop: the hero's two columns both declare `--width:100%` but
   rendered 512/512 at a 1024 viewport, because with `--flex-wrap` unset the
   default `nowrap` lets `flex-shrink` halve them instead of stacking. At 767
   the same rules rendered 767/767. That 512-vs-767 split was the tablet view
   not following the mobile view; the page CSS was never the cause.

   Restated here rather than edited into `elementor-frontend.min.css`, so the
   vendored framework stays byte-identical. Scoped to `.elementor-16528` so it
   cannot reach anything else, and it wins only because this file is enqueued
   after the framework (position 10 vs 4) - same specificity, later source.

   At 767 and below this is a no-op: the framework's own copy of the rule still
   applies and declares identical values, so the mobile rendering is unchanged.
   The page uses no other mobile-only framework class - no `.elementor-column`,
   no `.elementor-grid-mobile-*`, no `.elementor-reverse-mobile`, no
   `.elementor-mobile-align-*` - and the four `elementor-hidden-*` elements
   each carry all three variants, so they stay hidden at every width. */
@media (max-width:1024px) {
	.elementor-16528 .e-con.e-flex {
		--width:100%;
		--flex-wrap:var(--flex-wrap-mobile);
	}
}

/* ---- Hero placeholder: mobile ----------------------------------------- */
/* Mirrors the vendored `...1fceba03 img{width:100%;max-width:100%;
   height:100%;}` rule, which lives in the same breakpoint. That breakpoint was
   moved from 767px to 1024px so the design's mobile layout starts at 1024 -
   see the note in assets/css/vendor/README.md - so this follows it there. Left
   at 767px it would have been the one part of the design still on the old
   breakpoint, and between 768 and 1024 the placeholder would have kept its
   700x500 desktop box while the real image beside it went full width. */
@media (max-width:1024px) {
	.elementor-16528 .elementor-element.elementor-element-1fceba03 .wsa-hero-placeholder {
		width:100%;
		max-width:100%;
		height:100%;
	}
}

/* ---- Fidelity: Hello's minimum page height: deliberately not restored --- */
/*
 * The live site renders this page inside the Hello theme, which lays out an
 * Elementor page with
 *
 *   .site-header + .elementor { min-height: calc(100vh - 320px) }
 *
 * and that rule used to be restated here. It was faithful only for as long as
 * the ported design carried the Agenda Grid: the design measured 3691px, so
 * `calc(100vh - 320px)` never actually binded and the min-height was invisible.
 *
 * The grid is gone on /agenda/ now (the Edition supplies no PDF), which leaves
 * this wrapper roughly 715px tall. The same min-height would then stretch it by
 * the difference and open a blank band between the breadcrumb and the programme
 * below - a gap the live page never rendered. Content height is therefore what
 * reproduces the live page, which is what the rule was for in the first place.
 */

/* ---- Chrome containment ------------------------------------------------ */
/*
 * Not a design rule. This exists because hello-elementor-reset.css is the Hello
 * theme's global normalise and nothing in it is scoped to the design, so on the
 * agenda templates it also restyles this theme's own header. The live site never
 * had this problem: its chrome is the Hello theme's, so the reset matches it.
 *
 * The reset's element rules (body, a, h1-h6, p, img) are all single-element
 * specificity, so functions.php re-enqueues style.css after the vendored stack
 * and those ties go to the theme. What is left are the reset's bare `button`
 * rules, which no theme rule contests, and which this theme's header buttons
 * were never written against:
 *
 *   button,input,optgroup,select,textarea{font-family:inherit;line-height:1.5}
 *   [type=button],[type=submit],button{...;border-radius:3px;...}
 *
 * The two rules below put the header's buttons back to what every other page on
 * the site renders. They are the whole of the remaining difference: measured
 * across header, .header-inner, .menu-toggle, the nav, its links and buttons,
 * and the footer, its heading and its links, the agenda pages now compute
 * identically to the front page at 1440px and at 390px.
 */
.site-header button,
.site-header .nav-link {
	border-radius:0;
}

/* The reset forces line-height:1.5 and font-family:inherit on every button.
   .menu-toggle is the one header button the theme sets no font or line-height
   on, so both landed: 51px tall in Poppins, against the 47px Arial line box it
   is everywhere else. `revert` rolls each back to the user-agent origin, which
   is exactly "as if the reset's rule were not here". */
.site-header .menu-toggle {
	font-family:revert;
	line-height:normal;
}

/* The reset's pink. It is the one visible remnant of Hello on this page:
 *
 *   [type=button]:focus,[type=button]:hover,
 *   [type=submit]:focus,[type=submit]:hover,
 *   button:focus,button:hover { background-color:#c36; color:#fff }
 *
 * `#c36` is Hello's own pink, and the selector is every button in the document.
 * The design has no buttons at all, so all of it lands on this theme's chrome,
 * where the theme has already said what each button should do:
 *
 *   .nav-link:hover    -> color:var(--blue), no background
 *   .menu-toggle       -> no hover state at all
 *   .btn-primary:hover -> background:var(--blue-dark)
 *
 * Two of the three are overridden by specificity, but the reset's background is
 * a property they never declare, so it survives. Measured result on the agenda
 * pages: the Programs/Events/About buttons got a pink block behind blue text,
 * and the mobile hamburger got both a pink background and color:#fff - white
 * text on the white header, i.e. invisible.
 *
 * Only the background is cancelled here, and with `background-color` rather than
 * the `background` shorthand, so the theme's own hover colours are untouched.
 * `.menu-toggle` also needs its colour back, because the reset sets #fff and the
 * theme defines no hover colour for it. */
.site-header .nav-link:hover,
.site-header .nav-link:focus,
.site-header .menu-toggle:hover,
.site-header .menu-toggle:focus {
	background-color:transparent;
}

/* The reset's `color:#fff` needs cancelling too, and on a different count from
   the background. `.nav-link` rests at (0,1,0) and the reset's
   `[type=button]:focus` is (0,2,0) - an attribute selector and a pseudo-class
   are both class-level - so the reset wins on focus even though the theme never
   declared a focus colour. Keyboard users tabbing the nav landed on white text
   on the white header. Cancelling it leaves the resting navy, which is what the
   same button shows on every non-agenda page; the reset's own :focus-visible
   outline still provides the focus ring. */
.site-header .nav-link:focus,
.site-header .menu-toggle:hover,
.site-header .menu-toggle:focus {
	color:var(--navy);
}

/* The footer's Subscribe button is fine on hover - `.btn-primary:hover` outranks
   the reset on specificity - but the theme defines no :focus state for it, so
   clicking it handed focus to the reset and turned it pink. Restate the resting
   background rather than the hover one: the brief for this file is that the
   agenda pages render their chrome exactly as every other page does, and on
   every other page a focused Subscribe stays --blue. */
.site-footer .btn-primary:focus {
	background:var(--blue);
}