/* Headings aim for Apple's look: -apple-system/BlinkMacSystemFont aren't
   fonts, they're a standing instruction to the browser to use the OS's own
   UI font - on macOS/iOS Safari and Chrome that resolves to actual San
   Francisco, with zero licensing issue since nothing is downloaded or
   redistributed (Apple ships SF Pro on the device; we're just asking for
   it). Everywhere else that instruction resolves to nothing, so the chain
   falls through to Helvetica Neue/Helvetica (macOS/older Safari without the
   keyword support), then to self-hosted Sora as the real fallback for
   Windows/Linux/Android, then Arial. Apple's own headings run at weight
   600 with slightly negative letter-spacing, not the 700-800 an all-caps
   display face like Sora defaults to reading as "bold" - matched below.

   Other text (body copy, subtext under headings, UI labels) stays on
   Inter, which is close enough to SF Pro's metrics for body use that it's
   commonly used as its stand-in already. The exported markup sets its
   font-family through Framer's own preset system - literal values on
   scoped preset classes, plus var(--framer-font-family) chains defined
   inline per rich-text block - so a plain unscoped override loses to
   those. Both rules below use !important; the heading rule is written
   second and targets a more specific (type) selector than the bare
   universal selector used for body text, so it always wins for h1-h6 and
   everything nested inside them, regardless of Framer's own declarations. */

* {
  font-family: "Inter", sans-serif !important;
}

h1, h1 *,
h2, h2 *,
h3, h3 *,
h4, h4 *,
h5, h5 *,
h6, h6 * {
  font-family: -apple-system, BlinkMacSystemFont, "SF Pro Display", "Helvetica Neue", Helvetica, "Sora", Arial, sans-serif !important;
  font-weight: 700 !important;
  letter-spacing: -0.015em;
}

/* Footer "Brand and Contact" (logo + tagline) vs "Navigation" (link list)
   columns are set by the original design to align-items:flex-end (bottom
   align). Since the nav column runs taller than the shorter brand column,
   the logo visibly drops well below the top of the nav links instead of
   sitting level with them. Top-align instead for a conventional footer
   layout - independent of theme, so this lives in the global stylesheet. */
.framer-YZ24Q .framer-s06j6o {
  align-items: flex-start !important;
}

/* App Store / Google Play badges, made larger per request. They sit in a
   Framer-fixed-width row with the two buttons packed edge-to-edge (zero
   spare width - just their combined width plus a 16px gap), so growing
   them via width/padding would overflow that row.

   This row appears in three places (hero, a left-aligned feature section,
   the footer) and only the hero centers it with even margin on both
   sides - the other two sit flush against the left edge of a text column.
   An earlier version of this rule scaled each BUTTON individually, anchored
   to its own outer edge so the pair grew apart instead of overlapping in
   the middle - correct for the centered hero, but in the left-aligned
   spots that made the App Store button's left edge grow straight past the
   surrounding text's own left margin, visibly sticking out of the block.

   Scaling the ROW as one unit fixes that: both buttons and the gap between
   them grow together at the same proportions (so they still never
   overlap), and anchoring at the row's own left edge means growth only
   ever extends rightward - which lines up with the left-aligned text in
   the feature section and footer.

   The row itself can't be the scaled element though - it's one of
   Framer's own entrance-animation targets, so it carries a live inline
   `transform` that a stylesheet rule (even !important) can't reliably win
   against. button-scale-fix.js wraps it in a plain .aimore-store-scale-wrap
   div at runtime and the transform goes there instead, one level out from
   Framer's animated element.

   The row's width is also fluid below the 810px breakpoint (see that
   script's own comment), so a fixed scale here would be safe at some
   viewport widths and overflow at others - button-scale-fix.js computes
   and sets `transform` itself, per element, from how much room is actually
   free; this rule only supplies the box model, not the transform value. */
.aimore-store-scale-wrap {
  display: inline-block;
}

a[href*="apple.com/app-store"],
a[href*="play.google.com/store"] {
  transition: filter 0.2s ease;
}

a[href*="apple.com/app-store"]:hover,
a[href*="play.google.com/store"]:hover {
  filter: brightness(1.08);
}

@media (prefers-reduced-motion: reduce) {
  a[href*="apple.com/app-store"],
  a[href*="play.google.com/store"] {
    transition: none;
  }
}

/* Footer legal links ("Child Safety Standards | Terms of Service | Privacy
   Policy") overflow the page on narrow viewports - confirmed present on
   the original aimorelove.com too (flex-wrap:nowrap holds all three links
   plus separators on one line regardless of available width), not
   something introduced here. Fixing it anyway since it silently pushes
   "Privacy Policy" out past the visible area on mobile. Scoped to narrow
   viewports only so the wider-screen single-line layout is untouched. */
@media (max-width: 500px) {
  [data-framer-name="Legal"] {
    flex-wrap: wrap !important;
    row-gap: 8px !important;
  }
}