/* Basis-Typografie der HTML-Elemente.
*
* Diese Werte sind NICHT aus dem Elementor-Kit abgeleitet, sondern am 2026-08-19 im Browser
* auf lifespin.health gemessen (computed styles, sechs Viewports, work/measure-elements.py,
* Rohdaten in work/elements-measured.json). Das Kit setzt fuer h1-h6 nur Familie und
* Gewicht; die Groessen kommen aus dem Astra-Stack und waeren aus keiner Konfigurationsdatei
* ablesbar gewesen.
*
* Gemessen wird auf /datenschutz_apotheke/ — die einzige Seite, deren Inhalt komplett aus
* rohem HTML in EINEM text-editor-Widget besteht, also ohne Elementor-Overrides. Auf
* /datenschutz/ und /impressum/ liegen widget-eigene Ueberschriftengroessen (h2 22px,
* h3 18px) darueber; die gehoeren an das jeweilige Element, nicht in diese Basis.
*
* Ohne diesen Block greift die ACSS-Ueberschriftenskala und macht aus einem h3 74 px statt 24.
* Betrifft jeden Text, der als rohes HTML im Inhalt steht (Impressum, Datenschutz, …).
*
* Reihenfolge: nach ACSS laden, sonst gewinnt ACSS.
*/
body {
font-family: 'Public Sans', sans-serif;
font-weight: 400;
font-size: 16px;
/* Als Variable, weil derselbe Wert weiter unten als Knopf-Strut gebraucht wird
(siehe `.brxe-button { min-height }`). Ein zweites Mal hingeschriebene 28
waere ein Handwert; so ist es derselbe geportete Wert. */
--ls-strut: 28px;
line-height: var(--ls-strut);
color: #161616;
}
h1, h2, h3, h4, h5, h6 {
font-family: 'Exo', sans-serif;
color: #000000;
margin-top: 0;
margin-bottom: 20px;
}
/* R59 (Fall 245) — Ueberschriften in FREMDEM Elementor-Markup, das den Abbau
* ueberlebt hat. The Events Calendar speichert unter `tribe_events_before_html`
* einen HTML-Baustein, der als Option in der Datenbank liegt und deshalb
* unveraendert weiterrendert, obwohl Elementor deaktiviert ist:
*
*
Meet us
*
* Auf Live setzt Elementors eigenes Stylesheet dafuer
* `.elementor-heading-title { margin-bottom: 0 }`. Faellt das Plugin weg, greift
* stattdessen die h1-h6-Regel darueber mit ihren 20px. Weil `.tribe-events-before-html`
* keinen eigenen Block-Formatting-Context aufspannt, kollabiert dieser Aussenabstand
* nach aussen und schiebt den GESAMTEN nachfolgenden Event-Inhalt nach unten —
* gemessen /event/medtech-world-europe/ @1440: Live gegen Dev 20px Versatz ueber
* den kompletten Inhaltsblock, @390 rund 7px (dort daempft eine abweichende
* Zeilenhoehe desselben H1 den Effekt teilweise).
*
* Der Bestand ist klein und vollstaendig ausgezaehlt (21 Seiten + Detailrouten,
* `grep -o` auf das gerenderte Dev-HTML): die Klasse kommt auf genau zwei Routen
* vor, /event// (1x) und /events/ (2x), beide aus derselben TEC-Option.
* Uebernommen wird deshalb Elementors Regel im Wortlaut statt eines auf
* `.tribe-events-before-html` verengten Sonderfalls: sie ist die treue Portierung
* und traegt auch, wenn dasselbe Fremdmarkup an einer weiteren Stelle auftaucht. */
.elementor-heading-title {
margin-bottom: 0;
/* Die ZEILENHOEHE dieser Ueberschrift steht bewusst nicht hier, sondern in
* `events.css` (Block R45/R59): dort liegt bereits eine Regel mit derselben
* Spezifitaet, und `events.css` laedt spaeter — eine zweite Deklaration an
* dieser Stelle waere toter Code. */
}
/* R38 — Zeilenhoehe als `em`, NICHT einheitenlos. Live (Astra `h1..h4`, Kit `h2/h3`)
* schreibt ueberall `1.4em` bzw. `1.3em`. Beide Schreibweisen ergeben denselben
* computed value (getComputedStyle meldet auf beiden Staenden `22.4px`), sie runden
* aber verschieden auf Layouteinheiten: Live's h4 ist 22.40625 px hoch, mit
* einheitenlosem 1.4 sind es 22.390625 — eine einzige Layouteinheit (1/64 px).
* Auf /privacy-statement/ mit rund 43 Ueberschriften summiert sich das auf 0,64 px
* und erzeugte ein Band an der Fusszeilenkante. Gemessen per CDP
* `CSS.getMatchedStylesForNode` (diag/r38-whylh.py), nicht aus dem computed value —
* der ist auf beiden Staenden identisch und haette nichts gezeigt. */
h1 { font-size: 45px; line-height: 1.4em; font-weight: 400; }
h2 { font-size: 33px; line-height: 1.4em; font-weight: 400; }
h3 { font-size: 24px; line-height: 1.4em; font-weight: 500; }
/* h4-h6 kommen im rohen Inhalt nicht vor und sind daher nicht am Live-Stand messbar.
* Werte aus dem Elementor-Kit, beim ersten Vorkommen gegen Live pruefen. */
h4 { font-size: 20px; line-height: 1.4em; font-weight: 400; }
h5 { font-size: 20px; line-height: 1.4em; font-weight: 400; }
h6 { font-size: 15px; line-height: 1.4em; font-weight: 500; }
/* Fliesstext erbt die Groesse vom body und haelt das Verhaeltnis 1.4 — NICHT 16px fest.
* Astra verkleinert die Basis ab 880px auf 91.2% (14.592px), und der Absatz geht mit.
* Mit festen 16px stand /privacy-statement/ auf dem Tablet durchgaengig zu gross
* (219 Abweichungen), auf dem Desktop war es nicht zu sehen, weil beide Werte dort 16px
* sind. Gemessen auf /imprint/ bei 1440/880/768/390 am 2026-08-19. */
p { font-size: 1em; line-height: inherit; font-weight: inherit; margin-top: 0; margin-bottom: 20px; }
ul, ol { font-size: 1em; line-height: inherit; font-weight: inherit; margin-top: 16px; margin-bottom: 16px; }
li { font-size: 1em; line-height: inherit; font-weight: inherit; margin-top: 0; margin-bottom: 0; }
a { color: #870A09; font-weight: 400; }
/* Bis 1024px sind alle Werte identisch mit Desktop — Astra skaliert erst ab 880px. */
@media (max-width: 880px) {
body { font-size: 14.592px; }
h1 { font-size: 40px; }
h2 { font-size: 25px; }
h3 { font-size: 20px; }
h4 { font-size: 18.24px; }
}
/* Unter 767px hebt das Kit h2 und h3 wieder an — kein Tippfehler, so steht es live.
*
* h4 und die Zeilenhoehe von h1 haben hier bis R39 GEFEHLT (Fall 193). Solange
* Elementor lief, lieferte `.elementor-kit-9 h1..h4` die Werte auf Dev gratis mit;
* mit dem Abbau fielen sie weg. Vollstaendig aus dem Kit ausgelesen (alle Regeln
* .elementor-kit-9 h1..h6 samt Media Queries):
* @media(max-width:767px){ h1 33px/1.4em · h2 28px/1.3em · h3 24px/1.3em · h4 20px/1.2em }
*
* Warum h4 beim Aufmass in Phase 3 durchgerutscht ist: die Kundenregel
* `.privacy-statement h4 { font-size: 1em }` ist spezifischer und macht daraus auf
* der Datenschutzseite 14,592 px — dort sah h4 unauffaellig aus. Auf /imprint/,
* wo die Regel nicht gilt, standen 18,24 gegen Lives 20 px.
* Folge des Fehlens: /privacy-statement/ @390 war 186 px hoeher als Live
* (28 H4 mit 1.4 statt 1.2 Zeilenhoehe, Summe exakt +185,85). */
@media (max-width: 767px) {
h1 { font-size: 33px; line-height: 1.4em; }
h2 { font-size: 28px; line-height: 1.3em; }
h3 { font-size: 24px; line-height: 1.3em; }
h4 { font-size: 20px; line-height: 1.2em; }
}
/* Grundstil des Text-Widgets aus dem Elementor-Kit (system_typography "Text").
*
* Elementor gibt ihn JEDEM text-editor-Widget mit, auch wenn im Widget selbst keine
* Typografie gesetzt ist — die Regel steht als `.elementor-widget-text-editor
* { font-size: var(--e-global-typography-text-font-size) }` in Elementors globalem CSS.
* Im Widget-JSON ist davon nichts zu sehen, genau wie beim globalen Button-Stil.
* Auf dem Desktop faellt das Fehlen nicht auf (16px = Basisgroesse), ab 880px schon:
* dort verkleinert Astra die Basis auf 14.592px, der Text-Baustein bleibt aber 16px.
* Gilt fuer alle Bausteine, die Elementor diese Typografie mitgibt — Text, Liste,
* Akkordeon, Zeitstrahl. Rohes HTML (Elementors html-Widget, etwa auf /imprint/ und
* /privacy-statement/) bekommt sie NICHT und erbt die verkleinerte Basis; das ist der
* Grund, warum die Absatzregel weiter unten mit 1em arbeitet.
* Ein benannter Kit-Style (.txt-*) laedt spaeter und ueberstimmt diesen Grundstil —
* genau die Reihenfolge, die Elementor auch hat.
*/
/* R17 — die Handliste fuer den Abstand des LETZTEN Absatzes ist ERSATZLOS weg.
*
* Was hier bis R16 stand: die Grundregel
* main .brxe-text > p:last-child { margin-bottom: 0 }
* und darunter VIER von Hand gepflegte Gegenausnahmen mit zusammen 28 Element-IDs
* (R6, R11, R13, R16), die den Abstand fuer einzelne Bausteine wieder auf 20px
* setzten. Jede Runde kamen welche dazu.
*
* Die Unterscheidung, um die es geht, steckt im Elementor-QUELLTEXT des Bausteins:
* steht dort roher Text, rendert Elementor ihn ohne
und ohne Abstand; steht dort
* ein Absatz, bleibt der Abstand. Genau diese Unterscheidung bildet der Konverter
* seit R11 im MARKUP ab (`Converter.kein_wpautop`, work/convert.py Z. 762 ff.):
* rohen Inhalt legt er in einen `
`-Mantel, damit Bricks' `wpautop()` keinen
* Absatz erfindet; Inhalt mit Block-Tag laesst er unangetastet.
*
* Erhoben ueber ALLE 21 Seiten und die drei Vorlagen (work/diag/r17a-textscan.py,
* SQL ueber `_elementor_data`, oberste Ebene in Block- und Rohtext-Laeufe zerlegt):
* 64 Bausteine nur Block | 64 Bausteine nur Rohtext | 1 leer | 0 gemischt
* Es gibt also KEINEN Baustein, in dem beide Formen zusammentreffen — der
* `
`-Mantel des Konverters deckt den Rohtextfall vollstaendig ab.
*
* Damit war die Grundregel nur noch schaedlich: sie traf ausschliesslich Bausteine,
* deren
Live ebenfalls hat, und nahm ihnen die 20px. Die Ausnahmeliste hat das
* fuer 28 bekannte IDs wieder repariert, fuer die uebrigen nicht.
*
* Gemessen am gerenderten Stand, `work/diag/r17a-mb.py 1440`: je Dev-
* `.brxe-text` der computed `margin-bottom` des letzten Kindes, gegen das TIEFSTE
* Live-Element mit demselben normalisierten Text. Ueber alle 21 Seiten,
* 281 Dev-Textbausteine:
* vorher (Grundregel + 28er Liste): 277 gleich, 2 abweichend, 2 ohne Gegenpart
* nachher (beides entfernt): 279 gleich, 0 abweichend, 2 ohne Gegenpart
* Die zwei behobenen Faelle sind `#brxe-630f09` (/investor-relations/) und
* `#brxe-6ebcba` (/datenschutz/) — Live 20px, Dev 0px, in keiner Handliste.
* Die zwei „ohne Gegenpart" sind Paarungsluecken des Messwerkzeugs, keine Funde:
* `#brxe-708073` und `#brxe-adef94` haben auf Live einen minimal anderen Text.
* Rohdaten: work/diag/r17a/mb-vor/, work/diag/r17a/mb-nach/.
*
* Bausteine, die Bricks ein