/* Absichtlich fast leer.

   Die gesamte Gestaltung kommt aus den gespiegelten Original-Stylesheets,
   die jede Seite selbst mitbringt (12-29 Dateien je Route, plus die
   eingebetteten <style>-Bloecke). Wer hier etwas ergaenzt, weicht von der
   Vorlage ab - genau das soll diese Replikation nicht tun. */
html, body { margin: 0; padding: 0; }

/* Ab hier: bewusste Abweichungen von der Vorlage, auf Wunsch des Betreibers.

   1. Hover im aufgeklappten Menue

   Elementor legt auf jeden Eintrag des Klappmenues beim Ueberfahren einen
   vollflaechigen Balken in der Sekundaerfarbe:

     .elementor-<id> .elementor-element-<id> .elementor-nav-menu--dropdown
       a:hover { background-color: var(--e-global-color-secondary) }

   Auf schmalen Fenstern ist das ein kraeftiger blauer Streifen ueber die
   ganze Breite. Ersetzt durch eine leichte Tonung derselben Farbe plus
   blaue Schrift - dieselbe Aussage, ohne den Balken.

   !important ist hier kein Faulheitsmittel: Die Elementor-Regel traegt
   Post- und Element-Kennungen im Selektor, die sich je Seite unterscheiden
   (elementor-1435, element-757a151, ...), und ihr Stylesheet steht im
   Dokument spaeter als diese Datei. Ohne !important gewinnt sie zweifach. */
.elementor-nav-menu--dropdown a:hover,
.elementor-nav-menu--dropdown a.elementor-item:hover,
.elementor-nav-menu--dropdown a.elementor-item:focus-visible {
  background-color: rgba(3, 120, 184, 0.08) !important;
  color: #0378b8 !important;
}

/* 2. Der weisse Abschnitt verdeckte die letzten Textzeilen des blauen

   Gestalterisch sollen die weissen Karten auf dem blauen Band aufliegen.
   Dafuer traegt das blaue Band unten Leerraum, und der folgende Abschnitt
   wird mit einem negativen Abstand darueber gezogen. Nur war der Hochzug
   groesser als der Leerraum:

     blaues Band   --padding-bottom:  380px
     Folgeabschnitt margin-top:      -420px  (bis 1024px)
                                     -480px  (darueber)

   Gemessen auf der Startseite, Abstand zwischen Textende und Beginn des
   folgenden Abschnitts:

     360 / 375 / 390 / 430 / 768 px   -26 px
     1024 / 1440 / 1920 px            -86 px

   Negativ heisst: Der folgende Abschnitt beginnt OBERHALB des Textendes und
   legt sich darueber. Der Text im blauen Band ist weiss, der folgende
   Abschnitt hell - weiss auf hell liest sich wie verblasst, und die letzte
   Zeile bricht mitten im Satz ab. Auf jeder geprueften Breite, nicht nur auf
   dem Handy.

   Der Leerraum unten muss also mindestens so gross sein wie der Hochzug,
   plus etwas Luft. 60px Luft, damit eine zusaetzlich umbrechende Zeile - bei
   anderer Schriftgroesse, anderer Sprache, anderem Browser - nicht sofort
   wieder darunter geraet. Der gestalterische Eindruck bleibt: Die Karten
   liegen weiterhin genauso weit auf dem Band. */
.elementor-element-39e4a6b {
  --padding-bottom: 540px !important;
}

/* 1023 und nicht 1024: Bei genau 1024px rechnet Elementor bereits mit dem
   Desktop-Hochzug von -480px. Eine Regel bis einschliesslich 1024px haette
   dort den kleineren Leerraum gesetzt und genau ein Pixel neben dem
   Breakpoint wieder 14px Luft gelassen statt 74. Gemessen. */
@media (max-width: 1023px) {
  .elementor-element-39e4a6b {
    --padding-bottom: 480px !important;
  }
}

/* 3. Die gestapelten Karten waren auf 600px genagelt und blieben halb leer

   Das Stacking-Cards-Widget setzt bis 1024px eine feste Kartenhoehe:

     @media (max-width: 1024px) { --card-height: 600px }
     .ue_card_content { height: var(--card-height); overflow: hidden }
     .ue_cards_wrapper { grid-template-rows: repeat(5, var(--card-height)) }

   Auf dem Desktop ist die Variable leer, die Karte waechst also mit dem
   Inhalt. Auf Tablet und Handy nicht - dort steht sie starr auf 600px.

   Gemessen, was der Inhalt der fuenf Karten tatsaechlich braucht:

     320px  480 | 360px  486 | 390px  485
     430px  491 | 768px  443 | 1023px 352

   Hoechster Wert ueber alle Breiten: 491px. Bei 600px Kartenhoehe bleiben
   also zwischen 109 und 248 Pixel leer - sichtbar als blaue Flaeche unter
   dem Text, auf jeder der fuenf Karten.

   Die Hoehe laesst sich nicht einfach auf auto stellen: Die Rasterzeilen
   des Stapels brauchen ein bestimmtes Mass, sonst rutscht der Stapeleffekt.
   Und overflow:hidden heisst, dass eine ZU KLEINE Hoehe Text abschneidet -
   schlimmer als Leerraum. Darum 540px: 49 Pixel ueber dem gemessenen
   Hoechstwert, also knapp zwei Textzeilen Reserve fuer den Fall, dass eine
   andere Schriftfassung oder ein anderer Browser breiter umbricht.

   Das stammt aus der Vorlage, nicht aus dem Umzug - die WordPress-Seite
   hatte dieselbe tote Flaeche. */
/* !important, weil die Vorlage einen ID-Selektor benutzt
   (#uc_stacking_cards_elementor_274cac2). Ein Attributselektor verliert
   dagegen unabhaengig von der Reihenfolge - gemessen: ohne !important blieb
   die Karte bei 600px. */
/* 530 und nicht 510: Bei 510px blieben auf 430px Breite nur 40 Pixel
   Reserve - anderthalb Textzeilen. overflow:hidden schneidet stillschweigend
   ab, das ist die unangenehmere Fehlerart als etwas Leerraum. Mit 530px sind
   es 60 Pixel. */
@media (max-width: 767px) {
  [id^="uc_stacking_cards"] {
    --card-height: 530px !important;
  }
}

/* Zwischen 768 und 1024 bricht der Text deutlich weniger um, der Inhalt
   braucht dort nur noch rund 400px. Eine einzige Hoehe fuer den ganzen
   Bereich bis 1024px liess hier bis zu 302 Pixel leer - deshalb gestaffelt.
   Gemessen: hoechster Inhalt bei 768px 403px, bei 1023px 320px. */
@media (min-width: 768px) and (max-width: 1024px) {
  [id^="uc_stacking_cards"] {
    --card-height: 450px !important;
  }
}

/* 4. Unter der letzten FAQ-Frage stand der Abstand doppelt

   Drei FAQ-Bloecke der Seite sind als Container im Container gebaut: ein
   aeusserer Abschnitt traegt die Ueberschrift, ein innerer das Akkordeon.
   Beide sind eigenstaendige Elementor-Abschnitte, und beide setzen ein
   eigenes --padding-bottom. Der Leerraum wird also zweimal berechnet.

   Gemessen ueber alle vier Breiten, innen + aussen:

     Seite                innerer     390    768   1024   1440
     /produkt/            j1000090   40+40  40+80  20+80  64+80
     /en/product/         j1000090   40+40  40+80  20+80  64+80
     /anwendungsfaelle/   fq8a0010   40+80  40+80  20+80  64+80
     /en/use-cases/       u5000090   40+40  40+80  20+80  64+80

   Alle 20 Seiten wurden auf dasselbe Muster abgesucht: ein .e-con.e-parent
   als letztes Kind eines anderen .e-con.e-parent, beide mit unterem
   Polster. Ausser diesen dreien findet sich nur b1000016 in b1000001 auf
   der Produktseite (20+50) - das ist die letzte von vier Karten, ihre 20px
   sind das Polster der Karte und stehen genauso bei den drei anderen.
   Die bleibt unangetastet.

   Sichtbar ist von den inneren Kaesten nichts: nachgemessen haben
   fq8a0010, u5000090 und j1000090 dieselbe Hintergrundfarbe, dasselbe
   Hintergrundbild, denselben Radius, denselben Rahmen und denselben
   Schatten wie ihr jeweiliger Aussencontainer. Die Kante ist gar nicht
   zu sehen, der Platz ist reiner Leerraum.

   Zum Vergleich der uebrige Seitenrhythmus: auf /produkt/ liegen die
   neun Abschnittsuebergaenge zwischen 150 und 195 Pixeln, gemessen von
   der letzten Textzeile des einen zur ersten des naechsten. Der
   FAQ-Uebergang war mit 203 bis 267 Pixeln auf jeder Breite der groesste
   der Seite; auf /anwendungsfaelle/ standen bis zum Fuss 153 bis 177
   Pixel leer.

   Links und rechts bleibt das Polster unangetastet, sonst laeuft das
   Akkordeon an den Rand.

   Auch das stammt aus der Vorlage, nicht aus dem Umzug.

   !important, weil die Vorlage drei Klassen stapelt
   (.elementor-3370 .elementor-element.elementor-element-j1000090) und ihre
   Datei spaeter geladen wird als diese hier. Gemessen: ohne !important
   bleibt es bei 40px. */
.elementor-element-j1000090,
.elementor-element-fq8a0010,
.elementor-element-u5000090 {
  --padding-bottom: 0px !important;
}

/* 5. Unter dem Kontaktformular stand eine halbe Bildschirmhoehe leer

   Das Formular laeuft im "reveal"-Modus: ausgefuellte Schritte bleiben
   stehen, das Formular waechst nach unten. Dafuer reserviert das
   Formular-Stylesheet der Agentur einen Vorlauf unter dem Formular

     .gform_wrapper.cs-landeseiten-form[data-mode="reveal"] {
       padding-bottom: var(--landeseiten-form-reveal-padding) !important; }
     --landeseiten-form-reveal-padding: 60vh;

   60vh sind auf einem 844 Pixel hohen Telefon 506 Pixel. Zusammen mit dem
   Polster des Abschnitts standen unter dem Formular 586 Pixel leer - beim
   ersten Anblick, bevor irgendetwas ausgefuellt ist, fast ein ganzer
   Bildschirm zwischen dem "Weiter"-Knopf und dem Fuss.

   Nachgemessen, ob der Vorlauf ueberhaupt gebraucht wird: den
   sechsstufigen Assistenten viermal durchgeklickt, mit 60, 40, 30 und
   20vh, und bei jedem Schritt notiert, wo das aktive Feld und der Knopf
   im Bild stehen (Telefon, 390x844):

     60vh   503/679  212/388  208/503  -32/584  -92/584  -32/584
     40vh   503/679  212/388  208/503  -32/584  -92/584  -32/584
     30vh   503/679  212/388  208/503  -32/584  -92/584  -32/584
     20vh   503/679  212/388  208/503  -32/584  -92/584  -32/584

   Zeichengleich. Das Skript scrollt zum Feld, nicht zum Dokumentende -
   der Vorlauf wird also nie gebraucht. Toter Raum unter dem Formular:
   586px bei 60vh, 418 bei 40, 333 bei 30, 249 bei 20.

   30vh, weil damit immer noch eine knappe halbe Bildschirmhoehe Auslauf
   bleibt, falls ein anderer Browser oder eine andere Schriftgroesse
   weiter scrollen muss als Chromium hier. Rueckgaengig mit einer Zeile:
   den Wert wieder auf 60vh setzen.

   Das ist eine Voreinstellung des Formular-Plugins, kein Fehler des
   Umzugs - aber sie kostet auf der wichtigsten Seite der Website einen
   halben Bildschirm. */
/* !important, weil das Formular-Stylesheet die Variable auf demselben
   Selektor setzt (.gform_wrapper.cs-landeseiten-form, zwei Klassen) und
   spaeter geladen wird. Gemessen: ohne !important bleibt es bei 506px. */
.gform_wrapper.cs-landeseiten-form {
  --landeseiten-form-reveal-padding: 30vh !important;
}

/* 6. "Ein anderes Land" ankreuzen und nicht sagen koennen, welches

   Das Formular fragt die Laender als vier Ankreuzfelder ab. Kreuzt man
   "Ein anderes Land" an, blendet die Bedingungslogik von Gravity Forms
   ein Textfeld ein, in das man das Land eintraegt. Das funktioniert
   auch - nachgemessen auf einem iPhone-13-Fenster:

     ankreuzen  -> field_3_53 wechselt von display:none auf block
     "Weiter"   -> das Feld ist sichtbar, hat .active, steht bei
                   y 124..268 in einem 664 Pixel hohen Fenster

   Nur sieht man davon im Moment des Ankreuzens nichts: der Assistent
   zeigt genau ein Feld je Schritt, das Landfeld ist der naechste
   Schritt. Wer nach dem Ankreuzen ein Eingabefeld erwartet, haelt das
   fuer kaputt und schickt das Formular ohne die Angabe ab.

   Darum ein Hinweis unter den vier Feldern, sobald "Ein anderes Land"
   angekreuzt ist. :has() koennen alle derzeitigen Browser; wo nicht,
   fehlt der Hinweis und der Ablauf bleibt wie zuvor.

   Die Beschriftung des Feldes selbst heisst jetzt ausserdem "In welchem
   Land?" statt "Land" und traegt einen Platzhalter - siehe
   src/content/kontakt.json und en_contact.json. */
#field_3_52:has(#choice_3_52_4:checked) .gfield_checkbox::after,
#field_4_52:has(#choice_4_52_4:checked) .gfield_checkbox::after {
  display: block;
  margin-top: 14px;
  font-size: 15px;
  line-height: 1.45;
  color: #0378b8;
}

#field_3_52:has(#choice_3_52_4:checked) .gfield_checkbox::after {
  content: "Im nächsten Schritt kannst du eintragen, welches Land es ist.";
}

#field_4_52:has(#choice_4_52_4:checked) .gfield_checkbox::after {
  content: "You can enter the country in the next step.";
}

/* 7. Das Klappmenue oeffnete sich als schmaler Kasten quer ueber der Seite

   Elementor stellt das Menue-Widget auf full_width:"stretch" - der
   aufgeklappte Kasten soll also die ganze Breite einnehmen und unter dem
   Kopf sitzen. Das Ausmessen und Setzen von Breite und Lage erledigt
   sonst der Handler aus nav-menu.bundle.min.js, und der fehlt (Elementor
   Pro, nicht quelloffen).

   Ohne ihn steht der Kasten auf Inhaltsbreite und haengt am Umschalter.
   Gemessen auf der ausgelieferten Seite:

     Fenster  Kasten           Lage       laengster Menuepunkt
      390px   235 x 240        x=0 y=23   195px
      768px   275 x 340        x=0 y=28   235px

   y=23 heisst: der Kasten beginnt auf Hoehe der Kopfzeile und liegt quer
   ueber der Ueberschrift. Genau das war auf dem Telefon zu sehen.

   Die Lage laesst sich in reinem CSS nicht ausrechnen: Bezugsrahmen ist
   der Umschalter selbst (offsetParent 36x36 bei x=334), und wie weit der
   vom Rand weg ist, weiss nur der Browser. Darum position:fixed - das
   loest den Kasten aus dem Bezugsrahmen und stellt ihn ans Fenster. Wo
   der Kopf aufhoert, meldet der Notbehelf in
   --analysit-menue-oben; 63px sind der gemessene Rueckfall, falls das
   ausbleibt.

   Alles davon haengt an der Marke analysit-menue-notbehelf, die nur
   gesetzt wird, wenn der Notbehelf tatsaechlich selbst oeffnet. Sobald
   das echte Buendel wieder da ist, uebernimmt Elementor, die Marke
   bleibt aus, und von diesem Block greift nichts mehr. */
.analysit-menue-notbehelf .elementor-nav-menu--dropdown.elementor-nav-menu__container {
  position: fixed !important;
  top: var(--analysit-menue-oben, 63px) !important;
  left: 0 !important;
  right: 0 !important;
  width: 100% !important;
  max-width: none !important;
  max-height: calc(100vh - var(--analysit-menue-oben, 63px)) !important;
  overflow-y: auto !important;
  /* Elementor gibt dem Kasten margin-top:10px - der Abstand zum
     Umschalter, an dem er sonst haengt. Mit position:fixed und einem
     gesetzten top kommen die 10px oben drauf: gemessen top=63px,
     tatsaechliche Oberkante 73px. In dem Streifen war der Seiteninhalt
     zu sehen, auf jeder Seite und bei jeder Rollhoehe. */
  margin-top: 0;
}

/* Die Menuepunkte standen im schmalen Kasten linksbuendig am Rand. Im
   breiten Kasten brauchen sie das Polster, das die Kopfzeile auch sonst
   verwendet, sonst kleben sie am Fensterrand. */
.analysit-menue-notbehelf .elementor-nav-menu--dropdown .elementor-nav-menu--dropdown,
.analysit-menue-notbehelf .elementor-nav-menu--dropdown ul.elementor-nav-menu {
  padding-left: 10px;
  padding-right: 10px;
}
/* 10px statt der urspruenglichen 20px: die Eintraege tragen ihr Polster
   inzwischen selbst, damit die Flaeche des aktiven Eintrags gerundet vom
   Rand abgesetzt ist. Siehe den Block "Woran man sieht, auf welcher Seite
   man ist" in post-99.css und post-1435.css. */


/* Die Filme auf den beiden Startseiten hatten scharfe Ecken.

   Auf Wunsch leicht gerundet. 8px auf einem Kasten, der auf dem Telefon
   400 Pixel breit ist - das ist knapp ein Fuenfzigstel der Breite und
   faellt nur auf, wenn man darauf achtet. Genau das war die Vorgabe.

   Gezaehlt: 24 Elemente, zwoelf auf / und zwoelf auf /en/, sonst
   nirgends. Kein anderes Stilblatt setzt an dieser Stelle einen Radius -
   nachgesehen ueber alle CSS-Dateien unter public -, deshalb genuegt
   diese eine Regel und es gibt keinen Vorrangstreit.

   Am <video> selbst und nicht am Behaelter: das Element steht ohnehin auf
   overflow:clip, damit werden Standbild und laufendes Bild mitgerundet.
   Am Behaelter wuerde nur dessen Rand rund, das Bild liefe darueber
   hinaus. */
.elementor-video {
  border-radius: 8px;
}