/*
 * Starter/source compatibility shim.
 *
 * The theme loads two stylesheets written independently: the starter's
 * base.css plus theme.json global styles (WordPress blocks, editor alignment,
 * accessibility) and the design source's rules copied verbatim. Where both
 * touch the SAME element with DIFFERENT properties, "later wins" does not
 * settle it, because they are not competing over one property.
 *
 * Every rule here is a MEASURED conflict, with the measurement recorded.
 * Deleting one should reproduce the difference it describes; if it does not,
 * the rule is stale and should be removed.
 *
 * This is not a place to redesign anything. Slice 1's rule is fidelity before
 * refactoring, and these exist only so the source's own values render.
 */

/*
 * .container width
 *
 * base.css caps it at `max-width: calc(wide-size + 2 * spacing)` = 1232px and
 * adds its own inline padding. The source sizes it with
 * `width: min(1240px, calc(100% - 56px))`. Both applied, so the starter's cap
 * silently clamped the source: measured 1232px against the source's 1240px at
 * 1440, and the footer grid came out 40px narrow.
 *
 * The shell's container is the source's, so the starter's cap and gutter are
 * dropped inside the shell only. base.css keeps them everywhere else.
 */
.site-header .container,
.site-footer .container,
.mega .container {
	max-width: none;
	padding-inline: 0;
}

/*
 * line-height
 *
 * theme.json declares a global `typography.lineHeight` of 1.6 (and 1.2 for
 * headings), which WordPress emits as global styles. The design source sets no
 * global line-height at all, so every shell element computes `normal` there and
 * a fixed multiple here. That single difference was most of the geometry gap:
 *
 *     .logo        43px source  ->  54px  (line-height 54.4px)
 *     .logo-years  22px source  ->  26px  (line-height 17.6px)
 *     .mega       332px source  -> 356px
 *     .nav-links   75px source  ->  78px
 *
 * Restoring `normal` for the shell reproduces the source. Scoped to the shell
 * on purpose: page bodies are still WordPress content and keep theme.json's
 * rhythm, which is the right default for prose.
 */
.site-header,
.site-header *,
.site-footer,
.site-footer *,
.skip-link {
	line-height: normal;
}

/*
 * Footer paragraph rhythm
 *
 * base.css resets `p` margins to `0 0 16px`; the source uses the browser
 * default `16px 0`. Measured on the footer brand blurb. The shell follows the
 * source.
 */
.site-footer p {
	margin-block: 1em;
}

/*
 * THE WORDPRESS ADMIN BAR AND THE STICKY HEADER
 *
 * PROJECT DEFECT, WORDPRESS-ADMIN COMPATIBILITY. Not a design change: a
 * logged-out visitor's page is untouched by everything below.
 *
 * When an administrator is logged in, WordPress prints a fixed toolbar across
 * the top of the frontend and pushes the document down with
 * `html { margin-top }`. A `position: sticky` element does not care about that
 * margin -- it sticks to the VIEWPORT -- so the site header slid underneath the
 * toolbar as soon as the page was scrolled. Measured on /sl/ and /sl/o-nas/,
 * scrolled past the sticky activation point:
 *
 *     1440   toolbar 32px fixed, bottom 32   navbar top 0     overlap 32px
 *     1024   toolbar 32px fixed, bottom 32   navbar top 0     overlap 32px
 *     783    toolbar 32px fixed, bottom 32   navbar top -34   overlap 66px
 *     768    toolbar 46px fixed, bottom 46   navbar top -34   overlap 80px
 *     390    toolbar 46px ABSOLUTE           navbar top -34   no overlap
 *
 * THE HEIGHT COMES FROM WORDPRESS, NOT FROM A BREAKPOINT WE MAINTAIN.
 *
 * Core publishes `--wp-admin--admin-bar--height` on the root element, and it
 * already changes from 32px to 46px at core's own 782px breakpoint. Reading it
 * means this file never has to know that number, and never has to be revisited
 * when core changes it. The fallback is 32px, which is what a browser gets if
 * the property ever disappears -- a small offset rather than none.
 *
 * THE ONE THING CORE DOES NOT PUBLISH is whether the toolbar is FIXED. Below
 * 601px it is `position: absolute` and scrolls away with the page, so offsetting
 * the header there would leave a 46px band of empty page above the navigation
 * for the whole scroll. That switch has no custom property, so the media query
 * below states it -- measured, not assumed: fixed at 601px, absolute at 600px.
 * Under 601px nothing is needed, because nothing overlaps: at the top of the
 * page the header already sits below the toolbar in normal flow, and once
 * scrolled the toolbar is gone.
 *
 * BOTH LEVELS OF THE STICKY MOVE TOGETHER. `#site-header` sticks at
 * `-topbar-h`; adding the toolbar height to that keeps the contact row rolling
 * up exactly as it does for a visitor, and `.navbar` then rests on the toolbar's
 * bottom edge instead of the viewport's.
 */
@media screen and (min-width: 601px) {
	body.admin-bar #site-header {
		top: calc(var(--wp-admin--admin-bar--height, 32px) - var(--topbar-h, 34px));
	}

	body.admin-bar .navbar {
		top: var(--wp-admin--admin-bar--height, 32px);
	}
}