/**
 * Silvalue — header.css
 *
 * Small, dependency-free stylesheet for the structural CSS
 * parts/header-*.html needs that block supports and theme.json cannot
 * express: swapping between the desktop brand mark (a single combined
 * logo image, Customizer-selected per installation, see below) and the
 * compact mobile mark (SILVALUE_Bildmarke_Mobilnavigation.svg's own path,
 * inlined in the template part per CLAUDE.md section 7) at the
 * WordPress-standard 782px breakpoint (docs/nz/home-plan.md 3.9), so
 * editor preview and frontend agree.
 *
 * Loaded after base.css, see functions.php. Colour values reference
 * theme.json tokens only (var(--wp--preset--color--…)); the logo height
 * below is a documented exception — a literal pixel value with no
 * matching design token, same precedent as `.sv-proof-bar{margin-top:
 * -72px}` (patterns.css) and the header CTA's `padding:11px 18px`
 * further down this file.
 */

/* .sv-brand's row layout (logo mark + tagline side by side, vertically
   centred) is given explicit CSS here rather than relying on the
   "sv-brand" wp:group block's own layout:flex attribute. Verified against
   the real rendered page (2026-08-26): WordPress's layout-support
   mechanism (wp_render_layout_support_flag(), wp-includes/block-supports/
   layout.php) injects its generated `is-layout-flex`/`wp-container-core-
   group-is-layout-*` classes onto whichever tag WP_HTML_Tag_Processor's
   next_tag() finds first inside the block's content — normally the
   group's own wrapper, but here that is the `.sv-logo-desktop` anchor
   (raw HTML, not a block) since it is literally the first tag after the
   wrapper's opening tag. The wrapper itself was left without any layout
   classes at all, which would otherwise stack the mark and the tagline
   as block-level content instead of a row. See the matching comment on
   silvalue_site_logo_link_header() in functions.php for the other
   consequence of the same misplacement (a broken href-rewrite regex). */
.sv-brand {
	display: flex;
	align-items: center;
	flex-wrap: wrap;
	gap: var(--wp--preset--spacing--2-xs);
}

/* Header height, moved here from a `dimensions.minHeight` block attribute
   (2026-08-27) so it shares one `:root` custom-property block with
   `--sv-header-logo-height` above instead of living as an inline style
   baked into parts/header-de.html/-en.html — the two need to move
   together (a taller logo needs a taller header) and are easier to keep
   in sync as adjacent CSS custom properties than as an inline attribute
   value edited separately in two template files. `align-items:center` on
   the inner .sv-header-row (unchanged, set via that group's own block
   layout attribute) centres the logo inside this fixed-height box. */
.sv-header {
	min-height: var(--sv-header-height);
}

/* NACHTRAG 2026-09-24 — Betreiberwunsch: Der Header soll auf jeder Seite
   dieselbe Breite/Ausrichtung haben. Bisher wich die Leistungen-Seite (und
   jede andere Nicht-Startseite) vom WordPress-Standardmaß
   (--wp--style--global--wide-size, 1400px) ab: home-redesign.css verbreitert
   auf der Startseite jede ".alignwide"-Gruppe innerhalb eines "constrained"-
   Containers auf 1680px (body.home .is-layout-constrained > .alignwide) —
   eigentlich nur für die Startseiten-Inhaltsabschnitte gedacht, trifft aber
   strukturbedingt auch den (auf jeder Seite identischen) Header, da dessen
   .sv-header-row ebenfalls ".alignwide" innerhalb eines "constrained"-
   Headers ist. Dadurch war nur die Startseite breiter, jede andere Seite
   blieb beim 1400px-Standardmaß.
   Hier stattdessen sitewide und dauerhaft festgelegt (header.css lädt
   bereits unbedingt auf jeder Seite, siehe Dateikopf) — Start-, Leistungen-
   und jede künftige Seite zeigen dadurch exakt dieselbe Header-Breite. Wert
   1680px identisch zu --sv2-content-max (home-redesign.css) und
   --sv2-content-max (services-redesign.css) — bewusst hier erneut
   deklariert statt importiert, dieselbe Begründung wie in
   services-redesign.css (unabhängig ladbare/entfernbare Dateien).
   !important nötig: die WP-Kernregel ".is-layout-constrained > .alignwide"
   hat dieselbe Selektor-Spezifität (zwei Klassen) und würde ohne ein
   zusätzliches Class-/Body-Präfix nicht zuverlässig überstimmt. */
.sv-header > .alignwide {
	max-width: 1680px !important;
}

.sv-logo-mobile {
	display: none;
}

/* ---------------------------------------------------------------------
 * Desktop brand mark (added 2026-08-23 as a live-text reconstruction,
 * replaced 2026-08-26 by a single combined artwork).
 *
 * A live icon + "SILVALUE" text + descriptor text reconstruction (the
 * 2026-08-23 approach) was replaced once four properly proportioned,
 * pre-baked logo files became available: symbol, wordmark and descriptor
 * all in one artwork, with the exact measured ratios (descriptor 34% of
 * the wordmark's height, etc. — see docs/nz/aenderungen.md Runde 9 for
 * the superseded reconstruction's numbers) built into the file itself,
 * so no separate CSS typography values are needed for them any more.
 *
 * Four approved files exist (brand/README.md "Approved production SVG
 * files"): two markets (Forst Consulting / Forestry Consulting) x two
 * text colours (dark/white). The operator picks the one matching their
 * installation's market and the header's light background (dark-text
 * variant) via the "Silvalue – Logo" Customizer control
 * (`silvalue_header_logo_id`, functions.php), rendered through the
 * `[silvalue_header_logo]` shortcode in parts/header-de.html/-en.html —
 * same per-installation-setting mechanism already used for the hero
 * photo and contour overlay.
 *
 * `--sv-header-logo-height` (raised from 45px to 63px, 2026-08-27; raised
 * again to 72px, 2026-09-15) and `--sv-header-height` (raised from 76px to
 * ~95px at the same time as the first logo increase, then to 104px with
 * the second, see `.sv-header` further down) are plain CSS custom
 * properties, not design tokens — grouped in one `:root` block below so
 * both can be retuned together without touching the rules themselves.
 * Width is intentionally never set directly on the image: the file's own
 * 1750:500 (3.5:1) aspect ratio determines it from the height alone, so a
 * future re-export at a different aspect ratio cannot silently distort
 * the logo.
 *
 * Why 45px read as too small: the four combined logo files (unlike the
 * old descriptor-less master logo) carry the wordmark at only 175 of the
 * file's 500 canvas units tall (35%) — the descriptor and the vertical
 * gaps around it take up the rest. At 45px total height the "SILVALUE"
 * wordmark itself was only ~16px tall, not ~26px as the 2026-08-23 live-
 * text reconstruction had it (that version sized the wordmark span
 * directly; this baked-image version only controls the *whole file's*
 * height, wordmark included proportionally). 63px total height puts the
 * wordmark back at ~22px (63 x 0.35), matching that same intent, at a
 * ~220px rendered width (63 x 3.5).
 *
 * 2026-09-15, Betreiberfeedback am gerenderten lokalen Stand ("Schrift im
 * Header und eventuell das Logo recht klein"): 63px still read as small
 * next to the header's other elements once seen on the real page rather
 * than in isolation. Raised to 72px (wordmark ~25px, rendered width
 * ~252px) — header height correspondingly to 104px, keeping the same
 * +32px headroom above the logo height used since 2026-08-27, so
 * `align-items:center` on `.sv-header-row` still centres the taller logo
 * with visibly equal space above and below it. See also the nav/CTA
 * font-size bump (`--wp--preset--font-size--ui`, theme.json) made the same
 * day for the same feedback. ------------------------------------------- */
:root {
	--sv-header-logo-height: 72px;
	--sv-header-height: 104px;
}

/* NACHTRAG 2026-09-28 — Betreiberwunsch: kompakte mobile Headerhöhe,
   ungefähr 72–100px angestrebt. Live nachgemessen (390px-Viewport, nach
   Behebung des Logo-Doppel-Bugs oben in home-redesign.css, der zuvor eine
   Headerhöhe von 202px verursachte): Marke (Icon+Positionszeile) und
   Menü-Schaltfläche+CTA brechen bei dieser Fensterbreite weiterhin in
   zwei Zeilen um (223,85px Zeile 1 + 16px Zeilenabstand + 44,4px Zeile 2
   ≈ 101px Gesamthöhe) — das entspricht bereits dem vom Betreiber
   ausdrücklich erlaubten Ausweg „CTA … unterhalb der primären
   Headerzeile" (siehe auch die eigene, ungestylt bereits vorhandene
   Zwei-Zeilen-Mechanik von .sv-header-row/.sv-header-actions, kein neues
   Markup nötig). --sv-header-height unten auf 88px gesenkt (deutlich
   unter den vollen 104px der Desktop-Logohöhe, aber über den tatsächlich
   benötigten Inhaltshöhen) — bei 768px (Navigation dort laut header.css
   noch inline, kein Umbruch, 44,4px Inhalt) füllt das schlicht weniger
   Leerraum um eine einzeilige Kopfzeile; bei ≤599px zusammen mit dem
   verkleinerten Zeilenabstand direkt darunter ausreichend, um auch die
   zweizeilige Variante innerhalb des Zielrahmens zu halten, ohne die
   44,4px hohe (damit weiterhin über der 44px-Mindestgröße für
   Touch-Ziele liegende) Kontakt-Schaltfläche selbst zu verkleinern. */
@media (max-width: 781px) {
	:root {
		--sv-header-height: 88px;
	}
}

/* Zeilenabstand beim Umbruch (.sv-header-row, blockGap "sm" = 16px, über
   WordPress' generierte "wp-container-core-group-is-layout-…"-Klasse
   gesetzt — instabiler Klassenname, siehe Kommentar bei
   .sv-mobile-market-link weiter unten zu vergleichbaren Layout-Support-
   Eigenheiten dieser Version, deshalb hier bewusst über die stabile
   ".sv-header-row"-Klasse mit !important überschrieben statt über den
   generierten Klassennamen) auf 8px reduziert — nur unterhalb 600px, wo
   die Zeile laut obiger Messung tatsächlich umbricht (600–781px bleibt
   einzeilig, siehe Messung 768px oben, dort unverändert). Spart die
   fehlenden Zentimeter zwischen den beiden Umbruchzeilen, ohne die
   Schriftgröße, den Header-Abstand zum Foto/Eyebrow-Text darunter oder
   die Klickfläche der Kontakt-Schaltfläche anzutasten. */
@media (max-width: 599px) {
	.sv-header-row {
		gap: 8px !important;
	}
}

/* NACHTRAG 2026-09-28 — Betreiberauftrag ausdrücklich: "Prüfe auch …
   Touch-Flächen". Live nachgemessen: Der Menü-Umschalter von WordPress'
   eigenem Navigation-Block (".wp-block-navigation__responsive-container-
   open", reines Core-Markup, kein eigenes hier) hat 0px eigenes Padding —
   seine tatsächliche Klickfläche ist exakt die 24x24px-SVG-Ikone selbst,
   deutlich unter der gängigen Mindestgröße von 44x44px für Touch-Ziele
   (WCAG 2.5.8/2.5.5). Padding vergrößert die Klickfläche; negativer Margin
   gleicher Größe hält die sichtbare Position/den sichtbaren Abstand zu
   Marke/Sprachumschalter/CTA in der Kopfzeile unverändert — nur die
   Interaktionsfläche wächst.
   NACHTRAG 2026-09-28 (2., selber Auftrag, Nachbesserung) — Betreiberwunsch:
   "vergrößere das sichtbare Hamburger-Symbol auf ungefähr 24-28px" (war
   zuvor exakt 24px, untere Bandgrenze) plus deutliche Hover-/Fokus-/
   Aktivzustände. Symbol auf 27px angehoben (Mitte des gewünschten Bands);
   Padding von 10px auf 9px angepasst, damit die Klickfläche bei der
   größeren Ikone weiterhin klar über der 44x44px-Mindestgröße bleibt
   (27+2x9=45x45px) — Margin im Gleichschritt mitgeführt. Zusätzlich der
   dazugehörige Schließen-Button (".wp-block-navigation__responsive-
   container-close", erscheint erst nach dem Öffnen, im selben Core-Markup
   bislang ganz ohne eigene Regel hier) auf dieselbe Weise mitbehandelt —
   hatte denselben 0px-Padding-Mangel und dieselbe 24px-Größe.
   Hover/Aktiv-Zustand über die Deckkraft des SVG-Icons selbst statt einer
   Hintergrundfarbe: Der Umschalter erscheint styleabhängig auf drei
   unterschiedlichen Untergründen (dunkler, halbtransparenter Header auf
   der Startseite; heller Header auf jeder anderen Seite; das stets helle
   Navigations-Overlay für den Schließen-Button) — eine feste
   Hintergrundfarbe müsste für jeden dieser drei Fälle einzeln abgestimmt
   werden, eine Deckkraftänderung des bereits kontrastreich eingefärbten
   Icons (siehe body.home .sv-header .wp-block-navigation__responsive-
   container-open svg weiter oben für die Startseiten-Einfärbung) wirkt
   dagegen unabhängig vom Untergrund gleich gut sichtbar. Fokuszustand
   kommt bereits unverändert aus dem globalen button:focus-visible
   (base.css) — hier nicht erneut definiert. */
@media (max-width: 599px) {
	.wp-block-navigation__responsive-container-open,
	.wp-block-navigation__responsive-container-close {
		padding: 9px;
		margin: -9px;
	}

	.wp-block-navigation__responsive-container-open svg,
	.wp-block-navigation__responsive-container-close svg {
		width: 27px;
		height: 27px;
	}

	.wp-block-navigation__responsive-container-open:hover svg,
	.wp-block-navigation__responsive-container-close:hover svg {
		opacity: 0.65;
	}

	.wp-block-navigation__responsive-container-open:active svg,
	.wp-block-navigation__responsive-container-close:active svg {
		opacity: 0.45;
	}
}

.sv-logo-desktop {
	display: inline-flex;
	align-items: center;
	text-decoration: none;
}

/* NACHTRAG 2026-10-08 — Logo/Text im Header vertikal zentriert.
   Ursache: Das <img> sass als Inline-Element auf der Grundlinie des
   umgebenden <p> (Zeilenhöhe ~28,8px bei 18px Schrift). Unter der
   Grundlinie bleibt Platz für Unterlängen, dadurch entstand unter dem
   Logo ca. 8,8px mehr Luft als darüber. Lösung: Bild als Block (keine
   Grundlinien-Lücke) und die weggefallene Höhe zur Hälfte oben/unten
   als Padding zurückgeben (0,244em ≈ 4,4px bei 18px), damit die
   Header-Höhe unverändert bleibt. */
.sv-logo-desktop-img {
	display: block;
	height: var(--sv-header-logo-height);
	width: auto;
}

.sv-logo-desktop p {
	padding-block: 0.244em;
}

/* Weiß-Variante des Logos (Redesign, 2026-09-22) — standardmäßig auf
   jeder Seite/Installation ausgeblendet; nur assets/css/home-redesign.css
   (ausschließlich auf der Startseite geladen) schaltet sie ein. Siehe
   silvalue_header_logo_white_shortcode(), functions.php. */
.sv-logo-desktop-white-variant {
	display: none;
}

/* NACHTRAG 2026-09-29 — Betreiberauftrag: Das volle Logo (Bildmarke +
   "SILVALUE"-Wortmarke + "Forst Consulting"-Beschreibungszeile, ein
   einziges Bild) soll bis hinunter zu 390px Breite durchgehend verwendet
   werden, statt unterhalb 782px auf die kompakte Bildmarke-plus-separater-
   Text-Variante umzuschalten (Auslöser: Auf dem Mobiltelefon fehlte in der
   kompakten Variante das Wort "Silvalue" im separaten .sv-tagline-Text,
   der bislang nur "Forst Consulting" enthielt — siehe .sv-brand-Kommentar
   weiter unten zur Ursache).
   Rechnerisch geprüft anhand der eigenen, bereits vom Betreiber bestätigten
   Maße (Logo-Seitenverhältnis 1750:500, Wortmarke 35% der Gesamthöhe,
   45px-Gesamthöhe/16px-Wortmarke 2026-08-27 als "zu klein" zurückgemeldet,
   63px/22px seither akzeptiert): Bei --sv-header-logo-height:72px (aktueller
   Wert) ist das Logo 252px breit. Verfügbare Header-Breite bei 390px
   Viewport: ca. 348px Inhaltsbreite (Gutter beidseitig) minus ca. 45px für
   den Menü-Umschalter (siehe dessen Klickflächen-Vergrößerung weiter oben)
   minus 8px Abstand = ca. 295px — das 252px breite Logo passt dort mit
   reichlich Rand, keine Verkleinerung der Logohöhe nötig.
   Deshalb jetzt: .sv-tagline unbedingt (nicht mehr nur ab 782px) ausblenden,
   da die Beschreibungszeile "Forst Consulting" im vollen Logo bereits
   enthalten ist und sonst doppelt erschiene. Der zugehörige Umschalt-Block
   weiter unten (".sv-brand .sv-logo-desktop{display:none}" /
   ".sv-logo-mobile{display:inline-flex}", vormals @media(max-width:781px))
   ist deaktiviert (siehe dortiger Kommentar) — .sv-logo-mobile bleibt damit
   durchgehend bei ihrer oben gesetzten Vorgabe display:none, ohne dass
   diese Regel hier erneut wiederholt werden müsste. */
.sv-tagline {
	display: none;
}

/*
 * Mobile-only country-switch shortcut at the end of the nav drawer
 * (CLAUDE.md section 8, point 3): the desktop header carries only the
 * language switch (silvalue_lang_switch), never the country/market
 * switch, so this item must stay hidden whenever the navigation renders
 * as the wide inline bar and only appear once it collapses into the
 * overlay drawer.
 *
 * Specificity note: WordPress core prints its own inline stylesheet
 * (`wp-block-navigation-inline-css`) with the rule
 * `.wp-block-navigation .wp-block-navigation-item{display:flex;...}`,
 * specificity 0-2-0. A bare `.sv-mobile-market-link` (0-1-0) always
 * loses to that core rule regardless of load order, so the item stayed
 * visible on desktop. Chaining the ancestor context plus our class,
 * `.wp-block-navigation .wp-block-navigation-item.sv-mobile-market-link`
 * (0-3-0), beats the core rule outright instead of merely tying it —
 * a tie would again depend on load order and could break with a future
 * core CSS change. No `!important` needed.
 */
.wp-block-navigation .wp-block-navigation-item.sv-mobile-market-link {
	display: none;
}

/*
 * Breakpoint corrected 2026-09-14 — this used to sit inside the same
 * `@media(max-width:781px)` block as the logo swap below, on the
 * (wrong) assumption that both track the same "mobile" cutoff. Measured
 * against the real rendered page across a range of widths (not
 * assumed): WordPress core's own Navigation block — `overlayMenu:
 * "mobile"` — collapses the inline list into the hamburger/drawer at a
 * fixed, content-independent 600px (core's own responsive-nav
 * breakpoint, wp-includes/blocks/navigation/style.css), not at this
 * theme's 782px logo/tagline breakpoint. Between 600px and 781px core
 * still renders the nav inline, so the old shared rule showed this item
 * as a fourth, oddly-worded item next to Leistungen/Über Silvalue/
 * Fachwissen instead of tucked inside the (in that range, not yet
 * collapsed) drawer. Matching core's own 600px here — rather than
 * inventing a coupling to whatever internal class/attribute core marks
 * the collapsed state with, which core does not document as stable API
 * — makes this item's breakpoint agree with the one thing that actually
 * decides whether a drawer exists to put it in.
 */
@media (max-width: 599px) {
	.wp-block-navigation .wp-block-navigation-item.sv-mobile-market-link {
		display: block;
	}
}

/*
 * NACHTRAG 2026-09-29 — Betreiberauftrag: Umschaltung auf die kompakte
 * mobile Bildmarke deaktiviert, volles Logo gilt jetzt durchgehend bis
 * 390px (Begründung/Rechnung siehe .sv-tagline-Kommentar oben). Die
 * ursprüngliche @media(max-width:781px)-Regel unten bewusst nur
 * auskommentiert, nicht gelöscht — der Specificity-Hinweis bleibt gültige
 * Dokumentation, falls eine kompakte Variante an dieser Stelle je wieder
 * gebraucht wird (z. B. bei einer künftigen, deutlich schmaleren
 * Logo-Datei). .sv-logo-mobile bleibt dadurch dauerhaft bei ihrer oben
 * (Zeile ~81) gesetzten Grundregel "display:none".
 *
 * Ursprünglicher Specificity-Hinweis, 2026-09-14: WordPress's layout-support
 * mechanism (see the long comment on `.sv-brand` above) injects its
 * `is-layout-flex` class onto this exact anchor, not onto `.sv-brand`'s
 * own wrapper. Core prints one page-wide, unconditional rule for that
 * class — `body .is-layout-flex{display:flex;...}`, specificity 0-1-1
 * — which beat a bare `.sv-logo-desktop{display:none}` (0-1-0) here
 * regardless of media query or load order, so the desktop lockup
 * never actually hid on mobile (confirmed on the live rendered page:
 * `computedDisplay` was "flex" at both 360px and 780px, not "none").
 * Chaining the ancestor class, `.sv-brand .sv-logo-desktop` (0-2-0),
 * beats the core rule outright instead of merely tying it — same
 * technique already used for `.sv-mobile-market-link` above, kept
 * consistent rather than reaching for `!important` here.
 *
 * The other rules in this block were checked against the same trap
 * and are not affected: `.sv-logo-mobile` and `.sv-proof-bar`/
 * `.sv-services-card`/`.sv-services-index-item` (patterns.css) all
 * set `display` directly on a block's own designated wrapper class,
 * never on a plain HTML tag nested first inside a flex/grid-attribute
 * block — the specific, unusual markup shape that misdirects core's
 * class injection only occurs here.
 *
@media (max-width: 781px) {
	.sv-brand .sv-logo-desktop {
		display: none;
	}

	.sv-logo-mobile {
		display: inline-flex;
		align-items: center;
	}
}
 */

/*
 * Main nav labels (Leistungen/Über Silvalue/Fachwissen), ergänzt
 * 2026-08-29: bislang ungestylt, damit auf die globale Fließtext-
 * Gewichtung (400, kein Override in theme.json) zurückfallend — wirkte
 * gegenüber der 600-Gewichtung von Logo-Wortmarke und Kontakt-Schaltfläche
 * (theme.json styles.elements.button) zu zurückhaltend. Angehoben auf
 * 500 (Inter Medium, innerhalb des geladenen Variable-Font-Bereichs
 * 300-700) — bewusst NICHT 600: Die Kontakt-Schaltfläche bleibt damit das
 * einzige Element mit voller Schriftgewichtung im Header, 500 hebt die
 * drei gleichrangigen Menüpunkte nur gegenüber normalem Fließtext hervor,
 * ohne mit der Schaltfläche zu konkurrieren. Schriftgröße bleibt
 * unverändert beim ui-Token (13px, `[FEST]`, gesetzt als Block-Attribut
 * in parts/header-de.html/-en.html, hier nicht berührt). Der mobile
 * Länderwechsel-Kurzlink (.sv-mobile-market-link) ist kein Menüpunkt und
 * bewusst ausgenommen, bleibt bei 400.
 */
.wp-block-navigation .wp-block-navigation-item:not(.sv-mobile-market-link) .wp-block-navigation-item__content {
	font-weight: 500;
}

/*
 * Touch-Ziel der Menüpunkte, ergänzt 2026-10-08 (Audit C3): Im Bereich
 * 600-1024px steht das Menü noch inline in der Hauptleiste (WordPress'
 * Navigationsblock kollabiert erst unter 600px), die Punkte waren dort nur
 * ~22px hoch. Vertikales Padding hebt das klickbare Ziel auf ~44px, ohne die
 * sichtbare Schrift oder die feste Header-Höhe zu verändern (der Header
 * zentriert seinen Inhalt). Spezifität über die Kernregel hinaus durch die
 * Verkettung mit .wp-block-navigation, kein !important.
 */
@media (min-width: 600px) and (max-width: 1024px) {
	.wp-block-navigation .wp-block-navigation-item:not(.sv-mobile-market-link) .wp-block-navigation-item__content {
		padding-block: 0.8em;
	}
}

/*
 * Empty band directly under the header, ergänzt 2026-09-15,
 * Betreiberfeedback ("ein Strich unter dem Header, der wie ein leerer
 * Block aussieht"). Not a stray element — confirmed on the live rendered
 * page (getBoundingClientRect()/matched CSSOM rule, not assumed): it is a
 * plain ~32px band of the page's own background colour between the
 * header's bottom border and whatever follows.
 *
 * Cause: WordPress's own global stylesheet gives every top-level area a
 * blockGap-based top margin — `:where(.wp-site-blocks) > *
 * {margin-block-start: var(--wp--preset--spacing--md)}` (zero-specificity
 * `:where()`, exempting only the very first child) — the same mechanism
 * already documented and zeroed for `.sv-proof-bar__item` in patterns.css
 * (2026-09-13). Between two ordinary content sections this spacing is
 * fine and left alone; between the header and whatever comes next it
 * reads as a bare gap, since `.sv-header` already carries its own visual
 * separator (the 1px `sv-line` bottom border, see the top of this file) —
 * a second, blank spacer band under that line is redundant, not
 * intentional.
 *
 * Scoped to only the element immediately after the header, not the whole
 * `:where(.wp-site-blocks) > *` selector, so the same spacing the theme
 * DOES want elsewhere at this level (e.g. before the footer template
 * part) is untouched. No `!important` needed — a plain class-chained
 * selector already beats the core rule's zero-specificity `:where()`
 * outright, same technique already used elsewhere in this file and in
 * patterns.css.
 *
 * Selector uses the tag `header`, not `.sv-header` — verified against the
 * live rendered page (`matches()`/`nextElementSibling`, not assumed),
 * first attempt (`.wp-site-blocks > .sv-header + *`) silently matched
 * nothing: WordPress's `wp:template-part` block wraps a "header"-area
 * part's own markup in an *additional*, auto-generated `<header
 * class="wp-block-template-part">` (matching the part's semantic area,
 * same mechanism this theme's own README already documents for the
 * footer area). `.sv-header` — the class this file and parts/header-*.html
 * actually use — sits one level deeper, on the template part's own root
 * element, not on this outer wrapper; `.wp-site-blocks`'s real direct
 * child is the outer one. Plain `header` (there is exactly one at that
 * level) reaches it without depending on an attribute WordPress itself
 * generates.
 */
.wp-site-blocks > header + * {
	margin-block-start: 0;
}

/*
 * Fixiert beim Scrollen, ergänzt 2026-09-17, Betreiberwunsch. `sticky`
 * statt `fixed`: bleibt im normalen Dokumentfluss, bis der Nutzer daran
 * vorbeiscrollt, dann klebt es oben fest — dadurch ist keine zusätzliche
 * Polsterung am nachfolgenden Inhalt nötig, um den Sprung auszugleichen,
 * den `fixed` sonst verursachen würde.
 *
 * Auf dem äußeren `.wp-site-blocks > header`-Wrapper gesetzt (siehe die
 * ausführliche Erklärung dieses Elements oben), NICHT auf `.sv-header`
 * selbst — erster Versuch dort verifiziert fehlgeschlagen (Header
 * verschwand schon nach wenigen hundert Pixeln Scroll-Weg, statt zu
 * kleben). Ursache: Ein `position:sticky`-Element bleibt nur innerhalb der
 * Box seines eigenen Containing Block "kleben" — `.sv-header`s direkter
 * Elter ist genau dieser Wrapper, dessen Box exakt so hoch ist wie
 * `.sv-header` selbst (kein zusätzlicher Inhalt darin). Es gibt also
 * keinerlei Spielraum, in dem das Element kleben könnte, bevor die Box
 * seines Elters selbst schon aus dem Sichtfenster gescrollt ist. Auf dem
 * Wrapper selbst gesetzt, ist dessen Containing Block `.wp-site-blocks`
 * (rund 4400px hoch, praktisch die ganze Seite) — dort ist genug Raum
 * vorhanden, das Element bleibt über die gesamte Seite hinweg oben
 * kleben. `z-index` höher als alles sonst Positionierte im Seiteninhalt
 * (z. B. `.sv-proof-bar` mit `z-index:5`, patterns.css), damit der Header
 * beim Überlappen immer oben liegt. `top:0` reicht für Besucher; ist der
 * Betreiber selbst in wp-admin eingeloggt, schiebt WordPress' eigene
 * fixierte Admin-Leiste (32px, bzw. 46px unter 782px) den Seiteninhalt
 * per `margin-top` auf `<html>` bereits nach unten — der Header klebt
 * dadurch automatisch richtig direkt darunter, ohne eigene Sonderregel
 * dafür.
 */
.wp-site-blocks > header {
	position: sticky;
	top: 0;
	z-index: 20;
}

/* NACHTRAG 2026-09-29 — Betreiberfeedback (iPhone 14 Pro, 390px, aufgeklapptes
   Mobil-Menü): Die Menüpunkte ("Leistungen", "Über Silvalue",
   "Waldinvestment in Neuseeland? → silvalue.com") waren im aufgeklappten
   Overlay "sehr zurückhaltend (in hell Grau) ... mit den Augen fast nicht
   wahrnehmbar".
   Ursache live nachgemessen (getComputedStyle): Der WordPress-
   Navigationsblock hat NUR eine Textfarbe gesetzt (rgb(244,243,238) —
   entspricht --wp--preset--color--sv-paper/sv-r-bg, dem hellen
   Seitenhintergrund-Ton), gedacht für den dunklen, halbtransparenten Header
   auf der Startseite. Für den aufklappenden Overlay-Zustand
   (".wp-block-navigation__responsive-dialog", von WordPress selbst stets
   mit WEISSEM Hintergrund gerendert, unabhängig vom Header-Hintergrund)
   fehlte eine eigene, dunkle Overlay-Textfarbe — Block-Editor bietet dafür
   zwar ein separates "Overlay-Textfarbe"-Feld, das war hier nicht gesetzt,
   die normale (helle) Textfarbe wurde also auch im Overlay übernommen.
   Direkte CSS-Korrektur statt Editor-Einstellung: Der Betreiber müsste die
   Overlay-Textfarbe sonst im Block-Editor je Installation von Hand pflegen
   (analog zur bereits dokumentierten Customizer-Logo-Einstellung); eine
   CSS-Regel hier gilt sitewide und automatisch für jede Installation.
   Selektor beschränkt auf ".wp-block-navigation__responsive-dialog" (nur
   der aufgeklappte Overlay-Zustand) — der eingeklappte/inline Zustand
   (Startseite, dunkler Header, ≥600px) bleibt von dieser Regel unberührt
   und zeigt weiterhin die helle, für den dunklen Hintergrund richtige
   Farbe.
   `!important`: WordPress' eigene generierte Farbregel für Navigationsblöcke
   mit gesetzter Textfarbe (".wp-block-navigation-item__content") kommt
   bereits mit `!important` (Block-Support-Mechanismus für Farben, core-
   eigenes Verhalten) — ohne ein eigenes `!important` hier würde die
   Kern-Regel weiterhin gewinnen, unabhängig von Selektor-Spezifität oder
   Ladereihenfolge. sv-text (dunkler Fließtext-Ton, theme.json) gewählt statt
   sv-ink — derselbe Ton, den Fließtext auf hellem Hintergrund im übrigen
   Theme bereits verwendet, kein neuer Kontrast-Fall.

   KORREKTUR 2026-09-29 (noch am selben Tag, vor Live-Übernahme, bei der
   lokalen Sichtprüfung entdeckt): Die erste Fassung dieser Regel (zwei
   Klassen, s. u. Git-Historie) griff auf Unterseiten, aber NICHT auf der
   Startseite — dort gewinnt weiterhin
   "body.home .sv-header .wp-block-navigation-item > a" aus
   home-redesign.css (ebenfalls !important, aber drei Klassen + zwei
   Element-Selektoren = höhere Spezifität als zwei Klassen). Jene Regel ist
   für den dunklen Hero-Hintergrund der Startseite gedacht, trifft aber
   denselben, von WordPress dort ebenfalls weiß gerenderten
   Menü-Overlay-Zustand. Fix: zusätzlicher Selektor mit einer weiteren
   Klasse (".wp-block-navigation-item" vom umschließenden <li>, live per
   getComputedStyle als Vorfahre bestätigt) — vier Klassen schlagen die
   drei Klassen der Startseiten-Regel unabhängig von deren zwei
   Element-Selektoren, da die Klassen-Stufe vor der Element-Stufe
   verglichen wird. Per Iframe-Sichtprüfung (390px, lokale Sandbox,
   Startseite UND Unterseite, aufgeklapptes Menü) bestätigt: Text jetzt in
   beiden Fällen im dunklen sv-text-Ton.

   KORREKTUR 2026-09-29 (Betreiberfeedback, nach Live-Übernahme): "die
   textfarbe für die Menüpunkte [wurde] auch in der normalen desktop
   variante verdunkelt und kann nur noch schwer gesehen werden". Ursache
   live nachgemessen (Desktop-Breite, Startseite,
   .closest('.wp-block-navigation__responsive-dialog')): Dieser
   Container ist Teil des vom Navigationsblock IMMER erzeugten Markups
   (Off-Canvas-Struktur), unabhängig von Fensterbreite oder
   Menüzustand — er wird nur bei aufgeklapptem Mobil-Menü tatsächlich als
   eigenes weißes Overlay dargestellt (zusätzliche Klassen wie
   "has-modal-open"/"is-menu-open" auf einem Vorfahren-Element steuern
   das), bleibt aber strukturell auch am Desktop vorhanden und inline
   sichtbar. Die Regel traf dadurch ungewollt auch die normale
   Desktop-Navigation und ersetzte deren helle, für den dunklen
   Hero-Header vorgesehene Textfarbe durch den dunklen sv-text-Ton — kaum
   lesbar auf dunklem Hintergrund. Fix: Regel auf eine Medienabfrage
   unterhalb 599px beschränkt (derselbe Breakpoint wie WordPress' eigener
   Nav-Hamburger-Kollaps, bereits an mehreren Stellen dieser Datei
   verwendet) — dort ist der Container tatsächlich das aufgeklappte,
   weiße Overlay, und nur dort soll die dunkle Textfarbe gelten. Desktop
   bleibt dadurch wieder bei der ursprünglichen, hellen Farbe. */
@media (max-width: 599px) {
	.wp-block-navigation__responsive-dialog .wp-block-navigation-item__content,
	.wp-block-navigation__responsive-dialog .wp-block-navigation-item .wp-block-navigation-item__content,
	body.home .wp-block-navigation__responsive-dialog .wp-block-navigation-item .wp-block-navigation-item__content {
		color: var(--wp--preset--color--sv-text) !important;
	}
}

/* NACHTRAG 2026-09-29 — Betreiberfeedback (mobile Version, Header): "wäre
   es möglich die Menü-Schaltfläche am rechten Rand neben dem Logo zu haben
   und in der mobilen Version den Button 'Kontakt aufnehmen' aus dem Header
   zu entfernen?"

   Ursache der bisherigen Anordnung: .sv-header-row (flex, wrap,
   justify-content:space-between) enthält zwei Kinder — .sv-brand (Logo,
   252px) und .sv-header-actions (Nav-Umschalter + Sprachumschalter +
   "Kontakt aufnehmen"-Button, zusammen ~246px). Unterhalb rund 600px
   reicht die Zeilenbreite nicht für beide nebeneinander (252+246 > ca.
   343px verfügbare Breite bei 390px Viewport), wodurch .sv-header-actions
   als Ganzes in eine zweite Zeile umbricht — der Menü-Umschalter erschien
   dadurch links unten statt oben rechts, und "Kontakt aufnehmen" blieb im
   Header sichtbar, obwohl der Hero direkt darunter bereits einen
   gleichwertigen CTA ("Projekt besprechen") enthält.

   Lösung: "Kontakt aufnehmen" unterhalb 600px (derselbe Breakpoint wie
   WordPress' eigener Nav-Umschalter/Hamburger-Kollaps, siehe
   .sv-mobile-market-link weiter oben) ausgeblendet. Der Sprachumschalter
   (.sv-lang-switch-wrap) ist in diesem Breitenbereich bereits durch
   anderweitige Regeln auf 0×0px reduziert (unverändert, keine Anpassung
   nötig). Dadurch schrumpft .sv-header-actions auf die Breite des
   Nav-Umschalters allein (45px) — 252+45=297px passt neben das Logo in
   eine einzige Zeile, und "justify-content:space-between" auf
   .sv-header-row platziert ihn automatisch am rechten Rand, direkt neben
   dem Logo. Kein zusätzliches Markup, keine Positionierung nötig — reiner
   Nebeneffekt des bestehenden Flex-Layouts, sobald der Button entfällt.
   Per Iframe-Sichtprüfung (390px, lokale Sandbox, Start- UND Unterseite,
   Logo dunkel wie hell) bestätigt: Menü-Umschalter einzeilig rechts neben
   dem Logo, "Kontakt aufnehmen" nicht mehr sichtbar; ab 600px (Bereich mit
   eingeklappter Vollnavigation, geprüft bei 700px) weiterhin unverändert
   sichtbar. */
@media (max-width: 599px) {
	.sv-header-actions .wp-block-buttons {
		display: none;
	}
}

/* NACHTRAG 2026-10-09 — Mobiles Menü-Overlay hatte keinen Innenabstand:
   Menüeinträge und Schließen-Kreuz klebten am Bildschirmrand (Betreiber-
   Screenshot, iPhone). Ursache: WordPress' Kernregel für das geöffnete
   Overlay lautet padding: clamp(1rem, var(--wp--style--root--padding-top),
   20rem) ... — theme.json setzt padding-top/-bottom auf "0" (ohne Einheit),
   ein einheitenloses 0 ist innerhalb von clamp() ungültig, die gesamte
   Deklaration fällt weg, padding = 0. Hier dieselbe Regel mit festem 1rem
   oben/unten; links/rechts weiter das Root-Padding (mind. 1rem). Am
   Live-Stand per eingespieltem Test-CSS geprüft: Einträge bei 16px statt 0px. */
.wp-block-navigation__responsive-container.is-menu-open:not(.disable-default-overlay) {
	padding: 1rem clamp(1rem, var(--wp--style--root--padding-right), 20rem) 1rem clamp(1rem, var(--wp--style--root--padding-left), 20rem);
}

/* NACHTRAG 2026-10-09 — Betreiberwunsch: im mobilen Menü die beiden
   Hauptpunkte (Leistungen, Über Silvalue) und den Verweis nach Neuseeland
   deutlicher voneinander absetzen. Hauptpunkte größer und mit mehr
   Luft, der Neuseeland-Verweis kleiner, gedämpft und durch Trennlinie
   plus Abstand klar als Sekundärlink erkennbar. Nur im geöffneten
   Overlay (is-menu-open), Desktop-Navigation unberührt. */
.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content .wp-block-navigation-item:not(.sv-mobile-market-link) .wp-block-navigation-item__content {
	font-size: 1.375rem;
	font-weight: 500;
	padding-block: 0.6rem;
}

.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content .wp-block-navigation-item.sv-mobile-market-link {
	margin-top: 1.5rem;
	padding-top: 1.25rem;
	border-top: 1px solid var(--wp--preset--color--sv-line);
}

.wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content .wp-block-navigation-item.sv-mobile-market-link .wp-block-navigation-item__content {
	font-size: 0.9375rem;
	font-weight: 400;
	color: var(--wp--preset--color--sv-text-soft) !important; /* !important: Farbe kommt sonst inline vom Navigationsblock */
}