/**
 * PGLTM custom tweaks
 * ---------------------------------------------------------------
 * Small, deliberate deviations from the stock Salient output, kept in
 * one place so they're easy to find/change later instead of hunting
 * through the (huge, minified) theme files.
 */

/* --- Footer rebuild --------------------------------------------------
   Replaces the old two-line copyright/credit row (which sat right under
   the "PRETTY GIRLS LIKE TRAP MUSIC" scrolling-text loop) with a proper
   footer: logo on the left, page links + social icons on the right, and
   a small credit line underneath. Plain custom markup/classes instead of
   WPBakery's grid — this section doesn't come from the visual editor
   (nothing here needs to stay WPBakery-editable), so there's no reason
   to fight its column/padding system the way the rest of the page does.
   Background color (#111111) intentionally matches the scrolling-text
   loop's row (moved below this one, at the very bottom of the page, so
   it reads as the closing line of the footer instead of a separator
   above it), and there's no divider between them — the loop is meant to
   read as part of the footer, not a separate section.

   The inner wrapper is deliberately NOT called .container: this whole
   row sits inside the page's own top-level .container.main-content (the
   box every WPBakery row lives in), and the theme has a defensive rule
   that force-zeroes any .container nested inside another .container —
   exactly what happened the first time this used that class, silently
   collapsing the padding back to 0. Its own class with the same
   max-width/centering/padding as the header's .container (not the 61px
   page-content one — the header isn't nested in anything, so it's the
   right one to match here) sidesteps that rule entirely. */
#pgltm-footer {
	/* Full-bleed: #pgltm-footer lives inside the page's own boxed
	   .container.main-content (same as every other WPBakery row), so
	   without this it's confined to that ~1300px content width instead
	   of spanning edge to edge like the scrolling-text loop above it.
	   Same escape trick the theme itself uses for its full-width rows
	   (left:50% + negative margin-left of half the viewport). --scroll-bar-w
	   is already pinned to 0 above, so this simplifies to a plain 100vw. */
	position: relative;
	left: 50%;
	width: 100vw;
	margin-left: calc(-50vw + var(--scroll-bar-w) / 2);
	/* Top padding (before the logo/nav row) was briefly matched to the
	   100px the page's regular sections use (About, "What we do", FAQ),
	   but a footer reads as a footer partly by being visibly more
	   compact than the sections above it, not the same size — so this
	   is deliberately smaller than that 100px rhythm, not equal to it. */
	background-color: #111111;
	padding: 65px 0 25px;
	color: rgba(255, 255, 255, 0.7);
	font-size: 15px;
}
#pgltm-footer .pgltm-footer-container {
	position: relative;
	max-width: 1425px;
	width: 100%;
	margin: 0 auto;
	box-sizing: border-box;
}
@media only screen and (min-width: 1000px) {
	#pgltm-footer .pgltm-footer-container {
		padding: 0 90px;
	}
}
@media only screen and (max-width: 999px) {
	#pgltm-footer .pgltm-footer-container {
		padding: 0 30px;
	}
}
#pgltm-footer .pgltm-footer-main {
	display: flex;
	align-items: center;
	justify-content: space-between;
	flex-wrap: wrap;
	gap: 30px;
}
#pgltm-footer .pgltm-footer-logo {
	display: block;
	flex: 0 0 auto;
}
#pgltm-footer .pgltm-footer-logo img {
	display: block;
	width: 130px;
	height: auto;
}
#pgltm-footer .pgltm-footer-right {
	display: flex;
	align-items: center;
	gap: 40px;
	flex-wrap: wrap;
}
#pgltm-footer .pgltm-footer-nav {
	display: flex;
	gap: 28px;
}
#pgltm-footer .pgltm-footer-nav a {
	color: #fff;
	text-decoration: none;
	opacity: 0.75;
	transition: opacity 0.2s ease;
}
#pgltm-footer .pgltm-footer-nav a:hover {
	opacity: 1;
}
#pgltm-footer .pgltm-footer-divider {
	width: 1px;
	height: 16px;
	background-color: rgba(255, 255, 255, 0.25);
}
#pgltm-footer .pgltm-footer-social {
	display: flex;
	align-items: center;
	gap: 28px;
}
#pgltm-footer .pgltm-footer-social a {
	color: #fff;
	text-decoration: none;
	opacity: 0.75;
	transition: opacity 0.2s ease;
}
#pgltm-footer .pgltm-footer-social a:hover {
	opacity: 1;
}
#pgltm-footer .pgltm-footer-bottom {
	display: flex;
	align-items: center;
	justify-content: space-between;
	gap: 12px;
	flex-wrap: wrap;
	margin-top: 24px;
	padding-top: 16px;
	padding-bottom: 16px;
	border-top: 1px solid rgba(255, 255, 255, 0.1);
	border-bottom: 1px solid rgba(255, 255, 255, 0.1);
	font-size: 12px;
	opacity: 0.5;
}
#pgltm-footer .pgltm-footer-bottom a {
	color: inherit;
	text-decoration: underline;
}

@media only screen and (max-width: 999px) {
	#pgltm-footer .pgltm-footer-main {
		flex-direction: column;
		align-items: center;
		text-align: center;
	}
	#pgltm-footer .pgltm-footer-right {
		flex-direction: column;
		gap: 22px;
	}
	#pgltm-footer .pgltm-footer-divider {
		width: 40px;
		height: 1px;
	}
	#pgltm-footer .pgltm-footer-bottom {
		flex-direction: column;
		justify-content: center;
		text-align: center;
	}
}

/* --- Scrolling-text loop, now living at the very bottom of the page --
   Two leftovers from when this sat ABOVE the footer info (between the
   FAQ section and the copyright row), now that it's been moved below
   that row per the reorder above:

   1. Its column has a 1px top border (border_top_desktop_1px, a WPBakery
      setting) that used to mark the seam between the cream FAQ section
      and this dark one — a reasonable divider on a light-to-cream
      transition. Now it sits between two dark sections that are meant to
      read as one continuous footer, so that same border shows up as an
      unwanted seam right where the user asked for none.
   2. Its own inner row carried a lopsided 50px top / 50px bottom padding
      that made sense when it had more content below to breathe against.
      Now it's the very last thing on the page, so top is a much
      tighter 20px (the logo/nav row above it needs noticeably more
      breathing room than this thin text loop does, so its own padding,
      above, is intentionally not the same number — matching them made
      the footer-info feel cramped), and bottom is 35px — a bit more
      than the top, as the closing space at the very end of the page.
      Both deliberately compact: the loop is part of the footer, and a
      footer should read as visibly smaller than a regular page section,
      not match their scale.

   Both scoped via :has() to just this row (identified by containing
   .nectar-scrolling-text) so nothing else on the page is affected.

   On mobile, the row also carries WPBakery's own top_padding_phone_0px /
   bottom_padding_phone_0px classes, backed by a page-generated inline
   `body .vc_row.inner_row.top_padding_phone_0px{padding-top:0!important}`
   rule (in <head>) — 4 selector parts to this rule's 2, so despite both
   being !important it won on specificity and silently zeroed the padding
   below on phones. Matched (and beaten) by repeating those same classes
   plus `body` here, so this wins on both counts everywhere. */
.wpb_column:has(> .vc_column-inner .nectar-scrolling-text) > .vc_column-inner {
	border-top: none !important;
}
.inner_row:has(.nectar-scrolling-text),
body .vc_row.inner_row.top_padding_phone_0px:has(.nectar-scrolling-text),
body .vc_row.inner_row.bottom_padding_phone_0px:has(.nectar-scrolling-text) {
	padding-top: 20px !important;
	padding-bottom: 35px !important;
}

/* --- Kill the leftover empty footer-widgets area --------------------
   The original WordPress footer widget area (#footer-outer) never had
   any widgets in it (data-has-widgets="false") — everything visible now
   lives in #pgltm-footer above. Nothing of value here anymore, so it's
   hidden outright. */
#footer-outer {
	display: none;
}

/* Salient gives .container-wrap (the box holding every page section,
   from the hero down to the old footer-widgets area) a permanent 40px
   padding-bottom, meant as breathing room before that widget footer.
   With #footer-outer gone, that 40px was still there on its own —
   showing up as a ~40px band of the page's plain background color (a
   different, lighter shade than the loop right above it) right at the
   very bottom of the page. Not needed anymore: the new footer and loop
   both already carry their own top/bottom spacing. */
.container-wrap {
	padding-bottom: 0 !important;
}

/* --- Header nav/social divider ---------------------------------------
   Same small vertical divider used between the nav links and social
   icons in the footer, mirrored here between Home/Events/Agency and the
   mail/Instagram/TikTok/Spotify icons — same visual language in both
   places instead of just a plain gap. */
#header-outer .pgltm-header-divider {
	display: flex;
	align-items: center;
	/* #social-in-menu (right after this) already carries its own 30px
	   margin-left, so the gap on that side was already ~30px — this
	   just matches the same amount on the left, against Agency, which
	   otherwise touched it with no gap at all. */
	margin-left: 30px;
}
/* The theme's own #top nav>ul>li>a base rule (padding:0 10px, display:
   block, ...) kept winning over every property here despite this
   selector actually being the more specific one on paper — same
   fighting-the-cascade pattern as the nav-hover rule above, just
   affecting more properties at once here. !important across the board
   rather than chasing it property by property. */
#header-outer .pgltm-header-divider a {
	display: inline-block !important;
	width: 1px !important;
	height: 16px !important;
	padding: 0 !important;
	margin: 0 !important;
	pointer-events: none;
	cursor: default;
	/* currentColor, not a fixed white: the theme's nav-link white color
	   is set on the <a> element specifically (its <li>/<ul>/nav ancestors
	   actually resolve to a muted gray, #676767 — confirmed by comparing
	   getComputedStyle up the tree), not inherited generically, and it
	   isn't always white anyway (e.g. once the header switches to a
	   light/scrolled state). This divider is itself an <a> (inert:
	   pointer-events none, tabindex -1, aria-hidden) purely so it picks
	   up that same color rule automatically instead of needing to
	   duplicate the theme's own selector for every header color state.
	   Opacity kept on the element itself so it stays subtle regardless
	   of which color that resolves to. */
	background-color: currentColor;
	opacity: 0.25 !important;
}

/* --- Header social icons (Instagram/Spotify/TikTok) hover -----------
   Stock Salient does a "roll up and swap" animation on hover: JS slides
   the icon (and a duplicate glyph parked right below it via ::after)
   up out of view by exactly its own height. Cancelling the icon's
   transform stops that slide; the theme's own rule for these icons
   already transitions opacity too, so a plain :hover opacity dip is all
   that's added below — small and simple, no moving parts. */
#header-outer #social-in-menu a i {
	transform: none !important;
}
#header-outer #social-in-menu a:hover i {
	opacity: 0.6;
}

/* --- Header nav links (Home/Events/Agency) hover ---------------------
   The theme's "animated_underline" link-hover-effect setting (data-lhe
   on #header-outer) drew a sliding underline under the text on hover —
   changed the setting itself to "default" to turn that off, but that
   setting turns out to give these particular links no hover feedback
   at all. Same small opacity dip as the social icons just above, so
   hovering a nav link still reads as interactive. Needs !important: an
   equal-specificity theme rule elsewhere sets opacity too and, without
   it, wins on source order alone (confirmed by temporarily injecting
   this exact rule with !important in a <style> appended after
   pgltm-custom.css — same selector, only that difference, and it took
   effect immediately). */
header#top nav > ul > li > a:hover {
	opacity: 0.6 !important;
}

/* The current page's nav item (Home/Events/Agency) is already marked
   with the theme's own current-menu-item/current_page_item classes
   (that's what drives its underline) — bold added on top so it's
   readable at a glance, not just on close inspection of the underline. */
header#top nav > ul > li.current-menu-item > a {
	font-weight: 700;
}

/* --- Skip the header entrance animation on repeat page loads -------
   Salient slides/fades the header in from the top on every fresh page
   load (see the header_nav_entrance_animation keyframes in the theme's
   own CSS). On a real WordPress site with AJAX page transitions that
   only happens once; here, every internal link is a full page reload,
   so it would replay on every single click between pages. The inline
   script near the top of <body> adds pgltm-no-header-entrance to <html>
   once sessionStorage shows this isn't the first page of the visit --
   this just makes that case show the header in its normal end state
   immediately, no animation. */
html.pgltm-no-header-entrance #header-outer {
	opacity: 1 !important;
	animation: none !important;
}
html.pgltm-no-header-entrance #header-outer #top,
html.pgltm-no-header-entrance #header-outer #header-secondary-outer {
	animation: none !important;
	transform: none !important;
}

/* --- Kill the "vertical black bars" bug ---------------------------
   Every full-width section (video, purple/cream backgrounds, footer)
   is sized with calc(100vw - var(--scroll-bar-w)), where
   --scroll-bar-w is measured once by an inline script very early in
   <body> (theme code, not ours) to compensate for a real scrollbar.
   If that script runs before the page has its real layout, it can
   measure a much bigger gap than the scrollbar actually is and bake
   that wrong value into body's inline style — permanently, since it
   only runs once. Every full-width section then falls short of the
   true edge by that same amount on both sides, and the dark page
   background shows through as two vertical bars. The header doesn't
   use this calc, which is why it's never affected.
   Nearly everyone's actual scrollbar is 0px (overlay-style) anyway,
   so pinning this to 0 is safe and sidesteps the race condition
   entirely. `!important` is required — it's fighting an inline style. */
body {
	--scroll-bar-w: 0px !important;
}

/* --- Homepage hero video ------------------------------------------
   Salient normally fades the hero video + its dark tint overlay in
   via JS a few hundred ms after load, which on a fast connection
   reads as a flash. Skip the fade: show both in their final state
   immediately (same color/opacity the theme itself uses). */
.video-color-overlay {
	opacity: 0.7 !important;
	background-color: #1e1e1e !important;
}
.nectar-video-wrap,
.nectar-video-wrap video {
	opacity: 1 !important;
}

/* Promote the continuously-playing video and the two scroll-linked
   parallax elements (hero heading, about-section photo) to their own
   compositor layers. Doesn't change how they look — it just gives the
   browser a hint to isolate their repaints instead of recalculating
   the whole page on every video frame / scroll tick, which is what
   causes the occasional stutter while scrolling. */
.nectar-video-wrap video,
[data-scroll-animation="true"] {
	will-change: transform;
	transform: translateZ(0);
}

/* --- Side padding: align boxed sections with the header ------------
   Regular ("boxed") content — About, What we do, FAQ, the events list
   — sits inside .container.main-content, which the theme gives a
   fixed 90px of side padding (a site-wide "extra padding" setting)
   on top of ~37px of its own nested row/column padding. The header
   uses a separate, smaller padding setting for its own .container
   (no "main-content" class, so untouched by this rule), which is why
   its logo/nav sit noticeably closer to the edge than the text below.
   Full-width sections (hero, footer) don't use .container at all, so
   they're unaffected either way. Reducing just the content container's
   padding (90px -> 61px, i.e. by the ~29px gap measured between the
   logo and e.g. the FAQ heading) pulls boxed sections in to line up
   with the header without moving the header itself. */
@media only screen and (min-width: 1000px) {
	.container.main-content {
		padding-left: 61px;
		padding-right: 61px;
	}
}

/* --- "What we do" row (Events / Hostings / Agency / Policy / Concepts) ---
   The stock markup spaces these 5 columns apart with a percentage gutter
   (padding-3-percent) PLUS a separate grid-column padding/margin pair that
   counteracts it, layered so several different values combine to produce
   the gap on screen. Zeroing each layer one at a time (tried previously)
   kept leaving a small residual offset — clearly still visible to the eye
   even once every number checked out in DevTools.
   Simpler and actually robust: stop fighting that stack of paddings and
   margins and rebuild just this one row as a plain flexbox with
   padding-free columns, scoped tightly to this row's own id
   (#fws_6a7423c8b4e21, the "What we do" items row and nothing else) so it
   can't affect any other part of the site. All the spacing between items
   now lives in exactly one place (18px on .vc_column-inner), and the
   first/last column's outer side is forced to 0 directly — no more
   competing values to keep in sync.

   The actual visual bug, found after this rebuild still didn't look
   right: the box (.vc_column-inner) WAS flush at 0px all along — that's
   what every DevTools/automated check kept confirming — but the h4
   *text* inside it is centered, so the glyphs themselves sat far in from
   that edge while the (invisible) box edge lined up perfectly. Measuring
   only the box, not where the letters actually render, is why this took
   so many rounds to nail down. Fix: left-align the first item's text and
   right-align the last item's, so the visible word — not just its
   invisible container — touches the edge. Middle 3 stay centered.

   Scoped to min-width: 1000px (same breakpoint the theme itself switches
   layouts at, and the one already used below for the container padding
   fix) — below that, Salient stacks these 5 items into a single centered
   column instead of a row, which still works fine on its own and
   shouldn't be forced into the row layout above. */
@media only screen and (min-width: 1000px) {
	#fws_6a7423c8b4e21 .row_col_wrap_12_inner {
		display: flex;
		margin: 0 !important;
	}
	#fws_6a7423c8b4e21 .row_col_wrap_12_inner > .vc_col-sm-1\/5 {
		flex: 1 1 0;
		width: auto;
		max-width: none;
		padding: 0 !important;
		margin: 0 !important;
	}
	#fws_6a7423c8b4e21 .vc_column-inner {
		padding: 0 18px !important;
	}
	#fws_6a7423c8b4e21 .row_col_wrap_12_inner > .vc_col-sm-1\/5:first-child .vc_column-inner {
		padding-left: 0 !important;
	}
	#fws_6a7423c8b4e21 .row_col_wrap_12_inner > .vc_col-sm-1\/5:last-child .vc_column-inner {
		padding-right: 0 !important;
	}
	#fws_6a7423c8b4e21 .row_col_wrap_12_inner > .vc_col-sm-1\/5:first-child .wpb_text_column,
	#fws_6a7423c8b4e21 .row_col_wrap_12_inner > .vc_col-sm-1\/5:first-child h4 {
		text-align: left !important;
	}
	#fws_6a7423c8b4e21 .row_col_wrap_12_inner > .vc_col-sm-1\/5:last-child .wpb_text_column,
	#fws_6a7423c8b4e21 .row_col_wrap_12_inner > .vc_col-sm-1\/5:last-child h4 {
		text-align: right !important;
	}
}

/* A bit more breathing room between the "What we do" heading and the
   Events/Hostings/Agency/Policy/Concepts row underneath it — stock
   spacing there was only ~21px, felt cramped right under the heading. */
#fws_6a7423c8b4e21 {
	margin-top: 50px;
}

/* --- Event detail page image: fill a set share of its column ---------
   The theme's own image wrapper only caps size with max-width:100%,
   which scales a photo DOWN to fit but never scales it UP — fine for
   hand-picked, properly-sized WordPress uploads, but event photos here
   come from whatever the team uploads (a phone screenshot, a small
   flyer export, etc.), so the source resolution isn't guaranteed to be
   at least as wide as its column. A smaller source image was rendering
   at its own native size instead of stretching to the column's edge,
   leaving a visible gap on the right that doesn't line up with the
   header/mini-card above it. width:80% (rather than 100%, kept a touch
   smaller than the full column on request) forces it to always scale
   consistently regardless of the source photo's resolution;
   margin-left:auto keeps it flush against the right edge — the column
   itself is already set up as right-aligned — instead of centering. */
#pgltm-event-image {
	width: 80%;
	height: auto;
	margin-left: auto;
	display: block;
}
/* Below 1000px the text/image columns stack instead of sitting side by
   side, so "flush against the right edge" (matching the menu, next to
   the text column on desktop) no longer has anything to align against.
   100% here matches the text block and date/venue card right above it
   — same left/right edges as the rest of the section, rather than
   floating at some in-between size that doesn't line up with anything. */
@media only screen and (max-width: 999px) {
	#pgltm-event-image {
		width: 100%;
		margin-right: auto;
	}
}

/* This row's bottom padding (100px, inherited from the event_01/event_02
   pages this template started from) left a big gap between the image
   and the footer right below it. Needs !important: the 100px comes from
   an inline style="padding-bottom: 100px" on the row itself, and inline
   styles beat any external rule regardless of selector specificity
   (only !important can override them). The phone-specific
   `body .vc_row.bottom_padding_phone_100px{padding-bottom:100px!important}`
   rule is also in the mix on mobile, but #pgltm-event-content's ID
   selector already outranks its (body + 2 classes) specificity, so this
   one rule covers both desktop and mobile. */
#pgltm-event-content {
	padding-bottom: 50px !important;
}

/* --- Upcoming-events cards: a "real" button -------------------------
   The "More" link only ever showed the literal word "More", styled
   as a faint, low-contrast outline pill — nothing like the real
   ticket/RSVP button on the event's own page. Restyled to match
   that button's exact look (same purple fill, white text, pill
   shape, bold), and events-loader.js now also gives it that
   button's actual label (ev.buttonLabel from the sheet, e.g.
   "Tickets" or "Sign-Up") instead of the hardcoded word "More" —
   so what you see in the list is a preview of the real button on
   the page it leads to, not a generic, differently-labeled one.
   (The card itself deliberately keeps the theme's own default hover —
   a custom lift/border/text-darken effect was tried here and reverted
   per request.) */
.nectar-hor-list-item .nectar-list-item-btn {
	background-color: #8462c1 !important;
	color: #fff !important;
	border-radius: 20px !important;
	padding: 15px 35px !important;
	font-size: 14px !important;
	font-weight: 700 !important;
	line-height: normal !important;
	position: static !important;
	margin-top: 12px !important;
	transition: opacity 0.25s ease !important;
}
.nectar-hor-list-item .nectar-list-item-btn:hover {
	opacity: 0.85;
}

/* The "UPCOMING EVENTS" heading on the homepage is itself a link to the
   Events page (<h2><a href="events/index.html">…</a></h2>) but had no
   hover feedback at all — same darkening as the card/text below it, for
   one consistent "this is clickable" language across the whole section. */
.vc_custom_1761467795142 h2 a {
	transition: color 0.25s ease;
}
.vc_custom_1761467795142 h2 a:hover {
	color: #5c4587;
}

/* --- Match overscroll-bounce color to the top of each page -----------
   Scrolling past the very top on a trackpad/touch device (elastic
   "overscroll" bounce) reveals a sliver of <html>'s background color
   above the page for a moment — this sets that to match what's actually
   at the top of each page (a cream section, #f6f2e6, on the pages that
   open on one) instead of the site-wide dark default, so that bounce
   reads as part of the page rather than a flash of the wrong color.
   html:has(body.X) reaches the ancestor <html> based on which
   page-identifying class ended up on <body> — avoids having to also
   hand-add a matching class to <html> itself in every page's markup.
   The homepage opens on a dark navy video hero, but deliberately isn't
   singled out here: its top and bottom bounce are meant to match each
   other (both the footer's #111111, the same color this falls back to
   without a page-specific rule), not the hero specifically.

   The BOTTOM bounce needs a different color than the top on the pages
   that DO get one above, but per spec <html>'s background covers the
   whole scrollable canvas, top and bottom alike — CSS alone can't give
   the two ends different colors. assets/js/pgltm-overscroll-bg.js
   handles that half: it swaps this same background-color to the
   footer color once you're scrolled all the way down, and back the
   moment you scroll away from the bottom, so whichever end actually
   bounces shows the right color (on the homepage, since both ends
   already agree, that swap ends up being a harmless no-op).

   Explicit #111111 default (not left to fall back on whatever <body>'s
   own background happens to be) so the homepage's "both ends match" is
   exact rather than relying on the propagation rule from CSS 2.1 §14.2
   — that would likely land on the same color anyway, but this is
   guaranteed correct instead of assumed. */
html {
	background-color: #111111;
}
html:has(body.pgltm-cream-bg) {
	background-color: #f6f2e6;
}