/* Contact page (Figma node 3380:21987). No footer on desktop by design —
   see page-contact.php's own top comment — but it's brought back on
   mobile (see the (max-width:900px) block below), so it's hidden here
   unconditionally and only shown again inside that override. */
body.is-contact-page .site-footer {
	display: none;
}

.contact {
	position: relative;
	min-height: 100vh;
	/* auto, not hidden, on the Y axis — .contact__intro/.contact__panel
	   are both position:absolute, so they don't contribute to this box's
	   own height at all; on a short desktop window (resized, or just a
	   small laptop screen) their content can need more room than a
	   shrunk 100vh gives, and hidden would clip it with no way to see
	   the rest. auto only ever shows a scrollbar once that actually
	   happens — on any normal-height viewport this is a no-op. X stays
	   hidden since nothing here should ever overflow horizontally. */
	overflow-x: hidden;
	overflow-y: auto;
	background: var(--color-ink);
}

/* display:contents on desktop — a pure layout no-op, so .contact__video
   (its child) positions itself exactly as if it were still a direct child
   of .contact, same as before this wrapper existed. Only at mobile width
   (contact.css's own (max-width:900px) rules) does this div actually
   generate a box, becoming the fixed + blurred layer — see
   page-contact.php's own comment on why the blur lives on this wrapper
   rather than the <video> element itself or a backdrop-filter. */
.contact__video-blur {
	display: contents;
}

.contact__video {
	position: absolute;
	inset: 0;
	width: 100%;
	height: 100%;
	object-fit: cover;
	z-index: 0;
}

.contact__intro {
	position: absolute;
	z-index: 1;
	left: var(--gutter);
	bottom: clamp(48px, 6vw, 80px);
	max-width: 26rem;
	color: var(--color-white);
}

.contact__heading {
	margin: 0 0 24px;
	font-family: var(--font-display);
	font-weight: 800;
	font-size: 3.125rem;
	letter-spacing: 1px;
	line-height: 0.9;
	color: var(--color-white);
}

/* Global mobile h1 baseline (3.1rem) — see base.css. Was already
   effectively this size (3.125rem); normalized for consistency. */
@media (max-width: 900px) {
	.contact__heading {
		font-size: 3.1rem;
	}
}

.contact__details {
	display: flex;
	flex-wrap: wrap;
	gap: 8px 24px;
	margin-bottom: 20px;
}

.contact__details a {
	font-family: var(--font-body);
	font-size: 1.125rem;
	color: var(--color-white);
	text-decoration: none;
}

.contact__details a:hover,
.contact__details a:focus-visible {
	text-decoration: underline;
}

.contact__address {
	display: block;
	margin: 0;
	max-width: 26rem;
	font-family: var(--font-body);
	font-size: 1.125rem;
	line-height: 1.67;
	color: var(--color-white);
	text-decoration: none;
}

.contact__address:hover,
.contact__address:focus-visible {
	text-decoration: underline;
}

.contact__socials {
	display: flex;
	align-items: center;
	gap: 12px;
	margin-top: 20px;
}

.contact__socials img {
	display: block;
	height: 22px;
	width: auto;
}

/* Frosted glass — values taken from the real HubSpot/live-site panel
   rather than Figma's literal export (see contact.css history: Figma's
   backdrop-blur(40px) + bg-white + mix-blend-mode:multiply doesn't work —
   multiply against white is a no-op at any opacity, and pairing blend-mode
   with backdrop-filter on one element renders as a flat opaque swatch).
   The near-zero-alpha fill means the softening here comes almost entirely
   from the blur itself, not from any visible tint. */
.contact__panel {
	position: absolute;
	z-index: 1;
	inset: 0;
	left: 41.25%;
	display: flex;
	align-items: center;
	justify-content: center;
	/* Fixed-height box (inset:0 pins it to .contact's own height, which
	   doesn't grow to fit this panel — position:absolute content never
	   contributes to an ancestor's height) — on a short window the
	   centred form can need more vertical room than that gives it.
	   overflow-y:auto scrolls WITHIN the panel itself when that happens,
	   rather than clipping the form with no way to reach the rest of it
	   (confirmed live: .contact's own overflow-y:auto alone did NOT
	   extend its scrollable area to cover this — an absolutely
	   positioned descendant's own overflowing content doesn't reliably
	   bubble up through Chrome's scrollable-overflow calculation here,
	   so the scroll container needs to be the element whose content is
	   actually overflowing, not an ancestor further up). */
	overflow-y: auto;
	padding: 40px var(--gutter);
	background: rgba(165, 165, 165, 0.01);
	-webkit-backdrop-filter: blur(14px);
	backdrop-filter: blur(14px);
}

/* The embedded HubSpot form itself is styled generically by hubspot-
   popup.css's ".hs-form" rules (shared with the popup system's own
   forms, submit button included — white with dark text there too) —
   this just constrains the target's width within the panel, same width
   the old static form used. */
.hs-form-target {
	width: 100%;
	max-width: 34.625rem;
}

@media (max-width: 900px) {
	.contact {
		min-height: auto;
	}

	/* Figma's own mobile frame (node 4014:26304) still uses this same
	   video, just blurred beyond recognition and fixed in place behind
	   the content as it scrolls — not reserving its own 60vh block the
	   way the old default did (that was just empty dead space above the
	   actual content, not this effect).
	   Two things that both looked fine in headless-Chrome testing broke
	   on real devices, so read this before changing it back:
	   1) filter:blur() applied directly to the <video> element — a real
	      Chromium compositor bug, not just a testing artifact: confirmed
	      live via raw pixel sampling that the video's own dark colour was
	      bleeding straight through .contact__input's fully opaque white
	      background above it, ignoring z-index entirely. Video elements
	      often composite via a separate hardware path a plain `filter`
	      doesn't reliably fit into.
	   2) backdrop-filter on .contact__intro/.contact__panel instead
	      (blurring the fixed video behind them, without filtering the
	      video itself) — this is exactly what .contact__panel's own
	      desktop styling already does, and it looked right in this same
	      headless testing, but backdrop-filter capturing a
	      position:fixed backdrop specifically is a real, longstanding
	      Safari inconsistency; on a real device it rendered as a flat
	      grey panel instead (the tint colour with nothing blurred behind
	      it to show through).
	   The blur lives on .contact__video-blur instead (page-contact.php) —
	   a plain wrapping div, not a video and not depending on
	   backdrop-filter's fixed-content support, so the blur just always
	   renders directly, everywhere. transform:scale keeps the blur's own
	   sampling-outside-the-box edge artifact safely past the viewport
	   edge instead of showing as a faint lighter border. */
	.contact__video-blur {
		display: block;
		position: fixed;
		inset: 0;
		overflow: hidden;
		filter: blur(60px);
		transform: scale(1.2);
	}

	.contact__video {
		position: static;
	}

	/* Both content regions sit on their own translucent tint over that
	   same fixed, already-blurred video — dark up top (matching the
	   heading/details' white text and Figma's own darker top-of-frame
	   look), lighter behind the form further down (matching Figma's fade
	   toward white there): a two-tone approximation of Figma's own
	   smoother gradient rather than a literal multi-stop reproduction of
	   it. No backdrop-filter needed on either — the video is already
	   blurred at the source now, so a plain translucent background is
	   enough to let its colour show through softly. */
	.contact__panel {
		/* relative, not static — a statically-positioned element can't use
		   z-index at all (the property is simply ignored on it), so this
		   section's own z-index:1 (base rule, unconditional) was doing
		   nothing and the fixed video-blur wrapper — a genuinely
		   positioned element — was painting above it regardless, letting
		   crisp video colour show straight over what should have been
		   opaque content. relative with no offset keeps it exactly where
		   normal flow already puts it, purely to make that z-index
		   actually take effect. The desktop rule above also sets
		   inset:0 + left:41.25% — ignored under position:static, but
		   inset/top/right/bottom/left all become real, ACTIVE offsets the
		   moment an element is positioned at all (even just relative),
		   so without resetting it back to auto here this shifted/resized
		   the panel into that same desktop left/right split instead of a
		   plain full-width block. */
		position: relative;
		inset: auto;
		padding: clamp(40px, 8vw, 64px) var(--gutter);
		-webkit-backdrop-filter: none;
		backdrop-filter: none;
	}

	.contact__intro {
		/* Same fix as .contact__panel above, same reason — the desktop
		   rule's own left/bottom offsets (meant for its absolute
		   positioning there) would otherwise become active here too. */
		position: relative;
		inset: auto;
		max-width: none;
		/* Clears the fixed header (measured live elsewhere on this site at
		   ~75.6px tall) with a little room to spare. */
		padding: 5.5rem var(--gutter) 16px;
		text-align: center;
	}

	/* Just heading + form on mobile — the phone/email/address is already
	   repeated in the footer below (now shown here, see .site-footer
	   override further down), so keeping it here too was redundant and
	   pushed the form further down the page than it needed to be. */
	.contact__details,
	.contact__address,
	.contact__socials {
		display: none;
	}

	.contact__panel {
		padding-top: 24px;
	}

	/* No footer on desktop (Figma, see page-contact.php's own comment) —
	   but on mobile the page now ends right after the form with nothing
	   else below, so the footer is brought back here to give it somewhere
	   natural to scroll to. Its own opaque background (var(--color-ink),
	   base.css) was showing the fixed blurred video straight through it
	   though — not a background problem (it's already fully opaque), a
	   stacking one: .contact__video-blur is position:fixed with
	   z-index:auto, and per the CSS painting-order spec, ANY positioned
	   element at that stacking level paints above plain static in-flow
	   content regardless of DOM order, so the footer (position:static)
	   was losing to it despite coming later in the markup. Giving the
	   footer its own position (relative, no offset — purely to opt it
	   into that same "positioned" paint step) puts it back in normal DOM-
	   order competition with the video layer, where it correctly wins. */
	body.is-contact-page .site-footer {
		display: block;
		position: relative;
	}
}