/*
 * THE FRONT-END DOCUMENT SHELL: the page scrolls inside .wp-site-blocks.
 *
 * Deliberately NOT in style.css. That stylesheet is also loaded into the block
 * editor's canvas iframe via add_editor_style(), and pinning html/body to the
 * viewport with overflow:hidden there would leave the editor unable to scroll
 * the post being edited. These rules describe the real page's outer shell,
 * which the canvas has no counterpart for, so they ship as their own stylesheet
 * and are enqueued on the front end only (see functions.php).
 *
 * WHY THE PAGE DOES NOT SCROLL THE DOCUMENT
 * iOS Safari slides its address bar in and out in reaction to scrolling THE
 * DOCUMENT, and each time it does the visible viewport changes height in the
 * middle of a scroll: the layout shifts under the reader's finger and every
 * scroll-driven animation here has its reference height moved (measured — see
 * notes/mobile-fixes.md; the Matter Rain replay and the over-tall hero were
 * both this). Choosing between vh/svh/dvh only ever treats the symptom.
 *
 * So the document is taken out of the equation: html/body are pinned to the
 * viewport and clipped, and every pixel of scrolling happens inside
 * .wp-site-blocks — WordPress's own root wrapper on any block theme, not markup
 * this theme invents. With a document that never scrolls, the browser chrome
 * has nothing to react to and simply never moves.
 *
 * What still works exactly as before, and why:
 *  - position:fixed (the nav bar, the contact badge) — overflow does not make an
 *    ancestor the containing block for fixed, so they still track the viewport
 *    and are not clipped by the container.
 *  - position:sticky (pinned-section, .s3d-pin) — sticks to its nearest
 *    scrollport, which is now this container instead of the document.
 *  - IntersectionObserver with root:null — still measures against the viewport,
 *    and correctly accounts for the container clipping its contents.
 * What does NOT: window.scrollY / documentElement.scrollHeight / window scroll
 * events. Everything on the site that reads those goes through
 * assets/js/scroll-root.js instead.
 */

html,
body {
	height: 100%;
	height: 100svh;
	overflow: hidden;
	/* NO overscroll-behavior here. It was added as insurance and it is the one
	   thing that matches the report word for word — "like it drags the edges of
	   a container that wants to scroll and isn't allowed to". On iOS that
	   property suppresses the rubber-band, so a gesture that would have bounced
	   gets stopped dead against the edge instead. There is nothing outside to
	   chain to anyway: the body is fixed. */
}

/*
 * position:fixed as well as overflow:hidden, because on iOS Safari
 * overflow:hidden on the document is NOT a scroll lock — it clips, but the
 * document can still be scrolled programmatically and still has a scrollable
 * overflow area, and Safari moves its toolbars in response. Reported from the
 * phone: the BOTTOM bar shakes while scrolling, which only happens when the
 * document itself moves. Pinning the body takes that last possibility away.
 * It does not affect the fixed overlays: position:fixed on an ancestor does not
 * make it the containing block for fixed descendants (only transform, filter
 * and perspective do).
 */
body {
	position: fixed;
	inset: 0;
	width: 100%;
	/* Keep the base surface INSIDE the body's own paint, not on the canvas.
	   See the html rule below — this is the half that actually gets blended
	   against; without it the declaration would just be propagated away. */
	background-color: var( --wp--preset--color--base, #fafafa );
}

/*
 * GIVE THE ROOT A BACKGROUND, SO THE BODY STOPS GIVING AWAY ITS OWN.
 *
 * This one line is what keeps the nav bar's mix-blend-mode:difference alive,
 * and it is repaying a debt this very file created. Reported from the phone:
 * over Services the bar rendered WHITE instead of inverting to black.
 *
 * The chain, measured in headless Chromium at 1440x900 (glyph luminance in the
 * nav strip, page background 250):
 *   - `position: fixed` above makes the body a stacking context (fixed always
 *     does). The nav is a child of the body — scroll-root.js lifts it out of
 *     the scroll container — so from then on it can only blend with what is
 *     painted INSIDE that context.
 *   - CSS propagates the body's background to the canvas whenever the root
 *     element has none, and the canvas is painted OUTSIDE the body's box. So
 *     the base colour left the group the nav blends with.
 *   - Sections that carry their own background (the hero, Our Team) kept
 *     inverting correctly, because those paint inside the body. Sections that
 *     are transparent and simply show the base colour through (Services,
 *     Events) had nothing left underneath: nav 250-255 over a 250 background,
 *     i.e. white ink on white, exactly as reported.
 *
 * Declaring a background on the root stops the propagation, so the body's
 * background stays where it was written and the nav has its canvas back:
 * measured 250 -> 5 over Services and Events, hero and Our Team unchanged.
 *
 * Nothing about the page's appearance changes — the same colour is painted in
 * the same place, one box further in. Point 4 of the nav-bar comment in
 * style.css ("A SOLID BASE CANVAS") is the rule this restores.
 */
html {
	background-color: var( --wp--preset--color--base, #fafafa );
}

.wp-site-blocks {
	/* The admin bar (logged-in users only) pushes the whole page down; without
	   subtracting it the bottom of the scroll container would sit off-screen and
	   the last stretch of the page would be unreachable. The variable is
	   WordPress's own and is simply absent for visitors, so this is plain 100svh
	   for everyone who is not editing. */
	height: calc( 100svh - var( --wp-admin--admin-bar--height, 0px ) );
	overflow-x: hidden;
	overflow-y: auto;

	/*
	 * UNA BARRA DISCRETA EN WINDOWS, SIN ROMPER macOS.
	 *
	 * Se usan las propiedades ESTÁNDAR (`scrollbar-width` / `scrollbar-color`) y
	 * no `::-webkit-scrollbar`, y la diferencia no es de estilo: dar cualquier
	 * regla `::-webkit-scrollbar` obliga a Chromium a abandonar la barra
	 * FLOTANTE de macOS y dibujar una clásica que ocupa sitio. O sea, el atajo
	 * habitual para «hacerla bonita» le empeora la web a quien no tenía el
	 * problema. Las estándar solo la adelgazan donde ya existe.
	 *
	 * El gris se elige contra el fondo base y no contra cada sección: la barra
	 * está fuera del flujo y pasa por encima de secciones claras y oscuras, así
	 * que un gris medio translúcido es lo único que se lee en todas.
	 */
	/*
	 * LA BARRA FINA, SOLO DONDE HAY BARRA. (Restaurado 2026-08-19, acotado.)
	 *
	 * Estuvo aplicada a secas y se sospechó de ella cuando en un iPhone el pie
	 * quedaba tapado: es lo único que el trabajo de Windows puso sobre el
	 * contenedor de scroll, y la trampa que describe el comentario de arriba
	 * —pedir una barra que no sea la del sistema puede hacer que el navegador
	 * abandone la FLOTANTE y dibuje una clásica que ocupa sitio— también puede
	 * darse con las propiedades estándar en navegadores que las soportan desde
	 * hace poco. Resultó no ser la causa (era caché), pero el riesgo era real.
	 *
	 * Ahora va tras `pointer: fine` + `hover: hover`, que es exactamente «hay un
	 * ratón»: Windows, Linux y macOS con ratón. Un móvil o una tablet NUNCA
	 * entran en esta regla, así que la duda no puede volver a plantearse.
	 *
	 * Se mantienen las propiedades ESTÁNDAR y no `::-webkit-scrollbar`, por lo
	 * que explica el comentario de arriba: esa vía fuerza una barra clásica
	 * también en macOS, donde no hay ningún problema que arreglar.
	 */
	/* La declaración vive en el @media de primer nivel que hay justo debajo. */
	/* Deliberately nothing else. `overscroll-behavior: contain` was suppressing
	   the bounce at this box's own ends, and `-webkit-overflow-scrolling: touch`
	   is a legacy iOS property that puts the box on a separate, older scrolling
	   layer with known glitches around `position: sticky` descendants — of which
	   this page has two, full-height and stacked. Both were precautions; iOS has
	   not needed either since 13. */
}
/* Ver el porqué en el comentario de `.wp-site-blocks`, arriba.
   A PRIMER NIVEL y no anidado dentro de la regla: esta es una hoja CSS plana, y
   un `@media` dentro de un selector depende del anidamiento nativo. Funciona en
   navegadores recientes y se descarta en los que no lo soportan — justo los que
   más probable es que estén en el Windows de alguien. */
@media ( hover: hover ) and ( pointer: fine ) {
	.wp-site-blocks {
		scrollbar-width: thin;
		scrollbar-color: rgba( 128, 128, 128, .55 ) transparent;
	}
}


/*
 * flex-shrink:0 is what keeps the layout identical to before. .wp-site-blocks is
 * a flex column (see style.css); the moment it stops being an auto-growing
 * min-height box and becomes a fixed height, its flex children become
 * shrinkable, and a tall section would be squashed down to its own min-height.
 * Pinning shrink to 0 restores exactly the previous behaviour: children keep
 * their natural height and the container scrolls. `.rooa-page-main`
 * (flex:1 0 auto) still grows to push the footer down on short pages.
 */
.wp-site-blocks > * {
	flex-shrink: 0;
}

/* The container carries tabindex="-1" so the keyboard can scroll it (see
   assets/js/scroll-root.js). It is a scroll region, never a control, and it is
   only ever focused programmatically or by a click, so the ring would only ever
   be a full-page box around nothing. Every real control inside keeps its own
   :focus-visible ring untouched. */
.wp-site-blocks:focus {
	outline: none;
}