/* ==========================================================================
   SPU Stainless - motion.css
   The one sanctioned addition to the approved design: a subtle reveal as each
   page section scrolls into view. Requested by the client ("a nice lazyload or
   subtle animation on sections, to just not make it feel so static").

   Enqueued on EVERY front-end view, after style.css. It is deliberately not in
   style.css (the approved design's own stylesheet, which stays provably
   untouched) and not in extensions.css (which is scoped to undesigned states
   and is not loaded on the blog listing, category archives or 404).

   THREE PROPERTIES OF THIS FILE, ALL DELIBERATE

   1. It cannot hide anything on its own. Every rule below is gated on
      html.spu-motion, and that class is added by assets/js/motion.js - the
      same file that reveals the sections again. If the script is missing,
      blocked, or the browser has no IntersectionObserver, the class never
      lands and every section renders exactly as approved.

   2. It is wrapped in prefers-reduced-motion: no-preference. A visitor who
      asks for reduced motion gets no fade and no movement, and a browser too
      old to understand the query drops the whole block, which again means
      "fully visible".

   3. The settled state is pixel-identical to the approved design. Only opacity
      and a 12px translateY are touched, so nothing reflows, and when a section
      has finished revealing it computes to opacity 1 / transform none /
      will-change auto - no leftover transform, so no stacking or containing
      context that could change how the sticky header renders.

   TWO KINDS OF REVEAL
   Most bands reveal as a band. Four bands on the front page - the five
   install steps, the application cards, the certification cards and the FAQ -
   carry data-spu-items instead, which takes the band out of the band-level
   reveal and hands the reveal to the pieces inside it, one after another. A
   whole band fading as one piece reads as nothing at all on those bands: they
   are tall, so the fade is over while the band's top edge is still crossing
   the fold and the visitor never sees it. The client asked for the pieces.

   NUMBERS
   rise 12px, duration 520ms, easing cubic-bezier(0.16, 0.84, 0.44, 1)
   (ease-out). Bands stagger 70ms within one batch, capped at two steps;
   pieces inside a band stagger 90ms, capped at five steps, so up to six of
   them come in one by one over 450ms.

   THE FAQ COLUMN
   The only layout addition: on desktop the FAQ band's left-hand column holds
   still while the questions scroll past it. It is deliberately NOT gated on
   html.spu-motion or on reduced motion, because it is a layout request, not
   an animation, and it must keep working with JavaScript switched off.

   @package spu-stainless
   ========================================================================== */

@media ( prefers-reduced-motion: no-preference ) {

	/* The pending state. `main section` is every page section of every
	   template; the design has no nested <section> and none in the header or
	   footer, so this is exactly the set of sections. */
	html.spu-motion main section {
		opacity: 0;
		transform: translateY( 12px );
	}

	/* The first two sections of every view are the ones that can be on the
	   first screen on load, so they are never hidden at all - a visitor can
	   never land on a blank page, and there is no hidden-then-shown blink
	   while the script measures the viewport. */
	html.spu-motion main > div > section:nth-of-type( -n+2 ) {
		opacity: 1;
		transform: none;
	}

	/* Revealing. */
	html.spu-motion main section.spu-reveal-in {
		opacity: 1;
		transform: none;
		transition: opacity 520ms cubic-bezier( 0.16, 0.84, 0.44, 1 ), transform 520ms cubic-bezier( 0.16, 0.84, 0.44, 1 );
		will-change: opacity, transform;
	}

	/* Revealed, and finished with. Each section reaches this state once and
	   never leaves it, so nothing re-animates on the way back up. */
	html.spu-motion main section.spu-reveal-done {
		opacity: 1;
		transform: none;
		transition: none;
		will-change: auto;
	}

	/* ------------------------------------------------------------------
	   Bands that reveal their contents instead of themselves.
	   The band is taken straight back out of the pending state above, so
	   its heading, rules and background are never hidden for a moment.
	   ------------------------------------------------------------------ */
	html.spu-motion main section[data-spu-items] {
		opacity: 1;
		transform: none;
	}

	/* The pieces inside such a band. Each one waits for its own position on
	   the page, which is the whole point: on a tall band the visitor is
	   looking straight at them when they arrive. */
	html.spu-motion main [data-spu-item] {
		opacity: 0;
		transform: translateY( 12px );
	}

	html.spu-motion main [data-spu-item].spu-reveal-in {
		opacity: 1;
		transform: none;
		transition: opacity 520ms cubic-bezier( 0.16, 0.84, 0.44, 1 ), transform 520ms cubic-bezier( 0.16, 0.84, 0.44, 1 );
		will-change: opacity, transform;
	}

	html.spu-motion main [data-spu-item].spu-reveal-done {
		opacity: 1;
		transform: none;
		transition: none;
		will-change: auto;
	}

}

/* Printing, and saving as PDF, which is the same thing. A printer gets no
   scroll events, so any section the visitor had not yet scrolled to would
   still be hidden and would print as a blank stretch of paper. Outside the
   reduced-motion block on purpose, so it applies either way. */
@media print {

	html.spu-motion main section,
	html.spu-motion main [data-spu-item] {
		opacity: 1 !important;
		transform: none !important;
		transition: none !important;
	}

}

/* ==========================================================================
   The FAQ band's left-hand column, desktop only.

   The client asked for the "Questions we get asked" column to hold still
   while the questions scroll past it. 961px is the approved design's own
   breakpoint - its stylesheet switches the navigation at 960px - so this
   never applies on a tablet or a phone, where that band is a single column
   anyway. The 96px offset is the design's own scroll-margin-top, which is
   what clears the sticky navigation bar.

   Nothing moves until the visitor scrolls: a sticky element sits at its
   normal place until its offset is reached, so the band looks exactly as
   approved on arrival and in a screenshot. The column is a grid item, so it
   is held inside its own grid area and stops at the bottom of the questions
   rather than floating on over the next band. Nothing in its ancestry sets
   overflow, which would have disabled it.

   Deliberately outside the reduced-motion and html.spu-motion gates: this is
   layout, not animation, and it must work with JavaScript switched off.
   ========================================================================== */
@media ( min-width: 961px ) {

	main [data-spu-sticky] {
		position: sticky;
		top: 96px;
	}

}