/* Sticky-Scrollytelling fuer den Homepage-Hero: der Hero bleibt beim
   Scrollen stehen, der naechste Abschnitt schiebt sich sichtbar darueber,
   statt normal wegzuscrollen. Bewusst eine eigene, nur von den zwei
   Homepage-Seiten (de/en) eingebundene Datei statt einer Erweiterung von
   components.css - so bleibt das Cache-Busting auf genau diese zwei
   Seiten beschraenkt, siehe CLAUDE.md/EDITING.md ("Cache-Busting nicht
   vergessen ... in allen Dateien, die die geaenderte Datei einbinden").

   Reines Verhaltensprinzip aus dem Think:Act-System (SVE Authoring Tool)
   uebernommen, NICHT dessen Farben/Tokens - schmidpower.de bleibt beim
   eigenen hellen "Papier"-Theme. */

.hero {
  position: sticky;
  top: 0;
  z-index: 1;
}

/* Wird per JS auf JEDES auf .hero folgende Geschwister-Element gesetzt
   (hero-scroll.js) - macht diese Abschnitte blickdicht, damit sie den
   stehenbleibenden Hero beim Darueberschieben tatsaechlich verdecken.
   Autor-Fund (Screenshot-Test, 1. Versuch): die betroffenen Abschnitte
   tragen selbst die Klasse .container (max-width, zentriert mit
   margin:auto) - ein normales background auf dem Element deckt darum nur
   die mittlere Inhaltsspalte ab, links/rechts blieb der Hero sichtbar.
   Autor-Fund (Screenshot-Test, 2. Versuch): ein erster Fix ueber
   `box-shadow: 0 0 0 100vmax` malt dieselbe Farbe zwar links/rechts bis
   zum Fensterrand, aber GENAUSO WEIT nach oben/unten - bei mehreren kurzen,
   direkt aufeinanderfolgenden Abschnitten (hier 479px, ohne Abstand
   dazwischen) ueberdeckte der riesige Schatten eines SPAETEREN Abschnitts
   (malt zuletzt, damit im selben Stapelkontext ueber allem) grossflaechig
   auch die eigentlich sichtbaren FRUEHEREN Abschnitte - die ganze Seite
   wirkte leer. Jetzt derselbe "100vw-Breakout" wie an anderer Stelle im
   Projekt bereits fuer randlose Elemente verwendet: ein Pseudo-Element,
   das nur exakt die Hoehe DIESES EINEN Abschnitts einnimmt (inset:0
   innerhalb des relativ positionierten Abschnitts), aber ueber
   `left:50%;transform:translateX(-50%);width:100vw` horizontal bis zum
   Fensterrand reicht - kein Ueberstand nach oben/unten in Nachbar-
   Abschnitte hinein. */
.hero-cover {
  position: relative;
  z-index: 2;
}
.hero-cover::before {
  content: "";
  position: absolute;
  inset: 0;
  left: 50%;
  width: 100vw;
  transform: translateX(-50%);
  background: var(--background);
  z-index: -1;
}

/* Autor-Fund Runde 3: "Kannst du nicht mit einem Reveal-Layer arbeiten,
   das denselben Mausfokus umsetzt wie beim Think:Act-Format?" - Prinzip
   1:1 aus dem Journey-Hero des SVE Authoring Tools uebernommen (dort
   ".ta-jh-spot"/".ta-jh-ov" nach vielen Feinschliff-Runden): ein Schleier
   ueber dem Hero-Hintergrund.
   Autor-Fund (Farbwahl): --accent-deep (Taupe) durch die urspruengliche,
   im Repo bereits hinterlegte dunkelblaue Marken-Farbe ersetzt - dieselbe
   Farbe, die vor der Paper-Neugestaltung zusammen mit dem Magenta
   verwendet wurde und heute noch als --role-accent der "Entwicklung"-
   Rollenkarte lebt (#160B52, s. z. B. website/de/index.html). Eigener
   Token statt direktem Hex-Wert, damit die Quelle an einer Stelle
   dokumentiert bleibt. Deckkraft auf 90% Sichtbarkeit (= 90% Deckkraft).
   Autor-Fund (WICHTIG, mehrfach bemaengelt: "eine andere Farbe steckt im
   Mousefokus, dieses schmutzige Grau ueberblendet das Blau des Bilds").
   Ursache: der Schleier war ein Farbverlauf zu einer ZWEITEN, aufgehellten
   Farbe (--hero-spot-color-light, ein Grau-Lavendel-Ton) UNTER dem
   halbtransparenten Bild-Reveal (.hero-bg-reveal, s. u.) - an der
   Uebergangszone beider unabhaengig ausblendender Ebenen (Bild UND
   Schleier veraendern sich beide gleichzeitig, mit unterschiedlichen
   Zielfarben) entstand eine dritte, keiner der beiden Quellen entsprechende
   Mischfarbe - exakt das "schmutzige Grau". Fix (wie ausdruecklich
   verlangt): "nur eine einzige Farbe setzen - die des Layers". Der
   Schleier ist jetzt eine VOELLIG FLACHE, vom Mausfokus komplett
   unabhaengige Flaeche in genau EINER Farbe (--hero-spot-color, kein
   Verlauf, keine zweite Farbe mehr, keine --mx/--my/--hero-spot-reveal-
   Abhaengigkeit). Das "elegante Durchscheinen" bei Mausfokus kommt
   AUSSCHLIESSLICH von der zweiten Ebene (.hero-bg-reveal), die das echte
   Bild ueber diesem konstanten Schleier einblendet - eine einzige
   veraendernde Ebene, kein Ineinanderblenden zweier Farbwelten mehr. */
.hero-bg .hero-spot {
  position: absolute;
  inset: 0;
  background: var(--hero-spot-color);
  opacity: 0.9;
  pointer-events: none;
}
/* Autor-Fund ("Bild als Überraschungseffekt beim Mousefokus", Ziel:
   "der Layer verblendet das Bild, bei Mausfokus soll das blaue
   Hintergrundbild elegant durchscheinen"): das echte Kirschbluetenfoto
   bleibt in der Basis-Ebene (.hero-bg img) bewusst so entsaettigt/
   abgedunkelt wie zuvor ("alles so lassen") - hier eine ZWEITE Kopie
   desselben Bilds, unbehandelt in seinen echten Farben, die per Masken-
   Aussparung NUR innerhalb des wachsenden Mauskreises sichtbar wird.
   Liegt bewusst als eigenes, ZULETZT im Markup stehendes Element ueber
   dem jetzt flachen Navy-Schleier - eine explizite z-index-Stufe ist
   noetig, weil generierter Inhalt (.hero-bg::after, der Duoton-Multiply-
   Schleier) sonst laut Spezifikation immer NACH allen echten Kind-
   Elementen gemalt wuerde und die frischen Farben sofort wieder
   eintoenen wuerde. Dies ist jetzt die EINZIGE Ebene, die sich mit der
   Maus veraendert (der Schleier darunter bleibt konstant) - keine zwei
   gleichzeitig ausblendenden Farbquellen mehr, kein Mischfarbton. */
/* Autor-Fund ("Transparenz erhoehen, damit die Bluete richtig sichtbar
   wird"): die Maske hatte nur ZWEI Haltepunkte (0%/100%) - ein reiner,
   ununterbrochener Verlauf ohne Plateau bedeutet, dass wirklich nur der
   EINE exakte Mittelpunkt-Pixel voll deckend (Bild 100% sichtbar) war;
   schon wenige Pixel daneben mischte sich das halbtransparente Foto
   zunehmend mit dem undurchsichtigen Navy-Schleier darunter und wirkte
   dadurch gedaempft statt "richtig sichtbar". Jetzt ein zusaetzlicher
   Haltepunkt bei 55%: ein satter Kernbereich, in dem das Foto komplett
   ungedaempft (voll deckend) durchscheint, erst danach faellt die Maske
   zum Rand hin weich auf transparent ab. */
.hero-bg-reveal {
  position: absolute;
  inset: 0;
  width: 100%;
  height: 120%;
  object-fit: cover;
  display: block;
  z-index: 2;
  pointer-events: none;
  -webkit-mask: radial-gradient(circle var(--hero-spot-reveal, 0px) at var(--mx, 12%) var(--my, 88%), #000 0%, #000 55%, transparent 100%);
  mask: radial-gradient(circle var(--hero-spot-reveal, 0px) at var(--mx, 12%) var(--my, 88%), #000 0%, #000 55%, transparent 100%);
}
/* Der Schleier waechst beim Laden einmal animiert von 0 auf seinen
   Zielradius auf (".is-in", per JS gesetzt) - ein Lade-Moment, nicht nur
   ein Hover-Komfort. @property macht den Custom-Property-Uebergang
   ueberhaupt erst animierbar (ohne @property wuerde der Wert nur springen);
   Browser ohne @property-Unterstuetzung zeigen den Schleier stattdessen
   sofort in voller Groesse - kein Funktionsverlust, nur ohne Anwachs-
   Animation (PFLICHT-Fallback). */
@property --hero-spot-reveal {
  syntax: '<length>';
  inherits: true;
  initial-value: 0px;
}
.hero {
  --hero-spot-color: #160B52;
  --hero-spot-reveal: 0px;
  --mx: 12%;
  --my: 88%;
  transition: --hero-spot-reveal 1.2s ease;
}
.hero.is-in { --hero-spot-reveal: 340px; }

/* Autor-Fund (Kontrast-Fund nach der 90%-Deckkraft-Korrektur): bei 90%
   Deckkraft dominiert der dunkelblaue Schleier den Hero-Hintergrund fast
   vollflaechig - der fuer das helle Paper-Theme gedachte dunkle Text
   (h1/p/Buttons) wurde darauf praktisch unlesbar. Nur INNERHALB des Heros
   auf helle Schrift umgestellt, der Rest der Seite bleibt unveraendert
   beim hellen Theme. .hero-scroll-cue braucht keine eigene Regel - er
   nutzt bereits color:inherit - braucht darum ein explizites color:#fff
   auf .hero selbst (h1/p haben eigene, staerker spezifische Farbregeln
   an anderer Stelle und muessen zusaetzlich einzeln ueberschrieben
   werden, s. u.). */
.hero {
  color: #fff;
}
/* Autor-Fund: "Ueber der Schrift erscheint wieder ein Strich statt des
   Mousezeigers" - h1/p sind schlichter, selektierbarer Text ohne eigene
   cursor-Regel, der Browser zeigt darueber daher standardmaessig den
   Text-Cursor (I-Beam) statt eines normalen Pfeils - irritierend auf
   einem reinen Anzeigetext, der nicht zum Editieren gedacht ist. Dieselbe
   Lektion aus dem SVE Authoring Tool (dort exakt so am Journey-Hero-Titel
   gefunden): cursor:default GEZIELT nur auf h1/p, NICHT auf dem
   umschliessenden .hero-content-Block, sonst wuerde die Zeigehand der
   Links/Buttons darin (z. B. "Lernbereich erkunden") mit ueberschrieben
   und verschwinden - die bleiben unveraendert bei ihrem eigenen
   cursor:pointer. */
.hero .hero-content h1 {
  color: #fff;
  cursor: default;
}
.hero .hero-content p {
  color: rgba(255, 255, 255, 0.82);
  cursor: default;
}
.hero-cta-row .btn-primary {
  border-color: #fff;
  color: #fff;
}
.hero-cta-row .btn-primary:hover {
  background: #fff;
  color: var(--text-primary);
}
.hero-cta-row .btn-outline {
  border-color: rgba(255, 255, 255, 0.45);
  color: rgba(255, 255, 255, 0.85);
}
.hero-cta-row .btn-outline:hover {
  border-color: #fff;
  color: #fff;
}

/* Autor-Fund Runde 3: "Die Menüleiste wird nicht ueberblendet wie beim
   Think:Act-Hero, sondern ist weiterhin sticky" - dieselbe Ueberblenden-
   Logik wie beim Think:Act-".ta-topbar": ueber dem Hero transparent/
   durchsichtig, erst sobald der Hero komplett ueberdeckt ist (derselbe
   Ausloeser wie das Sticky-Loesen in hero-scroll.js), wechselt die Leiste
   auf ihre normale, deckende ".glass"-Optik. Diese Klasse wird nur von den
   zwei Homepage-Seiten eingebunden (hero-scroll.js setzt/entfernt sie), auf
   allen anderen ~100 Seiten bleibt die Menueleiste unveraendert immer
   deckend. */
.site-nav.nav-overlay {
  background: transparent;
  backdrop-filter: none;
  -webkit-backdrop-filter: none;
  border-bottom-color: transparent;
  transition: background-color 0.35s ease, border-color 0.35s ease, color 0.35s ease;
}
/* Autor-Fund (Kontrast-Fund): waehrend die Menueleiste transparent ueber
   dem jetzt dunkelblauen Hero liegt, ist ihr fuer den hellen Seiten-
   hintergrund gedachter dunkler Text (Logo/Links/Sprachumschalter/
   Anmelden-Button) ebenso unlesbar - hier auf hell umgestellt, faellt
   beim Ueberblenden auf die deckende ".glass"-Optik automatisch auf die
   normale dunkle Schrift zurueck (Klasse wird entfernt, keine eigene
   Rueckstell-Regel noetig). */
.site-nav.nav-overlay .nav-logo,
.site-nav.nav-overlay .nav-logo-dot,
.site-nav.nav-overlay .nav-links,
.site-nav.nav-overlay .lang-switch,
.site-nav.nav-overlay .btn-primary {
  color: #fff;
}
.site-nav.nav-overlay .nav-links a:hover {
  color: rgba(255, 255, 255, 0.7);
}
.site-nav.nav-overlay .lang-switch:hover {
  color: #fff;
}
.site-nav.nav-overlay .btn-primary {
  border-color: #fff;
}
.site-nav.nav-overlay .btn-primary:hover {
  background: #fff;
  color: var(--text-primary);
}
.site-nav.nav-overlay .nav-toggle span {
  background: #fff;
}

/* Autor-Fund Runde 3: "Der Footer hat weiterhin eine Trennlinie, das
   finde ich unschön. Bitte weg." - die Linie kam nicht (nur) von der in
   Runde 2 schon entfernten .section-border-Klasse, sondern ist ein fester
   Teil von .site-footer selbst (components.css, sitehweit auf allen ~100
   Seiten). Dort eine geteilte Datei anzufassen wuerde die Linie ueberall
   entfernen, nicht nur auf der Homepage - hier bewusst nur fuer die zwei
   Homepage-Seiten (einzige Einbindung dieser Datei) uebersteuert, der
   Footer auf allen anderen Seiten bleibt unveraendert. */
.site-footer {
  border-top: none;
}

/* Autor-Fund: "Über dem Abschnitt Embodied Learning ist immer noch eine
   Trennlinie, die störend wirkt." - andere Quelle als die in Runde 2
   bereits entfernten .section-border-Klassen: .chapter selbst (component
   .css, sitehweit z. B. auch für die drei Playbook-Kapitel verwendet,
   dort als bewusster Kapitel-Trenner gewollt) traegt einen eigenen
   border-top. Direkt nach dem Hero, als allererstes Element der Seite
   nach der neuen, dunklen Hero-Flaeche, wirkt genau diese eine Linie wie
   ein unschoener Bruch. Gezielt nur fuer DIESES eine Vorkommen (der
   .chapter direkt im ersten auf den Hero folgenden Abschnitt) entfernt -
   .chapter an anderer Stelle (z. B. die drei Playbook-Kapitel) bleibt mit
   seiner Trennlinie unveraendert, da dort mehrere Kapitel hintereinander
   stehen und die Linie dort tatsaechlich als Kapitel-Trenner gebraucht
   wird. */
.hero + section .chapter {
  border-top: none;
}

/* Autor-Fund Runde 2: "Der Chevron hat wieder eine Button - das moechte
   ich nicht" + "Die Farbe ist nicht schoen". Kreisflaeche/Rand/Hintergrund
   ersatzlos entfernt - reines Icon ohne Button-Optik. Autor-Fund Runde 3:
   der zwischenzeitliche Akzentton (--learn-accent, Blau) wurde ausdruecklich
   abgelehnt ("Das Blau deines Vorschlags gefaellt mir auch ueberhaupt
   nicht") - der Token ist wieder entfernt (s. tokens.css). Statt eine
   dritte Farbe zu raten, bezieht der Chevron seine Farbe jetzt einfach aus
   der bereits vorhandenen Hero-Textfarbe (color:inherit) - dieselbe Lektion
   wie im anderen Projekt ("Der Chevron soll schlicht und ohne Button
   erscheinen, Farbe automatisch ueber color:inherit"). Der eigentliche
   "ausdrucksstarke Hero"-Wunsch wird jetzt ueber den Maus-Reveal-Schleier
   weiter unten erfuellt, nicht ueber eine kraeftige Chevron-Farbe. */
.hero-scroll-cue {
  position: absolute;
  left: 50%;
  bottom: 2rem;
  transform: translateX(-50%);
  display: grid;
  place-items: center;
  color: inherit;
  background: none;
  border: none;
  padding: 0;
  cursor: pointer;
  z-index: 1;
  transition: opacity 0.25s ease;
}
.hero-scroll-cue:hover {
  opacity: 0.7;
}
.hero-scroll-cue svg {
  width: 28px;
  height: 28px;
  animation: hero-scroll-cue-bounce 1.8s ease-in-out infinite;
}
@keyframes hero-scroll-cue-bounce {
  0%, 100% { transform: translateY(0); }
  50% { transform: translateY(4px); }
}

/* PFLICHT-Fallback: ohne Bewegungswunsch bleibt der Hero ein normales,
   nicht-klebendes Element - Sticky/Cover ist reine Zusatzinszenierung,
   kein Inhalt haengt daran. hero-scroll.js prueft dasselbe und greift bei
   reduzierter Bewegung gar nicht erst ein; diese Regel deckt zusaetzlich
   den Fall ab, dass CSS vor JS geladen wird. */
@media (prefers-reduced-motion: reduce) {
  .hero { position: static; }
  .hero-scroll-cue svg { animation: none; }
}

/* Der Chevron zeigt nur, dass noch etwas folgt. Ist der Hero der letzte Abschnitt, bleibt er im Markup,
   wird aber ausgeblendet. Sobald Abschnitte folgen, erscheint er wieder und das Scrolldesign greift. */
main > .hero:last-child .hero-scroll-cue { display: none; }