/* ==========================================================================
   Glenelly base -- font faces, type scale, focus, motion
   ========================================================================== */

/* --------------------------------------------------------------------------
   Font faces

   Elementor's Custom Fonts block in post-6.css declares four Futura faces.
   Three have `src: ;` -- invalid, so the parser drops those rules and Futura
   currently has exactly ONE usable face. The valid one ships a 2011-era
   five-format stack (eot, eot?#iefix, woff2, woff, ttf, svg#Futura) with
   hardcoded absolute URLs; the .svg is a 247-byte stub. On production those
   URLs are http:// on an https:// site -- a mixed-content risk this removes.

   Same family + same descriptors declared LATER wins, so this supersedes it.

   Two rules, both pointing at the SAME file, and the split matters:

   1. The first has descriptors identical to Elementor's (family + style +
      weight 400), which is what identifies an @font-face rule. Declared later,
      it SUPERSEDES theirs rather than joining the family alongside it. Without
      this the browser downloads Futura twice -- once from Elementor's rule for
      weight-400 text and once from ours for anything bolder. Verified: two
      requests before this split, one after.

   2. The second covers 500-900 so the 38 per-widget rules that hardcode
      .elementor-button{font-weight:bold} resolve to the real light file
      instead of a synthesized smear, without touching a single one of them.
      Same URL, so it costs no extra request.

   Relative url() resolves against this stylesheet's own URL, so these work
   identically on Local and production with no domain hardcoding.
   -------------------------------------------------------------------------- */
@font-face {
	font-family: "Futura";
	font-style: normal;
	font-weight: 400;
	font-display: swap;
	src: url("fonts/Futura-BT-Light.woff2") format("woff2");
}

@font-face {
	font-family: "Futura";
	font-style: normal;
	font-weight: 500 900;
	font-display: swap;
	src: url("fonts/Futura-BT-Light.woff2") format("woff2");
}

/* Shippori Mincho, latin/400 only -- the only face this site can render.
   Extracted verbatim from the 610-block, 581 KB file Elementor caches, which
   is suppressed in glenelly-design-system.php. */
@font-face {
	font-family: "Shippori Mincho";
	font-style: normal;
	font-weight: 400;
	font-display: swap;
	src: url("fonts/shippori-mincho-latin-400.woff2") format("woff2");
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA,
		U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191,
		U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

/* Belt to the token braces: even where a stray bold or italic survives, render
   the real face rather than a synthesized one. Safe globally -- where a genuine
   face exists (Montserrat ships real 100-900 plus italics) this has no effect. */
body[class*="elementor-kit-"] {
	font-synthesis-weight: none;
	font-synthesis-style: none;
}

/* But <strong> and <em> in body copy must not become invisible. Remap them to
   Montserrat, which has real 600 and real italic faces. Emphasis stops being a
   smear and becomes an actual different face -- a net improvement, not a
   workaround. Extend this selector list if bold text is found in other widgets. */
body[class*="elementor-kit-"] .elementor-widget-text-editor :is(strong, b),
body[class*="elementor-kit-"] .elementor-widget-theme-post-content :is(strong, b),
body[class*="elementor-kit-"] .entry-content :is(strong, b) {
	font-family: "Montserrat", sans-serif;
	font-weight: 600;
}

body[class*="elementor-kit-"] .elementor-widget-text-editor :is(em, i),
body[class*="elementor-kit-"] .elementor-widget-theme-post-content :is(em, i),
body[class*="elementor-kit-"] .entry-content :is(em, i) {
	font-family: "Montserrat", sans-serif;
	font-style: italic;
}

/* --------------------------------------------------------------------------
   Type scale

   h2-h4 and body ship as TOKEN redefinitions in tokens.css so Elementor's own
   media queries pick them up for free. h1, h5 and h6 need element rules,
   because no token exists for them.

   Currently the scale has three owners: h1's family comes from the Elementor
   kit while its size comes from Astra; h5/h6 have no kit rule at all and fall
   through to Astra's Montserrat while h1-h4 are Shippori.
   -------------------------------------------------------------------------- */

/* h1 has no font-size anywhere in the kit; Astra's h1{font-size:40px} (0,0,1)
   fills the gap by accident.

   :not(.elementor-heading-title) scopes this to the h1s Elementor is NOT
   sizing -- WooCommerce product titles, archive titles, single posts.
   Elementor heading widgets carry per-widget sizes at (0,3,0) and keep
   winning, which is correct: an explicit editor choice should beat a system
   default.

   Astra steps h1 40px -> 30px at its tablet breakpoint, a hard jump. The clamp
   reproduces both endpoints exactly (40px at 1440, 30px at 360) and smooths
   everything between. Line-height 1.4 matches Astra's 56/40 and 42/30. */
body[class*="elementor-kit-"] h1:not(.elementor-heading-title) {
	font-size: clamp(30px, 26.6667px + 0.9259vw, 40px);
	line-height: 1.4;
}

/* h5/h6 have no kit rule at all, so they drop out of the brand serif into
   Astra's Montserrat while h1-h4 are Shippori. Bring them into the system.

   This is a deliberate design change, not a size fix -- the sizes below
   preserve Astra's measured desktop values exactly (20px / 16px). */
body[class*="elementor-kit-"] :is(h5, h6) {
	font-family: "Shippori Mincho", serif;
	font-weight: 400;
	text-transform: uppercase;
	letter-spacing: 0.4px;
}

body[class*="elementor-kit-"] h5 {
	font-size: clamp(17px, 16px + 0.2778vw, 20px);
	line-height: 1.2;
}

body[class*="elementor-kit-"] h6 {
	font-size: clamp(14px, 13.3333px + 0.1852vw, 16px);
	line-height: 1.25;
}

/* --------------------------------------------------------------------------
   Focus and motion
   -------------------------------------------------------------------------- */

/* The site currently has no focus styling beyond UA defaults. Reference:
   :focus-visible { outline: 2px solid var(--brand-primary); outline-offset: 2px } */
:focus-visible {
	outline: 2px solid var(--gl-brand-primary);
	outline-offset: 2px;
}

/* Scroll-reveal, ported verbatim from glenelly-blog/app/globals.css.

   These duplicate what Elementor's own entrance animations already do
   (fadeIn/fadeInLeft/fadeInRight/fadeInUp are enqueued on the homepage).
   Ship the classes for parity, but do NOT retrofit them onto pages that
   already use Elementor animations -- you would get two competing opacity
   transitions on the same element. */
.sr-base {
	opacity: 0;
	transition: opacity 0.6s ease-out, transform 0.6s ease-out;
}

.sr-fade-in-left  { transform: translateX(-50px); }
.sr-fade-in-right { transform: translateX(50px); }
.sr-fade-in-up    { transform: translateY(40px); }
.sr-fade-in       { transform: none; }
.sr-visible       { opacity: 1; transform: translate(0, 0); }

@media (prefers-reduced-motion: reduce) {
	.sr-base {
		opacity: 1;
		transform: none;
		transition: none;
	}
}

/* Required by the +/-50px slide-ins, which would otherwise cause horizontal
   scroll. clip rather than hidden so it does not create a scroll container. */
html {
	overflow-x: clip;
}