/* Phase 2 fixes — deliberate corrections layered ON TOP of the Webflow export.
 *
 * Loaded last in Layout.astro, after tonemaki-tm.webflow.css, so these rules win
 * on equal specificity. Kept in its own file rather than hand-edited into the
 * generated Webflow CSS: that file is a build artifact of the export, and an
 * inline edit there would be invisible, unreviewable, and lost the moment the
 * export is refreshed.
 *
 * Every rule here must say WHAT it fixes and WHY, with the measurement behind it.
 */

/* ------------------------------------------------------------------- marquee
 * Five of the seven marquees are driven by GSAP (Layout.astro): a real tween's
 * `x` can be read, paused and hijacked by a pointer drag the way a running
 * CSS animation cannot, which is what real drag needs. `data-duration` and
 * the draggable/non-draggable split are authored at port time — see
 * osmoMarquee in port-page.mjs — so there is nothing to tune here. No CSS
 * rule is needed for their animation; GSAP sets `transform` via inline style
 * directly, and the export's own `.marquee-wrapper`/`.marquee-item` rules
 * already provide the flex row, gap and grab-cursor artwork
 * (`.grab-element`'s custom cursor image) unchanged.
 *
 * The other two — hero-marquee and section_hero_banner, both
 * [data-tm-marquee-css]/-css-list — are the exception: the only two marquees
 * above the fold, and they run on the plain CSS @keyframes rule below
 * instead. Measured: with hero-marquee alone on the same GSAP tween as the
 * rest, Lighthouse attributed 0.238 of a 0.246 total CLS to its <ul> alone,
 * because an unscrolled trace only ever observes above-the-fold marquees
 * moving. Moving just that one off GSAP first only got mobile CLS to
 * ~0.10-0.11 — because section_hero_banner is also above the fold and
 * immediately became the new dominant culprit (0.102 of it) for the
 * identical reason. Chrome's Layout Instability API exempts a declarative
 * CSS @keyframes animation from CLS scoring but does not exempt a script
 * writing `transform` frame by frame (what the GSAP tween does) — visually
 * identical motion, scored differently. hero-marquee was never draggable on
 * production (data-marquee="normal"), so nothing is lost there;
 * section_hero_banner WAS draggable on production (data-marquee="draggable")
 * — moving it here is a deliberate, confirmed trade of its drag for CLS.
 * Full writeup: PHASE-2-NOTES.md.
 *
 * `--tm-marquee-css-distance`/`-duration`/`-direction` are written once by
 * Layout.astro's CSS-marquee init script, after it clones enough item-sets
 * for coverage and measures the resulting pitch; `-play-state` is toggled by
 * that same script's IntersectionObserver. The keyframe rule itself only
 * applies once `data-tm-marquee-css-ready` is set, so nothing animates (or
 * has to jump) before the distance is known.
 */
@keyframes tm-marquee-scroll-css {
  from {
    transform: translateX(0);
  }
  to {
    transform: translateX(var(--tm-marquee-css-distance, 0px));
  }
}

[data-tm-marquee-css-ready] [data-tm-marquee-css-list] {
  animation-name: tm-marquee-scroll-css;
  animation-duration: var(--tm-marquee-css-duration, 30s);
  animation-direction: var(--tm-marquee-css-direction, normal);
  animation-timing-function: linear;
  animation-iteration-count: infinite;
  animation-play-state: var(--tm-marquee-css-play-state, running);
}

@media (prefers-reduced-motion: reduce) {
  [data-tm-marquee-css-ready] [data-tm-marquee-css-list] {
    animation-name: none;
  }
}

/* ------------------------------------------------------- a11y: colour contrast
 * Three approved brand-colour corrections. Each keeps the brand hue and
 * saturation exactly and only lowers lightness, and each is scoped to the
 * failing context rather than redefining the design token — the tokens are
 * shared with backgrounds (--base-color-brand--makirange is also
 * --background-color--background-tertiary, used 29 times), so redefining them
 * would repaint areas that were never the problem.
 *
 * All measured against the page background #fffbea.
 */

/* "+50" / "+11" awards counters. 48px normal = WCAG large text, needs 3:1.
 * #ff7145 measured 2.63. #ff5a27 is the same hue/sat at 57.7% lightness
 * instead of 63.5%, measuring 3.00. */
.number-tag.text-color-makirange {
  color: #ff5a27;
}

/* "Most Popular" pricing tag. 14px bold is NOT large text, so it needs 4.5:1.
 * #fa3c23 measured 3.53. #e41f05 keeps hue/sat at 45.8% lightness, giving 4.50. */
.most-popular-tag-card .text-size-small.text-weight-bold.typography-allcaps {
  color: #e41f05;
}

/* Struck-through "not included" feature rows. 14.4px normal, needs 4.5:1.
 * #bbbaad measured 1.88 — by far the worst on the page, and the one most
 * likely to matter, since a struck-through item still has to be readable to
 * tell you what you are NOT getting. #767562 keeps hue/sat, gives 4.51. */
.text-style-strikethrough.text-color-makibeigen3 {
  color: #767562;
}

/* Pricing card's small labels ("Billed p/mo.", "EUR15897/Qtr.", "(qtr)",
 * "SAVE x%"), one set per card, keyed to that card's brand colour.
 *
 * An earlier version of this rule ALSO set font-size:18.66px/700 to make these
 * WCAG "large text" and so lower the contrast bar from 4.5:1 to 3:1. That was
 * reverted: the wider labels collided with their neighbours in the Quarterly
 * tab at 412px ("(qtr)" overlapping "SAVE 16%" by 12x24px). Verified by
 * toggling the rule - with it, two overlaps; without it, none.
 *
 * Size is now left exactly as the export has it. NOTE this means the colours
 * below sit at 3.0:1 against #fffbea while 14px normal text requires 4.5:1,
 * so `color-contrast` does not pass on these four labels. Clearing 4.5:1 at
 * 14px needs #da3400 (orange) and #e90000 (pink) - a visibly deeper, redder
 * pair, and two new values in the palette. That trade is a brand decision, so
 * it is left open rather than made here.
 *
 *     makiwar  (green)  #38582c  7.78:1  unchanged, already compliant
 *     makirange(orange) #ff7145  2.63:1  -> #ff5a27  3.00:1
 *     makituna (pink)   #ff7575  2.51:1  -> #ff5656  3.01:1
 */
.home_logo-list_content .text-size-small.text-color-makirange {
  color: #ff5a27;
}

.home_logo-list_content .text-size-small.text-color-makituna {
  color: #ff5656;
}

/* ------------------------------------------- button character stagger (restored)
 * The Feb-2025 site ran the Flowbase "GSAP Text Hover" booster:
 *
 *     @flowbase-co/boosters-gsap-text-hover@1.0.2/dist/gsap-text-hover.js
 *
 * It is loaded by the archived snapshot and absent from the current export, so
 * the effect disappeared — but its attributes (fb-text-hover, -type, -speed)
 * are still on 45 elements, orphaned. Those attributes are kept as the selector
 * hook here: they are the site's own record of which elements opted in.
 *
 * Reproduced from the shipped script's own values, with type="1" speed="2" as
 * the markup sets, rather than from Osmo's defaults:
 *
 *     duration   0.8s / timeScale(2)      = 0.4s effective
 *     ease       power3.inOut             ≈ cubic-bezier(.76, 0, .24, 1)
 *     stagger    0.03s per character
 *     motion     yPercent: -100 — a vertical roll, the character sliding up and
 *                out while a duplicate slides in beneath it
 *
 * The technique is Osmo's (CSS transitions over per-character spans, no GSAP);
 * only the timing and motion are Flowbase's. Hover-only, transform-only, so it
 * cannot shift layout — the characters are absolutely stacked inside a
 * fixed-size inline-block, and the element's own box never changes.
 */
[fb-text-hover] .tm-char {
  display: inline-block;
  position: relative;
  overflow: hidden;
  vertical-align: top;
}

[fb-text-hover] .tm-char__in,
[fb-text-hover] .tm-char__out {
  display: inline-block;
  transition: transform 0.4s cubic-bezier(0.76, 0, 0.24, 1);
  transition-delay: calc(var(--tm-i, 0) * 0.03s);
  will-change: transform;
}

/* The incoming copy waits one line-height below until hover. */
[fb-text-hover] .tm-char__in {
  position: absolute;
  inset: 0;
  transform: translateY(100%);
}

[fb-text-hover]:hover .tm-char__out,
[fb-text-hover]:focus-visible .tm-char__out {
  transform: translateY(-100%);
}

[fb-text-hover]:hover .tm-char__in,
[fb-text-hover]:focus-visible .tm-char__in {
  transform: translateY(0);
}

/* Respect a reduced-motion preference: the duplicate layer is pointless without
 * the roll, so the text simply sits still. */
@media (prefers-reduced-motion: reduce) {
  [fb-text-hover] .tm-char__in,
  [fb-text-hover] .tm-char__out {
    transition: none;
  }
  [fb-text-hover]:hover .tm-char__out,
  [fb-text-hover]:focus-visible .tm-char__out {
    transform: none;
  }
  [fb-text-hover] .tm-char__in {
    display: none;
  }
}

/* ------------------------------------------------ a11y: heading order (h6->div)
 * The 19 tool-name labels ("Adobe", "Figma", "Rive", …) were marked up as <h6>
 * inside the tools grid, directly after an <h4> — a skipped level, which is
 * what `heading-order` flagged. They are labels, not document structure, so the
 * port now emits them as <div>. Browsers give <h6> font-weight:700 by default
 * and <div> 400, and nothing in the export's CSS sets it, so it is restored
 * here; everything else (10.4px, line-height 20px, colour, flex) already comes
 * from the .tool-tips-apps class and is unchanged. Verified identical box:
 * 16x20 either way. */
.tool-tips-apps {
  font-weight: 700;
}

/* --------------------------------------------------- testimonial card height
 * `.testimonial-grid` was a fixed `height: 11.75rem`, which cropped the longer
 * quotes. Swapped for a min-height so the card keeps its floor but grows with
 * its content. `height: auto` is needed alongside it because the export's rule
 * is equal specificity and would otherwise still apply.
 */
.testimonial-grid {
  height: auto;
  min-height: 11.75rem;
}