/* Site-weite Layout-Robustheits-Fixes – 2026-07-20, vierundvierzigster
   Durchgang. #main ist Avadas durchgehender Hauptinhalts-Wrapper um ALLE
   Seitenabschnitte auf JEDER Seite (nicht nur der Startseite).

   overflow:clip verhindert, dass Render-Überlauf einzelner Nachfahren
   (Transform-bedingt, Bild-Nachlade-Layoutverschiebungen, o.ä.) die
   scrollbare Dokumenthöhe künstlich aufbläht - das erzeugt sonst das
   "Zurückspringen" beim Erreichen des Seitenendes, weil der Browser
   document.scrollHeight nachträglich auf den tatsächlichen Wert korrigiert
   und die Scroll-Position dabei klemmt. Ursprünglich nur für die
   GSAP-Fold-In-Effekte der Startseite eingeführt (siehe
   drg-section-transitions.css, 2026-07-15), aber der gleiche
   Symptom-Effekt trat auch auf der KI-Risikomanagement-Seite auf, obwohl
   die dortige Seite gar keine GSAP-Animationen nutzt (Playwright-Nachweis:
   scrollHeight schrumpft dort ebenfalls beim Erreichen des Endes,
   ~47px). Da die genaue Überlaufquelle je nach Seiteninhalt variieren
   kann (Bilder, Avada-eigene Animationen, künftige Layout-Elemente), ist
   die robusteste Lösung, overflow:clip site-weit statt seitenspezifisch
   zu setzen, statt jede Einzelursache separat zu jagen.

   WICHTIG - Prüfpunkt für jede künftige Session mit Scroll-/Layout-
   Änderungen: Nach jeder neuen Seite oder jedem neuen Abschnitt mit
   Animationen/Bildern per Playwright prüfen, ob document.scrollHeight vor
   und nach dem Scrollen zum Seitenende gleich bleibt (Scroll-zu-Ende,
   300ms warten, Wert vergleichen). Weicht er ab, liegt ein Render-
   Überlauf-Bug vor, der zum "Zurückspringen" führt - siehe
   S01 Startseite.md Durchgang 33-36 für die ursprüngliche Fehlersuche. */
#main {
	overflow: clip;
}

/* Site-weiter Dunkel-Hintergrund als Fallback – 2026-07-20, vierundvierzigster
   Durchgang. Ausgangsbefund: Klick auf "English" im Sprachumschalter zeigte
   einen sichtbar anderen (hellen/weißen) Header/Seiteninhalt. Ursache: es
   existiert noch keine echte englische Startseiten-Übersetzung (Polylang
   pll_get_post(9, "en") liefert 0) - Mehrsprachigkeit/Übersetzungs-Workflow
   ist ein bekannter, bewusst zurückgestellter Punkt (siehe S04 Header und
   Navigation.md). Ohne Übersetzung fällt WordPress auf die Standard-
   Blog-Übersicht zurück, die keine unserer dunklen Fusion-Builder-Container
   enthält und deshalb Avadas Standard-Weiß zeigt (color_palette color1 =
   #FFFFFF) statt des Ember-Schemas.
   Diese Regel behebt NICHT das eigentliche Fehlen des Inhalts (das bleibt
   ein Punkt für den Übersetzungs-Workflow), sorgt aber dafür, dass JEDE
   Seite ohne eigene Fusion-Builder-Hintergrundfarbe trotzdem im
   Ember-Dunkel-Schema bleibt statt in Avadas hellem Standard-Look - robuster
   als jede einzelne Fallback-Seite individuell zu stylen. */
body {
	background-color: #0D0C0C;
	color: #EDE8E3;
}

/* Header-Hintergrund erzwungen statt nur body - Fund: auf der englischen
   Sprachversion (noch keine echte Übersetzung, Fallback auf die leere
   Standard-Blog-Übersicht) generiert Avada seine dynamische CSS für den
   Header offenbar unvollständig (header_bg_color #080807 erscheint gar
   nicht im Seiten-Quellcode, obwohl die Theme-Option korrekt gesetzt ist -
   vermutlich weil Avadas Dynamic-CSS-Generierung an eine einzelne
   Post-ID gebunden ist, die die Blog-Übersicht nicht hat). Statt Avadas
   interne Cache-/Generierungslogik weiter zu verfolgen: direkt und robust
   per eigenem, immer geladenem Stylesheet erzwungen. */
.fusion-header {
	background-color: #080807 !important;
}

/* Header-/Footer-Zeile an die Breite der Inhalts-Sektionen angleichen –
   2026-07-23. Ausgangsbefund von Dr. Gellner: Bei sehr breiten Fenstern
   (deutlich über 1400px) wandern Logo, Social-Media-Icons im Header und
   der Copyright-Text im Footer sichtbar nach rechts, während Kicker,
   Überschriften und Inhalte links angelehnt bleiben (Netzanimationen
   laufen weiterhin über die volle Breite).

   Ursache (per Playwright gemessen, u. a. bei 1920px Viewport-Breite):
   Zwei unterschiedliche Ausrichtungs-Systeme sind auf derselben Seite
   aktiv. Die Inhalts-Sektionen (hundred_percent-Container, Fusion-Builder-
   Spalten) laufen randlos über die volle Viewport-Breite und bekommen
   ihren Innenabstand über `.post-content{padding:0 30px}` – ihr Text
   beginnt deshalb bei JEDER Fensterbreite konstant bei x=30px vom
   linken Rand. Header- und Footer-Zeile (`.fusion-row` innerhalb
   `.fusion-header-wrapper` bzw. `.fusion-footer-copyright-area`) folgen
   dagegen Avadas Standard-Verhalten für "boxed" Kopf-/Fußzeilen-Inhalte:
   `max-width: var(--site_width)` (hier 1200px) plus `margin: 0 auto` –
   eine zum Viewport zentrierte Box. Solange der Viewport nur wenig breiter
   als 1200px ist, fällt der Unterschied kaum auf; bei deutlich breiteren
   Fenstern wächst der Abstand ((Viewport - 1200px) / 2) immer weiter, und
   Logo/Icons/Copyright rücken sichtbar von der linken Kante weg, während
   der übrige Content unverändert bei 30px bleibt.

   Fix: Für Header- und Footer-Zeile dieselbe 30px-Logik wie im Content
   erzwingen, statt der zentrierten 1200px-Box – `max-width` aufheben,
   festen 30px-Innenabstand statt zentrierender Außenabstände. Dadurch
   sitzen Logo/Social-Icons und Copyright-Text bei jeder Fensterbreite
   exakt an derselben x-Position wie Kicker/Überschriften/Content; rechts
   ausgerichtete Elemente (Sprachumschalter, Hauptmenü) rücken dafür näher
   an die tatsächliche rechte Fensterkante statt an eine künstliche
   1200px-Grenze – konsistent mit dem randlosen Verhalten der übrigen
   Seite. */
.fusion-header-wrapper .fusion-row,
.fusion-footer-copyright-area .fusion-row {
	max-width: 100% !important;
	margin-left: 0 !important;
	margin-right: 0 !important;
	padding-left: 30px;
	padding-right: 30px;
	box-sizing: border-box;
}

/* "Nach oben"-Button überlagert Footer-Social-Icons – 2026-07-23. Ausgangsbefund
   von Dr. Gellner (Punkt 2.2 nach der Header-/Footer-Ausrichtungskorrektur
   oben): Der "Nach oben"-Button legt sich bei bestimmten Fensterbreiten über
   die Social-Media-Icons im Footer.

   Ursache (per Playwright bei neun Breiten von 390px bis 1920px gemessen):
   `#toTop` ist `position: fixed; bottom: 0; right: 75px; height: 35px`
   (Avada-Standard) - der Button klebt IMMER an der tatsächlichen unteren
   Kante des Browser-Fensters, unabhängig von der Scroll-Position. Sobald
   das Seitenende erreicht ist, liegt der Footer zwangsläufig ebenfalls am
   unteren Fensterrand - die Social-Icons-Zeile hatte bisher nur 20px
   Innenabstand nach unten, also deutlich weniger als die 35px Höhe des
   Buttons. Ergebnis: Bei JEDER Desktop-Breite (nicht nur einzelnen)
   übrschneiden sich Button und Icons um ca. 15px vertikal - kein
   breitenabhängiger Bug, sondern ein grundsätzlich zu knapper
   Sicherheitsabstand zwischen einem fixierten Element und dem
   Dokumentende. (Auf Mobile/Tablet unterhalb von Avadas eigenem
   toTop-Breakpoint ist der Button ohnehin ausgeblendet - dort kein
   Überlappungsrisiko.)

   Fix: Statt den Button oder die Icons horizontal zu verschieben (würde
   bei jeder neuen Breite wieder neu kollidieren können, da beide
   letztlich rechts/unten am Viewport-Rand ausgerichtet sind), wird
   stattdessen vertikal Platz geschaffen - der Footer bekommt genug
   zusätzlichen unteren Innenabstand, damit die Social-Icons-Zeile IMMER
   oberhalb der 35px hohen Button-Zone endet, bevor das Dokument zu Ende
   ist. Das ist breitenunabhängig robust, weil es nicht auf die genaue
   horizontale Position von Button oder Icons ankommt, sondern nur auf den
   vertikalen Sicherheitsabstand zum Dokumentende. */
.fusion-footer-copyright-area {
	padding-bottom: 60px !important;
}