/* vereto-app.css — Design-System-Angleichung an www.vereto.de (DESIGN-SYSTEM.md) Neu angelegt fuer php-design (Staging), NICHT Teil der Original styles.css. Wird ZUSAETZLICH nach styles.css geladen (Override per Ladereihenfolge + gezielte Spezifitaet, moeglichst wenig !important). Rundes 1 -- 2026-07-22. */ :root { --accent: #2d7a3e; --accent-dark: #1f5b2c; --accent-soft: #5a8020; --bg: #ffffff; --card-bg: #f7f8f7; --fg: #1a1a1a; --muted: #666666; --border: #b3b8bd; /* dekorativ: Tabellen-Trennlinien. 23.07.2026 (Uwe: "Randlinien um Eingabefelder und Tabellen sind viel zu duenn und daher schlecht zu erkennen") -- war #e2e2e2 (Kontrast ~1.2:1, praktisch unsichtbar). Nachgerechnet 25.07.2026: exakt 2.00:1 auf Weiss, nicht die frueher notierten 2.4:1. */ /* 25.07.2026 (Code-Check): Rahmen von BEDIENELEMENTEN sind nach WCAG 1.4.11 (Non-text Contrast) 3:1-pflichtig -- --border erfuellt das mit 2.00:1 nicht. Eigener, dunklerer Token nur fuer Eingabefelder/Selects/Textareas: #8b9199 = 3.18:1 auf Weiss. Die dekorativen Tabellenlinien bleiben bewusst heller (dort gilt die Regel nicht). */ --border-control: #8b9199; --menu-height: 36px; /* 23.07.2026 (Uwe: "Menuebalken im Verhaeltnis zur Schrift zu dick"), von 44px verkleinert */ } /* ---------- Grundlayout / Typografie ---------- */ body { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; color: var(--fg); background: var(--bg); min-height: 100vh; } /* 24.07.2026 (Barrierefreiheits-Audit, WCAG 2.4.1 Bypass Blocks): Skip-Link, von hi_head.php als erstes Element nach ausgegeben. Visuell komplett unsichtbar (aus dem sichtbaren Bereich geschoben) bis er per Tab fokussiert wird -- Standardmuster, keine Aenderung am Erscheinungsbild fuer Maus-/Touch-Nutzer. position:fixed statt absolute, damit die Positionierung unabhaengig davon funktioniert, ob das Element (durch setupPageCenterWrapper(), s.u.) spaeter in den .vereto-page-center-Wrapper verschoben wird. */ .vereto-skip-link { position: fixed; top: -40px; left: 0; background: var(--accent); color: #ffffff; padding: 8px 16px; text-decoration: none; z-index: 1100001; /* ueber #head (1000001) und Dropdowns (1000002), unter flatpickr (1100000)+1 */ transition: top 0.1s; } .vereto-skip-link:focus { top: 0; } /* 23.07.2026 (Thomas: "footer soll immer unten am Seitenende sein, so etwas wie full height"): auf kurzen Seiten (z.B. h_login.php) schwebte der Footer bisher mittig statt am unteren Bildschirmrand zu kleben. .vereto-page-center (per JS um den kompletten Body-Inhalt gelegt, s.u. setupPageCenterWrapper) wird zur Flex-Spalte auf volle Viewport-Hoehe; main bekommt flex:1 und wächst, um die restliche Hoehe zu fuellen und den Footer nach unten zu druecken. Kopfzeilen-Tabelle/Footer selbst bleiben bei ihrer natuerlichen Groesse (kein flex-grow). */ .vereto-page-center { /* 23.07.2026 (Thomas-Entscheidung nach Abwaegen): 100vh statt 60vh-Kompromiss -- Footer soll garantiert auf JEDER Seite am unteren Fensterrand kleben (klassisches Sticky- Footer-Pattern), auch wenn das auf mittellangen Content-Seiten (z.B. Rechnung) eine sichtbare Luecke vor dem Footer erzeugt. 23.07.2026 Fund (Thomas: "im body ist ein padding, das ist der bug"): Legacy-styles.css setzt body{padding:20px 10px 0px}. Body-eigenes padding-top ADDIERT sich zur 100vh dieses Wrappers (Kind-Element), macht die Seite insgesamt 20px hoeher als der Viewport -> erzwang einen unnoetigen Mini-Scroll bis ganz ans Ende. Fix: body- padding-top unten neutralisieren, stattdessen HIER als box-sizing:border-box-Padding setzen, damit es Teil der 100vh-Boxgroesse ist statt zusaetzlich draufzukommen. */ box-sizing: border-box; padding-top: 20px; min-height: 100vh; display: flex; flex-direction: column; } /* 27.07.2026: :not(.vereto-hilfe-body) ergaenzt. Diese Regel gilt dem Hauptlayout, traf per !important aber auch das Hilfe-Fenster im iframe (h_hilfe.php setzt dieselbe body-Ebene) und loeschte dort den oberen Innenabstand -- die Ueberschrift klebte bei top:0 an der Kante und wirkte abgeschnitten (Rueckmeldung Thomas). */ body:not(.vereto-hilfe-body) { padding-top: 0 !important; } .vereto-page-center > main { flex: 1 0 auto; } /* 2026-07-23 Mobile-Scan-Fund (h_sys_session.php print_r()-Dump): 
-Bloecke mit langen
   unbeugsamen Zeilen (white-space:pre) sprengen auf schmalen Screens die Seitenbreite, ohne
   dass die eigene Box breiter wird -- daher greift der table[width=1000]-Ansatz hier nicht.
   Eigener Scroll-Container statt Seitenweitem Overflow. */
pre {
  max-width: 100%;
  overflow-x: auto;
  box-sizing: border-box;
}

/* 23.07.2026 (Thomas: "die App ist nach links verschoben, die Webseite ist zentriert --
   mach einen Div um alles und zentriere den Div"): EIN gemeinsamer Wrapper (per JS um den
   gesamten Body-Inhalt gelegt, siehe vereto-app.js setupPageCenterWrapper) statt einzelner
   Centering-Regeln nur auf #cssmenu/einzelnen Tabellen -- deckt automatisch auch vorher
   ungecappte Elemente ab (z.B. die Logo/"Anwendung verlassen"-Kopfzeilen-Tabelle aus
   hi_wp_header.php, die nur inline width:100% ohne jede Obergrenze hatte).
   Bewusst KEIN overflow:hidden hier -- echte breite Datentabellen (bis 1856px, Tabpflege)
   behalten ihren eigenen horizontalen Scroll-Container (.vereto-table-wrap) und duerfen
   weiterhin ueber die 1200px-Grenze hinaus INHALTLICH breiter sein; nur die sichtbare
   Ausgangsbreite ohne Scroll ist wie zuvor auf 1200px gekoppelt (unveraendert ggue. der
   vorherigen main-Regel). */
.vereto-page-center {
  max-width: 1200px;
  margin: 0 auto;
}

main {
  /* Bugfix 2026-07-22 (Thomas: 'kleiner Balken links'): urspruengliche 100px linker Margin
     reservierte einen leeren Streifen, den die WP-Hauptseite nicht hat -- ersatzlos entfernt. */
  margin-left: 0;
  padding: 0 16px 40px 16px;
}
@media (max-width: 767px) {
  main { margin-left: 0; padding: 0 12px 32px; }
}

h1 {
  color: var(--fg);
  font-family: inherit;
  font-weight: 700;
  font-size: 22px;
  padding-bottom: 8px;
  border-bottom: 2px solid var(--border);
  margin-bottom: 14px;
}

a { color: var(--accent); }
a:visited { color: var(--accent); }
a:hover { color: var(--accent-dark); }

/* ---------- Buttons ---------- */
/* Legacy-Layout hat viele dichte Tabellenformulare -- volle Design-System-Pille
   (25px/13px 28px) wuerde dort umbrechen/ueberlaufen. Kompromiss: klar erkennbare
   Pillen-Form, aber kompaktere Masse. */

button,
input[type="button"],
input[type="submit"],
input[type="reset"] {
  background-color: var(--accent);
  color: #fff;
  border: none;
  /* 23.07.2026 (Uwe: "Buttons sind im Verhaeltnis zur Schrift zu dick"): Polsterung/
     Mindesthoehe verkleinert (7px 18px/36px -> 5px 16px/30px), damit die Buttons enger am
     13px-Schrifttext sitzen statt wuchtig zu wirken. */
  padding: 5px 16px;
  border-radius: 18px;
  font-family: inherit;
  font-size: 13px;
  font-weight: 600;
  cursor: pointer;
  transition: background 0.15s ease;
  /* 22.07.2026: Mindestabstand -- Legacy-PHP gibt oft mehrere Buttons ohne eigenes
     Spacing hintereinander aus (z.B. Terminkalender-Navigation, Tabpflege-Blaettern) --
     ohne margin standen sie pixelgenau aneinander ("aneinandergeklebt").
     23.07.2026: margin-top testweise auf 14px erhoeht, aber dadurch rutschte z.B. der
     "Hilfe"-Button direkt neben der Seitenueberschrift sichtbar nach unten (globale
     Button-Regel trifft JEDEN Button, nicht nur die nach einer Tabelle). Zurueckgesetzt auf
     6px; der "Platz zur Tabelle"-Fall wird bereits ueber .vereto-table-wrap margin-top
     (s.u.) abgedeckt. */
  margin: 6px 10px 6px 0;
  min-height: 30px;
}

button:hover,
input[type="button"]:hover,
input[type="submit"]:hover,
input[type="reset"]:hover {
  background-color: var(--accent-dark);
}

/* 23.07.2026 (Thomas: "die X Buttons sehen nicht schoen aus" -- h_d_rechnung1.php/
   h_d_rechnungu1.php Leistungszeilen-Loeschen-Button): PHP setzt inline style="padding:0px"
   auf diese Ein-Zeichen-"x"-Buttons, das schlaegt die allgemeine Button-Regel oben (inline
   gewinnt immer gegen externes Stylesheet) -- kombiniert mit deren min-height:36px UND
   praktisch keiner Breite (Inhalt nur "x", kein eigenes padding mehr) ergab das einen sehr
   schmalen, hohen gruenen Balken statt eines Buttons. Eigene kompakte, quadratische/runde
   Form statt der Pillenform fuer alle Ein-Zeichen-"x"-Buttons. */
input[type="button"][value="x"] {
  min-height: 26px;
  height: 26px;
  width: 26px;
  min-width: 26px;
  max-width: 26px;
  padding: 0 !important;
  border-radius: 50%;
  font-size: 13px;
  line-height: 24px;
  text-align: center;
  vertical-align: middle;
}

/* 23.07.2026 (Thomas: "h_d_rechnung2.php looks bad with the icons"): hi_anz_rechnung.php
   setzt die "aendern"/"x"-Buttons per 
 direkt unter das Behandlungsdatum in derselben
   Tabellenzelle -- ohne jeden Abstand wirkt das zusammengequetscht. */
td br + input[type="button"] {
  margin-top: 8px;
}
td input[type="button"] + input[type="button"] {
  margin-left: 6px;
}

button:disabled,
input[type="button"]:disabled,
input[type="submit"]:disabled {
  /* 25.07.2026 (Code-Check): vorher --border (#b3b8bd) als Flaeche + --muted (#666) als Schrift
     = 2.87:1, praktisch unlesbar. Hellere Flaeche + dunklere Schrift ergibt 5.4:1 und bleibt
     durch die fehlende Akzentfarbe trotzdem klar als "deaktiviert" erkennbar. */
  background-color: #e6e8ea;
  color: #5a5f63;
  cursor: default;
}

/* ---------- Formularfelder ---------- */

.textfield,
input[type="text"],
input[type="password"],
input[type="email"],
input[type="number"],
input[type="date"],
/* 23.07.2026 Fund (Thomas: "leistung nothing i can see" -- h_d_rechnungu1.php/
   h_d_rechnung1.php Leistungsfeld): dieses und mehrere andere Legacy-Awesomplete-Felder
   haben GAR KEIN type-Attribut (HTML faellt implizit auf "text" zurueck, aber
   input[type="text"] matcht NUR bei explizit gesetztem Attribut) -- ohne Attribut-Selektor-
   Treffer blieb der native, graue 3D-Inset-Rahmen des Browsers stehen statt unseres
   Formularfeld-Stils. input:not([type]) faengt jedes untypisierte Legacy-Feld sitewide ab. */
input:not([type]),
select,
textarea {
  font-size: 13px;
  color: var(--fg);
  background: #ffffff;
  border: 1px solid var(--border-control);
  border-radius: 5px;
  padding: 5px 8px;
  max-width: 100%;
  box-sizing: border-box;
}
.textfield:focus,
input[type="text"]:focus,
input[type="password"]:focus,
input:not([type]):focus,
select:focus,
textarea:focus {
  outline: none;
  border-color: var(--accent);
  /* 23.07.2026 (Barrierefreiheits-Audit): 0.15 Alpha ergab nur ~1.1:1 Kontrast gegen weissen
     Hintergrund -- fuer Nutzer mit Sehschwaeche praktisch unsichtbar (WCAG 2.2 SC 2.4.11
     empfiehlt >=3:1). Auf 0.7 angehoben.
     25.07.2026 (Code-Check, nachgerechnet): 0.7 Alpha ueber Weiss ergibt effektiv #6ca278 =
     2.97:1 -- knapp UNTER den geforderten 3:1, ohne dass die Transparenz einen Nutzen haette.
     Deckende Akzentfarbe #2d7a3e liefert 5.30:1. */
  box-shadow: 0 0 0 2px var(--accent);
}
/* iOS-Autozoom-Fix: 16px Mindestschrift auf schmalen Screens */
@media (max-width: 767px) {
  .textfield, input[type="text"], input[type="password"], input[type="email"],
  input[type="number"], input[type="date"], select, textarea {
    font-size: 16px;
  }
}

/* ---------- Tabellen ---------- */

table[border="1"] {
  border-collapse: collapse;
  border: none;
}
table[border="1"] th {
  background-color: var(--card-bg);
  color: var(--fg);
  font-weight: 600;
  border: none;
  border-right: 1px solid rgba(0, 0, 0, 0.06);
  border-bottom: 2px solid var(--border);
  padding: 8px 10px;
  text-align: left;
}
table[border="1"] td {
  border: none;
  border-bottom: 1px solid var(--border);
  /* 23.07.2026 (Uwe: "keine senkrechten Linien -- finde ich mit Linien besser"; Thomas-
     Kompromiss: "ganz ganz ganz leichte Linien"): sehr helle vertikale Trennlinie statt der
     vollen Gitter-Optik -- deutlich dezenter als --border, aber als Orientierung erkennbar. */
  border-right: 1px solid rgba(0, 0, 0, 0.06);
  padding: 7px 10px;
  /* 23.07.2026 (Thomas-Screenshot: Sticky-Aktionsspalten ueberlappten sichtbaren Zelleninhalt
     bei h_tabpflege.php?tabelle=ve_ticket): Tabellenzellen clippen Inhalt standardmaessig NICHT
     (overflow:visible), lange unwrapped Inhalte konnten dadurch ueber die eigene Zellgrenze
     hinaus in Nachbarspalten (inkl. der sticky Aktionsspalten) hineinragen. Erzwingt Umbruch
     UND Clipping an der eigenen Zellgrenze -- jede Zelle bleibt visuell in ihrer eigenen Spalte. */
  overflow: hidden;
  overflow-wrap: break-word;
  word-break: break-word;
}
table[border="1"] td:last-child,
table[border="1"] th:last-child {
  border-right: none;
}
th { background-color: var(--card-bg); }

/* 23.07.2026 (Thomas: "h_tabpflege.php Formular besser designen"): generelles Update fuer
   ALLE border=1-Datentabellen (nicht mehr nur .tab_termin, s.u.) -- dichtes Vollgitter durch
   weicheres Zeilen-Design ersetzt (nur horizontale Trennlinien, kein Kaestchen-Look mehr),
   Kartenoptik (Rahmen+Schatten) um die gesamte Tabelle, Zeilen-Hover, dezente
   "neue-Zeile"-Hervorhebung fuer die Formular-Zeile am Tabellenanfang (erkennbar an
   input/select-Feldern, unabhaengig davon welche konkrete Tabelle/Seite). */
table[border="1"] tbody tr:hover td {
  background-color: rgba(45, 122, 62, 0.06);
}
table[border="1"] tr:has(> td > input, > td > select):not(:hover) td {
  background-color: rgba(45, 122, 62, 0.03);
}
.vereto-table-wrap:has(> table[border="1"]) {
  border: 1px solid var(--border);
  border-radius: 10px;
  box-shadow: 0 1px 3px rgba(0, 0, 0, 0.06);
  /* NICHT overflow:hidden (Shorthand) -- das setzt auch overflow-x auf hidden und
     ueberschreibt (dank :has() hoeherer Spezifitaet) das overflow-x:auto der Basisregel
     weiter oben, wodurch breite Tabellen (>Container) gar nicht mehr horizontal scrollbar
     waren -- nur clipped, kein Scrollbalken erreichbar (2026-07-23 Thomas-Fund: "table
     smaller, cannot see other entries"). overflow-y:hidden reicht fuer die Eckenrundung. */
  overflow-x: auto;
  overflow-y: hidden;
}
.vereto-table-wrap:has(> table[border="1"]) table[border="1"] {
  border-radius: 0;
}

/* 23.07.2026 (Thomas: "modernize h_terminkalender.php, layout of the table looks so old"):
   dichtes Vollgitter (jede Zelle einzeln umrandet) + kein Kartenrahmen/Schatten wirkt wie
   eine reine Tabellenkalkulation. Weicheres, moderneres Grid speziell fuer den
   Terminkalender: nur noch horizontale Zeilentrenner (keine harten vertikalen Linien
   zwischen jeder Spalte), dezenter Hover-Zustand pro Zeile, Karten-Optik (Rahmen + Schatten)
   um die gesamte Tabelle statt um jede einzelne Zelle. Bewusst NICHT die generelle
   table[border=1]-Regel oben veraendert (betrifft zu viele andere Datentabellen), sondern
   gezielt nur .tab_termin. */
.tab_termin th,
.tab_termin td {
  border-left: none;
  border-right: none;
  border-top: none;
  border-bottom: 1px solid var(--border);
}
.tab_termin tbody tr:hover td {
  background-color: rgba(45, 122, 62, 0.06);
}
.vereto-table-wrap:has(> .tab_termin) {
  border: 1px solid var(--border);
  border-radius: 10px;
  box-shadow: 0 1px 3px rgba(0, 0, 0, 0.06);
}
.vereto-table-wrap:has(> .tab_termin) .tab_termin {
  border: none;
}

/* Wrapper, den vereto-app.js um breite/scrollende Content-Tabellen legt */
.vereto-table-wrap {
  overflow-x: auto;
  max-width: 100%;
  margin-top: 14px; /* 2026-07-23 (Thomas: "zwischen Buttons und Tabelle bisschen Platz") --
                        Buttons (z.B. Blaettern-Leiste in h_tabpflege.php) stiessen direkt an
                        den Tabellenrand. */
  margin-bottom: 8px;
  -webkit-overflow-scrolling: touch;
  /* 2026-07-23 Desktop-Scan-Fund: macOS/moderne Browser blenden Scrollbalken standardmaessig
     nur bei Hover/Interaktion ein -- bei breiten Auto-Layout-Tabellen ohne width=1000
     (z.B. ve_leistungskette/ve_person auf ~1440px-Laptops) sah das wie abgeschnittener
     Inhalt aus, ohne jeden Hinweis, dass die Ändern/Löschen-Spalte per Scroll erreichbar
     ist. Dauerhaft sichtbarer, dezenter Scrollbalken statt geänderter Tabellen-Groessenlogik. */
  scrollbar-width: thin;
}
.vereto-table-wrap::-webkit-scrollbar {
  height: 10px;
}
.vereto-table-wrap::-webkit-scrollbar-thumb {
  background: var(--border);
  border-radius: 4px;
}

/* 23.07.2026 (Thomas: "Scrollbalken oben an der Tabelle"): zusaetzlicher, per JS mit dem
   eigentlichen .vereto-table-wrap synchronisierter Scrollbalken direkt ueber breiten
   Tabellen, damit man bei langen Tabellen nicht erst ans untere Ende scrollen muss, um den
   Scrollbalken zu erreichen. Nur ein 1px hoher Platzhalter mit der echten scrollWidth der
   Tabelle darin -- die sichtbare Scrollbar selbst kommt vom Browser (::-webkit-scrollbar
   greift auch hier). */
.vereto-table-topscroll {
  overflow-x: auto;
  overflow-y: hidden;
  height: 16px;
  margin-top: 14px;
  margin-bottom: -8px; /* der eigentliche .vereto-table-wrap bringt bereits margin-top:14px mit */
  scrollbar-width: thin;
}
.vereto-table-topscroll > div {
  height: 1px;
}
.vereto-table-topscroll::-webkit-scrollbar {
  height: 10px;
}
.vereto-table-topscroll::-webkit-scrollbar-thumb {
  background: var(--border);
  border-radius: 4px;
}
.vereto-table-wrap table {
  margin-bottom: 0;
}

/* ---------- Mobile-Sweep (2026-07-23, 10 Agents): border="0"-Formular-/Prosa-Tabellen
   reflowen statt in den Scroll-Wrapper zu zwingen ----------
   vereto-app.js wrapt JEDE Tabelle unconditional in .vereto-table-wrap, auch reine
   Formular-/Fliesstext-Tabellen mit fest verdrahtetem width-Attribut (z.B. h_login.php
   width=500, h_herunterladen.php/h_sysprax_upload.php width=$app_width als reiner
   Hinweistext-Container) -- das erzwingt horizontales Scrollen fuer Inhalte, die eigentlich
   umbrechen sollten (Login-Formular teilweise unbrauchbar auf Mobile, Hilfetext mitten im
   Wort abgeschnitten). ECHTE Datentabellen nutzen im gesamten Code konsequent border="1"
   (siehe table[border="1"] weiter oben) -- daher hier gezielt nur border="0"-Tabellen
   reflowen, border="1" bleibt unangetastet (horizontales Scrollen dort weiterhin gewollt). */
/* 2026-07-23 Desktop-Scan-Fund: diese Regel fehlte urspruenglich eine Media-Query, obwohl
   der Kommentar oben ausdruecklich ein Mobile-Problem beschreibt (Login-Formular auf dem
   Handy). Ungated stretchte sie auch auf Desktop JEDE border=0-Formulartabelle auf die volle
   Wrap-Breite (~1200px) -- bei zweispaltigen Label/Feld-Tabellen ohne feste Spaltenbreite
   floss die zusaetzliche Breite in die Label-Spalte, wodurch Label und Eingabefeld/Button
   teils >600px auseinanderrissen (h_kennwort.php, h_rechnungsjournal_such.php,
   h_patient_import.php u.a.). Auf Mobile bleibt die Reflow-Absicht (s.o.) erhalten, auf
   Desktop behalten diese Tabellen wieder ihre natuerliche/kompakte Breite. */
@media (max-width: 767px) {
  .vereto-table-wrap > table[border="0"] {
    width: 100% !important;
    max-width: 100%;
  }
}

/* 23.07.2026 (Breiten-Konsistenz-Check): einige echte Datentabellen (Terminkalender,
   Ablage) sind fest auf width="1000" (SESS_APP_WIDTH) verdrahtet -- seit #cssmenu auf
   1200px verbreitert wurde (s.u.), liess das auf breiten Bildschirmen einen leeren
   ~150-200px-Gap rechts neben der Tabelle entstehen. Nur diese exakte Breite auf Desktop
   (>767px, Mobile-Scroll-Verhalten bleibt unberuehrt) auf 100% des Wrap-Containers
   strecken -- betrifft NICHT breitere Tabellen (z.B. 1856px-Tabpflege-Tabellen), die
   weiterhin unveraendert horizontal scrollen. */
@media (min-width: 768px) {
  .vereto-table-wrap table[width="1000"] {
    width: 100% !important;
    max-width: 1200px; /* an #cssmenu-Breite gekoppelt, s.u. -- main selbst ist unbegrenzt */
  }
  /* 23.07.2026 Nachtrag (Thomas: "dont center the content within the container, they
     should be on the right side and using the full size" -- ein erster Versuch mit
     margin:auto allein liess schmale Formulartabellen als kompakten Block MITTIG im
     breiten 1200px-Container schweben, statt ihn auszufuellen. border=0-Formulartabellen
     sind IMMER reiner Fliesstext/Formularinhalt (nie echte mehrspaltige Datentabellen),
     daher hier bedenkenlos width:100%. */
  .vereto-table-wrap > table[border="0"] {
    width: 100%;
    max-width: 1200px;
  }
  /* border="1"-Datentabellen NICHT hier pauschal auf width:100% strecken (frueherer
     Versuch, per Live-Test widerlegt: table-layout:auto WEICHT eine zu kleine width-Vorgabe
     NICHT automatisch auf -- stattdessen wird Zellinhalt in mehrere Zeilen umgebrochen, um
     die vorgegebene Breite doch einzuhalten. Fund: ve_person (13 Spalten, natuerlich
     >1600px) wurde dadurch auf 880px zusammengequetscht statt zu scrollen). Stattdessen
     JS-gesteuert (vereto-app.js setupTableWrap): nur Tabellen, die von Natur aus SCHMALER
     als der Container sind, bekommen die Klasse .vereto-table-stretch und damit width:100%
     -- echte breite Tabellen bleiben unangetastet und scrollen weiterhin. */
  .vereto-table-wrap > table[border="1"].vereto-table-stretch {
    /* !important noetig: Legacy-PHP schreibt ein festes inline style="width:1000px"
       (SESS_APP_WIDTH aus pi_login-exec.php) auf viele Tabpflege-Tabellen -- eine
       Klassenregel ohne !important verliert gegen ein inline style, egal wie schmal
       die Tabelle von Natur aus waere (2026-07-23 Uwe/Thomas-Fund: ve_rechnungsjournal
       blieb bei 1000px statt volle Containerbreite zu nutzen). */
    width: 100% !important;
    max-width: 1200px;
  }
  /* 28.07.2026 (Kundenfeedback Scheele, Root Cause gefunden): h_tabpflege.php setzt die
     Tabellenbreite NICHT als HTML-Attribut width="1000" (das obige [width="1000"]
     traefe), sondern als Inline-Style style="width:1000px;" ($tab_width, s. h_tabpflege.php
     Zeile ~1258) -- ein voellig anderer Selektor. Die o.g. table[width="1000"]-Regel lief
     dadurch bei JEDER Tabpflege-Tabelle (u.a. ve_akte/Patientenakte) ins Leere. Attribut-
     Contains-Selektor faengt das ab, unabhaengig davon, ob vereto-app.js die Tabelle
     zusaetzlich als .vereto-table-stretch einstuft. */
  .vereto-table-wrap table.sticky[style*="width:1000px"] {
    width: 100% !important;
    max-width: 1200px;
  }
}

/* 28.07.2026 (Kundenfeedback Scheele, sehr breiter Monitor): der 1200px-Cap oben ist eine
   bewusste Design-Entscheidung vom 23.07. (Menue+Inhalt synchron begrenzt, an Bootstraps
   xl-Breakpoint angelehnt) und bleibt fuer normale/mittlere Breitbild-Monitore unveraendert.
   Auf SEHR breiten Viewports (>=1600px, deutlich ueber gaengigen 1440px-Notebook-Displays)
   bekommen Menue UND die o.g. Tabellen-Regeln stattdessen 1450px -- Menue und Inhalt bleiben
   dabei synchron (kein Auseinanderlaufen), es wird aber mehr vom vorhandenen Platz genutzt.
   Bewusst kein Cap-Entfernen (volle Fensterbreite) -- reine Datentabellen mit sehr langem
   Freitext wuerden bei unbegrenzter Breite unleserlich lange Zeilen bekommen. */
@media (min-width: 1600px) {
  #cssmenu {
    max-width: 1450px;
  }
  .vereto-table-wrap table[width="1000"],
  .vereto-table-wrap > table[border="0"],
  .vereto-table-wrap > table[border="1"].vereto-table-stretch,
  .vereto-table-wrap table.sticky[style*="width:1000px"] {
    max-width: 1450px;
  }
}

/* 2026-07-23 Mobile-Scan-Fund (h_sysprax_upload.php): Hinweistext-Box (bgcolor=#d8ddca,
   width=$app_width=1000) ist reiner Fliesstext in Tabellenform, kein Datentabellen-Raster --
   erzwang bisher auch auf Mobile horizontales Scrollen mitten im Satz/Wort, statt wie Prosa
   umzubrechen. Anders als echte breite Datentabellen (Terminkalender/Tabpflege) soll dieses
   Muster auch unterhalb 768px auf 100% reflowen. */
@media (max-width: 767px) {
  .vereto-table-wrap table[width="1000"][bgcolor="#d8ddca"] {
    width: 100% !important;
  }
  /* Trotz width:100% auf der Tabelle blieb sie durch ein hart auf width="380" verdrahtetes
     Beispielbild breiter als der Viewport -- Tabellen-Auto-Layout wird durch ein Bild ohne
     Breitenbegrenzung trotzdem auf dessen Breite aufgezogen. */
  .vereto-table-wrap table[width="1000"][bgcolor="#d8ddca"] img {
    max-width: 100%;
    height: auto;
  }
}

/* 23.07.2026 (Thomas: "modernize h_sysprax_upload.php"): Hinweisbox wirkte durch flaches
   Khaki (#d8ddca) ohne Rundung + harte schwarze 2px-Bildrahmen (inline style="border:2px
   solid black", laesst sich nur mit !important uebersteuern) sehr altbacken. Sanftere
   Kartenoptik + Design-System-Rahmenfarbe statt hartem Schwarz. */
.vereto-table-wrap:has(> table[bgcolor="#d8ddca"]) {
  border: 1px solid var(--border);
  border-radius: 10px;
  overflow: hidden;
  box-shadow: 0 1px 3px rgba(0, 0, 0, 0.06);
}
.vereto-table-wrap table[bgcolor="#d8ddca"] {
  /* 23.07.2026 Nachtrag (Thomas: "sieht nicht mehr passend aus"): Radius/Bildrahmen allein
     reichten nicht -- das satte Khaki (#d8ddca) selbst wirkte neben dem cleanen
     Design-System noch altbacken. Helle Kartenfarbe statt hartem Farbton. */
  background-color: var(--card-bg) !important;
}
/* 23.07.2026 Nachtrag (h_sysprax_upload.php Datei-Auswahl-Zeile): die generelle
   border=0-width:100%-Regel (s.u.) ist fuer normale Label+Eingabefeld-Formulare gedacht,
   riss hier aber Datei-Input und "Hochladen"-Button weit auseinander -- die
   setupPhantomColumnFix()-Spaltenbreite fuer den Button war zwar jetzt korrekt schmal,
   aber die verbleibende (uebrig breite) erste Spalte schob den Button trotzdem an den
   rechten Rand. Diese kleine 2-Elemente-Formularzeile braucht schlicht keine 1200px
   Breite -- natuerliche/kompakte Tabellenbreite behalten. */
.vereto-table-wrap:has(> table[border="0"] input[type="file"]) > table[border="0"] {
  width: auto !important;
  max-width: none !important;
}
.vereto-table-wrap table[bgcolor="#d8ddca"] img {
  border: 1px solid var(--border) !important;
  border-radius: 6px;
}
/* Datei-Auswahl + Hochladen-Button: native "Datei auswaehlen" bekommt denselben
   Button-Look wie der Rest der App (::file-selector-button), Zeile flexibel statt
   default-inline mit ungleicher Hoehe/Abstand zum "Hochladen"-Button. */
input[type="file"] {
  font-size: 13px;
  color: var(--fg);
}
input[type="file"]::file-selector-button {
  background-color: var(--accent);
  color: #fff;
  border: none;
  padding: 7px 18px;
  border-radius: 20px;
  font-family: inherit;
  font-size: 13px;
  font-weight: 600;
  cursor: pointer;
  margin-right: 10px;
  transition: background 0.15s ease;
}
input[type="file"]::file-selector-button:hover {
  background-color: var(--accent-dark);
}
/* 2026-07-23 Mobile-Scan-Fund (h_praxis.php): urspruenglich als Nachfahren-Selektor
   (".vereto-table-wrap table[border=0] td") formuliert -- das traf auch Zellen einer
   VERSCHACHTELTEN Compact-Preview-Tabelle (z.B. renr_gebueh_formatiert-Vorschau), die
   absichtlich kompakt/inline bleiben soll. ">"-Direktkind-Ketten (table > tbody > tr > td)
   beschraenken die Regel auf die AEUSSERE Tabelle, verschachtelte Tabellen bleiben
   unberuehrt. */
.vereto-table-wrap > table[border="0"] > tbody > tr > td,
.vereto-table-wrap > table[border="0"] > tbody > tr > th {
  width: auto !important;
  white-space: normal !important;
}
@media (max-width: 600px) {
  .vereto-table-wrap > table[border="0"] > tbody > tr {
    display: flex;
    flex-direction: column;
    align-items: flex-start;
  }
  .vereto-table-wrap > table[border="0"] > tbody > tr > td {
    display: block;
    width: 100% !important;
    box-sizing: border-box;
  }
}

/* Einzelne Formularfelder mit fest verdrahteter Breite (Legacy-HTML-size/cols-Attribute) an
   die Viewport-Breite binden -- betrifft u.a. h_praxis.php, h_patient_mit_akte.php
   (#ordner_akte), h_patient_import.php. */
@media (max-width: 600px) {
  input[type="text"], input[type="email"], input[type="password"],
  input[type="tel"], input[type="date"], select, textarea {
    max-width: calc(100vw - 40px);
    box-sizing: border-box;
  }
}

/* 23.07.2026 (Thomas: "obere Buttons besser gestalten"): das aktive-Klient-Banner
   (hi_patient_print.php, table.vereto-patient-banner) hat 2 nebeneinander stehende
   Tabellenzellen (Klient-Button+Infotext | Akte-Button). Die generelle Mobile-Regel
   "Buttons werden vollbreit" presste den 2. Button dadurch auf die Breite seiner eigenen,
   sehr schmalen Zelle zusammen ("Ax" statt "Akte"). Zellen stattdessen komplett stapeln. */
@media (max-width: 600px) {
  table.vereto-patient-banner tr {
    display: flex;
    flex-direction: column;
  }
  table.vereto-patient-banner td {
    display: block;
    width: 100% !important;
    text-align: left !important;
  }
}

/* Kleine Touch-Targets vergroessern (Apple/Google-Richtwert 8px Mindestabstand, siehe
   button-margin-Kommentar weiter oben) -- Checkboxen (u.a. SEPA-Einwilligung
   h_concreativ_sepa.php, Dokumentenauswahl h_ablage.php) waren nur ~13x13px klickbar. */
@media (max-width: 600px) {
  input[type="checkbox"], input[type="radio"] {
    /* 25.07.2026 (Code-Check): 20px lagen unter den 24x24 CSS-px, die WCAG 2.2 AA
       (2.5.8 Target Size Minimum) fordert -- gerade bei SEPA-Einwilligung und
       Dokumentenauswahl ist ein Fehlklick teuer. */
    width: 24px;
    height: 24px;
  }
}

/* Praxislogo-Link im Kopfbereich war nur ~22px hoch -- unter der 32px-Mindestklickflaeche.
   25.07.2026 (Code-Check): der fruehere Zusatzfilter img[src*="praxislogo"] traf nur Praxen
   MIT hochgeladenem Logo -- im Standardfall zeigt SESS_APP_LOGO auf ein Bild unter
   /vereto/images/, dort griff weder die Mindestklickflaeche noch der Ueberlaufschutz. */
a[href="hm_main.php"] img {
  min-height: 32px;
  padding: 6px 4px;
  box-sizing: content-box;
  /* 2026-07-23 CI-Fund: die umgebende  ist nur eine HTML-Breitenangabe,
     kein hartes Limit -- ein sehr breites Logo (Seitenverhaeltnis >3, von der App an
     anderer Stelle bereits als Sonderfall behandelt, z.B. zentrierte Ausgabe auf
     Dokumenten) sprengt die Kopfzeile, da das  selbst keine Breitenbegrenzung hatte.
     max-width gilt wegen box-sizing:content-box NUR fuer den Bildinhalt, das horizontale
     Padding (4px+4px) kommt oben drauf -- 152px Inhalt + 8px Padding = 160px Gesamtbreite
     (CI-Lauf 2026-07-23 hatte hier zunaechst 160px angesetzt und damit 168px Gesamtbreite
     gemessen, s. DesignAccessibilityRegressionCest). */
  max-width: 152px;
  width: auto;
  height: auto;
}

/* ---------- Kopfbereich (hi_wp_header.php) ---------- */

/* 25.07.2026 (Code-Check): hm_main.php gab denselben id="head_top" ein zweites Mal aus
   (doppelte id = invalides HTML, und document.getElementById trifft immer nur das erste
   Element). Dort jetzt .vereto-head-top; die Optik bleibt ueber diese Sammelregel gleich. */
#head_top,
.vereto-head-top {
  font-family: inherit;
  font-weight: 600;
  color: var(--fg);
}

/* Logo-/Verlassen-Leiste (Times-New-Roman-Tabelle aus hi_wp_header.php).
   25.07.2026 (Code-Check): die frueheren Selektoren "main + table" und
   "body > table:first-of-type" konnten strukturell nie treffen -- 
 umschliesst die
   gesamte Seite bis zum Footer (kein table-Geschwister danach), und setupPageCenterWrapper()
   haengt alle body-Kinder in .vereto-page-center um (kein table mehr direkt unter body).
   Die Tabelle traegt ihr font-family inline, daher der Attribut-Selektor. */
.vereto-page-center > table[style*="Times New Roman"],
main > table[style*="Times New Roman"] {
  font-family: inherit !important;
}

/* ---------- Hauptmenue #cssmenu ---------- */

#cssmenu {
  height: auto;
  min-height: var(--menu-height);
  border-radius: 8px;
  background: var(--accent);
  border-bottom: none;
  display: flex;
  align-items: stretch;
  position: relative;
  z-index: 1000001;
  /* 23.07.2026: Menue an eine feste Breite binden, statt unbegrenzt die volle Fensterbreite
     zu fuellen -- vorher wirkte die Seite darunter auf breiten Bildschirmen schmaler als
     das Menue. Bewusst NUR hier (nicht auf main, s.o.), damit einzelne breitere Elemente
     (z.B. 1856px-Tabpflege-Tabellen) trotzdem ihre volle Breite behalten koennen.
     1200px (Thomas-Wunsch, entspricht dem recherchierten Web-Standard-Container, siehe
     Bootstrap xl-Breakpoint 1140-1200px) statt der urspruenglichen 1000px (SESS_APP_WIDTH).
     23.07.2026 Nachtrag (Thomas: "die App ist nach links verschoben, die Webseite ist
     zentriert" -- Vergleich mit der echten WordPress-Seite, deren Hauptcontainer zentriert
     ist): margin:auto ergaenzt, um auf breiten Bildschirmen wie die Webseite mittig zu
     sitzen statt linksbuendig mit Leerraum nur rechts. Die zuvor hier dokumentierte Sorge
     ("Menue und Inhalt laufen auseinander") wird durch die begleitend ergaenzte Zentrierung
     der width=1000-Tabellen (s.u.) und der border=0-Formulartabellen aufgeloest -- beide
     zentrieren sich jetzt im Gleichschritt mit dem Menue, nur echte UEBERBREITE Tabellen
     (>1200px, z.B. 1856px-Tabpflege) bleiben bewusst linksbuendig/scrollend. */
  max-width: 1200px;
  margin-left: auto;
  margin-right: auto;
}
#cssmenu:after,
#cssmenu ul:after { content: none; }

#cssmenu > ul {
  display: flex;
  flex-wrap: wrap;
  /* 23.07.2026 (Nachtrag "abmelden" rechtsbuendig): das