/* ==========================================================================
   BPG Whatson — Eventonomy brand override
   Maps BPG's Elementor Global Colours onto Eventonomy's own CSS variables.
   Source palette (Elementor → Global Colours, confirmed from screenshot):
     Primary #193A59   Secondary #E67E22   Text #FFFFFF   Accent #E6CE3A
     BPG Background Blue #193A59   BPG Pale Blue #34495E
     BPG Container Blue #114471    BPG Deep Blue #0D2B4D

   WHERE THIS GOES: paste into Elementor → Site Settings → Custom CSS (or
   Appearance → Customize → Additional CSS) for now — both load after
   Eventonomy's own stylesheet, which is all that's needed. Move it into the
   BPG Whatson bridge plugin's own enqueued stylesheet once that exists;
   nothing here needs to change when you do.

   Eventonomy switches to its dark-mode token set whenever the theme adds
   .dark-mode / body.dark-scheme / [data-bx-mode="dark"] — Reign/BuddyX's own
   dark-mode signals — or an admin screen opts in with [data-theme="dark"].
   Rather than working out which of those is actually active on the live
   site, this file sets the SAME target colours in both the default block and
   the dark-mode block, so the result is identical either way.
   ========================================================================== */

:root {
	/* --- Brand / accent -----------------------------------------------
	   Eventonomy's own supported theming hook (evnm-ui.css ~L36-42): setting
	   these override variables is enough on its own — 126 places in the
	   plugin's CSS read --evnm-accent / --evnm-accent-hover / --evnm-accent-
	   contrast, only 2 read --evnm-brand directly (and those 2 are exactly
	   the lines that build --evnm-accent from --evnm-brand as a fallback).
	   These 3 lines alone re-colour every button, link, and active state in
	   the plugin, light or dark mode, with nothing else needed. */
	--evnm-accent-override: #E67E22;          /* BPG Secondary (orange) */
	--evnm-accent-hover-override: #C96A17;    /* Secondary, darkened ~15% for hover/active */
	--evnm-accent-contrast-override: #FFFFFF; /* text on the orange fill — matches your live CTA button */

	/* --- Page / surface tokens (default / light-triggered block) ------- */
	--evnm-bg: #193A59;            /* BPG Background Blue — matches the site's actual page background */
	--evnm-surface: #114471;       /* BPG Container Blue — card / panel fill */
	--evnm-surface-alt: #34495E;   /* BPG Pale Blue — secondary panels, alternating rows */
	--evnm-text: #FFFFFF;          /* BPG Text */
	--evnm-text-muted: #C7D3DE;    /* derived — not a named brand swatch, adjust if you'd rather match one exactly */
	--evnm-text-tertiary: #93A3B3; /* derived, ditto */
	--evnm-border: #2E4A66;        /* derived mid-tone between background and pale blue */
	--evnm-border-strong: #5C7A99; /* v1.12.1 fix — was #34495E, the same colour as --evnm-surface-alt and barely
	                                   distinguishable from --evnm-surface (#114471). Eventonomy's own dark-mode
	                                   default pairs a near-black surface (#26282b) with a distinctly lighter
	                                   border-strong (#4f5359) — the border, not the fill, is what makes an input
	                                   read as a separate control in their own design. This value restores that
	                                   same relative contrast against BPG's own surface tones. */

	/* Badge / chip tint — a translucent orange reads correctly over any of
	   the blues above, so one value works for both bg and surface. */
	--evnm-accent-soft: rgba(230, 126, 34, 0.16);

	/* Small accent chips on event card thumbnails: these sit on a fixed
	   near-white chip surface (--evnm-media-chip-surface), not on the page
	   background, so this wants something dark enough to read on white.
	   BPG Deep Blue gives a strong ~12.5:1 contrast there (checked) and
	   ties cleanly to a named brand swatch rather than an ad-hoc shade. */
	--evnm-media-chip-accent: #0D2B4D;
}

/* Same target colours, repeated for whichever dark-mode trigger is actually
   live on the theme — see note above. */
.dark-mode,
body.dark-scheme,
[data-bx-mode="dark"],
.evnm-admin[data-theme="dark"] {
	--evnm-bg: #193A59;
	--evnm-surface: #114471;
	--evnm-surface-alt: #34495E;
	--evnm-text: #FFFFFF;
	--evnm-text-muted: #C7D3DE;
	--evnm-text-tertiary: #93A3B3;
	--evnm-border: #2E4A66;
	--evnm-border-strong: #5C7A99; /* see :root note above */
	--evnm-accent-soft: rgba(230, 126, 34, 0.16);
	--evnm-media-chip-accent: #0D2B4D;

	/* evnm-ui.css's own dark block sets --evnm-brand to a bright lime and
	   --evnm-accent-contrast-override is left alone by that block, so the
	   :root override above already carries through correctly — repeated
	   here only for anyone reading this file top-to-bottom without also
	   reading evnm-ui.css. No functional effect. */
}

/* Deliberately NOT touched: --evnm-success / --evnm-warning / --evnm-danger
   / --evnm-info and their *-soft pairs. These carry meaning (a red "sold
   out" chip, a green "confirmed" state) rather than brand identity —
   recolouring them risks making error/success states harder to read at a
   glance. Revisit only if you specifically want them on-brand too. */

/* ============================================================
   v1.2.0 additions — carried over from a temporary YellowPencil pass
   made while testing Eventonomy, now folded in here so nothing is lost
   once that YellowPencil CSS is deleted. Checked each one against
   Eventonomy's actual default CSS first — only the ones that produce a
   DIFFERENT result than the variables above are included here; anything
   that already matched (RSVP submit button, hero link, map-cta link,
   etc.) needed no extra rule and isn't repeated.
   ============================================================ */

:root {
	/* Event tag chips + date tile background. Default token is
	   --evnm-media-chip-surface (untouched above — it's meant to stay a
	   fixed near-white so chips read on any photo). YellowPencil pushed it
	   toward yellow; using the real brand Accent (#E6CE3A) here rather than
	   YellowPencil's approximate #f1c40f. Note: --evnm-media-chip-accent is
	   already Deep Blue above, which should still read fine as text over
	   this yellow — worth a visual check regardless. */
	--evnm-media-chip-surface: #E6CE3A;
}

.dark-mode,
body.dark-scheme,
[data-bx-mode="dark"],
.evnm-admin[data-theme="dark"] {
	--evnm-media-chip-surface: #E6CE3A;
}

/* The rest have no reusable token — each is a small targeted rule rather
   than a variable, so they don't affect anything beyond the specific
   element they originally targeted. */

/* Meta-row icons: yellow rather than the default orange (--evnm-accent). */
.evnm-single-event__meta .evnm-single-event__meta-icon .evnm-icon {
	color: #E6CE3A;
}

/* Unselected RSVP option buttons: grey rather than the default blue
   (--evnm-surface). Eventonomy's own rule here uses !important, so this
   needs to as well to win. */
.evnm-rsvp__form .evnm-rsvp__choices .evnm-rsvp__choice {
	background-color: #7f8c8d !important;
}

/* Guest-count input: translucent orange accent. */
#evnm-rsvp-guests {
	background-color: rgba(230, 126, 34, 0.75) !important;
}

/* Share buttons: solid orange fill + orange border, rather than the
   default blue-outlined style. */
.evnm-single-event__share .evnm-single-event__share-wrap .evnm-single-event__share-btn {
	background-color: #E67E22 !important;
}
#evnm-register .evnm-single-event__share a.evnm-single-event__share-btn {
	border-color: #E67E22 !important;
}

/* RSVP success panel date-tile month label: yellow. Different from the
   single-event page's own date tile, which already goes through
   --evnm-media-chip-accent above — this one's default is --evnm-accent
   (orange), and the tweak pushes it to yellow specifically here. */
.evnm-rsvp__success-event .evnm-rsvp__datetile .evnm-rsvp__datetile-mon {
	color: #E6CE3A;
}

/* RSVP success calendar links: NOTE — this is a second, slightly
   different orange (#f39c12) from the main brand orange (#E67E22) used
   everywhere else. Kept exactly as found rather than silently correcting
   it to match — worth confirming whether that was deliberate (e.g. to
   visually separate the secondary calendar links from the primary CTA)
   or just an approximation during the original YellowPencil session. */
.evnm-rsvp__success .evnm-rsvp__success-cal a {
	background-color: #f39c12 !important;
}

/* Two-column event body background: a custom dark navy that doesn't
   exactly match any of the four named BPG blues (closest is Deep Blue,
   #0D2B4D, but this is #002B4F — kept distinct rather than assumed to be
   a typo for one of the named swatches). Without this, the area falls
   back to Container Blue via --evnm-surface on the parent element. */
.wp-block-eventonomy-single-event .evnm-single-event__body {
	background-color: #002B4F;
}

/* Donation panel: dark red-brown fill + light text, rather than the
   default light-orange tint + orange text. */
.wp-block-eventonomy-rsvp .evnm-rsvp__form .evnm-rsvp__donation {
	color: #ecf0f1;
	background-color: #d95b43;
}

/* NOT carried over — not colour/branding, a separate decision:
   - 85% width + padding constraint on the event body
   - Responsive H1 font-size (28px / 32px) on the hero headline
   Ask if you'd like these added as their own layout/typography pass. */

/* ============================================================
   v1.7.0 addition — Eventonomy calendar block (eventonomy/calendar),
   month grid view. Checked against the block's own style.css first:
   - Today's highlight (.evnm-calendar__cell.is-today) uses
     background: var(--evnm-accent-soft) — this SHOULD already be your
     translucent orange from the override above, but was showing
     Eventonomy's own default dark olive-green, which points at a
     caching or load-order issue rather than a wrong value. Fixed here
     with a direct, !important override on the exact selector so it's
     correct regardless of that underlying cause — worth still checking
     why --evnm-accent-soft itself wasn't taking effect there specifically,
     since the same variable is used in a few other places too.
   - "Blue palette for event days, like Eventpress": Eventonomy doesn't
     give day cells containing an event any distinct background by
     default (only the small event pill inside is coloured) — this is a
     genuine addition, not a re-colour, to match that reference.
   - Gridlines and the outer border are scoped to .evnm-calendar only, via
     a locally-overridden --evnm-border custom property — this changes
     borders inside the calendar without touching --evnm-border's value
     anywhere else on the site.
   - A cell can be both "has-events" and "is-today" at once (confirmed in
     render.php) — is-today is written after has-events below and uses
     !important, so the "today" treatment always wins on that overlap.
   ============================================================ */

.evnm-calendar {
	/* Scoped, not global — gridlines inside the calendar go white-ish
	   without affecting --evnm-border's value used elsewhere on the site.
	   0.55 opacity rather than the original 0.35 — the fainter value
	   wasn't visible enough against the dark cell backgrounds once the
	   load-order fix below let it actually apply at all. */
	--evnm-border: rgba(255, 255, 255, 0.55);
	border: 2px solid #E67E22 !important;
}

.evnm-calendar__weekdays {
	background: #FFFFFF;
}
.evnm-calendar__weekday {
	color: #193A59;
}

.evnm-calendar__cell.has-events {
	background: #2E5B85;
}
.evnm-calendar__cell.has-events:hover {
	background: #35688F;
}

.evnm-calendar__cell.is-today {
	background: #34495E !important; /* BPG Pale Blue — legible, replaces the dark-green */
	box-shadow: inset 0 0 0 2px #E67E22 !important; /* the orange ring already worked, kept as-is */
}
.evnm-calendar__cell.is-today .evnm-calendar__date {
	color: #FFFFFF;
}

/* Correction from v1.7.1: that version flattened every category's own
   pastel hue (.has-cat) to a single orange, on the theory that the mix of
   colours read as "not uniform" — turned out to be the wrong read. The
   .has-cat pastels (Eventonomy's own default: light background, dark
   toned text per category) are the legible ones; REVERTED here, so
   categorised events go back to Eventonomy's own default treatment,
   untouched.
   The actual legibility problem was the opposite: PLAIN events with no
   category use background: var(--evnm-accent-soft) — a translucent orange
   over the dark navy day-cell background — which reads as a dull, muddy
   slate rather than a clear pill. Given a light, dark-text pill of its own
   here, in the same spirit as the category pastels but in BPG's orange
   rather than a random hue, so plain events are just as legible as
   categorised ones instead of the odd one out. */
.evnm-calendar__event-link {
	background: #FBE4CC;
	color: #7A3E0A;
}
.evnm-calendar__event-link:hover {
	background: #E67E22;
	color: #FFFFFF;
}

/* Small-screen agenda view (calendar collapses to a list under 640px)
   uses the same is-today logic on a different element — aligned to match. */
.evnm-calendar__agenda-day.is-today .evnm-calendar__agenda-date {
	color: #E67E22;
}

/* ============================================================
   v1.8.0 addition — admin list tables (Attendees & Orders, Events,
   Venues, Organizers, etc.) were showing illegible pale text on
   near-white rows. Root cause is different from anything above: these
   tables use WordPress's own core "widefat striped" classes (confirmed in
   Eventonomy's own admin PHP — e.g. AttendeesOrdersPage.php,
   EventsPage.php), and WP core paints alternating rows with a hardcoded
   near-white background of its own — not an Eventonomy variable, not
   something --evnm-surface touches at all. Eventonomy's own dark
   background wins on the *even* rows, but WP core's hardcoded stripe wins
   on the *odd* ones, so white/light text (correct for the dark theme)
   reads fine on half the rows and is nearly invisible on the other half.
   Fixed by giving the odd rows an explicit dark background of their own,
   rather than trying to out-specificity WP core's fixed colour value.
   ============================================================ */
.evnm-admin table.striped > tbody > tr:nth-child(odd) {
	/* v1.12.2 — widened from .evnm-table.striped specifically: the same
	   WP-core mechanism turned up on a second table (evnm-health__table
	   widefat striped, Setup & Health's System checks list) that doesn't
	   carry the evnm-table class at all, so the original selector never
	   matched it. Matching on .striped alone catches any table using
	   this WP-core mechanism, present or future, rather than one at a time. */
	background-color: #34495E !important;
}

/* ============================================================
   v1.9.1 addition — Command Center "Needs attention" cards (and any
   other element reading --evnm-warning-soft / --evnm-info-soft) were
   showing the same pattern as the striped-table fix above: white text
   (correct for the dark theme) on a background that was deliberately
   left untouched. Those two tokens were skipped in the original brand
   override on purpose — they're semantic (warning/info), not brand
   identity, and recolouring them risked hurting readability. That
   reasoning was right for the tokens themselves, but Eventonomy's own
   default values for them are light pastels meant for a light-mode UI,
   which is exactly what's now colliding with white text. Given dark
   equivalents here instead — still visually distinct as warning
   (amber) vs info (blue), just legible against white text like
   everything else in the dark theme.

   v1.12.2 — --evnm-success-soft added to this same fix: the Setup &
   Health page's "Setup complete" banner (.evnm-setup-banner.is-complete)
   reads this token and showed the identical pale-background-plus-white-
   text problem. Worth noting Eventonomy's own dark mode doesn't cover
   this token either — --evnm-danger-soft has a dark-mode value in their
   own CSS, --evnm-success-soft doesn't, so this isn't only a brand.css
   gap. A dark green added here, following the same hue-preserving
   pattern as their own danger-soft dark value. */
   ============================================================ */
:root {
	--evnm-warning-soft: #4A3712;
	--evnm-info-soft: #1E3A5C;
	--evnm-success-soft: #12331F;
}
.dark-mode,
body.dark-scheme,
[data-bx-mode="dark"],
.evnm-admin[data-theme="dark"] {
	--evnm-warning-soft: #4A3712;
	--evnm-info-soft: #1E3A5C;
	--evnm-success-soft: #12331F;
}

/* ============================================================
   v1.12.1 addition — admin form fields (wp-admin Edit Event and
   similar screens: text/email/url/number/search/password inputs,
   selects, textareas). Reported as genuinely illegible — "none of
   the input boxes are visible" — and confirmed directly against
   Eventonomy's own CSS: .evnm-admin input/select/textarea reads
   background: var(--evnm-surface), the exact same token used for
   the surrounding card. The --evnm-border-strong fix above (:root,
   near the top of this file) addresses the root cause — border and
   fill were nearly the same colour — but given how strong this
   report was, fields are also given a genuinely distinct fill here
   rather than relying on the border alone: a step darker than the
   surrounding Container Blue card, reading as a recessed control
   rather than a flat continuation of the card behind it. Scoped to
   form controls only — .evnm-surface itself is untouched, so cards
   and panels elsewhere are unaffected. */
.evnm-admin input[type="text"],
.evnm-admin input[type="email"],
.evnm-admin input[type="url"],
.evnm-admin input[type="number"],
.evnm-admin input[type="search"],
.evnm-admin input[type="password"],
.evnm-admin select,
.evnm-admin textarea,
.evnm-admin .regular-text {
	background: #0D2B4D !important;
}

/* ============================================================
   v1.12.2 addition — native <select> dropdown option lists were
   showing dark, near-illegible text (confirmed against the actual
   dropdown popup, not just the closed control — a genuinely different
   rendering path from the input/select background fix directly above).
   Browsers largely render an open <select> popup using their own native
   widget and only reliably honour colour/background-color set directly
   on <option> elements themselves — not values inherited from the
   parent select — so those need setting explicitly here rather than
   assumed to follow from the select's own styling. Chrome, Firefox and
   Edge respect this; Safari's native popup ignores most option styling
   regardless of any CSS — a platform limitation, not something fixable
   from here.
   ============================================================ */
.evnm-admin select option {
	background: #0D2B4D;
	color: #FFFFFF;
}

/* ============================================================
   v1.12.2 addition — icon colours. Several status icons (the "Needs
   attention" list's clock/sparkle icons, the Setup & Health banner's
   icon) read color: var(--evnm-info) / var(--evnm-warning) /
   var(--evnm-success) directly — confirmed against evnm-ui.css:
   --evnm-info resolves to a mid blue (#2271b1), which is what was
   actually being seen, not a deliberate brand choice. Recoloured to
   BPG's own accent yellow instead. Scoped to the icon rules
   specifically, not the underlying --evnm-info/--evnm-warning/
   --evnm-success tokens themselves — those still drive other, non-icon
   things (the badge text next to these same icons, for one), and
   recolouring the base tokens wholesale would change those too, which
   wasn't asked for and isn't obviously wanted.
   ============================================================ */
.evnm-admin .evnm-setup-banner__icon,
.evnm-admin .evnm-attention__icon {
	color: #E6CE3A !important;
}

/* ============================================================
   v1.12.3 — CHANGE OF STRATEGY, not just another patch.
   The variable-based fix in v1.12.2 (--evnm-warning-soft etc.) was
   verified correct against Eventonomy's own CSS — checked every place
   those tokens are set, confirmed no more-specific rule anywhere
   overriding them — and yet the "Needs attention" rows were still
   reported pale, while the icon-colour fix in the very same file, at
   the same specificity, visibly worked. When two fixes of equal
   correctness in the same stylesheet behave differently in practice,
   the honest conclusion is that trusting Eventonomy's own variable
   indirection to propagate correctly everywhere is itself the
   unreliable part — not any one selector. So rather than keep finding
   and patching individual --evnm-*-soft consumers one at a time,
   everything below sets the actual consumed property directly, with
   !important, bypassing the variable layer entirely. Less elegant,
   considerably more resistant to this exact class of silent mismatch.
   ============================================================ */

/* Needs-attention rows and the Setup & Health banner, direct rather
   than via --evnm-warning-soft / --evnm-info-soft / --evnm-success-soft. */
.evnm-admin .evnm-attention__row.is-warning,
.evnm-admin .evnm-setup-banner.is-incomplete {
	background: #4A3712 !important;
}
.evnm-admin .evnm-attention__row.is-info {
	background: #1E3A5C !important;
}
.evnm-admin .evnm-setup-banner.is-complete {
	background: #12331F !important;
}
.evnm-admin .evnm-attention__message,
.evnm-admin .evnm-setup-banner__title,
.evnm-admin .evnm-setup-banner__body {
	color: #FFFFFF !important;
}

/* Form controls — every state (default, hover, focus, and the open
   dropdown's own option list), text and background both set directly.
   input[type=text] fix from v1.12.1 and the option-list fix from
   v1.12.2 are still correct and still needed; this adds explicit
   coverage for the plain closed-select state and hover, reported as
   still dark ("Bulk actions") even where the input/textarea fix
   already applied correctly. */
.evnm-admin select,
.evnm-admin select:hover,
.evnm-admin select:focus,
.evnm-admin input[type="text"],
.evnm-admin input[type="text"]:hover,
.evnm-admin input[type="email"],
.evnm-admin input[type="url"],
.evnm-admin input[type="number"],
.evnm-admin input[type="search"],
.evnm-admin input[type="password"],
.evnm-admin textarea,
.evnm-admin .regular-text {
	background: #0D2B4D !important;
	color: #FFFFFF !important;
}
.evnm-admin select option {
	background: #0D2B4D !important;
	color: #FFFFFF !important;
}

/* ============================================================
   v1.12.4 addition — bare <code> tags on the Setup & Health -> Importer
   tab (the CSV column-name hints: <code>title</code>, <code>start_local
   </code>, etc.) were showing dark, near-illegible text. Confirmed
   directly in ToolsPage.php: these are plain, unstyled <code> HTML
   elements — nothing in Eventonomy's own CSS or brand.css touches them
   at all (searched the whole stylesheet: the only existing code{} rule
   is scoped to a completely different, unrelated component). This means
   the styling is coming from somewhere else on the site entirely — a
   theme or another plugin's own generic code{} rule (BetterDocs is
   active here and commonly styles code snippets with a light background
   for documentation use, which would explain it, though not confirmed
   against BetterDocs' own source specifically). Rather than track down
   exactly which of several possible sources it is, this applies the
   same direct-override approach used since v1.12.3: style <code> inside
   Eventonomy's own admin pages explicitly, regardless of what else on
   the site might otherwise be styling it. Only .evnm-admin is scoped —
   any other plugin's own light-background code snippets elsewhere in
   wp-admin are untouched. */
.evnm-admin code {
	background: #0D2B4D !important;
	color: #FFF6D8 !important;
	padding: 1px 5px !important;
	border-radius: 3px !important;
}

/* ============================================================
   v1.12.5 addition — bare <h3> headings on Setup & Health -> Importer
   ("Migrate from another events plugin" among them) showed dark, near-
   illegible text. Checked ToolsPage.php directly: all of that page's h3
   headings (six of them, confirmed by count) are plain, unclassed <h3>
   tags — the same "nothing actually styles this element" situation as
   the <code> fix above, not a --evnm-* variable issue. Confirmed no
   other Eventonomy admin page uses this bare pattern and Eventonomy's
   own CSS has no h3{} rule of its own anywhere, so a single rule here
   safely covers this page's whole heading set rather than needing one
   narrow fix per heading as each is separately reported. */
.evnm-admin h3 {
	color: #FFFFFF !important;
}

/* ============================================================
   v1.12.6 addition — dropdown affordance. Checked Eventonomy's own CSS
   directly: it sets no appearance property and adds no chevron/caret of
   its own to <select> elements at all — they were always relying on the
   browser's native arrow. That native arrow is typically drawn in a
   muted grey by the OS/browser, which is legible against a plain white
   background but easy to miss against the dark navy fill this override
   applies — not removed, just not visually prominent enough to
   confidently signal "this is a dropdown" any more. Rather than leave it
   to chance across different browsers' native rendering, this replaces
   it with an explicit, always-visible, on-brand chevron.

   Text inputs are deliberately NOT included here — only genuine
   dropdowns need a "there's a list here" signal; a text field doesn't
   have one to show. */
.evnm-admin select {
	appearance: none;
	-webkit-appearance: none;
	background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 20 20' fill='%23E6CE3A'%3E%3Cpath fill-rule='evenodd' d='M5.23 7.21a.75.75 0 011.06.02L10 11.168l3.71-3.938a.75.75 0 111.08 1.04l-4.25 4.5a.75.75 0 01-1.08 0l-4.25-4.5a.75.75 0 01.02-1.06z' clip-rule='evenodd'/%3E%3C/svg%3E") !important;
	background-repeat: no-repeat !important;
	background-position: right 12px center !important;
	background-size: 16px !important;
	padding-right: 36px !important;
}

/* ============================================================
   v1.12.7 addition — Event Editor: three genuinely distinct fixes,
   scoped to the front-end .evnm-event-editor (not .evnm-admin — this
   form renders on the front end, members use it directly, unlike
   everything fixed so far which was wp-admin only).
   ============================================================ */

/* 1. Native datetime-local calendar-picker icon. Confirmed in
   event-editor/render.php: these are plain <input type="datetime-local">
   — the small calendar icon is the BROWSER's own native picker
   indicator, not anything Eventonomy or this override draws. Chrome/Edge
   render it in solid black by default with no CSS "color" property
   available to target directly — inverting it is the standard technique
   for making a black-only native icon visible on a dark background. */
.evnm-event-editor input[type="datetime-local"]::-webkit-calendar-picker-indicator {
	/* v1.13.2 — filter:invert(1) turned the icon white, not the accent
	   yellow actually asked for, and a filter chain can only ever
	   approximate a specific hex colour, never match it exactly. Same
	   precise technique as the dropdown-chevron fix instead: replace the
	   native icon outright with a hand-drawn SVG in the exact colour. */
	background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%23E6CE3A' stroke-width='2' stroke-linecap='round' stroke-linejoin='round'%3E%3Crect x='3' y='5' width='18' height='16' rx='2'/%3E%3Cline x1='3' y1='10' x2='21' y2='10'/%3E%3Cline x1='8' y1='2' x2='8' y2='6'/%3E%3Cline x1='16' y1='2' x2='16' y2='6'/%3E%3C/svg%3E") !important;
	background-repeat: no-repeat !important;
	background-size: 18px !important;
	cursor: pointer;
}

/* 2. Accordion sections (native <details>/<summary>, confirmed directly
   in render.php — not a custom JS accordion). Originally attempted a
   live colour cue based on whether a section still had an empty or
   invalid field inside it, using :has(input:placeholder-shown) and
   :has(.is-invalid). Removed as of v1.13.8: confirmed the border
   thickness this produced was inconsistent specifically between
   sections that are open vs. closed by default (Basics/Date & Time/
   Location start open; Organizer/Details/Tickets/Visibility start
   closed — confirmed directly against render.php, not guessed), and
   couldn't pin down with real confidence why a CSS-only check behaves
   differently between the two. Rather than keep patching visible
   symptoms of a mechanism whose actual reliability is now in doubt,
   removed it entirely — every section gets the same plain, unconditional
   border below, always, with no state-dependent variation to go wrong.
   A reliable version of this (Eventonomy exposing a genuine per-section
   "still has empty required fields" signal, checked when a section
   opens rather than relying on live CSS state) would need to be a
   deliberate small feature, not another CSS patch — worth scoping
   properly later if still wanted, rather than attempted again here. */

/* 3. Title sizing — single-event hero overlay, grid/list cards (shared
   class), and the plain-text Upcoming block. Font-size only, not weight,
   on the hero title — it's already font-weight:800 in Eventonomy's own
   CSS (confirmed directly), about as bold as text gets; the actual
   complaint was size specifically. Grid/list and Upcoming get both,
   since neither was bold to begin with (600 and unset respectively).
   v1.14.0 — the fixed 3.4rem had no allowance for narrow viewports, so
   a longer title had nowhere to go but overflow the card on mobile
   (reported directly, with a title visibly cut off). Replaced with
   clamp(), which scales smoothly between a mobile-safe minimum and the
   same 3.4rem desktop maximum already in place, rather than a fixed
   size that only ever worked at one width. Also added a soft, dark
   text-shadow — a "glow" rather than a hard offset — so the title
   stays legible over whatever a given event's own cover photo happens
   to look like, applied at every width rather than just larger screens,
   since legibility against a busy photo matters just as much on mobile. */
.evnm-single-event__title {
	/* v1.14.1 — still overflowing on mobile even after the v1.14.0 clamp;
	   the mobile-end numbers were still too generous for a longer title.
	   Both the minimum and the scaling rate reduced — same 3.4rem
	   desktop maximum kept, since that end was already correct. */
	font-size: clamp( 1.3rem, 4vw + 0.6rem, 3.4rem ) !important;
	text-shadow: 0 2px 6px rgba( 0, 0, 0, 0.8 ), 0 0 24px rgba( 0, 0, 0, 0.6 ) !important;
}
.evnm-events-list__title {
	font-size: 1.35rem !important;
	font-weight: 700 !important;
}
.evnm-upcoming__title {
	font-size: 1.15rem !important;
	font-weight: 700 !important;
}

/* ============================================================
   v1.13.1 addition — the whole Event Editor form "looked like plain
   text". Root cause confirmed directly in event-editor/style.css: the
   form's own card (.evnm-event-editor__form) and every single input/
   select/textarea inside it read the SAME --evnm-surface variable —
   fields are literally the same colour as the card behind them, with
   only a 1px border as the sole difference. Same underlying pattern as
   the wp-admin input fix from earlier, never extended to this front-end
   form specifically.
   ============================================================ */
.evnm-event-editor .evnm-event-editor__input,
.evnm-event-editor .evnm-event-editor__select,
.evnm-event-editor .evnm-event-editor__textarea {
	background: #0D2B4D !important;
}

/* Live "this still needs filling in" cue — no submit required, no JS.
   :placeholder-shown matches a text field exactly while it's empty (only
   fields that actually carry a placeholder qualify — confirmed against
   the real markup, most text fields do); :required:invalid catches
   genuinely required fields even without one (the Starts date/time,
   confirmed marked required, is the clearest example — empty required
   fields are natively :invalid the moment the page loads, no JS needed).
   Both are reactive: the moment a real value is entered, the field no
   longer matches and the highlight disappears on its own. */
.evnm-event-editor .evnm-event-editor__input:placeholder-shown,
.evnm-event-editor .evnm-event-editor__textarea:placeholder-shown,
.evnm-event-editor .evnm-event-editor__input:required:invalid {
	border-color: #E67E22 !important;
	box-shadow: 0 0 0 1px #E67E22 !important;
}

/* ============================================================
   v1.13.3 addition — every accordion row now looks like its own raised
   input card, always, regardless of fill state — not just when empty or
   erroring. Confirmed there was nothing giving them this identity at
   all: no distinct background, no border, nothing to signal "this row
   opens into a data-entry area" rather than being a plain section
   heading. Matches a supplied mockup precisely: a left-edge accent
   border, a card background distinct from the page, and a small lift
   shadow — reusing the exact "lift it off the page" idea Eventonomy's
   own sticky action bar already uses (--evnm-shadow-up), just applied
   consistently here instead of to one single element.
   ============================================================ */
.evnm-event-editor details.evnm-event-editor__section {
	margin-block-end: 10px !important;
	/* v1.13.6 — every row now gets a full, thin orange border on all four
	   sides as its baseline, always — not just a left accent with the
	   other three sides left at the default grey. Confirmed the previous
	   left-only-vs-full split was actually meaningful (only sections
	   with an empty/erroring field got the full border) but it read as
	   inconsistent/broken rather than intentional, so every row is
	   consistent now — the empty/error states below just make this
	   thicker rather than structurally different. */
	border-block-start: 1px solid #E67E22 !important;
	border-block-end: 1px solid #E67E22 !important;
	border-inline-start: 4px solid #E67E22 !important;
	border-inline-end: 1px solid #E67E22 !important;
	border-radius: 10px !important;
	box-shadow: 0 3px 8px rgba( 0, 0, 0, 0.25 ) !important;
	overflow: hidden;
}
.evnm-event-editor details.evnm-event-editor__section > summary {
	background: #0D2B4D !important; /* BPG Deep Blue — a genuinely distinct card tone, not the page's own surface colour */
	color: #E67E22 !important; /* collapsed title — orange, per the supplied mockup */
	padding: 14px 16px !important;
	margin: 0 !important;
}
/* Open state: title switches to the brighter accent yellow — a clear
   "this one is the active input area" signal, distinct from a merely
   collapsed row — matching the mockup's own open-vs-closed distinction. */
.evnm-event-editor details.evnm-event-editor__section[open] > summary {
	color: #E6CE3A !important;
	border-block-end: 1px solid var( --evnm-border-strong );
}
/* The revealed content area gets a visibly LIGHTER tone than the header
   above it — everything inside the <details> except the summary/legend
   itself. Gives the open state its own "this is the data-entry zone"
   identity, distinct from both the page and the collapsed header. */
.evnm-event-editor details.evnm-event-editor__section[open] > *:not(.evnm-event-editor__legend) {
	background: #2E4A66 !important;
	/* v1.13.7 — content was sitting flush against the edges of this
	   background with no inset of its own; Eventonomy's own padding is
	   applied one level up (on .evnm-event-editor__form's direct
	   children, i.e. the <details> itself), not on this inner area. */
	padding: 16px !important;
	box-sizing: border-box;
}

/* v1.13.2 — chevron made generally bigger and bolder (was too small and
   thin to read as a real control), as its own base rule applying to
   every section regardless of state — colour is set separately per
   state below, since a single fixed colour can't work against both the
   ordinary navy header and the orange/red attention states. */
.evnm-event-editor .evnm-event-editor__legend::after {
	width: 0.7em !important;
	height: 0.7em !important;
	border-inline-end-width: 3px !important;
	border-block-end-width: 3px !important;
}

/* Removed as of v1.13.8 — see the note above the (now-removed) error
   state rule for the full reasoning. Every section gets the same
   unconditional border from the base card rule now, regardless of
   whether it has an empty field or not. */

/* v1.13.5 addition — pale background overlay, still visible around the
   "Use a saved venue/organizer" picker and its manual fields. Traced to
   .evnm-event-editor__subsection, confirmed directly in Eventonomy's own
   style.css: it reads background: var(--evnm-surface-alt) — a genuinely
   different component from anything patched so far, but one that happens
   to share a variable overridden a long time ago for something
   unrelated (calendar alternating rows). That old override was never
   meant for this context and is what's producing the wash here.
   Overridden directly for this component specifically, rather than
   changing --evnm-surface-alt itself, which is still correct where it
   was originally meant to apply. */
.evnm-event-editor .evnm-event-editor__subsection {
	background: transparent !important;
	border-color: var( --evnm-border-strong ) !important;
}

/* v1.13.5 addition — a field populated via the venue/organizer picker
   was reported losing its dark background (reverting to a lighter
   tone) after a selection. Belt-and-braces reinforcement: explicitly
   re-targets every input nested inside .evnm-event-editor__subsection
   specifically, in case nesting inside that component was interacting
   with the general input fix in a way not otherwise accounted for. */
.evnm-event-editor .evnm-event-editor__subsection .evnm-event-editor__input,
.evnm-event-editor .evnm-event-editor__subsection .evnm-event-editor__select,
.evnm-event-editor .evnm-event-editor__subsection .evnm-event-editor__textarea {
	background: #0D2B4D !important;
}

/* ============================================================
   v1.13.6 addition — the outer form wrapper (.evnm-event-editor__form,
   the single container holding every accordion row and the Publish/
   Save Draft buttons underneath) had no distinct identity of its own —
   it read var(--evnm-surface), the same token used elsewhere, so it
   didn't visually register as "the one container holding everything."
   Given its own genuinely darker tone than the rows inside it (rows are
   #0D2B4D; this is a step darker again) plus extra padding beyond what
   Eventonomy's own CSS already gives each section, so it reads as a
   wider frame around the group rather than a tight fit around it.
   ============================================================ */
.evnm-event-editor .evnm-event-editor__form {
	background: #081D33 !important;
	padding: 16px !important;
}

/* ============================================================
   v1.13.6 addition — the pale background persisted inside opened
   sections in more places than the one component fixed in v1.13.5
   (.evnm-event-editor__subsection). Rather than continue finding and
   patching each individual sub-component one at a time as each turns
   up separately (checkbox-pill groups, nested field wrappers, and
   likely others not yet spotted), this re-scopes the two underlying
   variables those components all read from — --evnm-surface and
   --evnm-surface-alt — directly within an open section. Everything
   inside that reads either variable for its own background now
   automatically picks up the same consistent tone, comprehensively,
   without needing a separate override per component. Doesn't affect
   input/select/textarea fields, which stay the correct #0D2B4D — that
   fix is a direct, hardcoded override, not variable-based, so it isn't
   touched by this at all.
   ============================================================ */
.evnm-event-editor details.evnm-event-editor__section[open] {
	--evnm-surface: #2E4A66;
	--evnm-surface-alt: #2E4A66;
}