/* Integrations-Overrides fuer TYPO3 14/bootstrap-package, die im migrierten Original-Theme
   keine Entsprechung haben (im Gegensatz zu fileadmin/Resources/Public/Css/*, das 1:1 aus
   dem alten TYPO3 10.4 uebernommen wurde) - deshalb eine eigene Datei statt die migrierten
   CSS-Dateien mit neuem, dort fremden Code zu vermischen. */

/* Bootstrap-packages .frame-Basisklasse (jedes normale Content-Element - Text, Header,
   Table, ... - das nicht ueber unsere eigenen Container-Templates laeuft, wird darin
   gewrappt) bringt standardmaessig vertikales Padding mit (--frame-spacing, 1.75rem+
   responsiv skaliert, siehe vendor/bk2k/bootstrap-package/Resources/Public/Scss/components/
   _frame.scss). Das gab es im Original nicht - dort kam aller vertikale Abstand
   ausschliesslich ueber die (ebenfalls migrierten) frame-space-before- und
   frame-space-after-Klassen aus tronet.webflow.css. Ohne diesen Reset bekommt jedes so
   gerenderte Element zusaetzlichen, im Original nicht vorhandenen Abstand oben/unten
   (aufgefallen an der Ueberschrift "Die vielfaeltigen Aufgabengebiete...", betrifft aber
   grundsaetzlich jedes plaine Content-Element). Nur die Basis-Padding-Deklaration wird
   zurueckgesetzt, nicht die CSS-Variable --frame-spacing selbst - die wird an anderer Stelle
   (frame-layout-embedded, frame-has-backgroundimage, frame-size-small) auch fuer
   links/rechts-Innenabstand verwendet und soll dort unveraendert bleiben. */
.frame {
    padding-top: 0;
    padding-bottom: 0;
}

/* Bootstrap-packages .frame-Wrapper definiert per CSS-Variable eine eigene Standardfarbe fuer
   Links ohne eigene Klasse:
       .frame a[class=""], .frame a:not([class]) { color: var(--frame-link-color); }
   Durch die Attribut-Selektor-Kombination hat das Spezifitaet (0,2,1) - hoeher als tronets
   eigene, einfachere Kontext-Regeln wie ".box_mit_icon a { color: #fff }" (0,1,1) aus
   tronet.webflow.css/tronet.typo3.css. Die verlieren dadurch, obwohl sie unveraendert im
   migrierten CSS vorhanden sind. Betrifft NICHT nur Links in farbigen Boxen: da praktisch
   jedes Content-Element in .frame steckt, bekommt JEDER klassenlose Link site-weit
   bootstrap-packages Default-Wert (--frame-link-color, gruenlich per bootstrap-eigenem
   Theme-Setting) statt tronets blauem "a { color: #024a89 }" aus tronet.webflow.css.

   Fix ueber dieselbe CSS-Variable statt ueber einen Spezifitaets-Wettlauf: --frame-link-color
   vererbt sich normal durch den DOM-Baum, unabhaengig von der Spezifitaet der Regel, die sie
   konsumiert. Root-Definition = tronets normale Link-Farbe; pro farbiger Box (die jeweils
   explizit eine andere a-Textfarbe definiert) wird die Variable zusaetzlich lokal
   ueberschrieben - genau dieselben Selektoren wie die jeweilige "X a { color: ... }"-Regel im
   migrierten CSS. Ein neuer Box-Typ mit eigener Link-Farbe braucht hier denselben
   zweizeiligen Zusatz. */
:root {
    --frame-link-color: #024a89;
    --frame-link-hover-color: #024a89;
}
.box_mit_icon,
div[class^="kontaktbox_v"] table.contenttable,
.button_box.tro-dark-blue {
    --frame-link-color: #fff;
    --frame-link-hover-color: #fff;
}

/* we_cookie_consents eigenes Template (Pi2/"Datenschutzeinstellungen anpassen"-Button)
   bringt hartkodiert die Bootstrap-5-Klassen "btn btn-primary btn-lg" mit. Farbe/Hintergrund/
   Padding werden von tronets migrierter Regel ".tx-we-cookie-consent a.btn-primary"
   (tronet.global.css) ueberschrieben (gleiche Spezifitaet 0,2,1 wie Bootstraps
   ".btn"/".btn-lg", tronet.global.css laedt aber vor dieser Datei - "Ergaenzung" statt
   "Konkurrenz"). Zwei Eigenschaften fehlten der alten Regel, weil es im Original kein
   Bootstrap-".btn" mit eigenem Default gab, gegen das man sie haette setzen muessen:
   border-radius (Bootstraps "--bs-border-radius", macht den Button rund statt eckig) und
   font-size (kommt von der Groessen-Modifikatorklasse "btn-lg", macht den Button sichtbar
   groesser als im Original). Gleicher Selektor wie tronets Regel, direkt ergaenzt statt
   dupliziert.

   Seit websedit/cookie-consent als Site-Set eingebunden ist (siehe config.yaml), liefert
   die Extension ihr EIGENES CSS mit (page.includeCSS.we_cookie_consent_style, "style.css"),
   das dieselbe Regel ".tx-we-cookie-consent a.btn-primary" mit eigener Farbe (tuerkis auf
   weiss) definiert - GLEICHE Spezifitaet (0,2,1), laedt aber NACH dieser Datei (TYPO3
   sortiert TypoScript-Array-Keys fuer includeCSS alphabetisch: "file44" vor
   "we_cookie_consent_style") und gewinnt dadurch die Farbe zurueck. Deshalb hier zusaetzlich
   ueber die ohnehin vorhandene Klasse "js-showConsentModal" auf Spezifitaet (0,3,1)
   angehoben, statt von der (fragilen, nicht projektseitig kontrollierbaren) Ladereihenfolge
   abzuhaengen. */
.tx-we-cookie-consent a.btn-primary {
    border-radius: 0;
    font-size: 15px;
}
.tx-we-cookie-consent a.btn-primary.js-showConsentModal {
    color: #fff;
    background-color: #024a89;
    border-color: #024a89;
}

/* Derselbe "js-showConsentModal"-Button (identische Klassen "btn btn-primary
   js-showConsentModal") kommt noch in einem ZWEITEN, unabhaengigen Kontext vor: als
   Platzhalter-Link in we_cookie_consents Content-Blocker-Wrapper (".placeholder-when-inactive",
   siehe tronet.global.css), der eingebettete Inhalte wie die Baustellenkarte auf
   /service/baustellen ersetzt, solange keine Cookies akzeptiert wurden. Anders als der
   Consent-Banner-Button oben war dieser im Original NIE ein echter, gefuellter Button -
   ".btn"/".btn-primary" waren dort wirkungslose Klassennamen ohne jede CSS-Regel, der Link sah
   deshalb einfach wie ein normaler blauer Textlink aus (kein Bootstrap-Rahmen/-Hintergrund
   damals, weil es dort schlicht kein Bootstrap gab). Eigener, auf ".placeholder-when-inactive"
   beschraenkter Selektor (trifft NICHT den Consent-Banner-Button oben, andere Eltern-Klasse
   ".tx-we-cookie-consent"): Bootstraps komplette Button-Optik zurueckgesetzt, nur die Textfarbe
   bleibt. */
.placeholder-when-inactive a.btn-primary.js-showConsentModal {
    color: #024a89;
    background-color: transparent;
    border: 0;
    padding: 0;
    border-radius: 0;
}

/* ke_search 7.x (aktuell installierte Version) rendert die Ergebnis-Pagination als
   Bootstrap-Komponente (ul.pagination > li.page-item > a/span.page-link) statt wie im
   Original ueber ke_searchs eigenes klassisches Markup (.kesearch_pagebrowser ul li a,
   siehe tronet.ke_search.css - dessen Regeln greifen deshalb hier gar nicht, andere
   Klassennamen). Zwei bootstrap-package-Defaults weichen vom Original ab:
   - .pagination ist ein "display:flex" ohne justify-content (= linksbuendig) - im Original
     war der Pagebrowser ueber "text-align:center" auf dem Wrapper zentriert.
   - Der markierte Seiten-Button nutzt bootstrap-packages eigene, hartkodierte
     --bs-pagination-active-bg (#577760, gruenlich) statt tronets Blau - anders als bei
     --frame-link-color ist das hier eine lokale, direkt in der .pagination-Regel gesetzte
     Bootstrap-Variable, kein geerbter globaler Wert. */
.pagination {
    justify-content: center;
    --bs-pagination-active-bg: #024a89;
    --bs-pagination-active-border-color: #024a89;
}

/* Cookie-Consent-BANNER (die vorgelagerte Notiz-Leiste, nicht das Einstellungen-Modal
   weiter unten): tronets migrierte Regel ".cookie-notice .cn-body p.cn-ok .cm-btn"
   (tronet.global.css) stammt noch von der alten, auf der Live-Seite laufenden Klaro-Version,
   deren drei Buttons in einem "<p class="cn-ok">" lagen. Die hier installierte Version 7.0.1
   rendert stattdessen ein "<div class="cn-ok">" mit anderer Struktur (zwei <button> in
   ".cn-buttons" + ein "<a class="cm-link cn-learn-more">" fuer "Einstellungen bearbeiten") -
   der Typselektor "p.cn-ok" matcht dadurch nichts mehr, tronets Regel greift also gar nicht
   (nicht, wie eine fruehere Notiz hier faelschlich annahm, "bereits korrekt"). Es gewinnt
   ersatzlos die Extension-eigene, mit "#klaro" ID-praefixierte Regel (style.css): weisse/
   transparente Buttons mit blauem Rahmen plus Icons (Stift/X/Haken per "::before"-Pseudo-
   Element). Original: alle drei blau gefuellt mit weisser Schrift, keine Icons, Hover
   haesslich gruen, eckig (kein border-radius, kollidiert sonst mit dem Extension-Default
   von 4px). Fix mit demselben "#klaro..."-Praefix (gleiche Spezifitaet wie die
   Extension-Regel) plus "!important" (Klaro laedt sein Basis-CSS zur Laufzeit per JS
   nachtraeglich als <style>-Tag). */
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cm-btn,
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cm-link.cn-learn-more {
    background: #024a89 !important;
    border: none !important;
    border-radius: 0 !important;
    color: #fff !important;
    font-family: "Oswald", Helvetica, Arial, sans-serif !important;
    font-size: 15px !important;
    font-weight: 400 !important;
}
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cm-btn:hover,
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cm-link.cn-learn-more:hover {
    background: #87c43f !important;
    color: #fff !important;
    opacity: 1 !important;
}
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cm-btn::before,
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cm-btn:hover::before,
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cm-link.cn-learn-more::before,
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cm-link.cn-learn-more:hover::before {
    content: none !important;
}

/* Reihenfolge + Breite der drei Banner-Elemente (Kollegen-Wunsch): "Ablehnen" und
   "Alle zulassen" liegen im DOM eine Ebene tiefer als "Einstellungen bearbeiten" - sie
   stecken in einem eigenen, verschachtelten Flex-Container ".cn-buttons", waehrend der Link
   direktes Kind von ".cn-ok" ist. "order"/Breiten-Regeln auf den Buttons selbst wuerden
   dadurch nur INNERHALB von ".cn-buttons" wirken und den Link nicht einbeziehen. Fix:
   ".cn-buttons" per "display: contents" aus dem Rendering aufgeloest (der Container-Kasten
   verschwindet, seine beiden Buttons ruecken eine Ebene hoch und werden direkte Flex-Items
   von ".cn-ok") - danach lassen sich alle drei Elemente gleichberechtigt per "order"/"flex"
   auf ".cn-ok" anordnen, unabhaengig von der urspruenglichen DOM-Verschachtelung.

   Zweite Falle, erst nach visueller Kontrolle aufgefallen (Ablehnen-Button war komplett
   unsichtbar): eine ab 768px greifende, ID-praefixierte Extension-Regel setzt auf
   ".cm-btn-success" UND ".cm-link" ohne Modifikator-Klasse "position: absolute" (Layout
   fuer eine schwebende Variante, die hier gar nicht genutzt wird) - absolut positionierte
   Elemente werden aus dem Flex-Fluss genommen, "order"/"flex" liefen dadurch ins Leere und
   beide landeten deckungsgleich uebereinander an der von der Extension vorgegebenen
   Position, "Ablehnen" (das einzige verbleibende In-Flow-Element) einfach zentriert genau
   darunter. Fix: "position: static" zusaetzlich erzwungen. Dieselbe Regel setzt zudem
   "max-width" auf alle drei (33%/keine Deklaration/33% via "margin"-Trick) - ebenfalls
   explizit ueberschrieben, sonst kappt sie die per "width" gesetzte Breite.

   Dritte Falle (selbstverschuldet): "Einstellungen bearbeiten" (der Link) war kurzzeitig
   niedriger als die beiden Buttons, weil hier zusaetzlich "padding: 0.5em" + "display: flex"
   gesetzt war, um den Linktext zu zentrieren - das ueberschrieb (per eigenem "!important")
   die Extension-eigene "#klaro..."-Regel "padding: 1em 0" (768px-Breakpoint), die eigentlich
   schon dieselbe Innenabstand-/Zeilenhoehen-Kombination wie die Buttons liefert. Wieder
   entfernt: der Link braucht keine eigene Padding-/Flex-Regel, "text-align: center" kommt
   bereits als Extension-Default mit und reicht bei einzeiligem Text.

   "margin: .5em auto" auf "Alle zulassen" ist Kollegen-Vorgabe 1:1 aus dem Original
   uebernommen (siehe auch die migrierte, hier aber wirkungslose Regel in tronet.global.css:
   "p.cn-ok .cm-btn.cm-btn-success { margin: .5em auto }"). */
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cn-body .cn-ok {
    display: flex !important;
    flex-direction: row !important;
    flex-wrap: nowrap !important;
    align-items: center !important;
    justify-content: center !important;
    gap: 0.5em !important;
}
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cn-body .cn-buttons {
    display: contents !important;
}
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cn-body .cn-ok .cm-btn.cm-btn-danger {
    box-sizing: border-box !important;
    position: static !important;
    order: 1 !important;
    flex: 0 0 175px !important;
    width: 175px !important;
    max-width: 175px !important;
    margin: 0 !important;
}
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cn-body .cn-ok .cm-btn.cm-btn-success {
    box-sizing: border-box !important;
    position: static !important;
    order: 2 !important;
    flex: 0 0 50% !important;
    width: 50% !important;
    max-width: 50% !important;
    margin: .5em auto !important;
}
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cn-body .cn-ok .cm-link.cn-learn-more {
    box-sizing: border-box !important;
    position: static !important;
    order: 3 !important;
    flex: 0 0 175px !important;
    width: 175px !important;
    max-width: 175px !important;
    margin: 0 !important;
}

/* "Datenschutzerklaerung"-Link im Fliesstext ueber den Buttons: tronets migrierte Regel
   "a.privcyPage { color: #024a89 !important; }" (tronet.global.css) setzt denselben
   Klassennamen voraus, den die alte Extension-Version im Template mitgab - die hier
   installierte Version 7.0.1 rendert den Link ganz ohne Klasse, tronets Regel greift also
   wieder nicht (derselbe Migrationslücken-Musterfall wie beim Banner selbst weiter oben).
   Extension-eigener Default (klaro.css/style.css, kein "#klaro"-Praefix hier) ist dunkles
   Navy mit Unterstrich. Fix ueber den reinen Textinhalt-Link (".cn-body p a", trifft nicht
   die Buttons/den ".cm-link"-Einstellungen-Link, die eigene Klassen haben). */
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cn-body p a {
    color: #024a89 !important;
    text-decoration: none !important;
}
#klaro .klaro.we_cookie_consent .cookie-notice:not(.cookie-modal-notice) .cn-body p a:hover {
    opacity: 0.7 !important;
}

/* Das Klaro-Datenschutzeinstellungen-Modal (we_cookie_consent) nutzt in der hier
   installierten Bibliotheksversion 7.0.1 ein anderes Config-Schema als auf der Live-Seite
   (kein "hideDeclineAll" dort - offensichtlich eine deutlich aeltere Klaro-Version) und zeigt
   deshalb im Footer standardmaessig drei Buttons (Ablehnen/Einstellungen speichern/Alle
   akzeptieren, ".cm-footer-buttons") nebeneinander, linksbuendig - im Original war es ein
   einzelner, zentrierter, blau gefuellter Button. Per Nutzerentscheidung 2026-08-26 hier
   optisch angenaehert statt die Bibliotheksversion zu erzwingen: Reihe zentriert,
   "Einstellungen speichern" (die Haupt-Aktion, entspricht am ehesten dem alten Einzelbutton)
   in Tronet-Blau gefuellt, die beiden Nebenaktionen im gleichen Outline-Stil wie die jetzt
   (s.o.) korrekt blau gefuellten Buttons der vorgelagerten Cookie-Notiz-Leiste.

   Klaro injiziert sein eigenes CSS zur Laufzeit per JS als <style>-Tag (nicht als Datei -
   "href: inline" im DevTools), u.a. ".klaro .cookie-modal .cm-modal .cm-footer-buttons {
   justify-content: space-between }" mit Spezifitaet (0,4,0) - schlaegt eine einfache
   ".cm-footer-buttons"-Regel unabhaengig von der Ladereihenfolge. Deshalb hier dieselbe
   Selektor-Tiefe gespiegelt (Spezifitaet (0,5,0)) plus "!important" als Absicherung, falls
   Klaro seine Styles nach unseren nachlaedt/neu einfuegt. */
.klaro.we_cookie_consent .cookie-modal .cm-modal .cm-footer-buttons {
    justify-content: center !important;
}
.klaro.we_cookie_consent .cookie-modal .cm-modal .cm-footer-buttons .cm-btn.cm-btn-accept {
    background-color: #024a89 !important;
    border-color: #024a89 !important;
    color: #fff !important;
}
.klaro.we_cookie_consent .cookie-modal .cm-modal .cm-footer-buttons .cm-btn.cm-btn-decline,
.klaro.we_cookie_consent .cookie-modal .cm-modal .cm-footer-buttons .cm-btn.cm-btn-accept-all {
    background-color: #fff !important;
    border-color: #024a89 !important;
    color: #024a89 !important;
}
.klaro.we_cookie_consent .cookie-modal .cm-modal .cm-footer-buttons .cm-btn.cm-btn-decline:hover,
.klaro.we_cookie_consent .cookie-modal .cm-modal .cm-footer-buttons .cm-btn.cm-btn-accept-all:hover {
    background-color: #024a89 !important;
    color: #fff !important;
}

/* Bootstrap-package wrappt jede <table> aus RTE-Inhalten automatisch in ein zusaetzliches
   "<div class="table-responsive">" (vendor/bk2k/bootstrap-package/Configuration/Sets/
   ContentElements/TypoScript/Helper/ParseFunc.typoscript, externalBlocks.table.stdWrap.wrap)
   - im Original-Markup gab es diesen Wrapper nicht, "table.contenttable" war dort direktes
   Kind von "div[class^=kontaktbox_v]". tronets migrierte Regel
   "div[class^=kontaktbox_v] table.contenttable { clear: left; ... }" (tronet.webflow.css)
   trifft die <table> selbst weiterhin (Nachfahren-Selektor, kein Kind-Selektor), aber das
   "clear:left" wirkt nur auf die Box, die tatsaechlich am Blockfluss teilnimmt - und das ist
   jetzt der NEUE .table-responsive-Wrapper, nicht mehr die <table> direkt. Ohne eigenes
   "clear" auf dem Wrapper ruecken Tel./E-Mail-Tabellen neben (statt unter) den per
   "float:left" gesetzten ".kontakt-titel"/".kontakt_name" (siehe Header/SubHeader.html-
   Partial) und werden dadurch in einen wenige Pixel schmalen Rest-Streifen gequetscht -
   sichtbar als "fehlende" Telefonnummer, obwohl sie im HTML vorhanden ist. */
div[class^="kontaktbox_v"] .table-responsive {
    clear: left;
}

/* Derselbe Kontaktbox-Bereich, anderer Bootstrap-package-Konflikt (Kollegen-Fund: Name/
   Position und die Tel.-Zeile beruehren sich ohne Abstand, im Original 20px Luft). Ursache:
   bootstrap-packages eigene Theme-CSS (typo3temp/assets/bootstrappackage/css/theme-*.css)
   bringt die generische Konvention ".frame-header > :last-child { margin-bottom: 0; }" mit
   (gedacht fuer Ueberschriften direkt vor dem Frame-Body, die keinen doppelten Abstand
   erzeugen sollen). ".kontakt-titel" ist in diesem Markup zufaellig das letzte Kind von
   ".frame-header" (erst "kontakt_name", dann "kontakt-titel", siehe SubHeader.html-Partial)
   - die Regel trifft es mit und schlaegt tronets migrierte "margin-bottom: 20px"
   (abwasserbetrieb-troisdorf.webflow.css): Klasse + ":last-child" zaehlt wie zwei Klassen,
   also hoehere Spezifitaet als die einfache ".kontakt-titel"-Klasse. Fix mit noch hoeherer,
   auf die Kontaktbox beschraenkter Spezifitaet (nicht global an ".frame-header > :last-
   child" rutteln, das brauchen echte Ueberschriften vor Frame-Bodies andernorts weiterhin). */
.kontaktbox_v1 .frame-header > .kontakt-titel {
    margin-bottom: 20px !important;
}

/* Alte Webflow-Redakteure haben vereinzelt RTE-Absaetzen eine Klasse "h1"-"h6" verpasst, rein
   als optische Vorlagen-Auswahl im Webflow-Editor (z.B. "<p class="h3">" auf /ueber-uns/
   karriere, "Aktuell haben wir keine Stellen ausgeschrieben..."), OHNE dass das alte Theme
   dafuer je eine ".h3"-Regel definiert hat - abwasserbetrieb-troisdorf.webflow.css kennt nur
   die TAG-Selektoren "h1".."h6", keine gleichnamigen Klassen. Der <p> blieb dort optisch ein
   ganz normaler Absatz (dimgrey, 15px, 24px Zeilenhoehe), die Klasse war wirkungslose
   Webflow-Altlast.
   Bootstrap-package bringt jetzt aber selbst ".h1"-".h6"-Utility-Klassen mit (typo3temp/
   assets/bootstrappackage/css/theme-*.css, bilden 1:1 die jeweilige <h1>-<h6>-Typografie
   nach), die als Klassen-Selektor (Spezifitaet 0,1,0) den einfachen Tag-Selektor "p" aus dem
   migrierten CSS (Spezifitaet 0,0,1) unabhaengig von der Ladereihenfolge schlagen - der
   Absatz sieht dadurch neu wie eine echte Ueberschrift aus (24px, fett, dunkel) statt wie im
   Original ein normaler Fliesstext. Fix: dieselben Werte wie die migrierte "p"-Regel
   (abwasserbetrieb-troisdorf.webflow.css) hier nochmal gezielt fuer "p.h1".."p.h6"
   (Spezifitaet 0,1,1, schlaegt Bootstraps ".h1"-".h6" zuverlaessig), damit ein <p> mit einer
   dieser Klassen wieder wie ein ganz normaler Absatz aussieht. */
p.h1, p.h2, p.h3, p.h4, p.h5, p.h6 {
    margin-bottom: 10px;
    color: dimgrey;
    font-size: 15px;
    line-height: 24px;
    font-weight: 400;
}

/* RTE-Tabellen wie auf /strassenbeleuchtung ("Nationale Klimaschutzinitiative...") tragen aus
   der alten Webflow-Redaktion noch das veraltete HTML-Attribut "border" (z.B.
   "<table border="1" cellpadding="10" cellspacing="0" class="contenttable">") - vor
   Bootstrap-package hat der Browser daraus per HTML5-Spec (das "border"-Attribut setzt einen
   impliziten Default fuer die border-width jeder <td>/<th>-Zelle) automatisch sichtbare
   Innenrahmen erzeugt, ohne dass .contenttable dafuer selbst eine CSS-Regel braucht - deshalb
   kennt weder tronet.webflow.css noch .contenttable irgendeine Border-Deklaration fuer td/th.
   Bootstrap-packages eigenes Reboot-CSS setzt aber global "thead,tbody,tfoot,tr,td,th {
   border-width: 0 }" (typo3temp/assets/bootstrappackage/css/theme-*.css) - echtes CSS schlaegt
   das praesentative HTML-Attribut IMMER, unabhaengig von Spezifitaet oder Ladereihenfolge, die
   Innenrahmen verschwinden dadurch site-weit bei jeder Tabelle mit "border"-Attribut.
   Fix: das Attribut gezielt per Attribut-Selektor abfragen ("[border]", KEIN globaler
   ".contenttable td"-Reset - Kontaktbox-Tabellen in kontaktbox_v1/v2 haben nie ein
   "border"-Attribut und sollen weiterhin randlos bleiben) und dieselbe Randfarbe wie
   .contenttables eigener Aussenrahmen (#b5c0c7) wiederherstellen. */
table.contenttable[border] th,
table.contenttable[border] td {
    border: 1px solid #b5c0c7;
}

/* Bootstrap-5-Radiobuttons/-Checkboxen (".form-check-input", z.B. im "Art der
   Anfrage"-Formularfeld auf /service/kundenservice, EXT:form) werden per "appearance: none"
   komplett neu gezeichnet und brauchen dafuer Bootstraps eigene "width:1em; height:1em;"
   (typo3temp/assets/bootstrappackage/css/theme-*.css) - ohne die kollabiert der Kreis auf
   wenige Pixel Breite (sichtbar als duenner Strich statt Radiobutton). tronets migrierte
   Regel "input[type="checkbox"], input[type="radio"] { width: auto }" (tronet.global.css)
   hat im Original nie mit einem appearance:none-Radiobutton kollidiert - dort wurden
   Checkboxen/Radios immer nativ vom Browser gezeichnet, "width:auto" bedeutete schlicht
   "Standardgroesse". Der Selektor hat aber per Attribut-Selektor houhere Spezifitaet (0,1,1)
   als Bootstraps Klassen-Selektor (0,1,0) und gewinnt deshalb unabhaengig von der
   Ladereihenfolge. Fix per noch spezifischerem Selektor (0,2,1). */
.form-check-input[type="radio"],
.form-check-input[type="checkbox"] {
    width: 1em;
    height: 1em;
}

/* EXT:form-Absenden-/Weiter-/Zurueck-Buttons bekommen ueber Configuration/Form/TroContainers/
   config.yaml (prototypes.standard.formElementsDefinition.Form.renderingOptions.
   formNavigation) zusaetzlich zu Bootstraps eigenen ".btn"/".btn-primary"/
   ".btn-outline-primary"-Klassen die migrierte Klasse ".w-button" - site-weiter Standard fuer
   JEDES Formular, kein Redakteur muss dafuer selbst eine CSS-Klasse setzen. ".w-button"
   existiert bereits unveraendert in tronet.webflow.css/webflow.css, hat als reiner
   Klassen-Selektor aber dieselbe Spezifitaet (0,1,0) wie Bootstraps eigenes ".btn-primary" -
   welche Regel gewinnt, haenge sonst von der (fragilen) Ladereihenfolge ab. Deshalb hier
   nochmal mit den tatsaechlich gesetzten Klassenkombinationen (Spezifitaet 0,3,0),
   gewinnt zuverlaessig unabhaengig von der Reihenfolge. */
.btn.btn-primary.w-button {
    color: #fff;
    border: 1px solid #024a89;
    background: #024a89;
}
.btn.btn-primary.w-button:hover {
    background: #fff;
    border: 1px solid #024a89;
    color: #024a89;
}
.btn.btn-outline-primary.w-button {
    color: #024a89;
    border: 1px solid #024a89;
    background: #fff;
}
.btn.btn-outline-primary.w-button:hover {
    background: #024a89;
    border: 1px solid #024a89;
    color: #fff;
}

/* EXT:form-Eingabefelder/Textareas (Bootstraps ".form-control", z.B. Kontaktformular auf
   /service/kundenservice) sollen wieder wie die alten Webflow-".w-input"/".w-select"-Felder
   aussehen (webflow.css: "border: 1px solid #cccccc; color: #333333;", keine explizite
   "border-radius" = eckig) statt Bootstraps abgerundeten, gruenlich umrandeten Feldern
   (--bs-border-radius, ".form-control:focus" mit gruenem Fokus-Schatten
   "rgba(87, 119, 96, 0.25)"). Fokuszustand identisch zu "tronet.global.css":
   ".w-input:focus, .w-select:focus { border-color: #3898EC; outline: 0 none; }" - kein
   Bootstrap-Box-Shadow-Glow im Original, deshalb hier explizit entfernt statt nur
   ueberschrieben. Gilt fuer jedes Formular/jedes Feld (kein form-spezifisches YAML noetig,
   ".form-control" ist Bootstraps generische Basisklasse fuer alle Text-/E-Mail-/Telefon-/
   Textarea-Felder).
   "color" braucht "!important": border/border-radius greifen bei gleicher Spezifitaet (0,1,0)
   wie Bootstraps ".form-control{color:var(--bs-body-color)}" bereits ohne weiteres (spaeter
   geladene Datei gewinnt reibungslos), nur ausgerechnet bei "color" verliert dieselbe Regel
   trotz spaeterer Ladeposition - per Test verifiziert (auch ein frisch per JS nachtraeglich
   angehaengtes "<style>.form-control{color:rot}</style>" ohne "!important" gewinnt nicht,
   exakt dieselbe Regel MIT "!important" schon). Ursache nicht abschliessend geklaert
   (vermutlich eine Bootstrap-interne CSS-Custom-Property-Eigenheit bei "var(--bs-body-color)"
   statt eines literalen Werts) - "!important" ist hier der pragmatische, empirisch
   verifizierte Fix, genau wie bei den Klaro-Modal-Buttons weiter oben in dieser Datei. */
.form-control {
    border: 1px solid #cccccc;
    border-radius: 0;
    color: #333333 !important;
}
.form-control:focus {
    border-color: #3898EC;
    outline: 0;
    box-shadow: none;
}

/* PDF-Icon vor Downloads (Kollegen-Fund auf /downloadcenter): im Original gab es hier mal
   Icons (Webflow-Markup "<div class="download_icon"><img src="https://daks2k3a4ib2z.
   cloudfront.net/.../icon_..._download.png"></div>"), aber diese alte Webflow-CDN-Bildquelle
   ist tot - auch auf der Live-Seite selbst kaputt (kein migrierbarer Ist-Zustand). Das
   migrierte Markup nutzt hier ohnehin TYPO3s eigenes Core-Inhaltselement "Uploads"
   ("ul.ce-uploads li a"), das nie eigene Icons kannte. Deshalb bewusst neu statt migriert:
   ein selbst gezeichnetes, eingebettetes SVG (data-URI - keine externe Bildquelle, die wieder
   sterben koennte) als kleines rotes PDF-Symbol vor jedem Downloadlink. Gescopet auf die
   Dateiendung ".pdf" statt auf die Klasse ".ce-uploads", damit eine Datei-Liste mit anderen
   Dateitypen (kommt im Theme an anderer Stelle ggf. vor) kein falsches PDF-Icon bekommt.
   Das "::before" haengt am ".ce-uploads-fileName"-Span, nicht am "<a>" selbst: Fluid Styled
   Contents eigenes CSS setzt diesen Span auf "display: block" (fuer die eigene Klick-
   flaeche/Unterstreichung) - ein "::before" auf dem "<a>" wuerde dadurch als eigene Zeile VOR
   dem Block landen (Icon ueber statt neben dem Text). Innerhalb des Spans selbst ist das
   Icon dagegen ganz normaler erster Inline-Inhalt und bleibt in derselben Zeile wie der
   Dateiname.

   Haengender Einzug bei langen, umbrechenden Dateinamen (Kollegen-Fund): ohne Weiteres bricht
   die zweite Zeile ganz links unter das Icon um, nicht buendig unter den Textanfang. Klassischer
   Icon-plus-Text-Trick: "padding-left" auf den Span (schiebt JEDE Zeile um die Icon-Breite
   nach rechts) plus gleich grosses negatives "text-indent" (zieht NUR die erste Zeile wieder
   zurueck, wo dann das Icon per "::before" sitzt) - 16px Icon + 6px Abstand = 22px. */
ul.ce-uploads li a[href$=".pdf"] .ce-uploads-fileName {
    padding-left: 22px;
    text-indent: -22px;
}
ul.ce-uploads li a[href$=".pdf"] .ce-uploads-fileName::before {
    content: "";
    display: inline-block;
    width: 16px;
    height: 16px;
    margin-right: 6px;
    vertical-align: middle;
    background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'%3E%3Cpath fill='%23d32f2f' d='M6 2c-1.1 0-2 .9-2 2v16c0 1.1.9 2 2 2h12c1.1 0 2-.9 2-2V8l-6-6H6z'/%3E%3Cpath fill='%23fff' fill-opacity='.85' d='M14 2v6h6z'/%3E%3C/svg%3E");
    background-size: contain;
    background-repeat: no-repeat;
}