/* ==========================================================================
   PI - Frontend — Home Feed / Topic Feed
   Token values mirror the live brand palette already used by pi-topics,
   pi-single-event and pi-shortcodes (burgundy accent #7E3C3B etc.), scoped
   locally like those plugins scope their own (--pi-topic-*, etc.) rather
   than declared as a site-wide :root, since no shared token set exists yet.
   ========================================================================== */

.pif-layout {
	--pif-accent: #7e3c3b;
	--pif-accent-dark: #683130;
	--pif-accent-light: #fdf2f2;
	--pif-accent-pale: #ece0df;
	--pif-accent-border: #c4a09e;

	--pif-topic: #76403e;
	--pif-category: #2d3748;
	--pif-type: #917c55;

	--pif-fg-1: #111827;
	--pif-fg-2: #1f2937;
	--pif-fg-3: #374151;
	--pif-fg-muted: #64748b;
	--pif-fg-muted-2: #6b7280;
	--pif-fg-placeholder: #9ca3af;

	--pif-border: #e2e8f0;
	--pif-border-strong: #cbd5e1;
	--pif-border-cool: #d7d9dc;

	--pif-bg-soft: #f8fafc;
	--pif-bg-muted: #f1f5f9;

	--pif-sidebar-w: 280px;
	--pif-sidebar-gutter: 32px;
	/* Not some rail width: the fully-collapsed (non-narrow) sidebar wrapper
	   takes no layout space at all (width:0 — see .pif-layout.pif-collapsed
	   below), and this is just ordinary page margin so content isn't flush
	   against the viewport edge. It does double as clearance for
	   .pif-sidebar-toggle, though — that floating button sits at left:20
	   regardless of this variable, so shrinking it too far lets the button
	   overlap real content, which is exactly what happened when an earlier
	   pass here shrunk it at 640px. It now stays fixed at this value all
	   the way down to 800px, where the button moves into the header band
	   itself (repositioned in place, not replaced — see the ≤800px rule
	   below) and this just becomes an ordinary small mobile gutter, shrunk
	   to 16px (matching the page's right-hand padding at that width)
	   rather than clearing it to zero. */
	--pif-sidebar-collapsed-w: 32px;
	/* Main (760) + gap (32) + right sidebar (260) — the hero and the
	   main+right-sidebar row share this so their edges line up exactly. */
	--pif-content-max: 1052px;
	/* Shared row height for the view toggle and, in topic mode, the
	   Follow/Submit actions beside it in the right sidebar — both rows
	   start at the same y (align-items: flex-start on .pif-center), so
	   matching heights is what actually makes them read as one row. */
	--pif-toolbar-h: 34px;
	/* Measured at runtime from the real theme header (see assets/js/pi-frontend.js) —
	   the design handoff's own fixed header is a placeholder, not reproduced here,
	   so the sidebar/sticky offsets below can't assume a fixed pixel height. */
	--pif-header-h: 0px;
	--pif-sticky-gap: 20px;

	font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
	color: var( --pif-fg-2 );
}

.pif-icon { width: 16px; height: 16px; flex-shrink: 0; display: inline-block; vertical-align: middle; }
.pif-icon--9 { width: 9px; height: 9px; }
.pif-icon--12 { width: 12px; height: 12px; }
.pif-icon--13 { width: 13px; height: 13px; }
.pif-icon--14 { width: 14px; height: 14px; }
.pif-icon--15 { width: 15px; height: 15px; }
.pif-icon--16 { width: 16px; height: 16px; }
.pif-icon--18 { width: 18px; height: 18px; }
.pif-icon--24 { width: 24px; height: 24px; }
.pif-icon--placeholder { color: var( --pif-fg-placeholder ); }

.pif-link-btn,
.pif-link-btn:hover,
.pif-link-btn:focus,
.pif-link-btn:active {
	border: 0;
	background: transparent;
	color: var( --pif-accent );
	font-size: 12px;
	font-weight: 600;
	line-height: normal;
	box-shadow: none;
	cursor: pointer;
	padding: 0;
}
.pif-link-btn:hover { color: var( --pif-accent-dark ); }
.pif-is-hidden { display: none !important; }

/* -------------------------------------------------------------------------
   Topic hero (mirrors pi-topics; only the title is shown here — the
   Follow/Submit row moved into the right sidebar per the Home Feed design,
   see .pif-topic-actions below). It's rendered as a descendant of
   .pif-layout.pi-topics-topic-page (not a page-level sibling) specifically
   so var(--pi-topic-primary) etc. — set on that class by PI - Topics' own
   inline color-scheme CSS — are actually in scope here.
   ------------------------------------------------------------------------- */
.pif-hero-wrap {
	margin-left: calc( var( --pif-sidebar-w ) + var( --pif-sidebar-gutter ) );
	margin-bottom: 24px;
	box-sizing: border-box;
	transition: margin-left 0.3s ease;
}
.pif-layout.pif-collapsed .pif-hero-wrap,
.pif-layout.pif-narrow .pif-hero-wrap {
	margin-left: var( --pif-sidebar-collapsed-w );
}
/* PI - Topics' own `.pi-topic-hero, .pi-topic-layout { width: min(1242px,94vw); margin: 0 auto; }`
   already centers the hero within its containing block — exactly what we
   want, but that containing block needs to be the same available width
   .pif-center centers main+right-sidebar within (this wrapper, offset by
   the sidebar but otherwise unconstrained), and capped at the same content
   width, so the two rows land on identical edges instead of each centering
   within a different box. */
.pif-hero-wrap .pi-topic-hero { width: 100%; max-width: var( --pif-content-max ); margin: 0 auto; }
/* 200px = PI - Topics' own 250px min-height, -20%. Both classes (rather than
   just .pif-hero) so this reliably outranks .pi-topic-hero's own rule
   (topic-page.css) regardless of stylesheet load order. */
.pi-topic-hero.pif-hero { min-height: 200px; }

/* -------------------------------------------------------------------------
   Overall layout
   ------------------------------------------------------------------------- */
.pif-layout {
	position: relative;
	width: 100%;
	padding: 28px 32px 64px 0;
	box-sizing: border-box;
	display: block;
	/* Covers the whole view — hero, the left gutter, and the gaps around
	   the right sidebar's own panels — rather than just .pif-main below,
	   which left those areas showing the page's plain white underneath.
	   The left sidebar (.pif-sidebar-left-wrapper, fixed-position, above
	   this in stacking order) and the right sidebar's individual
	   .pif-panel cards each already set their own explicit white
	   background, so both still render white on top of this regardless. */
	background: var( --pif-bg-soft );
}
/* Topic-mode pages carry PI - Topics' own .pi-topics-topic-page class
   alongside .pif-layout (see feed.php/topic-settings.php), which sets its
   own `background: #fff` (topic-page.css) — equal specificity to the
   plain `.pif-layout` rule above, so whichever stylesheet happens to load
   later was winning and silently keeping topic pages white. The combined
   selector here (two classes) outranks pi-topics' single-class one
   regardless of load order. */
.pif-layout.pi-topics-topic-page {
	background: var( --pif-bg-soft );
}

.pif-center {
	margin-left: calc( var( --pif-sidebar-w ) + var( --pif-sidebar-gutter ) );
	display: flex;
	align-items: flex-start;
	justify-content: center;
	gap: 32px;
	transition: margin-left 0.3s ease;
}

.pif-layout.pif-collapsed .pif-center,
.pif-layout.pif-narrow .pif-center {
	margin-left: var( --pif-sidebar-collapsed-w );
}

/* No background of its own — transparent, so .pif-layout's gray (above)
   shows through behind the event list content, same as everywhere else
   in the view. */
.pif-main { min-width: 0; max-width: 760px; flex: 1 1 auto; width: 100%; }

/* The single-event shell wrap reuses .pif-layout/.pif-center/.pif-main so the
   sidebar CSS/JS above applies unmodified; PI - Single Event's own content
   (`.pise-wrap`) manages its own width, so don't cap it here too. */
.pif-layout--single-event .pif-main { max-width: none; }

/* Venue view (templates/venue.php): same reasoning as the single-event rule
   above — .pifv-wrap manages its own width, so don't cap it here too. */
.pif-layout--venue .pif-main { max-width: none; }

/* -------------------------------------------------------------------------
   Left sidebar
   ------------------------------------------------------------------------- */
.pif-sidebar-left-wrapper {
	position: fixed;
	left: 0;
	top: var( --pif-header-h );
	height: calc( 100vh - var( --pif-header-h ) );
	width: var( --pif-sidebar-w );
	background: #fff;
	border-right: 1px solid var( --pif-border );
	box-sizing: border-box;
	overflow: hidden;
	z-index: 5;
	transition: width 0.3s ease, opacity 0.2s ease, transform 0.3s ease, box-shadow 0.3s ease;
	/* Opening/closing the overlay only ever animates `transform` (width and
	   opacity are the same 280px/1 in both the open and closed narrow
	   states — see the two rules below); by itself that's a single clean
	   transition. But a fixed-position element animating `transform` can,
	   in some browsers, paint one frame at its untransformed layout
	   position (i.e. fully visible, flush left) before the transform value
	   actually applies — read as a brief flash of the sidebar right before
	   it slides to its real position. Promoting the element to its own
	   compositor layer ahead of time (rather than only once the transition
	   starts) avoids that first-frame mispaint. */
	will-change: transform;
}

/* Scrollable, but the scrollbar itself is suppressed (still fully
   scrollable via wheel/trackpad/touch/keyboard) — `scrollbar-width: none`
   (Firefox) + the ::-webkit-scrollbar rule below (Chrome/Safari/Edge) cover
   every evergreen engine; there's no standards-track property that also
   works in both without the vendor pseudo-element. */
.pif-sidebar-left {
	display: flex;
	flex-direction: column;
	gap: 0;
	height: 100%;
	width: 100%;
	overflow-y: auto;
	overflow-x: hidden;
	box-sizing: border-box;
	padding: 20px 0;
	scrollbar-width: none;
}
.pif-sidebar-left::-webkit-scrollbar { display: none; }

.pif-layout.pif-collapsed .pif-sidebar-left-wrapper {
	width: 0;
	opacity: 0;
	pointer-events: none;
}

.pif-layout.pif-narrow .pif-sidebar-left-wrapper {
	width: 280px;
	opacity: 1;
	box-shadow: 6px 0 16px -6px rgba( 0, 0, 0, 0.15 );
	transform: translateX( -100% );
	/* High enough to clear the theme's own header/mobile-menu chrome —
	   Kadence's sticky header, admin bar, and mobile nav drawer are all
	   fixed-position elements that can carry a z-index well above this
	   overlay's previous value of 16, which would leave the sidebar
	   genuinely open (class toggled, slid into view) but rendered
	   underneath them — indistinguishable from not opening at all. */
	z-index: 100000;
}
.pif-layout.pif-narrow:not( .pif-collapsed ) .pif-sidebar-left-wrapper {
	transform: translateX( 0 );
	pointer-events: auto;
}

.pif-sidebar-overlay {
	position: fixed;
	top: var( --pif-header-h );
	left: 0;
	right: 0;
	bottom: 0;
	background: rgba( 0, 0, 0, 0.35 );
	z-index: 99999;
	display: none;
}
.pif-layout.pif-narrow:not( .pif-collapsed ) .pif-sidebar-overlay { display: block; }

.pif-sidebar-toggle,
.pif-sidebar-toggle:hover,
.pif-sidebar-toggle:focus,
.pif-sidebar-toggle:active {
	position: fixed;
	left: 20px;
	/* +7px below the sticky-gap default the toggle used to sit flush at. */
	top: calc( var( --pif-header-h ) + var( --pif-sticky-gap ) + 7px );
	z-index: 100001;
	border: 1px solid var( --pif-border-strong );
	background: #fff;
	border-radius: 50%;
	width: 36px;
	height: 36px;
	padding: 0;
	align-items: center;
	justify-content: center;
	cursor: pointer;
	color: var( --pif-fg-muted );
	box-sizing: border-box;
	-webkit-appearance: none;
	appearance: none;
	font-family: inherit;
	line-height: inherit;
	box-shadow: none;
	outline: none;
}
.pif-sidebar-toggle { display: none; }
.pif-sidebar-toggle::-moz-focus-inner { border: 0; padding: 0; }
/* Kadence's global `button:hover,:focus,:active{background:...}` rule
   (element+pseudo-class, 0,1,1) otherwise wins on hover/focus/active even
   though the button's own border/color are unchanged at rest — same story
   as .pif-sb-collapse-btn/.pif-filter__toggle above, and the reported "red
   on red" was exactly that: Kadence's own hover fill (its brand red)
   showing through behind the icon's already-reddish-on-hover color. A
   distinct (if subtle) hover/focus/active state of our own, rather than
   just re-asserting the resting one verbatim, so the button still gives
   some feedback on interaction. */
.pif-sidebar-toggle:hover,
.pif-sidebar-toggle:focus,
.pif-sidebar-toggle:active {
	background: var( --pif-bg-muted );
	color: var( --pif-fg-2 );
}
.pif-sidebar-toggle:focus-visible {
	outline: 2px solid var( --pif-accent );
	outline-offset: 2px;
}
.pif-layout.pif-collapsed .pif-sidebar-toggle { display: flex; }
.pif-sidebar-toggle__hamburger,
.pif-sidebar-toggle__chevron { display: none; }
.pif-layout.pif-narrow .pif-sidebar-toggle__hamburger { display: inline-block; }
.pif-layout:not( .pif-narrow ) .pif-sidebar-toggle__chevron { display: inline-block; }

/* The site footer, driven by the pif-footer-inset(--narrow) classes
   pi-frontend.js toggles on <body> alongside #pif-layout's own
   pif-collapsed/pif-narrow. A real stylesheet rule targeting <body>, not an
   inline style written to the footer element itself — deliberately, since
   the footer's own inline style gets rewritten by something else on the
   page (Kadence's "sticky footer reveal" feature is the likely culprit) for
   its own reveal animation, wiping out anything set there directly.
   Literal 280px (not var(--pif-sidebar-w)) because that custom property is
   declared on .pif-layout, which the footer sits outside of and so can't
   inherit from. --narrow goes flush to 0 rather than keeping the small
   --pif-sidebar-collapsed-w gutter .pif-center/.pif-hero-wrap use — the
   footer isn't page content that needs breathing room next to the floating
   toggle button the way a headline or the first event card does. */
.pif-footer-inset .site-footer,
.pif-footer-inset #colophon,
.pif-footer-inset footer.site-footer,
.pif-footer-inset footer[ role="contentinfo" ],
.pif-footer-inset > footer {
	box-sizing: border-box;
	padding-left: 280px;
	transition: padding-left 0.3s ease;
}
.pif-footer-inset.pif-footer-inset--narrow .site-footer,
.pif-footer-inset.pif-footer-inset--narrow #colophon,
.pif-footer-inset.pif-footer-inset--narrow footer.site-footer,
.pif-footer-inset.pif-footer-inset--narrow footer[ role="contentinfo" ],
.pif-footer-inset.pif-footer-inset--narrow > footer {
	padding-left: 0;
}

/* Right-hand counterpart, matching .pif-sidebar-right's own 260px width —
   or rather, --pif-footer-right-inset (pi-frontend.js), the *measured*
   distance from the viewport's right edge to the sidebar's actual left
   edge, with 260px only as a fallback for before that measurement runs.
   A literal 260px alone isn't enough here the way a literal 280px is for
   the left inset above: the left sidebar sits a fixed distance from the
   viewport at any width (position: fixed), but the right one is centered
   as part of the main+sidebar row (.pif-center's justify-content: center)
   — once the viewport is wide enough that row is narrower than the space
   available for it, extra centering space opens up on *both* sides of the
   row, pushing the sidebar's real left edge further from the viewport's
   right edge than a flat 260px accounts for. Confirmed live on Dev at a
   wide (~1500px) viewport: the sidebar's actual edge and this rule's
   fixed-260px strip sat ~54px apart instead of aligned — a real gap the
   footer's content could render into. --pif-footer-right-inset is set on
   documentElement (not #pif-layout, which the footer sits outside of and
   so can't inherit a custom property from — same issue as the padding-left
   literal above, just solved with a var() this time instead of a literal,
   since this one genuinely needs to track the viewport width live).

   Gated by pif-footer-inset--has-sidebar-right (set once in pi-frontend.js,
   only when .pif-sidebar-right actually exists in the DOM) rather than
   plain .pif-footer-inset — single-event pages share this same
   left-sidebar shell (PIF_Router::shell_start()) but never render a right
   sidebar at all, and without this guard they'd still get this padding
   and rail on the right with nothing above to justify it. The right
   sidebar's own *visibility* (as opposed to its presence in the DOM) is
   plain CSS, not JS-driven — see its min-width: 900px rule — so unlike the
   left inset's --narrow class, there's no separate collapsed state to
   track here; the media query below handles that half on its own. */
@media ( min-width: 900px ) {
	/* Previously a ::after pseudo-element (position:absolute, right-offset,
	   z-index:-1) painted over this padding-right gutter to fake the rail
	   continuing into the footer. That depended on the footer establishing
	   its own stacking context (position:relative + z-index:0) so the
	   negative z-index resolved *within* it instead of escaping to
	   #wrapper.site further up the tree — fragile, and it broke again even
	   after that stacking-context fix landed: still invisible live on Dev,
	   with every computed style on the ::after (background, position,
	   width) checking out correctly and the box still just not painting
	   gray. Setting the background directly on the footer element itself
	   sidesteps the whole stacking-order question — a real element's own
	   background always paints behind its own children, full stop, no
	   z-index or stacking-context reasoning required. It's safe to do here
	   specifically because Kadence's own footer row backgrounds
	   (.site-footer-row-container-inner, footer.min.css) are ordinary block
	   children that stop at the footer's padding edge rather than a
	   full-bleed/100vw technique — confirmed by reading that stylesheet —
	   so they never paint over this padding-right gutter, leaving the
	   footer's own background as the only thing visible there. */
	.pif-footer-inset.pif-footer-inset--has-sidebar-right .site-footer,
	.pif-footer-inset.pif-footer-inset--has-sidebar-right #colophon,
	.pif-footer-inset.pif-footer-inset--has-sidebar-right footer.site-footer,
	.pif-footer-inset.pif-footer-inset--has-sidebar-right footer[ role="contentinfo" ],
	.pif-footer-inset.pif-footer-inset--has-sidebar-right > footer {
		padding-right: var( --pif-footer-right-inset, 260px );
		/* Literal #f8fafc (not var(--pif-bg-soft)): that custom property is
		   declared on .pif-layout, which the footer sits outside of and so
		   can't inherit from — var() with nothing in scope to resolve it
		   computes to the property's initial value (transparent), not an
		   error, which is exactly how this went invisible before with no
		   other symptom. Has to match --pif-bg-soft's own value exactly so
		   the padding-right gutter reads as a continuation of
		   .pif-sidebar-right's own rail (below) rather than a visibly
		   different shade right at the footer boundary. */
		background: #f8fafc;
		/* .pif-sidebar-right-sticky (below) is position: sticky, which makes
		   it a *positioned* element — and by the CSS painting-order rules,
		   any positioned element (even at the default z-index: auto/0) paints
		   above a plain, non-positioned sibling regardless of DOM order. With
		   the footer left as an ordinary static element, that put the sticky
		   sidebar's own content above the footer wherever their boxes
		   overlapped on screen — normally never, but on a short page
		   .pif-center's min-height: 100vh (so the sticky sidebar always has a
		   viewport's worth of room) can put the tail end of that tall sticky
		   content and the footer in the same viewport-full near the very
		   bottom of the page, and the sidebar's content painted over the
		   footer there instead of the other way around. Explicit position +
		   z-index here gives the footer its own stacking level higher than
		   the sidebar's implicit one, so it reliably wins that overlap. */
		position: relative;
		z-index: 1;
	}
}

/* Present on <body> only during initial load (pif_render_sidebar_state_script()
   adds it pre-paint; pi-frontend.js removes it once the page — including its
   own late header/toggle re-measurements — has settled), so every transition
   this layout drives (sidebar slide, content margin, footer inset) is inert
   for that whole window. The narrow/collapsed classes already being set
   correctly before first paint means none of these should have anything to
   actually transition *from* on load in the first place, but this removes
   any doubt rather than relying on that alone — a later resize or click,
   once the marker is gone, animates normally. */
body.pif-suppress-transitions .pif-sidebar-left-wrapper,
body.pif-suppress-transitions .pif-center,
body.pif-suppress-transitions .pif-hero-wrap,
body.pif-suppress-transitions.pif-footer-inset .site-footer,
body.pif-suppress-transitions.pif-footer-inset #colophon,
body.pif-suppress-transitions.pif-footer-inset footer.site-footer,
body.pif-suppress-transitions.pif-footer-inset footer[ role="contentinfo" ],
body.pif-suppress-transitions.pif-footer-inset > footer {
	transition: none !important;
}

.pif-sb-section { padding: 8px 16px 8px 16px; box-sizing: border-box; }
.pif-sb-section__head { display: flex; align-items: center; justify-content: space-between; padding: 8px 0; }
.pif-sb-eyebrow { font-size: 13px; font-weight: 700; text-transform: uppercase; letter-spacing: 0.06em; color: var( --pif-fg-muted ); }
/* Real <button> elements — see the .pif-save-btn/.pif-share-btn note below:
   the Kadence parent theme's global `button:hover,:focus,:active{...}` rule
   otherwise leaks its own chrome into these on hover/focus/active. */
.pif-sb-collapse-btn,
.pif-sb-collapse-btn:hover,
.pif-sb-collapse-btn:focus,
.pif-sb-collapse-btn:active {
	border: 0; background: transparent; width: 22px; height: 22px; padding: 0; border-radius: 4px;
	display: flex; align-items: center; justify-content: center; cursor: pointer; color: var( --pif-fg-muted );
	-webkit-appearance: none; appearance: none; font-family: inherit; line-height: inherit; box-shadow: none; outline: none;
}
.pif-sb-collapse-btn::-moz-focus-inner { border: 0; padding: 0; }
.pif-sb-collapse-btn:hover,
.pif-sb-collapse-btn:focus,
.pif-sb-collapse-btn:active { background: var( --pif-bg-muted ); color: var( --pif-fg-2 ); }
.pif-sb-collapse-btn:focus-visible { outline: 2px solid var( --pif-accent ); outline-offset: 2px; }
.pif-sb-rule { height: 1px; background: var( --pif-border ); margin: 4px 0; }
.pif-sb-empty { font-size: 13px; color: var( --pif-fg-muted ); padding: 4px 0; }

.pif-view-link {
	display: flex;
	align-items: center;
	gap: 10px;
	padding: 10px 12px;
	border-radius: 6px;
	font-size: 14px;
	font-weight: 600;
	text-decoration: none;
	color: var( --pif-fg-2 );
	margin-bottom: 2px;
	cursor: pointer;
}
.pif-view-link:hover { background: var( --pif-bg-muted ); }
.pif-view-link.is-active { background: var( --pif-accent-light ); color: var( --pif-accent ); }

/* Shared by the filter bar's date-range and event-type panels (see below). */
.pif-custom-range-fields { padding: 10px 12px 4px; display: flex; flex-direction: column; gap: 8px; }
.pif-field-label { display: flex; flex-direction: column; gap: 4px; font-size: 12px; color: var( --pif-fg-muted ); font-weight: 600; }
.pif-field-label input { border: 1px solid var( --pif-border-strong ); border-radius: 6px; padding: 6px 8px; font-size: 13px; }

.pif-type-filter__chips { display: flex; flex-wrap: wrap; gap: 6px; margin-bottom: 8px; }
.pif-type-chip,
.pif-type-chip:hover,
.pif-type-chip:focus,
.pif-type-chip:active {
	border: 1px solid var( --pif-type ); border-radius: 16px; background: #fff; color: var( --pif-type );
	font-size: 12px; font-weight: 600; line-height: normal; box-shadow: none;
	padding: 5px 10px; cursor: pointer; opacity: 0.6;
}
.pif-type-chip.is-selected,
.pif-type-chip.is-selected:hover,
.pif-type-chip.is-selected:focus,
.pif-type-chip.is-selected:active {
	background: var( --pif-type ); color: #fff; opacity: 1;
}

.pif-following-list { display: flex; flex-direction: column; }
.pif-following-list.pif-following-collapsed .pif-following-row:not( .is-favorite ) { display: none; }
/* Unrotated = the button's "at rest" direction (sidebar expanded / following
   list showing only favorites); .is-collapsed is toggled on by the *other*
   collapsed state (see pi-frontend.js apply()/followingCollapseBtn handler),
   which is when each icon should point the opposite way. This was previously
   inverted for both buttons: #pif-sidebar-collapse-btn's chevron-left pointed
   into the content (right) while the sidebar was open, and
   #pif-following-collapse-btn's chevron-down pointed down (i.e. "expand")
   while the list was already fully expanded. */
.pif-sb-collapse-btn .pif-icon { transition: transform 0.15s ease; transform: rotate( 0deg ); }
.pif-sb-collapse-btn.is-collapsed .pif-icon { transform: rotate( 180deg ); }
.pif-following-row { display: flex; align-items: center; gap: 10px; padding: 2px 12px; border-radius: 6px; }
.pif-following-row:hover { background: var( --pif-bg-muted ); }
.pif-favorite-star,
.pif-favorite-star:hover,
.pif-favorite-star:focus,
.pif-favorite-star:active {
	border: 0; background: transparent; padding: 0; width: 16px; height: 16px; border-radius: 4px;
	display: flex; align-items: center; justify-content: center; cursor: pointer; flex: 0 0 auto; color: var( --pif-border-strong );
	-webkit-appearance: none; appearance: none; font-family: inherit; line-height: inherit; box-shadow: none; outline: none;
}
.pif-favorite-star::-moz-focus-inner { border: 0; padding: 0; }
.pif-favorite-star:hover { color: #917c55; }
.pif-favorite-star:focus-visible { outline: 2px solid var( --pif-accent ); outline-offset: 2px; }
.pif-favorite-star .pif-icon { fill: none; stroke: currentColor; }
.pif-following-row.is-favorite .pif-favorite-star,
.pif-favorite-star[ aria-pressed="true" ] { color: #917c55; }
.pif-following-row.is-favorite .pif-favorite-star .pif-icon,
.pif-favorite-star[ aria-pressed="true" ] .pif-icon { fill: currentColor; }
.pif-following-link { flex: 1; min-width: 0; display: flex; align-items: center; gap: 10px; text-decoration: none; color: var( --pif-fg-2 ); padding: 8px 0; font-size: 14px; font-weight: 500; }
.pif-following-label { flex: 1; min-width: 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; }

/* Hardening: on the single-event view's shell (PIF_Router::shell_start()),
   this sidebar ends up nested inside <body class="pise-page">, which sets a
   blanket `body.pise-page a { color: #7E3C3B; }` for that page's own content
   links (single-event.php's inline <style>). That element-plus-class
   selector (0,1,2) outranks a single class like .pif-view-link (0,1,0), so
   every sidebar link rendered maroon there regardless of state. Re-assert
   the intended colors at ID-rooted specificity so the sidebar looks
   identical no matter which page it's embedded in. */
#pif-sidebar-left .pif-view-link { color: var( --pif-fg-2 ); }
#pif-sidebar-left .pif-view-link.is-active { color: var( --pif-accent ); }
#pif-sidebar-left .pif-following-link { color: var( --pif-fg-2 ); }

/* -------------------------------------------------------------------------
   Filter/sort bar — Event type / Sort / Date range dropdowns, shown above
   the results on My Feed, search results, and topic mode (see
   PIF_Feed::shows_filter_bar()).
   ------------------------------------------------------------------------- */
.pif-filter-bar { display: flex; align-items: center; gap: 10px; margin-bottom: 16px; flex-wrap: wrap; }
.pif-filter-bar[ hidden ] { display: none; }
.pif-filter { position: relative; }

/*
 * The parent Kadence theme styles bare `button` elements globally, and its
 * `button:hover,:focus,:active{background:...}` rule (specificity 0,1,1)
 * outweighs a single class like `.pif-filter__toggle` (0,1,0) — so without
 * these repeated-class overrides, clicking a dropdown open leaves it stuck
 * showing the theme's own brand-button fill/text color instead of ours.
 * Same story for `.pif-filter__option` and `.pif-type-chip` below.
 */
.pif-filter__toggle,
.pif-filter__toggle:hover,
.pif-filter__toggle:focus,
.pif-filter__toggle:active {
	display: flex;
	align-items: center;
	gap: 6px;
	height: var( --pif-toolbar-h );
	box-sizing: border-box;
	padding: 0 10px;
	border: 1px solid var( --pif-border-strong );
	border-radius: 6px;
	background: #fff;
	color: var( --pif-fg-2 );
	font-size: 13px;
	font-weight: 600;
	line-height: normal;
	box-shadow: none;
	cursor: pointer;
}
.pif-filter__toggle:hover { background: var( --pif-bg-muted ); }
.pif-filter__toggle:focus-visible { outline: 2px solid var( --pif-accent ); outline-offset: -2px; }
.pif-filter__toggle[ aria-expanded="true" ],
.pif-filter__toggle[ aria-expanded="true" ]:hover,
.pif-filter__toggle[ aria-expanded="true" ]:focus,
.pif-filter__toggle[ aria-expanded="true" ]:active {
	background: var( --pif-accent-light );
	border-color: var( --pif-accent );
	color: var( --pif-accent );
}
.pif-filter__toggle[ aria-expanded="true" ] .pif-icon--chevron { transform: rotate( 180deg ); }
.pif-filter__toggle .pif-icon--chevron { transition: transform 0.15s ease; color: var( --pif-fg-muted ); flex-shrink: 0; }
.pif-filter__toggle .pif-icon--leading { color: var( --pif-fg-muted ); flex-shrink: 0; }
.pif-filter__toggle[ aria-expanded="true" ] .pif-icon--leading { color: var( --pif-accent ); }
.pif-filter__panel {
	position: absolute;
	top: calc( 100% + 6px );
	left: 0;
	z-index: 50;
	min-width: 200px;
	background: #fff;
	border: 1px solid var( --pif-border-strong );
	border-radius: 8px;
	box-shadow: 0 6px 20px rgba( 15, 23, 42, 0.12 );
	padding: 8px;
	box-sizing: border-box;
}
.pif-filter__panel[ hidden ] { display: none; }
.pif-filter__option,
.pif-filter__option:hover,
.pif-filter__option:focus,
.pif-filter__option:active {
	display: block;
	width: 100%;
	text-align: left;
	border: 0;
	border-radius: 6px;
	background: transparent;
	padding: 8px 10px;
	font-size: 13px;
	font-weight: 500;
	line-height: normal;
	color: var( --pif-fg-2 );
	box-shadow: none;
	cursor: pointer;
}
.pif-filter__option:hover,
.pif-filter__option:focus-visible { background: var( --pif-bg-muted ); }
.pif-filter__option.is-selected,
.pif-filter__option.is-selected:hover,
.pif-filter__option.is-selected:focus,
.pif-filter__option.is-selected:active {
	background: var( --pif-accent-light );
	color: var( --pif-accent );
	font-weight: 700;
}

/* -------------------------------------------------------------------------
   Results row + view toggle
   ------------------------------------------------------------------------- */
.pif-results-row { display: flex; align-items: center; justify-content: space-between; margin-bottom: 16px; min-height: 36px; gap: 12px; flex-wrap: wrap; }
.pif-results-row[ hidden ] { display: none; }
.pif-results-label { display: flex; align-items: center; gap: 6px; font-size: 14px; color: var( --pif-fg-muted ); flex: 1; }
.pif-view-toggle { display: flex; height: var( --pif-toolbar-h ); box-sizing: border-box; border: 1px solid var( --pif-border-strong ); border-radius: 6px; overflow: hidden; flex: 0 0 auto; }
.pif-view-toggle__btn {
	border: 0;
	background: #fff;
	color: var( --pif-fg-muted );
	height: 100%;
	padding: 0 10px;
	display: flex;
	align-items: center;
	cursor: pointer;
	/* Only .pif-view-toggle's own border-radius (clipped via overflow:hidden)
	   should round anything here — individual buttons stay square-edged,
	   including where they're active, so native <button> appearance can't
	   round an inner edge that isn't at the group's outer corner. */
	border-radius: 0;
	-webkit-appearance: none;
	appearance: none;
	font-family: inherit;
	box-shadow: none;
	outline: none;
}
.pif-view-toggle__btn::-moz-focus-inner { border: 0; padding: 0; }
/* No hover effect: stay exactly as the current (active/inactive) state. */
.pif-view-toggle__btn:hover,
.pif-view-toggle__btn:focus,
.pif-view-toggle__btn:active { background: #fff; color: var( --pif-fg-muted ); }
.pif-view-toggle__btn:focus-visible { outline: 2px solid var( --pif-accent ); outline-offset: -2px; }
.pif-view-toggle__btn.is-active,
.pif-view-toggle__btn.is-active:hover,
.pif-view-toggle__btn.is-active:focus,
.pif-view-toggle__btn.is-active:active { background: var( --pif-accent ); color: #fff; }

/* This toggle is shared with the non-topic feed, so its topic-scheme
   coloring is a separate, additive override rather than a change to the
   base rule above. Scoped to .pif-layout--topic specifically, NOT
   .pi-topics-topic-page — that second class is present on #pif-layout
   unconditionally (every pi-frontend page, not just real topic pages;
   see templates/feed.php), while pi_topics_get_topic_scheme_inline_css()
   only ever actually declares the --pi-topic-* tokens it reads when
   there's a real topic. Scoping to .pi-topics-topic-page instead (an
   earlier version of this rule did) matched the main feed too, where
   those tokens are unset — an invalid var() reference makes the
   *declaration* fall back to its initial value (transparent), not fall
   through to the base rule above, which is what made the main feed's
   toggle lose its brand-red fill entirely rather than just keep it.
   Applies at any width (not just the <900px mobile tab row this toggle
   also appears in), so the desktop .pif-results-row copy matches too. */
.pif-layout--topic .pif-view-toggle { border-color: var( --pi-topic-surface-border ); }
.pif-layout--topic .pif-view-toggle__btn:focus-visible { outline-color: var( --pi-topic-primary ); }
.pif-layout--topic .pif-view-toggle__btn.is-active,
.pif-layout--topic .pif-view-toggle__btn.is-active:hover,
.pif-layout--topic .pif-view-toggle__btn.is-active:focus,
.pif-layout--topic .pif-view-toggle__btn.is-active:active { background: var( --pi-topic-primary ); }

.pif-empty { padding: 48px 0; text-align: center; color: var( --pif-fg-muted ); font-size: 15px; }

/* Discover: topic browser (pif_render_discover_topics() in
   render-helpers.php) — categories as h2, alphabetical topic chips beneath
   each, click-to-expand description + Follow/View Topic. Self-contained
   (own colors via --pif-topic, not PI - Topics' --pi-topic-* tokens) since
   topic-page.css, where those are defined, is only enqueued on an actual
   /topic/{slug}/ page — never on /discover/. */
.pif-discover-heading { font-size: 24px; font-weight: 700; color: var( --pif-fg-1 ); margin: 0 0 20px; }
.pif-discover-category { margin-bottom: 32px; }
.pif-discover-category:last-child { margin-bottom: 0; }
.pif-discover-category__title { font-size: 19px; font-weight: 700; color: var( --pif-fg-1 ); margin: 0 0 14px; }
.pif-discover-chips { display: flex; flex-wrap: wrap; gap: 10px 8px; }
.pif-discover-topic { display: contents; }

.pif-discover-chip,
.pif-discover-chip:hover,
.pif-discover-chip:focus,
.pif-discover-chip:active {
	border: 1px solid var( --pif-topic ); border-radius: 16px; background: #fff; color: var( --pif-topic );
	font-size: 13px; font-weight: 600; line-height: normal; box-shadow: none;
	padding: 7px 14px; cursor: pointer;
}
.pif-discover-chip.is-expanded,
.pif-discover-chip.is-expanded:hover,
.pif-discover-chip.is-expanded:focus,
.pif-discover-chip.is-expanded:active {
	background: var( --pif-topic ); color: #fff;
}

/* flex-basis: 100% forces this onto its own line within the wrapping
   .pif-discover-chips row (a "flat" flex item, not a grid), so the detail
   panel appears directly under whichever chip in the row it belongs to
   rather than at the row's end. */
/* Same background/border/radius/padding as .pif-panel (the right sidebar's
   card style) so the expanded topic reads as the same kind of surface. */
.pif-discover-detail {
	flex-basis: 100%; margin: 2px 0 4px; padding: 16px; border-radius: 10px;
	background: #fff; border: 1px solid var( --pif-border );
}
.pif-discover-detail__desc { margin: 0 0 12px; font-size: 14px; line-height: 1.5; color: var( --pif-fg-3 ); }
.pif-discover-detail__actions { display: flex; flex-wrap: wrap; gap: 8px; }

.pif-discover-follow-btn,
.pif-discover-view-btn {
	display: inline-flex; align-items: center; justify-content: center;
	border-radius: 8px; font-size: 13px; font-weight: 700; line-height: 1;
	padding: 9px 16px; cursor: pointer; text-decoration: none; white-space: nowrap;
}
.pif-discover-follow-btn {
	border: 1px solid var( --pif-topic ); background: #fff; color: var( --pif-topic );
}
.pif-discover-follow-btn:hover,
.pif-discover-follow-btn:focus-visible { background: var( --pif-bg-muted ); }
.pif-discover-follow-btn.is-following { background: var( --pif-bg-muted ); }
.pif-discover-follow-btn:disabled { opacity: 0.7; cursor: default; }
.pif-discover-view-btn {
	border: 1px solid var( --pif-topic ); background: var( --pif-topic ); color: #fff;
}
.pif-discover-view-btn:hover,
.pif-discover-view-btn:focus-visible { background: var( --pif-accent-dark ); color: #fff; text-decoration: none; }

.pif-pagination-footer { padding: 24px 0; display: flex; align-items: center; justify-content: center; color: var( --pif-fg-muted ); font-size: 14px; }

/* Shown in #pif-pagination-footer while an infinite-scroll page is in
   flight (see fetchEvents() in pi-frontend.js); cleared/replaced once the
   response lands, same as the "You're all caught up" text it shares that
   slot with. */
.pif-loading-spinner {
	display: inline-block;
	width: 22px;
	height: 22px;
	border: 2.5px solid var( --pif-border-strong );
	border-top-color: var( --pif-accent );
	border-radius: 50%;
	animation: pif-spin 0.7s linear infinite;
}
@keyframes pif-spin {
	to { transform: rotate( 360deg ); }
}
@media ( prefers-reduced-motion: reduce ) {
	.pif-loading-spinner { animation-duration: 1.8s; }
}

/* -------------------------------------------------------------------------
   Month / day grouping
   ------------------------------------------------------------------------- */
.pif-month-heading { display: flex; align-items: center; gap: 16px; margin: 0 0 20px; color: var( --pif-fg-2 ); font-size: 16px; font-weight: 600; }
/* Condensed-only, same reasoning as .pif-day-badge's padding-bottom above:
   tried at the requester's suggestion to see how the tighter condensed
   list reads without it. */
.pif-month-group:has( .pif-row ) .pif-month-heading { margin-bottom: 0; }
.pif-month-rule { height: 1px; background: var( --pif-border-cool ); flex: 1; }
.pif-day-group { display: grid; grid-template-columns: 56px minmax( 0, 1fr ); column-gap: 16px; align-items: start; border-top: 1px solid var( --pif-border-cool ); padding-top: 20px; }
.pif-day-group--first { border-top: 0; padding-top: 0; }
/* Condensed rows are short enough that this 20px (tuned for the gap above
   a full card) reads as an extra, uneven-looking band above every day
   group when sorted by event date — .pif-day-group--first's own 0 above
   made that plain by contrast, since only the first group in each month
   actually sat flush. Zeroing it for every condensed group, not just the
   first, evens that out. */
.pif-day-group:has( .pif-row ) { padding-top: 0; }
/* padding-bottom (invisible — nothing renders in it) rather than a bigger
   number for `top`: a sticky element's stopping point is capped by its own
   box bottom hitting its containing block's (this grid cell's) bottom edge,
   so inflating the box height here makes it release *before* that edge —
   i.e. before the next day group's divider (border-top, below) — instead
   of riding the divider all the way. */
.pif-day-badge { display: flex; flex-direction: column; align-items: center; padding-bottom: 24px; position: sticky; top: calc( var( --pif-header-h ) + var( --pif-sticky-gap ) ); }
/* margin-top/padding-top nudge the badge's weekday/num text block down to
   sit at the vertical center of the first event row's 48px
   .pif-row__thumb, instead of flush with the top of the row — condensed
   rows only. Full cards need no such nudge: .pif-card__title sits flush
   at the top of .pif-card__detail with nothing to center against, so the
   day-group's own `align-items: start` already lands the badge flush with
   the title's own top edge on its own. This used to apply unconditionally
   to both, leaving the badge sitting visibly below the title's top edge
   in card view too. */
.pif-day-group:has( .pif-row ) .pif-day-badge { margin-top: 12px; padding-top: 2px; }
/* The 24px padding-bottom above is tuned for full cards — condensed rows
   (.pif-row) are short enough that it reads as a visible gap under the
   day-group instead of the subtle pre-divider release cushion it's meant
   to be. :has() (already relied on elsewhere, see .pifv-actions below)
   scopes this to a day-group actually rendering condensed rows, without
   needing a container-level view-mode class/attribute that doesn't
   currently exist at this level. */
.pif-day-group:has( .pif-row ) .pif-day-badge { padding-bottom: 0; }
/* Sticky (position: sticky above) rides the day badge along with the
   viewport as the visitor scrolls past its own day group, releasing at
   the next one — a "sliding" effect that's more noticeable, and reads as
   more distracting than useful, over condensed rows: many short day
   groups pass in the time it'd take to scroll through one full card, so
   the badge is constantly catching and re-sliding. Plain static
   positioning (top has no effect without sticky/relative/absolute, so
   it's cleared too rather than left meaningless) just lets it scroll
   normally with its own day group instead. */
.pif-day-group:has( .pif-row ) .pif-day-badge { position: static; top: auto; }
.pif-day-badge__weekday { color: #8f6660; font-size: 11px; font-weight: 400; letter-spacing: 0.08em; margin-bottom: 5px; text-transform: uppercase; }
.pif-day-badge__num { font-size: 24px; font-weight: 700; line-height: 1; color: var( --pif-fg-1 ); }
.pif-day-events { min-width: 0; }

/* Recently added sort, and the Popular view (always popularity-ranked —
   see PIF_Query::build() — never chronological), both render as a flat list
   rather than a date-grouped one: events aren't in date order, so the
   day/month grouping chrome is meaningless and is dropped in favor of a
   divider line between every event (and above the first / below the last).
   Scoped via the data-pif-sort / data-pif-view attributes PIF_Feed renders
   on #pif-layout, kept in sync on an AJAX-driven sort or view change by the
   .pif-filter__option[data-pif-sort] and .pif-view-link[data-pif-view]
   click handlers below. */
#pif-layout[data-pif-sort="recentlyAdded"] .pif-month-heading,
#pif-layout[data-pif-view="popular"] .pif-month-heading {
	display: none;
}
#pif-layout[data-pif-sort="recentlyAdded"] .pif-day-group,
#pif-layout[data-pif-view="popular"] .pif-day-group {
	grid-template-columns: minmax( 0, 1fr );
	column-gap: 0;
	border-top: 0;
	padding-top: 0;
}
#pif-layout[data-pif-sort="recentlyAdded"] .pif-day-badge,
#pif-layout[data-pif-view="popular"] .pif-day-badge {
	display: none;
}
#pif-layout[data-pif-sort="recentlyAdded"] #pif-results,
#pif-layout[data-pif-view="popular"] #pif-results {
	border-top: 1px solid var( --pif-border-cool );
}
/* .pif-row (condensed) already carries its own border-bottom by default,
   so only the full card needs one added here. */
#pif-layout[data-pif-sort="recentlyAdded"] .pif-card,
#pif-layout[data-pif-view="popular"] .pif-card {
	margin-bottom: 0;
	padding: 24px 0;
	border-bottom: 1px solid var( --pif-border-cool );
}
/* padding: 24px 0 above zeroes out .pif-card--featured's own horizontal
   padding (20px, all sides) at equal specificity (one class each) by
   source order alone — with the day-badge column gone in this flat-list
   mode (no date grouping to key off), that left the card's content sitting
   flush against the gold border-left with no breathing room, unlike the
   normal date-sorted view where .pif-card--featured's own padding still
   applies untouched. Restoring just the horizontal half here (24px to
   match this scope's own vertical rhythm, not the unrelated 20px the
   dated view happens to use) fixes that without undoing the border-bottom
   divider treatment above.
   margin: 12px 0 — the general .pif-card rule above zeroes out margin-bottom
   entirely (the border-bottom divider is meant to be the only separator in
   this flat list), which left a featured card's own tan background sitting
   flush against the divider line on both sides — two featured events back
   to back read as one unbroken block. Only .pif-card--featured gets margin
   back, since a plain white card has no background to visually collide
   with that same line. */
#pif-layout[data-pif-sort="recentlyAdded"] .pif-card--featured,
#pif-layout[data-pif-view="popular"] .pif-card--featured {
	padding: 24px 20px;
	margin: 12px 0;
}

/* -------------------------------------------------------------------------
   Full card
   ------------------------------------------------------------------------- */
.pif-card { margin-bottom: 40px; }
.pif-card--featured { background: rgba( 161, 136, 90, 0.06 ); border-left: 4px solid var( --pif-type ); border-radius: 0 8px 8px 0; padding: 20px; }
/* Max width is 15% below the "natural" 320px this clamp() would otherwise
   cap at (320 * 0.85 = 272) — same 15% reduction applied to the two
   narrower-range overrides below. */
.pif-card__grid { display: grid; grid-template-columns: minmax( 0, 1fr ) clamp( 160px, 28vw, 272px ); column-gap: 28px; align-items: start; }
.pif-card__detail { min-width: 0; }

/* The image column is sized off raw viewport width (28vw), but the detail
   column next to it isn't — its actual available width also depends on
   whichever of the two sidebars are currently reserving space, which
   doesn't track vw at the same rate. Two ranges where that mismatch leaves
   the detail column uncomfortably narrow relative to the (barely shrinking)
   image, each given a smaller image column than the default clamp():
   1200–1350px, where the *left* sidebar is pinned (≥1200px, see the JS
   breakpoint) and eating ~312px that the vw-based image size doesn't
   account for; and 900–1140px, where the *right* sidebar (≥900px) does the
   same. Below 1200px the left sidebar becomes an overlay and stops
   reserving layout space, and below 900px the right sidebar disappears
   entirely — both hand that space back to the detail column, so the image
   can return to its normal (larger) default size in between and below. */
@media ( min-width: 1200px ) and ( max-width: 1350px ) {
	.pif-layout:not( .pif-collapsed ) .pif-card__grid {
		grid-template-columns: minmax( 0, 1fr ) clamp( 140px, 22vw, 221px );
	}
}

@media ( min-width: 900px ) and ( max-width: 1140px ) {
	.pif-card__grid {
		grid-template-columns: minmax( 0, 1fr ) clamp( 130px, 18vw, 179px );
	}
}

/* Venue view (templates/venue.php): a third squeeze the two ranges above
   don't anticipate — its own .pifv-rail (268px + 24px gap) sits alongside
   .pif-main-col at the *same* 1200-1350px range the left sidebar is
   already pinned, so the detail column loses space to both at once there
   instead of just the one the 140-221px reduction above was sized for.
   Confirmed live: still too cramped in the narrower 1200-1300px half of
   that range specifically. Scoped to .pif-layout--venue so the plain
   feed/topic case above (no .pifv-rail to speak of) is untouched. */
@media ( min-width: 1200px ) and ( max-width: 1300px ) {
	.pif-layout--venue:not( .pif-collapsed ) .pif-card__grid {
		grid-template-columns: minmax( 0, 1fr ) clamp( 110px, 16vw, 160px );
	}
}

.pif-card__title { font-size: 24px; line-height: 1.15; color: var( --pif-fg-1 ); text-decoration: none; font-weight: 700; display: block; }
/* Re-asserts the same color, not just "no override": removing the color
   here entirely still let it turn accent/red on hover, because the theme's
   own generic `a:hover` rule (element+pseudo-class, 0,1,1) outranks the
   *base* `.pif-card__title` rule (single class, 0,1,0) — the base color
   only wins at rest, not on hover. A hover-scoped rule of our own
   (0,2,0, class+pseudo-class) is what's needed to keep it, same story as
   the .pif-sb-collapse-btn/.pif-favorite-star hardening above. */
.pif-card__title:hover { color: var( --pif-fg-1 ); text-decoration: underline; }
.pif-card__time { font-size: 14px; margin-top: 6px; color: var( --pif-fg-muted-2 ); font-weight: 700; }
.pif-card__venue { margin: 4px 0 14px; font-size: 14px; color: var( --pif-fg-3 ); display: flex; align-items: baseline; gap: 5px; }
.pif-card__venue .pif-icon { position: relative; top: 2px; }
/* Same type scale/color as the rest of this section's text (.pif-card__venue/
   .pif-card__desc), just bold — not the title's much larger scale. */
.pif-card__cost { margin: 0 0 14px; display: flex; align-items: baseline; gap: 5px; font-size: 14px; color: var( --pif-fg-3 ); font-weight: 700; }
.pif-card__cost .pif-icon { position: relative; top: 2px; }
/* Shared by the card and condensed row's venue name (see .pif-row__venue
   below) — deliberately the same look as the plain text it replaced,
   picking up whichever color its parent (.pif-card__venue / .pif-row__venue)
   already sets rather than a link color of its own, and gaining only an
   underline on hover. Re-asserting `color: inherit` in the hover rule too,
   not just leaving it alone, for the same reason .pif-card__title:hover
   does above: the theme's own generic `a:hover` rule (element+pseudo-class,
   0,1,1) otherwise outranks this class's base, unhovered color (single
   class, 0,1,0) — that base color only wins at rest. */
.pif-venue-link { color: inherit; text-decoration: none; }
.pif-venue-link:hover,
.pif-venue-link:focus-visible { color: inherit; text-decoration: underline; }
/* Icon + paragraph(+ conditional "See more") side by side, info icon
   top-aligned against the paragraph's first line rather than centered on
   the whole (possibly 3-line-clamped) block — matches .pif-card__venue's
   own icon treatment just above. .pif-card__desc-col (not the row) is
   what data-pif-clamp's "See more" button needs to be data-pif-see-more's
   own immediate next sibling of (see initClamps() in pi-frontend.js) —
   nesting both under the icon would put a non-sibling element between
   them. */
.pif-card__desc-row { display: flex; align-items: flex-start; gap: 6px; }
.pif-card__desc-row .pif-icon { position: relative; top: 4px; flex-shrink: 0; }
/* flex: 1 1 0% (not the flex-item default 0 1 auto) — without an explicit
   grow/zeroed basis, this column's width comes from its own content's
   hypothetical size instead of simply filling whatever space the icon
   doesn't need, which pi-frontend.js's initClamps() then measures
   .pif-card__desc's scrollHeight/clientHeight against to decide whether
   "See more" is needed at all. Depending on a given event's description
   length, that content-based width could land narrower *or* wider than
   this row actually has available, making the clamp-vs-overflow check
   (and therefore whether "See more" shows/works at all) inconsistent
   from one event to the next — full-width, deterministic sizing (as it
   was before the icon made this a flex row) is what initClamps() needs
   to measure reliably. */
.pif-card__desc-col { flex: 1 1 0%; min-width: 0; }
.pif-card__desc { font-size: 14px; color: var( --pif-fg-3 ); margin: 0; max-width: 72ch; line-height: 1.5; display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 3; overflow: hidden; }
.pif-card__desc.pif-expanded { -webkit-line-clamp: unset; overflow: visible; }
.pif-card__see-more { margin-top: 2px; }
/* Topic-scoped, not a change to .pif-link-btn itself (see the
   Save/Share/Comments note below for why): that class also styles the
   left sidebar's "Clear" button and the type-filter panel's "Deselect
   all", neither of which should shift color just because the event list
   happens to be on a topic page. */
.pif-layout--topic .pif-card__see-more,
.pif-layout--topic .pif-card__see-more:hover,
.pif-layout--topic .pif-card__see-more:focus,
.pif-layout--topic .pif-card__see-more:active {
	color: var( --pi-topic-primary );
}
.pif-layout--topic .pif-card__see-more:hover { color: var( --pi-topic-primary-hover ); }
/* No min-height on the box itself when a real photo is present: that used to
   force a 120px floor while the img sized itself independently via
   `height:auto`, so any photo that rendered shorter than 120px left the
   --pif-bg-muted background showing through above/below as gray
   letterboxing. Instead the box (block, no flex) simply wraps the in-flow
   img at its own natural rendered height — proportions untouched, nothing
   to letterbox. `.pif-card__image--empty` (render-helpers.php, no promo
   image) is the one case that still wants a fixed-height, centered box for
   the placeholder icon. container-type below lets the img's own max-height
   read as a multiple of ITS width via cqw, capping (and only then cropping,
   via object-fit:cover) photos taller than 4x their width — pathologically
   tall images shouldn't blow out the card, but nothing under that ratio is
   touched. */
.pif-card__image { position: relative; width: 100%; container-type: inline-size; background: var( --pif-bg-muted ); border: 1px solid var( --pif-border ); overflow: hidden; }
.pif-card__image--empty { min-height: 120px; display: flex; align-items: center; justify-content: center; }
/* object-position: without it, cropping (the max-height cap above) is
   center-anchored and cuts off the top of the photo along with the bottom —
   event promo images are usually top-weighted (poster text, a flyer's
   header), so anchor the crop to the top instead. */
.pif-card__image img { display: block; width: 100%; height: auto; max-height: 400cqw; object-fit: cover; object-position: center top; }

/* Event badges row (pif_render_event_badges() in render-helpers.php) —
   Featured, Just Added, Past Event, and any future type share this same
   pill shape/scale; only background/color/border vary per type. */
.pif-badges { display: flex; flex-wrap: wrap; gap: 6px; margin-bottom: 8px; width: fit-content; }
.pif-badges--sm { gap: 4px; margin-bottom: 2px; }
.pif-badge { display: inline-flex; align-items: center; gap: 6px; padding: 6px 14px; border-radius: 999px; border: 1px solid transparent; font-size: 13px; font-weight: 700; line-height: 1; }
.pif-badge--sm { padding: 2px 7px; font-size: 10px; gap: 4px; }
/* Matches .pise-badge--featured (PI - Single Event's own header pill) — same
   gradient, shape, and type scale, so a Featured event reads identically
   whether seen in this list or on its own single-event page. */
.pif-badge--featured { background: linear-gradient( 135deg, #c79a3b 0%, #a1885a 50%, #8a6d3b 100% ); color: #fff; }
.pif-badge--just-added { background: #fff; color: var( --pif-accent ); border-color: var( --pif-accent ); }
.pif-badge--past { background: #d1d5db; color: var( --pif-fg-1 ); border-color: var( --pif-fg-1 ); }

/* Chip pills themselves are .pi-shortcodes__event-chip (theme's
   tribe-events/event-chips.css, enqueued in pif_enqueue_assets()) so they
   match the rest of the site (single-event view, topic pages) exactly. That
   stylesheet's own <a>-specific color/hover rules are scoped to a
   .tribe-common or .tribe-events ancestor, though — present on the pages
   that first used it, but never on this plugin's markup — so harden the
   ones rendered as real links (render-helpers.php) here instead of relying
   on inheriting unstyled/theme-default link color and underline. */
.pif-tags { display: flex; gap: 8px; margin-top: 10px; flex-wrap: wrap; }
.pif-tags a.pi-shortcodes__event-chip,
.pif-tags a.pi-shortcodes__event-chip:hover,
.pif-tags a.pi-shortcodes__event-chip:focus,
.pif-tags a.pi-shortcodes__event-chip:visited,
.pif-tags a.pi-shortcodes__event-chip:active {
	color: #fff;
	text-decoration: none;
}

.pif-actions { display: flex; gap: 18px; align-items: center; margin-top: 14px; flex-wrap: wrap; }
.pif-save-btn,
.pif-share-btn,
.pif-comments-link {
	border: 0; background: transparent; color: var( --pif-fg-muted ); font-size: 13px; font-weight: 600;
	display: flex; align-items: center; gap: 6px; cursor: pointer; padding: 0; text-decoration: none;
}
/* .pif-save-btn / .pif-share-btn are real <button> elements — unlike the
   <a>-based comments link, they carry native OS button chrome (appearance,
   font, a hover/active fill in some browsers) that the reset above doesn't
   fully strip, which is what made their hover state look off. */
.pif-save-btn,
.pif-share-btn {
	-webkit-appearance: none;
	appearance: none;
	font-family: inherit;
	line-height: inherit;
	box-shadow: none;
	outline: none;
}
.pif-save-btn::-moz-focus-inner,
.pif-share-btn::-moz-focus-inner { border: 0; padding: 0; }
.pif-save-btn:hover,
.pif-save-btn:focus,
.pif-save-btn:active,
.pif-share-btn:hover,
.pif-share-btn:focus,
.pif-share-btn:active,
.pif-comments-link:hover {
	background: transparent;
	color: var( --pif-accent );
}
.pif-save-btn:focus-visible,
.pif-share-btn:focus-visible { outline: 2px solid var( --pif-accent ); outline-offset: 2px; }
.pif-save-btn.is-saved { color: var( --pif-accent ); font-weight: 700; }
.pif-save-btn .pif-icon { fill: none; stroke: currentColor; }
.pif-save-btn.is-saved .pif-icon { fill: currentColor; }

/* Topic-scoped hover color only (not focus-visible/is-saved — left as the
   plugin default, matching what was actually asked for). --pif-accent
   above stays the main feed's default; .pif-layout--topic (real topic
   pages only — see the .pif-view-toggle note above for why not
   .pi-topics-topic-page) layers this on top rather than changing it. */
.pif-layout--topic .pif-save-btn:hover,
.pif-layout--topic .pif-save-btn:focus,
.pif-layout--topic .pif-save-btn:active,
.pif-layout--topic .pif-share-btn:hover,
.pif-layout--topic .pif-share-btn:focus,
.pif-layout--topic .pif-share-btn:active,
.pif-layout--topic .pif-comments-link:hover {
	color: var( --pi-topic-primary );
}

/* -------------------------------------------------------------------------
   Condensed rows
   ------------------------------------------------------------------------- */
.pif-row { display: flex; align-items: center; gap: 16px; padding: 12px 4px; border-bottom: 1px solid var( --pif-border ); }
/* Date-grouped display (any sort/view except recentlyAdded's and Popular's
   flat lists, which want a divider under every row — see the block below):
   the last event of each day doesn't need its own bottom line, since the
   next day's top divider (or the next month's separator rule) already marks
   the boundary. Left as-is that reads as a doubled line under the last
   event of a day, and especially under the last event of a month, right
   above the month separator's own rule. */
#pif-layout:not( [data-pif-sort="recentlyAdded"] ):not( [data-pif-view="popular"] ) .pif-day-events > .pif-row:last-child {
	border-bottom: 0;
}
/* ...except the very last row in the whole (possibly infinite-scrolled)
   results list, which still wants a single full-width line under it. The
   nested :last-child chain only ever matches the literal last .pif-row in
   the DOM, so this naturally follows the "last" row as more pages load in. */
#pif-results .pif-month-group:last-child .pif-day-group:last-child .pif-day-events > .pif-row:last-child {
	border-bottom: 1px solid var( --pif-border );
}
/* Condensed counterpart to .pif-card--featured — same tan tint + left
   accent, scaled down for the row's tighter padding. */
.pif-row--featured { background: rgba( 161, 136, 90, 0.06 ); border-left: 4px solid var( --pif-type ); border-radius: 0 6px 6px 0; padding-left: 8px; }
.pif-row__thumb { width: 48px; height: 48px; flex: 0 0 auto; border-radius: 6px; background: var( --pif-bg-muted ); border: 1px solid var( --pif-border ); display: flex; align-items: center; justify-content: center; overflow: hidden; }
.pif-row__thumb img { width: 100%; height: 100%; object-fit: cover; object-position: center top; }
.pif-row__main { display: flex; flex-direction: column; gap: 2px; flex: 1 1 auto; min-width: 0; }
.pif-row__title { font-size: 15px; color: var( --pif-fg-1 ); text-decoration: none; font-weight: 700; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; }
.pif-row__title:hover { color: var( --pif-fg-1 ); text-decoration: underline; }
/* Plain colored text at rest; on hover/focus it grows into the same pill
   used for the topic chip elsewhere (.pi-shortcodes__event-chip--topic —
   colors matched from tribe-events/event-chips.css) so the row stays
   compact until a visitor actually means to follow the link. The negative
   margin offsets the padding added on hover so the pill expands around the
   text in place instead of nudging the row's layout. */
.pif-row__topic { display: inline-flex; align-items: center; color: var( --pif-topic ); font-size: 12px; font-weight: 700; width: fit-content; text-decoration: none; padding: 3px 8px; margin: -3px -8px; border-radius: 16px; transition: background-color 0.15s ease, color 0.15s ease; }
.pif-row__topic:hover,
.pif-row__topic:focus-visible {
	background-color: #76403e;
	color: #fff;
}
.pif-row__venue { font-size: 13px; color: var( --pif-fg-3 ); flex: 0 0 auto; white-space: nowrap; display: flex; align-items: center; gap: 4px; }
.pif-row__save {
	border: 0; background: transparent; color: var( --pif-fg-muted ); cursor: pointer; padding: 0; flex: 0 0 auto;
	-webkit-appearance: none; appearance: none; font-family: inherit; box-shadow: none; outline: none;
	/* .pif-row__comments (a span) is display:flex + align-items:center,
	   which sizes its box tightly around the icon; a bare <button> instead
	   inherits its line-height as an inline-block "strut", leaving the icon
	   sitting inside a taller box than its sibling and reading as
	   vertically offset from it once the row aligns items to the top
	   (align-items: flex-start, mobile below) rather than averaging small
	   height differences out via the row's own center alignment. */
	display: flex;
	align-items: center;
}
.pif-row__save::-moz-focus-inner { border: 0; padding: 0; }
.pif-row__save:hover,
.pif-row__save:focus,
.pif-row__save:active { background: transparent; color: var( --pif-accent ); }
.pif-row__save:focus-visible { outline: 2px solid var( --pif-accent ); outline-offset: 2px; }
.pif-row__save.is-saved { color: var( --pif-accent ); }
.pif-row__save .pif-icon { fill: none; stroke: currentColor; }
.pif-row__save.is-saved .pif-icon { fill: currentColor; }
.pif-row__comments { color: var( --pif-fg-muted ); font-size: 12px; font-weight: 600; display: flex; align-items: center; gap: 4px; flex: 0 0 auto; }

/* -------------------------------------------------------------------------
   Map
   ------------------------------------------------------------------------- */
.pif-map-container .pi-shortcodes__map-wrapper { height: calc( 100vh - var( --pif-header-h ) - 120px ); border-radius: 8px; overflow: hidden; margin-bottom: 32px; }

/* The mobile "can't use the real Fullscreen API" fallback (pi-map.js /
   map.css's own .pi-shortcodes__map-wrapper--fullscreen-fallback, used on
   iOS Safari) sets height:auto + border-radius:0 so its own top/bottom
   insets (below the header, all the way to the screen's bottom edge) are
   what determine its height — but that rule is only one class (0,1,0), and
   the plain rule above is two classes (0,2,0), so the cascade picked *its*
   fixed calc() height regardless of which stylesheet loaded later: in
   fullscreen mode that fixed height still reserved the header + 120px this
   container normally leaves room for above/below itself, on top of a
   position:fixed box already offset below the header — doubling that gap
   and leaving fullscreen mode short of the actual bottom of the screen.
   Rounded corners had the same problem at what's supposed to be the
   literal edge of the viewport. margin-bottom is reset too, since this
   element has no trailing content below itself to reserve space for once
   fixed-positioned. Same specificity trick already used elsewhere in this
   file to win a fight against another stylesheet — just re-asserting the
   fallback's own intended values at a specificity this container's rules
   can't beat. */
@media ( max-width: 767px ) {
	.pif-map-container .pi-shortcodes__map-wrapper.pi-shortcodes__map-wrapper--fullscreen-fallback {
		height: auto;
		border-radius: 0;
		margin-bottom: 0;
	}
}

/* -------------------------------------------------------------------------
   Right sidebar
   ------------------------------------------------------------------------- */
/* Two boxes doing two different jobs (see templates/partials/sidebar-right.php):
   this outer rail is a plain, non-sticky flex item — `align-self: stretch`
   overrides .pif-center's own `align-items: flex-start` just for this child,
   so the rail's height always matches whichever of it or .pif-main is
   taller, the same automatic stretching flexbox already does for any
   ordinary row. Its background is what reads as "the sidebar's space"
   continuing all the way down the page, however long the event list
   actually scrolls — rather than only as tall as one viewport, which is
   as far as the sticky content below can ever visibly reach. */
.pif-sidebar-right {
	width: 260px; flex: 0 0 auto; display: none; align-self: stretch;
	/* bg-soft, not bg-muted: .pif-layout's own background — including the
	   top/bottom padding above and below .pif-center, and the gap below the
	   hero on topic pages — is already bg-soft, uninterrupted. bg-muted is a
	   visibly darker shade, so painting the rail with it made the rail's own
	   box (only as tall as .pif-center's row) read as a harder-edged block
	   sitting on top of the lighter page background, with the "gap" everyone
	   was seeing above/below the rail actually just being that same bg-soft
	   showing through past the rail's edges. Matching the token means every
	   part of .pif-layout not otherwise painted white (a .pif-panel, the
	   hero) is one continuous color, so there's no seam left to see — no
	   separate top/bottom "extend the rail further" fix needed. */
	background: var( --pif-bg-soft );
	/* Extends the rail's own background 28px above its real top edge — into
	   .pif-layout's own 28px padding-top (see that rule above), landing the
	   rail flush with the header — via box-shadow rather than moving the
	   box itself. An earlier version used `position: relative; top: -28px`
	   for this, which shifted the box's *painted* position up without
	   moving its *reserved* one: align-self: stretch (above) sizes this
	   box to match .pif-main's real height starting from its real
	   (unshifted) top, so pulling only the paint position up by 28px left
	   the box's bottom edge — and therefore the rail's own background —
	   ending 28px short of .pif-main's actual bottom, every time,
	   regardless of scroll position. That shortfall was only ever
	   invisible by coincidence: it happened to fall on .pif-layout's own
	   matching bg-soft background, so it read as fine right up until
	   anything else (the footer starting sooner than expected, a
	   different background nearby) made the gap fall somewhere that
	   wasn't already the same color.
	   box-shadow paints a solid, unblurred copy of this box's own
	   rectangle offset 28px upward (spread 0, so it's pixel-identical in
	   width/height) without moving or resizing the real box at all — so
	   this can't touch align-self: stretch's height math, .pif-center's
	   horizontal centering, or the sticky child's containing block the
	   way changing the box's own margin/position would. */
	box-shadow: 0 -28px 0 0 var( --pif-bg-soft );
}
/* Topic pages: .pif-center sits below .pif-hero-wrap, not directly below
   .pif-layout's own padding-top (that 28px is spent above the hero, which
   isn't moving) — the only gap between the hero and the sidebar is
   .pif-hero-wrap's own margin-bottom: 24px (see that rule above), so this
   overrides the plain rule's -28px shadow with the smaller offset that
   actually matches it, landing the rail flush with the bottom of the hero
   instead of 24px below it. */
.pif-layout--topic .pif-sidebar-right {
	box-shadow: 0 -24px 0 0 var( --pif-bg-soft );
}
@media ( min-width: 900px ) {
	.pif-sidebar-right { display: block; }
}

/* The part that actually needs to *stick* to the viewport and scroll
   independently of the page — unchanged from how the single, combined
   element used to behave, just moved onto its own inner box instead of
   also being the thing responsible for how tall the outer rail is (which
   used to leave the rail only ever as tall as one viewport, cutting off
   short of the bottom of a long page).

   max-height capped to the viewport (not some shorter, more conservative
   value) + overflow-y so its own content is what determines whether it
   ever needs to scroll: content that fits a screenful (the common case)
   renders in full, and content that's genuinely taller than the viewport
   scrolls independently of the page instead of either clipping outright or
   fighting the page's own scroll for control while position:sticky holds
   this in place. The scrollbar itself is suppressed the same way the left
   sidebar's is (still fully scrollable via wheel/trackpad/touch/keyboard) —
   `scrollbar-width: none` (Firefox) + the ::-webkit-scrollbar rule below
   (Chrome/Safari/Edge) cover every evergreen engine.

   The breathing room above the first panel and below the last one is
   padding on this box itself, not `top`/`max-height` reserving space
   outside it — that space would sit *outside* the scrollable box, so it'd
   never scroll away, just sitting there as dead white space above and
   below the content while scrolling. Starting flush at the header and
   sizing to the full remaining viewport, then pushing the content in from
   both edges with padding instead, puts that same visual space *inside*
   the scrollable area, where it scrolls with everything else — while
   still leaving short content (fewer/no events elsewhere on the page
   shouldn't change this) sized to fit itself rather than stretched to
   fill the box, since this is `max-height`, not `height`. `box-sizing:
   border-box` is what keeps the padding inside that max-height budget
   instead of adding to it. */
.pif-sidebar-right-sticky {
	display: flex; flex-direction: column; gap: 20px;
	box-sizing: border-box;
	position: sticky; top: var( --pif-header-h );
	max-height: calc( 100vh - var( --pif-header-h ) );
	padding: var( --pif-sticky-gap ) 0;
	overflow-y: auto;
	scrollbar-width: none;
}
.pif-sidebar-right-sticky::-webkit-scrollbar { display: none; }
.pif-topic-actions { display: flex; flex-wrap: nowrap; align-items: center; gap: 6px; margin-top: 1px; margin-bottom: 12px; width: 100%; box-sizing: border-box; }
/* Override PI - Topics' own (larger, hero-overlay-sized) button padding/font
   so both fit on one line at the sidebar's width, matching the view
   toggle's height so the two rows read as aligned. Equal flex-grow makes
   the pair fill the full row width (matching the sidebar below them)
   instead of sitting at their natural (smaller) size. */
.pif-topic-actions .pi-topic-follow-btn,
.pif-topic-actions .pi-topic-submit-btn {
	flex: 1 1 0;
	min-width: 0;
	height: var( --pif-toolbar-h );
	padding: 0 10px;
	font-size: 12px;
	box-sizing: border-box;
	justify-content: center;
	white-space: nowrap;
	overflow: hidden;
	text-overflow: ellipsis;
}
.pif-topic-actions .pi-topic-submit-btn { gap: 4px; }
.pif-panel { background: #fff; border: 1px solid var( --pif-border ); border-radius: 10px; padding: 16px; }
.pif-panel__heading { font-size: 13px; font-weight: 700; text-transform: uppercase; letter-spacing: 0.06em; color: var( --pif-fg-muted ); margin-bottom: 10px; }
.pif-panel__heading-row { display: flex; align-items: center; justify-content: space-between; margin-bottom: 10px; }
.pif-panel-item { display: block; text-decoration: none; padding: 10px 0; border-top: 1px solid var( --pif-border ); }
.pif-panel-item:first-child { border-top: 0; }
.pif-panel-item__eyebrow { font-size: 11px; font-weight: 700; color: var( --pif-topic ); margin-bottom: 3px; }
.pif-panel-item__title { font-size: 14px; color: var( --pif-fg-1 ); font-weight: 700; line-height: 1.3; }
.pif-panel-item__meta { font-size: 12px; color: var( --pif-fg-muted ); margin-top: 3px; }

/* Matches .pif-panel's own border color above — PI - Topics' own
   .pi-topic-card (templates/partials/topic-sidebar.php, rendered here in
   topic mode via pif_render_right_sidebar()) had none of its own
   (topic-page.css only sets background/radius/padding on it), so the
   topic-mode sidebar and the feed's own right-sidebar panels read as two
   different components rather than the same one. Scoped to elements
   actually inside this layout, not a blanket override of pi-topics' own
   class — that plugin's other (now effectively unused, pre-pi-frontend)
   direct rendering of this same markup is left alone. */
.pif-layout .pi-topic-card {
	border: 1px solid var( --pif-border );
}

@media ( min-width: 900px ) {
	/* .pif-sidebar-right now stretches to match .pif-center's own height
	   (align-self: stretch, above) instead of needing a height floor
	   itself — but .pif-center is *still* only ever as tall as the taller
	   of its two children in the first place, and when .pif-main's content
	   is short (few or no matching events — the exact case that came up
	   testing a lightly-populated topic) neither child has much height to
	   offer, leaving both the row and the rail short of a full viewport
	   with nothing beyond their own content for the sticky math inside
	   .pif-sidebar-right-sticky to place itself against. Guaranteeing at
	   least one viewport's worth of height here — regardless of how far
	   down the page this row actually starts, since `top` on the sticky
	   content is measured against the viewport either way — gives it that
	   room on every view alike. Scoped to the same breakpoint the sidebar
	   itself only shows at (above), so this never adds empty space below
	   short content on narrower widths where there's no sidebar to make
	   room for. */
	/* var( --pif-sidebar-min-h, ... ) instead of the plain calc() alone:
	   pi-frontend.js's scroll handler raises that property while infinite
	   scroll still has more pages to fetch, keeping this floor comfortably
	   ahead of the user's current scroll position instead of it sitting
	   fixed at exactly one viewport. Without that, the *one-time* moment
	   .pif-main's real (growing) content first grows past this floor —
	   this rule stops being what determines .pif-center's height, .pif-main's
	   own now-taller content is — .pif-sidebar-right (align-self: stretch,
	   matching .pif-center) grows to match, handing
	   .pif-sidebar-right-sticky's position:sticky containment more room to
	   work with than it had a moment earlier. Sticky positioning
	   re-evaluates continuously, so a sticky box already sitting at its
	   container's old, shorter bottom edge (because the user had scrolled
	   far enough for it to release and follow the page, the normal
	   behavior for a short page) would suddenly find itself back inside
	   the "should still be stuck" range the instant the container grew,
	   snapping back up to stuck-at-header position — a jarring jump timed
	   to whenever an infinite-scroll page happened to land. The plain
	   calc() is still the fallback here (pages before JS has run, or with
	   no infinite scroll to speak of), so nothing changes for those. */
	.pif-center {
		min-height: var( --pif-sidebar-min-h, calc( 100vh - var( --pif-header-h ) ) );
	}
}

/* -------------------------------------------------------------------------
   Topic mode, below 900px: reach the right sidebar's content
   -------------------------------------------------------------------------
   .pif-sidebar-right only ever shows at min-width:900px (above) — below
   that, its Follow/Submit row and topic-details card are simply
   unreachable. Everything here is that content's mobile-only stand-in:
   a duplicate actions row (see pif_render_topic_actions() 'mobile'
   variant), the existing filter bar made collapsible, and a Feed/Topic
   Details tab switch (see templates/feed.php). Every rule below is scoped
   to .pif-layout--topic (topic mode only — this plugin's non-topic feed
   already shows an unrelated sidebar down to no width at all) and, except
   for the two "hidden by default" baselines, to max-width:899px (the exact
   complement of the real sidebar's own min-width:900px) — so none of it
   shows on the non-topic feed, and all of it self-corrects back to the
   desktop baseline on any resize past 900px with no JS resize listener
   needed: the class pi-frontend.js toggles for the active tab only means
   anything inside that same media query. */
.pif-mobile-topic-actions,
.pif-mobile-filters-toggle,
.pif-mobile-view-switch {
	display: none;
}

/* The real sidebar already shows this content at ≥900px, so this second
   copy (rendered for the "Topic Details" tab specifically) stays hidden
   there unconditionally — not just outside the media query below, since a
   lingering .pif-mobile-details-active class from a narrower viewport
   should never resurrect it once that query stops applying. */
#pif-mobile-panel-details {
	display: none;
}

@media ( max-width: 899px ) {
	.pif-layout--topic .pif-mobile-topic-actions {
		display: flex;
		gap: 12px;
		flex-wrap: wrap;
		margin-bottom: 16px;
	}

	.pif-layout--topic .pif-mobile-filters-toggle,
	.pif-layout--topic .pif-mobile-filters-toggle:hover,
	.pif-layout--topic .pif-mobile-filters-toggle:focus,
	.pif-layout--topic .pif-mobile-filters-toggle:active {
		display: inline-flex;
		align-items: center;
		gap: 6px;
		border: 0;
		background: transparent;
		/* --pi-topic-primary/-hover (set inline per-topic — see
		   pi_topics_get_topic_scheme_inline_css()), not --pif-accent: this
		   toggle only ever renders in topic mode, so it should read as part
		   of that topic's own color scheme, same as the Follow button. */
		color: var( --pi-topic-primary );
		font-size: 13px;
		font-weight: 600;
		padding: 0;
		margin-bottom: 12px;
		cursor: pointer;
		-webkit-appearance: none;
		appearance: none;
		font-family: inherit;
		box-shadow: none;
	}
	.pif-layout--topic .pif-mobile-filters-toggle::-moz-focus-inner {
		border: 0;
		padding: 0;
	}
	.pif-layout--topic .pif-mobile-filters-toggle:hover { color: var( --pi-topic-primary-hover ); }
	.pif-layout--topic .pif-mobile-filters-toggle:focus-visible {
		outline: 2px solid var( --pi-topic-primary );
		outline-offset: 2px;
	}
	.pif-layout--topic .pif-mobile-filters-toggle .pif-icon--chevron {
		transition: transform 0.15s ease;
	}
	.pif-layout--topic .pif-mobile-filters-toggle[ aria-expanded="true" ] .pif-icon--chevron {
		transform: rotate( 180deg );
	}

	/* Collapsed by default (no JS-computed pre-paint state needed, unlike
	   the left sidebar's narrow/collapsed classes — this has no other-width
	   state to disagree with on first paint, just a plain default). */
	.pif-layout--topic:not( .pif-mobile-filters-expanded ) #pif-filter-bar {
		display: none;
	}

	.pif-layout--topic .pif-mobile-view-switch {
		display: flex;
		align-items: center;
		justify-content: space-between;
		gap: 12px;
		margin-bottom: 16px;
	}

	/* .pif-mobile-view-switch (above) already carries its own copy of the
	   view-mode toggle (see pif_render_view_toggle() / templates/feed.php)
	   — .pif-results-row's copy, right next to the results count, would
	   otherwise show a second, redundant set of the same three buttons. */
	.pif-layout--topic .pif-results-row .pif-view-toggle {
		display: none;
	}

	.pif-layout--topic .pif-mobile-tabs {
		display: flex;
		height: var( --pif-toolbar-h );
		box-sizing: border-box;
		/* --pi-topic-surface-border, not --pif-border-strong: matches
		   .pi-topic-card's own border (see .pif-layout .pi-topic-card in
		   the Right sidebar section above), so this reads as belonging to
		   the topic's own color scheme rather than the plugin's neutral
		   default. */
		border: 1px solid var( --pi-topic-surface-border );
		border-radius: 6px;
		overflow: hidden;
		flex: 0 0 auto;
	}
	.pif-layout--topic .pif-mobile-tab,
	.pif-layout--topic .pif-mobile-tab:hover,
	.pif-layout--topic .pif-mobile-tab:focus,
	.pif-layout--topic .pif-mobile-tab:active {
		border: 0;
		border-right: 1px solid var( --pi-topic-surface-border );
		background: #fff;
		color: var( --pif-fg-muted );
		height: 100%;
		padding: 0 12px;
		display: flex;
		align-items: center;
		cursor: pointer;
		font-size: 13px;
		font-weight: 600;
		white-space: nowrap;
		-webkit-appearance: none;
		appearance: none;
		font-family: inherit;
		box-shadow: none;
		outline: none;
	}
	.pif-layout--topic .pif-mobile-tab::-moz-focus-inner {
		border: 0;
		padding: 0;
	}
	.pif-layout--topic .pif-mobile-tab:last-child { border-right: 0; }
	.pif-layout--topic .pif-mobile-tab:focus-visible { outline: 2px solid var( --pi-topic-primary ); outline-offset: -2px; }
	.pif-layout--topic .pif-mobile-tab.is-active,
	.pif-layout--topic .pif-mobile-tab.is-active:hover,
	.pif-layout--topic .pif-mobile-tab.is-active:focus,
	.pif-layout--topic .pif-mobile-tab.is-active:active {
		background: var( --pi-topic-primary );
		color: #fff;
	}

	.pif-layout--topic.pif-mobile-details-active #pif-mobile-panel-feed {
		display: none;
	}
	.pif-layout--topic.pif-mobile-details-active #pif-mobile-panel-details {
		display: block;
	}

	/* The view-mode toggle (Full/Condensed/Map) only means anything for
	   the event list, not the topic-details card — hide it once that tab
	   is active rather than leaving three inert-looking buttons next to
	   the tabs. */
	.pif-layout--topic.pif-mobile-details-active .pif-mobile-view-switch .pif-view-toggle {
		display: none;
	}

	/* Scoped to this mobile tab panel specifically — the same content
	   rendered in the desktop right sidebar is already narrower than this
	   (260px) and shouldn't also get capped/centered here. */
	#pif-mobile-panel-details .pi-topic-sidebar {
		max-width: 500px;
		margin: 0 auto;
	}
}

/* -------------------------------------------------------------------------
   Responsive
   ------------------------------------------------------------------------- */
@media ( min-width: 801px ) and ( max-width: 1199px ) {
	/* Wider than the default static 32px (see --pif-sidebar-collapsed-w's
	   declaration above) specifically in this band. Only .pif-center and
	   .pif-hero-wrap read this variable — both are page content inside
	   #pif-layout, entirely separate from the theme header markup
	   get_header() renders — so widening it here only ever pushes the
	   event list content itself over; the header stays exactly as wide as
	   it already was. */
	.pif-layout {
		--pif-sidebar-collapsed-w: 76px;
	}
}

@media ( max-width: 800px ) {
	/* Below 800px, reposition the *same* toggle button (still the one
	   .pif-sidebar-toggle bound in initSidebar() — nothing new is inserted
	   or separately wired up) so it reads as sitting in the header row,
	   mirroring Kadence's own mobile-menu toggle on the right side of that
	   row, instead of floating over the page content below it. A previous
	   attempt here instead injected a brand-new button directly into the
	   theme's own header markup, which meant guessing at Kadence's exact
	   structure (it wasn't found reliably) and put the button inside a DOM
	   subtree the theme's own header JS also touches — the most likely
	   explanation for it visibly flickering on click. Moving *this* button
	   with plain `position: fixed` avoids both: no theme markup to locate,
	   and nothing else on the page has a reason to touch it.
	   All three custom properties below are measured live off Kadence's
	   real toggle button (see initToggleOffset()) rather than guessed —
	   two earlier passes at guessing (a fixed left offset, then a
	   header-height-based vertical center) each landed slightly wrong for
	   the theme's actual layout. The literal pixel fallbacks are only for
	   the instant before that script runs, or if it can't find that button
	   or the logo at all. */
	.pif-layout.pif-collapsed .pif-sidebar-toggle {
		top: var( --pif-toggle-top, calc( var( --pif-header-h ) / 2 ) );
		left: var( --pif-toggle-left, 16px );
		transform: translateY( -50% );
		width: var( --pif-toggle-size, 32px );
		height: var( --pif-toggle-size, 32px );
		border: 0;
		background: transparent;
		border-radius: 0;
	}
	.pif-layout.pif-collapsed .pif-sidebar-toggle:hover,
	.pif-layout.pif-collapsed .pif-sidebar-toggle:focus,
	.pif-layout.pif-collapsed .pif-sidebar-toggle:active {
		background: transparent;
	}

	/* Confirmed against the live site's actual markup: Kadence renders the
	   mobile logo with zero padding of its own (`.site-branding{padding:0}`),
	   flush against the header row's left edge — there's no gap at all for
	   the button above to sit in before it without the two overlapping,
	   which is what an earlier, unreserved version of this fix ran into.
	   Carving out real room by pushing the logo itself over, rather than
	   trying to slot the button into space that doesn't exist, is what
	   actually fixes that. `.mobile-site-branding` is Kadence's own class
	   specifically on the *mobile* header's branding instance (kept
	   separate from the desktop one, which this deliberately leaves alone).
	   `--pif-toggle-reserve` is computed alongside the button's own
	   position/size above, so this always reserves exactly enough — no
	   more, no less — regardless of what that measurement actually is. */
	.mobile-site-branding {
		padding-left: var( --pif-toggle-reserve, 44px );
		box-sizing: border-box;
	}

	/* No longer needs to reserve gutter space for a floating button (it
	   lives in the header band now, not over the content below) — this is
	   just an ordinary small mobile margin, matching the right-hand
	   padding below so content isn't flush against either edge. */
	.pif-layout {
		--pif-sidebar-collapsed-w: 16px;
		padding-right: 16px;
	}
}

@media ( max-width: 640px ) {
	.pif-card__grid { display: flex; flex-direction: column; }
	.pif-card__image { width: 100%; }
	.pif-card__title { font-size: 22px; }

	/* Interleave title/time/image/venue: title and time (date/timeframe) on
	   top, then the promo image, then venue and the rest. `.pif-card__detail`
	   wraps title through actions and normally sits before `.pif-card__image`
	   as a whole (see render-helpers.php) — `display: contents` here drops
	   that wrapper's own box so its children become direct flex items of
	   `.pif-card__grid` right alongside the image, letting `order` interleave
	   them instead of only being able to move the image before or after the
	   entire detail block. */
	.pif-card__detail { display: contents; }
	.pif-badges { order: 1; }
	.pif-card__title { order: 2; }
	.pif-card__time { order: 3; }
	.pif-card__image {
		order: 4;
		/* Breathing room above (from the time) and below (to the venue) —
		   neither had a bottom/top margin of its own to lean on since the
		   image previously sat outside `.pif-card__detail` entirely. */
		margin: 12px 0;
	}
	.pif-card__venue { order: 5; }
	.pif-card__cost { order: 6; }
	/* .pif-card__desc-row (not .pif-card__desc/.pif-card__see-more
	   individually) is what's now actually a direct child of
	   .pif-card__detail — see render-helpers.php/the icon+description
	   wrapper introduced above. */
	.pif-card__desc-row { order: 7; }
	.pif-tags { order: 8; }
	.pif-actions { order: 9; }

	/* Condensed rows (list view): .pif-row__venue's flex:0 0 auto +
	   white-space:nowrap never shrinks or wraps, so on a narrow viewport it
	   (and the save/comments controls that follow it) simply overflow the
	   row's width instead of making room — pushing the save button and
	   comment count off the edge of the screen. Forcing venue onto its own
	   full-width second line — placed after save/comments via `order`, not
	   DOM position, so those stay up on the first line where a row this
	   size expects them — gives the title line back essentially the row's
	   full width again.

	   flex-basis:0 on .pif-row__main is the other half of that: flex-wrap
	   decides where to break lines using each item's *hypothetical*
	   (un-shrunk) main size, and flex-basis:auto resolves that to the
	   title's full, un-truncated text width — often well over 390px on its
	   own — so with the default basis the browser wrapped .pif-row__main
	   onto its own line before even considering shrinking it, scattering
	   thumb/title/icons across three separate lines instead of shrinking
	   main to fit alongside them on the first. Starting from a 0 basis (it
	   still grows via flex:1 1 auto) makes the line-break decision use 0
	   instead, so thumb+main+save+comments correctly share line one and
	   main just grows to fill whatever's left over.

	   align-items:flex-start (rather than the base rule's :center) keeps
	   the thumbnail and icons pinned to the top of the row regardless of
	   whether the title below them wraps to one line or two, rather than
	   the row's cross-axis centering shifting them up/down to match
	   whatever height the title happens to need this time. */
	.pif-row {
		flex-wrap: wrap;
		align-items: flex-start;
		row-gap: 6px;
		gap: 10px;
	}
	.pif-row__thumb { width: 40px; height: 40px; }
	.pif-row__main { flex-basis: 0; }
	/* Two lines instead of one — a hard single-line ellipsis was cutting
	   long titles down to just a word or two once the row narrowed to
	   phone width; wrapping into the row's own second line uses the space
	   that's already there instead of hiding more of the title than it has to. */
	.pif-row__title {
		white-space: normal;
		display: -webkit-box;
		-webkit-box-orient: vertical;
		-webkit-line-clamp: 2;
		overflow: hidden;
	}
	.pif-row__save { order: 3; }
	.pif-row__comments { order: 4; }
	/* display:block instead of the base rule's display:flex: a flex
	   container doesn't support text-overflow on its children (the icon
	   and the venue name are two separate direct children, not one text
	   run), so a long venue name just wrapped instead of eliding — display
	   :block puts the icon (already inline-block) and the text back into a
	   normal inline formatting context, where overflow/ellipsis on the
	   container correctly clips and truncates that whole line as one unit.
	   The icon's own gap (`gap` needs flex/grid, so it's a plain margin here). */
	.pif-row__venue {
		order: 5;
		flex: 1 1 100%;
		display: block;
		white-space: nowrap;
		overflow: hidden;
		text-overflow: ellipsis;
		/* Lines up under the title/topic column instead of the thumbnail. */
		margin-left: calc( 40px + 10px );
	}
	.pif-row__venue .pif-icon { margin-right: 4px; }
}

@media ( max-width: 480px ) {
	.pif-results-row { flex-wrap: wrap; row-gap: 8px; }
	.pif-results-label { font-size: 13px; }
	.pif-view-toggle__btn { padding: 6px 8px; }
	.pi-shortcodes__event-chip { padding: 4px 8px; font-size: 11px; }
	.pif-actions { gap: 12px; }
}

/* =========================================================================
   Venue view (templates/venue.php)
   Mirrors PI - Single Event's own .pise-* layout (same wrap/shell/rail
   proportions, same 1040px/720px breakpoints) so the two "single item"
   pages read as one design language, one column narrower than that: the
   venue view only ever has the one rail image (no separate mobile hero/
   side-image placement to choreograph the way PI - Single Event's promo
   image needs), so it just stays part of the rail and stacks below the
   article at both the 1040px and 720px breakpoints instead of relocating.
   The upcoming/past lists reuse this file's own .pif-card/.pif-month-group
   event rendering (PIF_Feed::render_results_html()) rather than a bespoke
   layout.
   ========================================================================= */

/* margin-right cancels .pif-layout's own 32px padding-right (present above
   800px) so this 28px is the *only* space on the right, instead of the two
   stacking into 60px — same reasoning, same fix, as PI - Single Event's own
   .pise-wrap. */
.pifv-wrap { padding: 0 28px 64px; margin-right: -32px; box-sizing: border-box; }

@media ( max-width: 800px ) {
	/* PI - Frontend's own padding-right drops from 32px to 16px at this
	   exact breakpoint (.pif-layout, above) — match it so the cancellation
	   above stays exactly 28px instead of overshooting by 16px. */
	.pifv-wrap { margin-right: -16px; }
}

/* Left side has no equivalent cancellation above: unlike the right,
   .pif-layout's own left padding is already 0 — but this wrap's 28px still
   stacks on top of *.pif-center's* margin-left (the left sidebar's own
   gutter), which is a much bigger number once that sidebar is pinned at
   its full width (≥1200px, not collapsed — 280px + a 32px gutter). 28px on
   top of that reads as a visibly oversized, lopsided gap versus the right
   side's clean 28px — confirmed live. Below that (collapsed/narrow, sidebar
   reduced to a small icon-only gutter), the 28px stays: it's what keeps the
   floating .pif-sidebar-toggle button (36px circle at left:20px, so
   reaching to ~56px) clear of the title text sitting right next to a
   collapsed-width gutter of only 32px/16px on its own. */
.pif-layout--venue:not( .pif-collapsed ) .pifv-wrap { padding-left: 0; }

.pifv-shell {
	display: flex;
	align-items: flex-start;
	justify-content: center;
	gap: 24px;
	max-width: 1052px;
	margin: 0 auto;
}

.pifv-main-col { min-width: 0; max-width: 760px; flex: 1 1 auto; }

.pifv-article {
	min-width: 0;
	overflow: hidden;
	background: #fff;
	border: 1px solid var( --pif-border );
	border-radius: 10px;
}

.pifv-header { display: flex; flex-wrap: wrap; gap: 28px; padding: 28px 32px 26px; border-bottom: 1px solid var( --pif-border ); }
.pifv-details { flex: 1 1 340px; min-width: 0; display: flex; flex-direction: column; }

/* Header's own copy of the venue image — hidden here above 1040px, where
   the desktop rail (below) carries it instead. See the ≤1040px rules
   further down for its visible/sized state. */
.pifv-side-image { display: none; }

/* Its own copy of the Topics/Types card, between the actions row and the
   event list — hidden here above 1040px for the same reason. */
.pifv-info-section { display: none; }

.pifv-title { font-size: 28px; font-weight: 700; line-height: 1.12; letter-spacing: -0.5px; color: var( --pif-fg-1 ); margin: 0 0 20px; }

.pifv-meta-list { display: flex; flex-direction: column; gap: 16px; }
.pifv-meta-row { display: flex; gap: 11px; }
.pifv-meta-icon { flex: 0 0 auto; margin-top: 2px; color: var( --pif-fg-muted ); }
.pifv-meta-primary { font-size: 14px; font-weight: 700; color: var( --pif-fg-1 ); }
.pifv-meta-sub { font-size: 13px; color: var( --pif-fg-3 ); margin-top: 2px; }
.pifv-meta-cta { display: inline-block; font-size: 13px; font-weight: 700; margin-top: 4px; color: var( --pif-accent ); text-decoration: none; }
.pifv-meta-cta:hover { text-decoration: underline; }
.pifv-meta-link { display: inline-block; font-size: 13px; margin-top: 2px; color: var( --pif-accent ); text-decoration: none; word-break: break-all; }
.pifv-meta-link:hover { text-decoration: underline; }

.pifv-actions { display: flex; flex-wrap: wrap; align-items: center; gap: 10px; padding: 10px 32px; border-bottom: 1px solid var( --pif-border ); }
.pifv-action-btn,
.pifv-action-btn:hover,
.pifv-action-btn:focus,
.pifv-action-btn:active {
	display: inline-flex; align-items: center; gap: 7px;
	background: #fff; border: 1px solid var( --pif-border-strong ); border-radius: 6px;
	padding: 7px 14px; font-size: 13px; font-family: inherit; font-weight: 600;
	color: var( --pif-fg-3 ); cursor: pointer; text-decoration: none;
	transition: background 0.15s ease;
}
.pifv-action-btn:hover { background: var( --pif-bg-muted ); }

/* The two admin-only buttons' inline-in-the-actions-row placement — hidden
   here above 1040px, where the desktop rail's own boxed "Admin actions"
   card (.pifv-admin-card below) carries them instead (see the ≤1040px
   rules further down). Chained with .pifv-action-btn rather than used alone
   so this specificity ties with — and, by coming later in the file, wins
   over — that base rule's own :hover/:focus/:active group above, which
   would otherwise still show it in the wrong context on hover. */
.pifv-action-btn.pifv-action-btn--admin,
.pifv-action-btn.pifv-action-btn--admin:hover,
.pifv-action-btn.pifv-action-btn--admin:focus,
.pifv-action-btn.pifv-action-btn--admin:active { display: none; }

.pifv-events { padding: 22px 32px 30px; }

.pifv-events-header { display: flex; align-items: center; flex-wrap: wrap; gap: 12px; margin-bottom: 18px; }
.pifv-events-count { display: flex; align-items: center; gap: 8px; font-size: 13px; color: var( --pif-fg-muted ); }

.pifv-tabs { margin-left: auto; display: flex; gap: 4px; padding: 3px; background: var( --pif-bg-muted ); border-radius: 999px; }
/* Base rest-state rule, deliberately repeated verbatim across the
   :hover/:focus/:active group below rather than left to fall through to it —
   Kadence's own global button:hover/:focus/:active rule otherwise wins
   uncontested on those states (same issue .pif-sidebar-toggle's own comment
   documents): with no .pifv-tab rule of its own matching :hover at all,
   there's nothing here to compete with it. Repeating every property (not
   just color) pins the whole rest-state look — border, background, padding,
   font — through every interactive state instead of leaving any single one
   exposed. */
.pifv-tab,
.pifv-tab:hover,
.pifv-tab:focus,
.pifv-tab:active {
	border: 1px solid transparent; cursor: pointer; font-family: inherit;
	font-size: 13px; font-weight: 700; padding: 8px 16px; border-radius: 999px;
	background: transparent; color: var( --pif-fg-3 );
}
.pifv-tab::-moz-focus-inner { border: 0; padding: 0; }
.pifv-tab:hover,
.pifv-tab:focus,
.pifv-tab:active { color: var( --pif-fg-2 ); }
.pifv-tab:focus-visible { outline: 2px solid var( --pif-accent ); outline-offset: -2px; }
.pifv-tab.is-active,
.pifv-tab.is-active:hover,
.pifv-tab.is-active:focus,
.pifv-tab.is-active:active {
	background: #fff; border-color: var( --pif-border ); color: var( --pif-accent );
}

/* Short label ("Upcoming"/"Past") only swaps in at ≤480px — see that rule
   further down — where it helps the toggle fit its own row instead of the
   full "Upcoming events"/"Past events" text pushing it to wrap under the
   results count. */
.pifv-tab-label-short { display: none; }

.pifv-results[ hidden ] { display: none; }

/* -------------------------------------------------------------------------
   Right rail
   ------------------------------------------------------------------------- */

.pifv-rail {
	flex: 0 0 268px; width: 268px;
	position: sticky; top: 20px;
	display: flex; flex-direction: column; gap: 20px;
}

/* Transparent, borderless card — per the design, only the image's own
   rounded corners should read as "a card" here, unlike .pifv-info-card
   below (or PI - Single Event's own bordered .pise-rail-image). Height is
   whatever the image's own aspect ratio needs (no aspect-ratio box), so a
   tall or short photo is never letterboxed/cropped. */
.pifv-image-card { width: 100%; }
.pifv-image-card img { display: block; width: 100%; height: auto; border-radius: 10px; }

.pifv-info-card { min-width: 0; background: #fff; border: 1px solid var( --pif-border ); border-radius: 10px; padding: 18px; }
.pifv-info-label { font-size: 12px; font-weight: 700; text-transform: uppercase; letter-spacing: 0.06em; color: var( --pif-fg-muted ); margin-bottom: 10px; }
.pifv-info-label--spaced { margin-top: 18px; }
.pifv-chip-row { display: flex; flex-wrap: wrap; gap: 6px; }
.pifv-info-empty { font-size: 14px; color: var( --pif-fg-placeholder ); font-style: italic; margin: 0; }

/* Admin-only "Admin actions" card, under the Topics/Types card — always its
   own bordered box (unlike .pifv-info-card, which loses its border for the
   ≤1040px .pifv-info-section placement below) since it's a set of actions,
   not informational content that needs to read as a continuation of the
   page around it. */
.pifv-admin-card { min-width: 0; background: #fff; border: 1px solid var( --pif-border ); border-radius: 10px; padding: 18px; }
.pifv-admin-actions { display: flex; flex-direction: column; gap: 8px; margin-top: 10px; }
.pifv-admin-btn,
.pifv-admin-btn:hover,
.pifv-admin-btn:focus,
.pifv-admin-btn:active {
	display: flex; align-items: center; gap: 8px; width: 100%; box-sizing: border-box;
	background: #fff; border: 1px solid var( --pif-border-strong ); border-radius: 6px;
	padding: 8px 12px; font-size: 13px; font-family: inherit; font-weight: 600;
	color: var( --pif-fg-3 ); cursor: pointer; text-decoration: none;
}
.pifv-admin-btn:hover,
.pifv-admin-btn:focus,
.pifv-admin-btn:active { background: var( --pif-bg-muted ); }
.pifv-admin-btn:focus-visible { outline: 2px solid var( --pif-accent ); outline-offset: -2px; }
.pifv-admin-btn:disabled,
.pifv-admin-btn:disabled:hover { background: #fff; opacity: 0.6; cursor: default; }

/* -------------------------------------------------------------------------
   Responsive: single column, ≤1040px — mirrors PI - Single Event's own
   .pise-shell breakpoint. Unlike that page, the rail here has nowhere to
   reorder to (nothing above/below the article the way PI - Single Event's
   comments section gives it a place to fall between) — its two pieces move
   into the header and a dedicated section instead (.pifv-side-image /
   .pifv-info-section below), so the rail itself just hides rather than
   stacking as its own block.
   ------------------------------------------------------------------------- */

@media ( max-width: 1040px ) {
	.pifv-shell { flex-direction: column; align-items: stretch; max-width: 820px; margin: 0 auto; gap: 20px; }
	.pifv-rail { display: none; }

	.pifv-header { flex-wrap: nowrap; }
	.pifv-side-image { display: block; flex: 0 0 120px; width: 120px; }

	/* Admin-only buttons join the actions row here instead of the desktop
	   rail's boxed card (see the base rule's own comment above). */
	.pifv-action-btn.pifv-action-btn--admin,
	.pifv-action-btn.pifv-action-btn--admin:hover,
	.pifv-action-btn.pifv-action-btn--admin:focus,
	.pifv-action-btn.pifv-action-btn--admin:active { display: inline-flex; }

	/* Top padding: without it, this section's content sits flush against
	   the .pifv-actions row's own bottom border right above it — the same
	   28px breathing room .pifv-header/.pifv-events already get from their
	   own padding, just supplied here since this section has no border of
	   its own to visually separate it. */
	.pifv-info-section { display: flex; flex-direction: column; gap: 18px; padding: 22px 32px; }
	/* Border-less here (unlike the desktop rail's own .pifv-info-card) — a
	   bottom rule instead separates it from whatever comes after (the event
	   list directly below), reading as a continuation of the page around it
	   rather than a floating box mid-column. */
	.pifv-info-section .pifv-info-card {
		background: transparent; border: 0; border-radius: 0;
		padding: 0 0 18px; border-bottom: 1px solid var( --pif-border );
	}
}

/* -------------------------------------------------------------------------
   Responsive: mobile, ≤720px — floating action bar, matching PI - Single
   Event's own .pise-actions treatment at the same breakpoint.
   ------------------------------------------------------------------------- */

@media ( max-width: 720px ) {
	/* margin-top cancels .pif-layout's own 28px padding-top, which — unlike
	   its padding-right (already handled above) — never shrinks at any
	   breakpoint on its own, so it was showing through as a gray strip
	   above the article. margin-right: 0 stops chasing that same padding's
	   16px value here too — .pif-center's own margin-left already reduces
	   to a plain 16px gutter at this width (.pif-layout's --sidebar-
	   collapsed-w, ≤800px), so this wrap accepting that same ~16px on the
	   right instead of trying to cancel it keeps both sides symmetric,
	   matching PI - Single Event's own .pise-wrap at this breakpoint. */
	.pifv-wrap { padding: 0 0 96px; margin-top: -28px; margin-right: 0; }
	.pifv-shell { max-width: none; margin: 0; gap: 16px; }

	/* Breaks .pifv-article out past that same ~16px ambient gutter on both
	   sides, reaching the true screen edges — "gray showing on the left"
	   was that gutter plus .pif-layout's own now-cancelled padding stacking
	   on top of it, not just the top strip above. The 16px reappears as
	   ordinary inner padding on .pifv-header/.pifv-actions/.pifv-events/
	   .pifv-info-section below instead, so the *content* inside lands
	   exactly where it did before — only the white background now reaches
	   the true edges. Same technique as PI - Single Event's own
	   .pise-article at this breakpoint. */
	.pifv-article {
		border: 0; border-radius: 0;
		margin-left: -16px; margin-right: -16px; width: calc( 100% + 32px );
	}
	.pifv-header { padding: 20px 16px 22px; }
	.pifv-events { padding: 20px 16px 26px; }
	.pifv-info-section { padding: 20px 16px; }
	.pifv-side-image { flex: 0 0 88px; width: 88px; }

	.pifv-actions {
		position: fixed; left: 12px; right: 12px; bottom: 12px; z-index: 40;
		display: flex; flex-wrap: wrap; align-items: center; gap: 4px;
		background: #fff; border: 1px solid var( --pif-border ); border-radius: 999px;
		box-shadow: 0 6px 20px rgba( 0, 0, 0, 0.12 ); padding: 4px 6px;
	}
	/* Two admin-only buttons join Directions/Share here (see
	   .pifv-action-btn--admin above), which a single-row pill has no room
	   for — 40% (not 50%) leaves flex-wrap room to break 4 buttons into two
	   rows of two instead of squeezing all four onto one, while still
	   filling a full row exactly in two (flex-grow:1) when only
	   Directions/Share are present. */
	.pifv-action-btn,
	.pifv-action-btn:hover,
	.pifv-action-btn:focus,
	.pifv-action-btn:active {
		flex: 1 1 40%; justify-content: center; gap: 6px;
		background: transparent; border: 0; border-radius: 6px;
		padding: 8px 8px; min-height: 38px; font-size: 13px; color: var( --pif-fg-3 );
	}
	/* A tall, wrapped 2-row bar reads oddly at the same near-999px pill
	   radius the common 2-button/1-row case uses — only reduced when the
	   admin buttons are actually present to force that second row. */
	.pifv-actions:has( .pifv-action-btn--admin ) {
		border-radius: 16px;
	}
}

@media ( max-width: 480px ) {
	.pifv-events-header { row-gap: 8px; }
	.pifv-tab { padding: 8px 12px; }

	/* The Upcoming/Past toggle wrapping onto its own row below the results
	   count (.pifv-events-header's own flex-wrap) reads as more cramped at
	   this width than swapping in shorter labels to help it fit instead —
	   see .pifv-tab-label-full/--short in templates/venue.php. */
	.pifv-tab-label-full { display: none; }
	.pifv-tab-label-short { display: inline; }

	/* The sitewide ≤480px chip shrink (.pi-shortcodes__event-chip, further
	   below) was sized for the feed's own narrow event cards — too small
	   here, where the Topics/Types chips have a whole card row to
	   themselves. Restored to the class's own un-shrunk base size
	   (tribe-events/event-chips.css: padding 6px 10px, font-size 12px). */
	.pifv-chip-row .pi-shortcodes__event-chip { padding: 6px 10px; font-size: 12px; }
}

/* PI - Frontend's own footer right-inset (pi-frontend.css, "Right-hand
   counterpart" above) turns on at min-width:900px, matching when *its own*
   .pif-sidebar-right becomes visible on feed/topic views. .pifv-rail is
   this page's equivalent, but (like PI - Single Event's own .pise-rail) it
   only behaves like a right-hand sidebar above this template's own 1040px
   breakpoint — below that it hides entirely instead (see the ≤1040px rule
   above). Between 900-1040px PI - Frontend's rule was otherwise still
   reserving ~260px on the right for a rail that, on this page specifically,
   isn't actually there — squishing the real footer content into whatever
   was left on the left (reported live: footer text wrapped down to a
   single narrow column). Selectors mirror pi-frontend.css's own list
   exactly, scoped to body.pifv-page so nothing else on the site is
   affected — same fix, same reasoning, as PI - Single Event's own
   body.pise-page override. */
@media ( min-width: 900px ) and ( max-width: 1040px ) {
	body.pifv-page.pif-footer-inset--has-sidebar-right .site-footer,
	body.pifv-page.pif-footer-inset--has-sidebar-right #colophon,
	body.pifv-page.pif-footer-inset--has-sidebar-right footer.site-footer,
	body.pifv-page.pif-footer-inset--has-sidebar-right footer[ role="contentinfo" ],
	body.pifv-page.pif-footer-inset--has-sidebar-right > footer {
		padding-right: 0;
	}
}