/* Fliesstext-Block fuer lange Redaktionstexte (Impressum, Datenschutz, Kampagnen- Firmenportrait, spaeter Blog-Artikel). Bewusst KEINE Karte/Box wie page-guide -- ein Rechtstext ueber mehrere tausend Woerter liest sich auf einer schlichten, begrenzten Spalte besser als in einer abgesetzten Flaeche mit Schatten. Nur eine komfortable Lesebreite (~70ch) plus die Typo-Anbindung fuer klassenloses HTML aus inhaltHtml -- alles andere kommt aus elemente.css/system.css. */@layer komponenten{.rich-text{container-type:inline-size;max-width:44rem;margin-inline:auto;padding-inline:var(--container-padding);padding-block:var(--space-16);/* Sektions-Faerbung (Guido, 2026-08-19: "Ton-Rhythmus" ueber die Blockfolge): exakt derselbe data-thema-Mechanismus wie hero.css/page-guide.css, nur lokal auf rich-text angewendet -- ohne eigenen [data-thema]-Block hier, die Rollen-Ueberschreibung passiert zentral in marke-todayislife.css. Fuer die 44rem-Lesespalte (Impressum/Datenschutz, kein 'thema' gesetzt) bleibt das wirkungslos (--farbe-grund = Seiten-Default), erst data-darstellung="seite" (volle Breite) macht die Faerbung sichtbar. */background:var(--farbe-grund);color:var(--farbe-text)}/* "Seite"-Darstellung (TEIL D, Guido 2026-08-19) -- volle Container-Breite wie jeder andere Seiten-Abschnitt (Hero/Cards), aber OHNE den Zeitungsstil-Look: keine Serife, kein Papier-Hintergrund, keine Mehrspaltigkeit. Gedacht fuer Argumentations-/Prinzipien-Abschnitte auf Themenseiten (z.B. /de/ai), die zu echtem Fliesstext wurden, aber optisch zum Rest der Seite (dunkler Hero, moderne Sans-Serif-Typo) passen muessen -- die schmale 44rem-Lesespalte (Default, kein 'darstellung'-Feld gesetzt) wirkt dort mittig-schmal und deplatziert, der Zeitungsstil ('spalten' gesetzt) bringt ungewollt Serife+Papier mit, die zu einer normalen Themenseite nicht passen. Nutzt bewusst NICHT den 100vw-Ausbruchstrick von .rich-text[data-spalten] weiter unten -- der ist nur fuer den randlosen Papier-Hintergrund noetig. Hier reicht der normale --container-max-Rahmen, identisch zum etablierten Muster von .hero__container (hero.css): max-width:var(--container-max) + margin-inline:auto statt eines 100vw-Ausbruchs ist der einfachere Weg fuer eine "normale" volle Breite ohne Hintergrund-Bleed. Reihenfolge im Stylesheet bewusst VOR .rich-text[data-spalten]: sollte ausnahmsweise beides gesetzt sein (Fehlbedienung), gewinnt bei gleicher Selektor-Spezifitaet die spaeter stehende Regel -- 'spalten' soll Vorrang behalten (siehe rich-text.schema.json, Feld 'darstellung'). */.rich-text[data-darstellung="seite"]{/* Vollbreite-Flaeche-Fix (Guido 2026-08-20): 'darstellung="seite"' setzt in site-lib.js#renderKomponente jetzt zusaetzlich 'istVollbreite' -> die .vollbreite-flaeche-Utility (design/base/utilities.css) uebernimmt max-width/width auf DIESEM Element (Layer-Vorrang schlaegt die vorherige, hier frueher stehende max-width:var(--container-max)-Regel, die die Faerbung faelschlich auf Content-Breite geklemmt hatte -- Bug gemeldet von Guido). padding-inline muss trotzdem hier auf 0, sonst bliebe die Aussen-Section trotz voller Breite optisch eingerueckt (doppeltes Padding: einmal hier von der generischen .rich-text-Basisregel oben, einmal von .vollbreite-flaeche__inhalt im Markup). */padding-inline:0;background:var(--farbe-grund)}/* Inhaltsverzeichnis (Aufgabe 1, Guido 2026-08-19) braucht mehr Breite als die 44rem-Lesespalte (Default oben): 14rem TOC-Spalte + --space-10 Gap + eine noch komfortabel lesbare Fliesstextspalte passen nicht in 44rem. Bug gefunden beim Verifizieren (Playwright, 1440px-Viewport): ohne diesen Override blieb .rich-text bei 44rem (704px) -- unter der 56rem-Schwelle der @container-Regel weiter unten, die 2-Spalten-Sidebar griff deshalb NIE, unabhaengig von der Fensterbreite. 64rem ist bewusst kleiner als --container-max (96rem, Hero/Cards- Breite) -- ein Rechtstext-Block soll nicht auf die volle Seitenbreite ausufern, nur genug Raum fuer TOC+Lesespalte nebeneinander bekommen. */.rich-text[data-inhaltsverzeichnis]{max-width:64rem}/* Gleiches Kantenraster wie Hero/Card-Sections (Guido 2026-08-20, Screenshot- belegt): vollbreite rich-text-Bloecke duerfen ihren Inhalt nicht nochmal intern zentrieren, sonst beginnt Text sichtbar spaeter als in den Nachbarsektionen. Lesebreite bleibt gedeckelt, aber LINKS ausgerichtet -- dieselbe Startkante wie die uebrigen Komponenten, kein zusaetzlicher margin-inline:auto-Versatz mehr. */.rich-text[data-darstellung="seite"] .rich-text__kopf,.rich-text[data-darstellung="seite"] .rich-text__inhalt{max-width:min(var(--lese-spalte-1), 100%);margin-inline:0}.rich-text[data-darstellung="seite"] .rich-text__inhalt p{max-width:none}.rich-text[data-darstellung="seite"] .rich-text__hauptbereich{width:100%}/* Zweispaltige Themen-/Definitionsseiten (Briefing Langtext 2026-10-13, Stufe 1): render/site-lib.js (seitenBloeckeHtml) zerlegt lange 'seite'-Texte in .rich-text__abschnitt-Bloecke (je H2, lange Abschnitte an Absatzgrenzen) und setzt data-seiten-spalten. Gleiche Mechanik wie der Blog (Multicol je Abschnitt, kein Springen beim Scrollen, DOM-Reihenfolge unveraendert), aber Sans, kein Papier. Schwelle 64rem bezieht sich auf die INHALTSbreite: .rich-text selbst ist bei 'seite' vollbreit, deshalb eigener benannter Container am Hauptbereich. Rechtstexte (kein data-darstellung) sind nie betroffen. */.rich-text[data-darstellung="seite"] .rich-text__hauptbereich{container:rt-text/inline-size}.rich-text[data-seiten-spalten] .rich-text__inhalt{max-width:calc(2 * var(--lese-spalte-2-weit) + var(--lese-gutter));gap:0;hyphens:auto}.rich-text[data-seiten-spalten] .rich-text__intro,.rich-text[data-seiten-spalten] .rich-text__abschnitt{max-width:var(--lese-spalte-1)}.rich-text[data-seiten-spalten] .rich-text__intro{margin-block-end:var(--space-8)}.rich-text[data-seiten-spalten] .rich-text__abschnitt{column-gap:var(--lese-gutter);column-rule:1px solid var(--farbe-linie)}.rich-text[data-seiten-spalten] .rich-text__abschnitt + .rich-text__abschnitt{margin-block-start:var(--space-8);padding-block-start:var(--space-8);border-block-start:1px solid var(--farbe-linie)}.rich-text[data-seiten-spalten] .rich-text__abschnitt--fortsetzung{margin-block-start:var(--space-6);padding-block-start:0;border-block-start:none}.rich-text[data-seiten-spalten] .rich-text__abschnitt > *{margin-block:0 var(--space-5);break-inside:avoid-column}.rich-text[data-seiten-spalten] .rich-text__abschnitt > *:last-child{margin-block-end:0}.rich-text[data-seiten-spalten] .rich-text__abschnitt > h2,.rich-text[data-seiten-spalten] .rich-text__abschnitt > h3{break-after:avoid-column;hyphens:manual;text-wrap:balance}.rich-text[data-seiten-spalten] .rich-text__abschnitt > h3{margin-block-start:var(--space-3)}.rich-text[data-seiten-spalten] .rich-text__abschnitt > :first-child{margin-block-start:0}/* Absaetze duerfen die Spalte wechseln (sonst entstehen ungleich hohe Spalten), aber nie mit weniger als 3 Zeilen auf einer Seite. */.rich-text[data-seiten-spalten] .rich-text__abschnitt > p{max-width:none;break-inside:auto;orphans:3;widows:3}.rich-text[data-seiten-spalten] .rich-text__abschnitt li{break-inside:avoid-column}@container rt-text (min-width: 64rem){.rich-text[data-seiten-spalten] .rich-text__abschnitt{columns:2;max-width:calc(2 * var(--lese-spalte-2-weit) + var(--lese-gutter))}.rich-text[data-seiten-spalten] .rich-text__abschnitt > .rich-text__begriffe,.rich-text[data-seiten-spalten] .rich-text__abschnitt > figure,.rich-text[data-seiten-spalten] .rich-text__abschnitt > table,.rich-text[data-seiten-spalten] .rich-text__abschnitt > .rich-text__bild-vollbreit{column-span:all}/* Einleitung (Text vor der ersten H2): erster Absatz als Lead ueber beide Spalten, weitere Einleitungsabsaetze laufen danach in zwei Spalten wie die Abschnitte. */.rich-text[data-seiten-spalten] .rich-text__intro{columns:2;column-gap:var(--lese-gutter);max-width:calc(2 * var(--lese-spalte-2-weit) + var(--lese-gutter))}.rich-text[data-seiten-spalten] .rich-text__intro > p:first-child{column-span:all;max-width:none;font-size:var(--text-lg);line-height:var(--leading-normal);text-wrap:pretty}.rich-text[data-seiten-spalten] .rich-text__intro > p{break-inside:auto;orphans:3;widows:3;max-width:none}}.rich-text[data-seiten-spalten] .rich-text__intro > *{margin-block:0 var(--space-5)}.rich-text[data-seiten-spalten] .rich-text__intro > *:last-child{margin-block-end:0}/* Zeitungsstil (TEIL B, Guido 2026-08-19) -- nur aktiv, wenn 'spalten' gesetzt ist (Blog-Artikel). Volle Container-Breite wie jede andere Seite (Guido- Nachtrag: KEINE schmale zentrierte Lesespalte), Lese-Serife statt Sans, warmer Papier-Hintergrund NUR fuer diesen Block (nicht sitebreit). Spalten selbst kommen erst innerhalb von .rich-text__inhalt (siehe unten), damit Kopf (Titel/Meta) ueber die volle Breite bleibt und nicht mitspaltet. *//* Nachtrag (TEIL B, Guido 2026-08-19): Papier-Hintergrund EXPLIZIT randlos ueber die volle Bildschirmbreite (nicht mehr nur --container-max) -- klassischer Ausbruch aus dem zentrierten Elternflow per width:100vw + negatives Zentrierungs-margin. padding-inline haelt den eigentlichen Inhalt (Kopf/Meta/Spalten, ueber die direkten Kind-Elemente hier drunter) trotzdem auf --container-max begrenzt und zentriert -- kein zusaetzlicher Wrapper im Markup noetig, da .rich-text selbst schon alle Kinder direkt umschliesst. border-radius/box-shadow ergeben bei echter Bildschirmbreite keinen Sinn mehr (keine sichtbaren Ecken an den Bildschirmraendern) -- entfernt. */.rich-text[data-spalten]{width:100vw;max-width:100vw;margin-inline:calc(50% - 50vw);/* max() statt reinem calc(): sobald --container-max (96rem) breiter ist als der Viewport (z.B. 1440px-Laptop -- Alltagsfall, kein Exot), wird (100vw - container-max)/2 negativ. calc() klemmt negative padding- Werte per Spec auf 0 -- damit stand der Inhalt randlos am Bildschirmrand (Bug Guido 2026-08-19), statt auf den normalen --container-padding zurueckzufallen. max() erzwingt --container-padding als Untergrenze, identisch zum Verhalten von max-width+margin-inline: auto bei jedem anderen .site-block. */padding-inline:max(var(--container-padding), calc((100vw - var(--container-max)) / 2 + var(--container-padding)));background:var(--farbe-papier);border-radius:0;box-shadow:none}.rich-text[data-spalten] .rich-text__kopf{max-width:65ch;margin-inline:auto}/* Nachschaerfung (Guido 2026-08-19, Screenshot-belegt): .rich-text__ki- hinweis stand bisher in derselben Regel wie __kopf (max-width:65ch + margin-inline:auto) -- dadurch landete der Hinweis in einer schmalen, ZENTRIERTEN Box, text-align:right drehte den Text darin nur intern nach rechts, ohne je den echten rechten Seitenrand zu erreichen. Fix: eigene Regel OHNE Breitenbegrenzung -- volle verfuegbare Breite, text-align schiebt den Text dadurch tatsaechlich an den rechten Rand. */.rich-text[data-spalten] .rich-text__ki-hinweis{max-width:none}.rich-text[data-spalten] .rich-text__inhalt{/* display:block zwingend noetig (Bug Guido 2026-08-19): die generische Regel .rich-text__inhalt weiter unten setzt display:flex; flex- direction:column -- ein Flex-Container ignoriert 'columns' komplett (Multicol gilt nur fuer Block-Container). Ohne dieses Reset stand columnCount:2 zwar im Computed Style (per Cascade-Spezifitaet gewonnen), lief aber visuell nie sichtbar in zwei Spalten -- per vollstaendigem Full-Page-Screenshot + Bounding-Box-Vergleich zweier Absaetze verifiziert, nicht nur getComputedStyle() (das allein hatte den Fehler in einer frueheren Runde verdeckt). Der Flex-'gap' entfaellt damit fuer den Abstand zwischen Absaetzen -- ersetzt durch margin-block-end auf den Kindern (siehe unten). Die eigentlichen 'columns'-Eigenschaften sitzen NICHT mehr hier, sondern auf .rich-text__abschnitt (siehe Nachtrag Guido 2026-08-19 unten) -- damit jeder Abschnitt seinen EIGENEN Multicol-Kontext hat und nicht der gesamte Artikel als eine einzige, kilometerlange Spalte laeuft. */display:block;font-family:var(--font-serif-lesend);line-height:var(--leading-relaxed);hyphens:auto}/* Spalten-Reset pro Abschnitt (Nachtrag Guido 2026-08-19): render/site-lib.js (spalteInhaltHtml) zerlegt inhaltHtml VOR dem Rendern an jeder Top-Level-

in eigene Abschnitte -- der Text VOR der ersten

landet in .rich-text__intro (immer einspaltig, wie ein Zeitungs-Lead-Absatz), jeder Abschnitt AB einer

in einem eigenen .rich-text__abschnitt. Jeder .rich-text__abschnitt ist ein eigener Multicol-Container -- das laesst den Browser die Spaltenhoehe PRO Abschnitt neu berechnen (column-fill:balance, Default), statt eine einzige Riesenspalte ueber den ganzen ~2500-Woerter- Artikel zu ziehen. Kein JS noetig, reiner CSS-Container-Reset durch echte Elementgrenzen im Markup. */.rich-text__intro{font-size:var(--lese-schrift);font-family:var(--font-serif-lesend);line-height:var(--leading-relaxed);hyphens:auto}.rich-text[data-spalten] .rich-text__abschnitt{/* column-fill: balance (Korrektur Guido 2026-08-19, ersetzt fruehere "auto"-Annahme): "auto" ist NICHT das CSS-Standardverhalten -- das ist "balance". "auto" fuellt Spalte 1 sequenziell, aber OHNE eine explizite Hoehe auf dem Multicol-Container gibt es fuer den Browser keinen Hoehen-Trigger, um in Spalte 2/3 zu springen. "balance" berechnet die Spaltenhoehe automatisch aus dem Inhalt DIESES Abschnitts und verteilt ihn gleichmaessig -- kein abgeschnittener Text, keine endlose Spalte. Deshalb keine explizite column-fill-Deklaration mehr noetig (Default). */column-gap:var(--space-10);column-rule:1px solid var(--farbe-linie);/* Default: 1 Spalte -- Container Query unten schaltet ab 40rem echte Breite hoch. Damit faellt jede Spaltenzahl auf schmalem Viewport automatisch auf 1 zurueck, unabhaengig vom konfigurierten Wert. */columns:1}/* Schwelle 64rem statt 40rem (Briefing Langtext 2026-10-13): bei 768 px waren die Spalten nur 38 Zeichen breit. Darunter 1 Spalte in Lesebreite, darueber 2 Spalten mit gedeckelter Spaltenbreite (--lese-spalte-2), sonst laeuft die Zeile auf breiten Schirmen auf > 80 Zeichen. */.rich-text[data-spalten] .rich-text__abschnitt{max-width:var(--lese-spalte-1)}@container (min-width: 64rem){.rich-text[data-spalten="2"] .rich-text__abschnitt{columns:2;column-gap:var(--lese-gutter);max-width:calc(2 * var(--lese-spalte-2) + var(--lese-gutter))}.rich-text[data-spalten="3"] .rich-text__abschnitt{columns:3;max-width:none}}/* Blog-Lead: Zeilenlaenge begrenzen (vorher 150-190 Zeichen), erster Absatz groesser. */.rich-text[data-spalten] .rich-text__intro{max-width:38rem}.rich-text[data-spalten] .rich-text__inhalt > .rich-text__intro:first-child > p:first-child{font-size:calc(var(--lese-schrift) * 1.2);line-height:var(--leading-normal);text-wrap:pretty}/* Ueberschriften/Listen/Zitate/Tabellen sollen innerhalb einer Spalte nicht mitten drin umbrechen -- sonst reisst der Zeitungslook auseinander. */.rich-text[data-spalten] .rich-text__abschnitt > *{break-inside:avoid-column}/* Waisen-Ueberschrift-Fix (Achilles 2026-08-19, Playwright-belegt an mehreren Breakpoints 700-1920px, "Der Raum veraendert sich..."/"So funktioniert Erkenntnis" im Assoziation-Artikel): ein .rich-text__abschnitt kann mehrere

-Abschnitte zu EINEM Multicol-Block zusammenfassen (siehe spalteInhaltHtml() in render/site-lib.js). Der Browser balanciert die Spaltenhoehe dieses Blocks selbst (column-fill:balance) und darf den Spaltenumbruch dabei genau zwischen eine

und ihren ersten Absatz legen -- 'break-inside:avoid-column' oben schuetzt nur JEDES Element einzeln, nicht die Fuge ZWISCHEN zwei aufeinanderfolgenden Elementen. Das ist reines Browser-Rendering (haengt von echter, zur Build-Zeit unbekannter Pixelhoehe ab) -- die JS-Blockgrenzen in spalteInhaltHtml koennen das nicht verhindern, nur diese CSS-Eigenschaft kann es: sie weist den Balance-Algorithmus an, direkt NACH einer Ueberschrift keinen Spaltenumbruch zu platzieren, wenn es sich vermeiden laesst. */.rich-text[data-spalten] .rich-text__abschnitt > h2,.rich-text[data-spalten] .rich-text__abschnitt > h3{break-after:avoid-column;/* Oberkanten der Spalten (Vera 7): ein oberer Rand wird am Spaltenanfang nicht abgeschnitten und versetzte die zweite Spalte um ca. 25 px. Der Abstand vor einer Ueberschrift steht stattdessen am Vorgaenger (naechste Regel). */margin-block-start:0}.rich-text[data-spalten] .rich-text__abschnitt > :has(+ h2),.rich-text[data-spalten] .rich-text__abschnitt > :has(+ h3){margin-block-end:var(--space-6)}/* Abstand zwischen Elementen -- sowohl INNERHALB eines Abschnitts/der Intro (Ersatz fuer den Flex-'gap' der generischen Regel, siehe oben) als auch ZWISCHEN Intro/Abschnitten selbst (.rich-text__inhalt > *). */.rich-text[data-spalten] .rich-text__inhalt > *,.rich-text[data-spalten] .rich-text__intro > *,.rich-text[data-spalten] .rich-text__abschnitt > *{margin-block-end:var(--space-5)}.rich-text[data-spalten] .rich-text__inhalt > *:last-child,.rich-text[data-spalten] .rich-text__intro > *:last-child,.rich-text[data-spalten] .rich-text__abschnitt > *:last-child{margin-block-end:0}/* Zierlinie am Block-Uebergang (Guido 2026-08-19, Screenshot-Referenz): wenn zwei .rich-text__abschnitt DIREKT aufeinanderfolgen (kein einspaltiger Intro-/Atempause-Block dazwischen -- der trennt bereits optisch genug, siehe spalteInhaltHtml()), bekommt der zweite Block eine duenne horizontale Linie oben, ueber die volle Breite BEIDER Spalten (nicht nur eine Spalte -- deshalb border-block-start auf dem Abschnitt selbst, nicht auf einer Spalte/Kind-Element). Selbe Rolle wie die vertikale column-rule zwischen den Spalten (--farbe-linie), damit es wie dieselbe Zier-Familie wirkt statt eine zweite Linienfarbe einzufuehren. */.rich-text[data-spalten] .rich-text__abschnitt + .rich-text__abschnitt{margin-block-start:var(--space-10);padding-block-start:var(--space-10);border-block-start:1px solid var(--farbe-linie)}/* Bug-Fix (Guido 2026-08-19, Screenshot-belegt): die generische Regel '.rich-text__inhalt p { max-width: 65ch }' weiter unten ist fuer die schmale Rechtstext-Lesespalte (Impressum/Datenschutz, KEIN data-spalten) gedacht -- in Zeitungsstil-Artikeln griff sie aber AUCH im 1-spaltigen Intro-Block (der volle --container-max-Breite nutzen soll, siehe .rich-text[data-spalten] oben) und kappte ihn versehentlich auf 65 Zeichen, mit riesiger Leerflaeche rechts als Folge. Im 2/3-spaltigen .rich-text__abschnitt greift dieselbe Kappung ebenfalls unnoetig (die Spaltenbreite selbst ist ohnehin schon schmaler als 65ch). Beide Faelle hier gezielt zurueckgesetzt -- die einspaltige Rechtstext-Lesespalte (kein data-spalten) bleibt unveraendert bei 65ch. */.rich-text[data-spalten] .rich-text__intro p,.rich-text[data-spalten] .rich-text__intro blockquote,.rich-text[data-spalten] .rich-text__abschnitt p,.rich-text[data-spalten] .rich-text__abschnitt blockquote{max-width:none}/* Spalten-Sprung-Icon (Guido 2026-08-19, siehe rich-text.js fuer die Positionierungs-Logik/Begruendung). display:block + margin-inline- start:auto + width:fit-content statt absoluter Positionierung -- rechtsbuendig, robust gegenueber jeder Textmenge, ohne Zeilenhoehen- Berechnung gegen echten Fliesstext. Erbt break-inside:avoid-column und margin-block-end bereits ueber die bestehende '.rich-text__abschnitt > *'-Regel oben (rich-text.js haengt es als direktes Kind von .rich-text__abschnitt ein). */.rich-text__spalten-sprung{display:block;width:fit-content;margin-inline-start:auto;padding:var(--space-1);color:var(--farbe-text-dezent);background:none;border:none;border-radius:var(--radius-full);cursor:pointer;transition:color 0.15s ease,background-color 0.15s ease}.rich-text__spalten-sprung:hover,.rich-text__spalten-sprung:focus-visible{color:var(--farbe-akzent);background:var(--farbe-flaeche)}.rich-text__spalten-sprung svg{display:block;width:var(--space-4);height:var(--space-4)}.rich-text__ki-hinweis{margin-block-start:var(--space-10);padding-block-start:var(--space-4);border-block-start:1px solid var(--farbe-linie);/* Nachtrag Guido 2026-08-19: deutlich kleiner (--text-xs, kleinster vorhandener Type-Scale-Schritt) und rechtsbuendig statt der bisherigen linksbuendigen --text-sm-Darstellung -- dezenter KI-Transparenz-Hinweis, kein prominentes Fliesstext-Element. Zweite Nachschaerfung (Guido, Screenshot-belegt): --text-xs bleibt -- ist bereits der kleinste Schritt in system.css, kein noch kleinerer Token vorhanden (geprueft). Das "zu gross/zentriert"-Problem lag an der Breitenbegrenzung weiter oben (max-width:65ch + margin-inline:auto), nicht an der Schriftgroesse -- siehe Fix bei .rich-text[data-spalten] .rich-text__ki-hinweis. */font-size:var(--text-xs);text-align:right;color:var(--farbe-text-dezent);line-height:var(--leading-relaxed)}/* Dritte Nachschaerfung (Guido 2026-08-19, Screenshot-belegt): voller Container-Breite lief der Hinweistext nur auf 2 (zu breite) Zeilen -- enger fassen, damit er auf 3 Zeilen umbricht. margin-inline-start:auto (statt margin-inline:auto) haelt die Box weiterhin an der RECHTEN Kante verankert (text-align:right bleibt fuer den Text selbst erhalten) -- nur ihre eigene Breite schrumpft, sie wandert nicht in die Mitte. */.rich-text[data-spalten] .rich-text__ki-hinweis{/* Zeichenbreite statt rem: bei 13 px waren 38rem = 94 Zeichen je Zeile (Vera 1), jetzt ca. 65. */max-width:56ch;margin-inline-start:auto}/* Vorheriger/naechster-Artikel-Navigation + Lesezeit (Guido 2026-08-19, zwei Nachschaerfungen) -- nur auf echten Blog-Artikeln vorhanden (render/site-lib.js liefert 'lesezeit' nur dort, siehe baueArtikelNavigation()), oben UND unten im Artikel mit demselben Grid-Layout. Beide Instanzen sitzen FLUSH an ihrer jeweiligen Nachbar- Flaeche (oben direkt am Hero, unten direkt am Footer -- keine Box mehr, keine runden Ecken, kein eigener Hintergrund) und grenzen sich nur ueber eine duenne Trennlinie UEBER DIE GESAMTE BILDSCHIRMBREITE ab (nicht nur Container-Breite) -- per Pseudo-Element mit demselben 100vw-Ausbruch- Trick wie .rich-text[data-spalten] selbst (siehe oben), damit der eigentliche Inhalt (Pfeile/Titel/Lesezeit) trotzdem auf Container-Breite bleibt und nicht bis an den Bildschirmrand laeuft. Die Linie sitzt jeweils auf der Seite, die zum Fliesstext hin zeigt (oben: unterhalb der Leiste: unten: oberhalb der Leiste) -- symmetrisch gespiegelt. */.rich-text[data-spalten] .rich-text__artikel-nav{position:relative;display:grid;grid-template-columns:1fr auto 1fr;align-items:center;gap:var(--space-4);padding-block:var(--space-4);font-size:var(--text-sm)}.rich-text[data-spalten] .rich-text__artikel-nav--oben{margin-block:0 var(--space-8)}.rich-text[data-spalten] .rich-text__artikel-nav--oben::after{content:'';position:absolute;inset-block-end:0;inset-inline-start:50%;width:100vw;margin-inline-start:-50vw;border-block-end:1px solid var(--farbe-linie)}.rich-text[data-spalten] .rich-text__artikel-nav--unten{margin-block:var(--space-8) 0}.rich-text[data-spalten] .rich-text__artikel-nav--unten::after{content:'';position:absolute;inset-block-start:0;inset-inline-start:50%;width:100vw;margin-inline-start:-50vw;border-block-start:1px solid var(--farbe-linie)}/* Oben/unten wirklich FLUSH gegen Hero/Footer: die generische .rich-text- Regel (ganz oben in dieser Datei) setzt padding-block: var(--space-16) auf dem gesamten Container -- ohne Override bliebe trotz margin:0 auf der jeweiligen Nav-Leiste selbst noch dieser Innenabstand als Luecke stehen (beim ersten Versuch genau so beobachtet: 64px Luecke zum Hero = exakt --space-16). :has() greift NUR, wenn die jeweilige Nav-Leiste tatsaechlich vorhanden ist (nicht auf Impressum/Datenschutz etc.). */.rich-text[data-spalten]:has(.rich-text__artikel-nav--oben){padding-block-start:0}.rich-text[data-spalten]:has(.rich-text__artikel-nav--unten){padding-block-end:0}.rich-text__artikel-nav-link{display:flex;align-items:center;gap:var(--space-2);min-width:0;color:var(--farbe-text);text-decoration:none}.rich-text__artikel-nav-link:hover .rich-text__artikel-nav-titel{text-decoration:underline}.rich-text__artikel-nav-link--zurueck{grid-column:1;justify-self:start}.rich-text__artikel-nav-link--weiter{grid-column:3;justify-self:end;text-align:right}.rich-text__artikel-nav-titel{overflow:hidden;text-overflow:ellipsis;white-space:nowrap;/* Verhindert, dass ein langer Nachbar-Titel die mittige Lesezeit verdraengt -- Grid-Spalte selbst ist 1fr (elastisch), der Titel innerhalb bricht stattdessen mit Ellipsis ab. */max-width:22ch}.rich-text__artikel-nav-pfeil{flex-shrink:0;color:var(--farbe-akzent);font-weight:var(--weight-bold)}.rich-text__artikel-nav-lesezeit{grid-column:2;justify-self:center;color:var(--farbe-text-dezent);white-space:nowrap}/* Schmaler Viewport: Grid-Spalten haben keinen Platz mehr fuer drei Elemente nebeneinander -- stapeln, in Lesereihenfolge (zurueck, Lesezeit, weiter). Container Query statt Media Query, konsistent mit dem bestehenden Spalten-Umschalter oben (@container (min-width: 40rem)). */@container (max-width: 39.99rem){.rich-text[data-spalten] .rich-text__artikel-nav{grid-template-columns:1fr;justify-items:start;gap:var(--space-3)}.rich-text__artikel-nav-link--zurueck{grid-column:1;order:1}.rich-text__artikel-nav-lesezeit{grid-column:1;justify-self:start;order:2}.rich-text__artikel-nav-link--weiter{grid-column:1;justify-self:start;text-align:left;order:3}}.rich-text__kopf{margin-block-end:var(--space-10)}/* Inhaltsverzeichnis (Aufgabe 1, Guido 2026-08-19) -- fuer lange Rechtstexte (Impressum, Datenschutz) mit vielen Abschnitten. ZWEI Markup-Varianten statt einer per Container-Query umgestylten
(siehe rich-text.mustache fuer die ausfuehrliche Begruendung): ein Playwright- Check zeigte, dass moderne Chromium-Versionen den geschlossenen details-Inhalt intern per content-visibility-Unterdrueckung verstecken, NICHT mehr (nur) per stylebarem 'display:none' -- ein CSS-Override auf den Kindern (auch mit zusaetzlichem content-visibility:visible) blieb wirkungslos, die Kinder blieben trotz korrektem computed display:block unsichtbar. Robuster Ersatz: '.rich-text__toc--breit' (normales