/* ==================================================================== M&W-Framework · © 2026 Tobias Wachtel — Alle Rechte vorbehalten. Geschützter Quellcode — Nutzung nur mit schriftlicher Genehmigung. ==================================================================== assets/grund.css — Grundregeln des Kerns, die VOR jedem Theme geladen werden (Gegenstück zu `assets/app.js`). Zweierlei gehört hier hinein: 1. Was am SEITENGERÜST hängt und in jedem Theme gleich gelten soll (Fuß unten, Gerätebreite, gesperrter Hintergrund). 2. Der brauchbare GRUNDZUSTAND der Bausteine, die der Kern SELBST ins HTML schreibt: Meldung (`mwToast`), Rückfrage (`mwConfirm`), Menü-Zeichen, Abzeichen. Wer ein Element erzeugt, muss auch dafür sorgen, dass es benutzbar ankommt — sonst hängt es davon ab, ob ein Theme zufällig daran gedacht hat. Genau das ist passiert: `themes/admin` kannte `.mw-toast` und `.mw-modal` nicht. Die Meldung stand am ENDE der Seite (2 883 px weit unten, nie im Bild), und die Rückfrage lag ohne Abdunklung mitten im Text — gemessen, nicht vermutet. `themes/papier` fehlt bis heute das Menü-Abzeichen, und der Updater fasst fremde Themes nie an (`Aktualisierung.php:24`): Was dort fehlt, kann NUR der Kern liefern. Alles Übrige — Farben, Abstände und Schrift der SEITE — bleibt Sache des Themes. WICHTIG — das Theme hat immer das letzte Wort. Es wird NACH dieser Datei gebündelt und gewinnt deshalb bei jedem Gleichstand. ⚠️ Aber NICHT jede Regel hier ist `:where()`. Es gibt drei Gewichte, und jedes hat einen Grund, der an Ort und Stelle noch einmal steht: · 0,0,1 — der Normalfall (`body:where(:has(> .fuss))`, `div:where(.mw-modal)`): Tag-Name plus `:where()`. Jede Theme-Regel mit Klasse (0,1,0) gewinnt, ein Theme-Reset `*{margin:0}` (0,0,0) verliert. Ohne `:where()` wöge `body:has(> .fuss)` mehr als ein schlichtes `body{…}` im Theme — der Kern würde dem Theme die Regel aufzwingen, und genau das soll er nicht. · 0,1,0 — für Bausteine, die es nur im Kern gibt (`.nav-zeichen`). Hier gibt es nichts zu überstimmen; ein Theme, das mitreden will, schreibt ohnehin seinen eigenen Kontext davor. · 0,2,0 — nur dort, wo der Kern gewinnen MUSS (`body.geraet-handy .inhalt`, die erzwungene Handy-Ansicht). Mit `:where()` kam sie gegen `.inhalt{max-width:…}` des Themes nicht an: 1 180 px trotz „Handy". ==================================================================== */ /* ── Fuß bleibt unten ──────────────────────────────────────────────── Das Seitengerüst aus `Seite::rumpf()` ist: header.kopf + main.inhalt + footer.fuss untereinander. Stehen die drei einfach hintereinander, endet der Fuß dort, wo der Inhalt endet — bei einer kurzen Seite also mitten im Fenster, mit einer großen leeren Fläche darunter. `:has(> .fuss)` greift nur, wenn die Seite diesem Gerüst folgt. Die Anmeldeseite (Layout „leer", ohne Fuß) bleibt dadurch unangetastet — dort zentrieren die Themes ihre Karte selbst. Bewusst im KERN und nicht nur in `themes/standard`: Jedes App-Theme bringt sein eigenes `theme.css` mit und müsste den Fix sonst neu erfinden. Genau das ist passiert — in 1.8.3 saß er nur im Standard- Theme, und in einer App mit eigenem Theme hing der Fuß weiter. */ body:where(:has(> .fuss)){ min-height:100vh; display:flex; flex-direction:column; } /* flex:1 0 auto — der Inhalt nimmt den freien Platz ein und schiebt den Fuß nach unten, schrumpft aber nie unter seine eigene Höhe (0 = kein shrink), damit auf langen Seiten nichts gestaucht wird. width:100% ist PFLICHT, nicht Kosmetik: `.inhalt` trägt in praktisch jedem Theme `max-width` + `margin:0 auto`. Sobald `body` ein Flex- Container ist, unterbinden auto-Margins in der QUERachse das Strecken (`align-items:stretch`) — das Element fällt dann auf seine INHALTS- breite zurück. Im normalen Blockfluss passiert das nicht, deshalb fällt es beim Umstellen auf Flex leicht durch: In 1.8.4 schrumpfte `.inhalt` dadurch von 1180 px auf 246 px, ein Kachel-Raster (`repeat(auto-fit,minmax(190px,1fr))`) von fünf Spalten auf eine. Mit width:100% + max-width verhält es sich wieder wie im Blockfluss. */ body:where(:has(> .fuss)) > :where(.inhalt){ flex:1 0 auto; width:100%; } /* Auf dem Handy meint 100vh das Fenster OHNE eingeblendete Adressleiste — die Seite wäre dann etwas zu hoch. 100dvh misst den sichtbaren Teil. */ @supports (min-height:100dvh){ body:where(:has(> .fuss)){ min-height:100dvh; } } /* ── Grundstock ────────────────────────────────────────────────────── Ab 1.9.0. Hier steht ausschließlich, was Browser-Vorgaben NEUTRALISIERT — nichts Gestalterisches. Grund: Ein App-Theme ersetzt `themes/standard` vollständig und erbt nichts davon. Alles, was nur dort stand, musste jedes Theme neu erfinden; vergaß es eins, sah die App kaputt aus. Farben, Abstände und Schriften bleiben Sache des Themes. Der Browser färbt Rollbalken, Zahlenfelder und Datumswähler von selbst passend, sobald das Theme `color-scheme: light` bzw. `dark` setzt — dafür braucht es kein eigenes CSS. */ /* Maße rechnen mit Rand und Innenabstand — sonst sprengt jedes Feld mit Innenabstand seine Spalte. Stand bisher nur im Standard-Theme. */ *, *::before, *::after{ box-sizing:border-box; } /* Formularelemente erben die Schrift der Seite. Ohne das setzt der Browser seine eigene (meist 13,33 px Arial) — mitten in einer Oberfläche, die überall sonst die Theme-Schrift nutzt. BEWUSST nur Familie und Größe, NICHT die Kurzform `font:inherit`: Die setzt auch die Zeilenhöhe mit. Ein Knopf, dem das Theme nur `font-size` gibt, behielte dann die geerbte Zeilenhöhe (1.5 statt `normal`) und würde spürbar höher — gemessen wuchs eine lange Seite dadurch um 5 px. Farbe bleibt ebenfalls außen vor: Feldfarben hängen am Theme, ein `color:inherit` könnte helle Schrift auf hellem Feld erzeugen. */ :where(input, select, textarea, button){ font-family:inherit; font-size:inherit; } /* Die kleinen Auf-/Ab-Pfeile an Zahlenfeldern zeichnet der Browser in seiner eigenen Optik: hell, klobig, mit eigener Trennlinie. In einem dunklen Design sieht das nach Fehler aus, und das Feld wird unnötig breit. Sie sind reine Zugabe — verstellen geht weiterhin mit den Pfeiltasten, dem Mausrad und der Tastatur. */ :where(input[type="number"]){ appearance:textfield; -moz-appearance:textfield; } input[type="number"]::-webkit-outer-spin-button, input[type="number"]::-webkit-inner-spin-button{ -webkit-appearance:none; appearance:none; margin:0; } /* Medien sprengen nie das Layout — ein zu großes Bild schiebt sonst die ganze Seite seitlich auf und erzeugt eine waagerechte Bildlaufleiste. */ :where(img, svg, video, canvas){ max-width:100%; } /* Sichtbarer Fokus für Tastaturbedienung. `:focus-visible` erscheint nur bei Tastatur, nicht beim Mausklick. `currentColor` passt sich der Textfarbe des Themes an, ohne eine eigene Farbe vorzugeben. */ :where(:focus-visible){ outline:2px solid currentColor; outline-offset:2px; } /* ── Menü-Knopf: der Grundzustand ──────────────────────────────────── Den Knopf (☰) liefert der Kern (`Seite::navigation`), und `app.js` klappt damit das Menü auf. Ob er ÜBERHAUPT sichtbar ist und ob das Menü eingeklappt wird, stand bis 1.10.0 nur in `themes/standard` — ein App-Theme bekam also ein Bedienelement, das dauerhaft sichtbar und wirkungslos war. Man merkt so etwas schlecht, weil nichts fehlt, sondern etwas zu viel da ist. Hier steht deshalb nur die FUNKTION: wann der Knopf erscheint und dass `.nav.offen` das Menü zeigt. Aussehen (Farbe, Rahmen, Größe, Anordnung der Einträge) bleibt vollständig beim Theme. Der Umschaltpunkt 820px ist eine Vorgabe. Ein Theme mit eigener Grenze setzt seine eigene Media-Query — sie kommt später im Bündel und gewinnt; für den Bereich dazwischen dort `display:none` bzw. `display:flex` ausdrücklich setzen. ACHTUNG bei der Gewichtung: Das Ein-/Ausklappen steht hier BEWUSST nicht in `:where()`. Ein Theme setzt typischerweise `.nav{display:flex}` — mit `:where()` (Gewicht 0) käme der Kern dagegen nicht an, das Menü bliebe im schmalen Fenster ausgeklappt und der Knopf sinnlos (genau so gemessen). `.nav:not(.offen)` wiegt eine Klasse mehr und gewinnt. Ein Theme, das es anders will, überschreibt es mit `.kopf .nav{…}`. Beim reinen Aussehen (`.nav-schalter` im Ruhezustand) bleibt es bei `:where()`. WER DIE RICHTUNG DREHT, MUSS DIE AUSRICHTUNG MITDREHEN: Ein Theme setzt für die waagerechte Leiste fast immer `.nav{align-items:center}` — völlig richtig. Klappt der Kern dieselbe Leiste zur Spalte um, zentriert genau diese Regel die Einträge plötzlich WAAGERECHT und lässt sie auf Textbreite schrumpfen: ein schmaler, mittiger Stapel statt einer Liste. Deshalb gehören `align-items` und `flex-basis` hier dazu — sonst ist die Funktion nur halb hergestellt. Gemessen in der Energie-Zentrale (Theme „orbit"), Fenster 390 px. Die Mindestgröße des Knopfes ist ebenfalls Funktion, nicht Optik: Ohne sie war die Tap-Fläche 18 × 23 px — zu klein zum Treffen. Aussehen (Rahmen, Farbe, Schrift) bleibt beim Theme, deshalb per `:where()`. */ :where(.nav-schalter){ display:none; min-width:40px; min-height:40px; } @media (max-width:820px){ .nav-schalter{ display:block; } .nav:not(.offen){ display:none; } .nav.offen{ display:flex; flex-direction:column; align-items:stretch; flex-basis:100%; } } /* Dasselbe für die erzwungene Ansicht (Fuß-Umschalter Computer/Tablet/Handy): Dort zählt nicht die Fensterbreite, sondern die Wahl des Benutzers. */ body.geraet-handy .nav-schalter, body.geraet-tablet .nav-schalter{ display:block; } body.geraet-handy .nav:not(.offen), body.geraet-tablet .nav:not(.offen){ display:none; } body.geraet-handy .nav.offen, body.geraet-tablet .nav.offen{ display:flex; flex-direction:column; align-items:stretch; flex-basis:100%; } /* Das aufgeklappte Menü braucht einen HINTERGRUND — sonst liegen die Einträge ohne Abgrenzung auf dem Seiteninhalt und es sieht aus, als schwebten sie (gemessen: `rgba(0,0,0,0)`, gemeldet als „poppt einfach oberhalb auf"). Der Kern stellt hier nur die Lesbarkeit sicher; die Farbe kommt aus der Theme-Variable, der Rückfall greift nur, wenn ein Theme sie nicht setzt. Rundung und Innenabstand sind bewusst minimal — per `:where()` überschreibt ein Theme beides mit einer einzigen Regel. */ @media (max-width:820px){ :where(.nav.offen){ background:var(--karte, rgba(20,22,28,.97)); border-radius:10px; padding:8px; gap:2px; } } :where(body.geraet-handy, body.geraet-tablet) :where(.nav.offen){ background:var(--karte, rgba(20,22,28,.97)); border-radius:10px; padding:8px; gap:2px; } /* ── Ansichtswahl: darf umbrechen ─────────────────────────────────── Seit der vierten Position („Automatisch", 1.11.3) passt die Zeile nicht mehr in ein schmales Fenster: gemessen 412 px bei 390 px Fensterbreite — die Seite bekam dadurch eine WAAGERECHTE Bildlaufleiste. Umbrechen statt überstehen; Farben und Abstände bleiben beim Theme. */ :where(.ansicht-wahl){ display:inline-flex; flex-wrap:wrap; justify-content:center; } :where(.fuss){ flex-wrap:wrap; } /* ── Erzwungene Ansicht am großen Bildschirm ───────────────────────── Wer im Fuß „Handy" oder „Tablet" wählt, will die schmale Darstellung sehen — bisher passierte am Desktop fast nichts. Nur OBERHALB des Umschaltpunkts, damit sich auf einem echten Handy nichts ändert. ⚠️ Das ist eine Annäherung, keine Simulation: Die `@media (max-width:…)`- Regeln eines Themes beziehen sich auf das FENSTER, nicht auf diese Breite — sie greifen hier also nicht. Wer eine originalgetreue Vorschau will, hängt seine Handy-Regeln zusätzlich an `body.geraet-handy` (so macht es `themes/standard`). Genau daran liegt es, wenn die Umschaltung in einem App-Theme „nichts tut". ACHTUNG Gewichtung — hier bewusst OHNE `:where()`: Ein Theme setzt für den Inhalt fast immer `.inhalt{max-width:…}` (Gewicht 0,1,0). Mit `:where()` käme der Kern mit Gewicht 0,0,1 nicht dagegen an, und die erzwungene Ansicht bliebe wirkungslos — genau so gemessen (1180 px trotz „Handy"). Dieselbe Falle wie beim Menü in 1.11.3. `body.geraet-handy .inhalt` wiegt 0,2,0 und gewinnt; ein Theme überschreibt es mit `body.geraet-handy .kopf .inhalt` oder eigener Angabe. */ @media (min-width:821px){ body.geraet-handy > .kopf, body.geraet-handy > .inhalt, body.geraet-handy > .fuss { max-width:430px; margin-inline:auto; } body.geraet-tablet > .kopf, body.geraet-tablet > .inhalt, body.geraet-tablet > .fuss{ max-width:834px; margin-inline:auto; } } /* ── Fenster (Dialoge): die Seite dahinter darf nicht scrollen ─────── Solange ein Fenster offen ist, trägt `body` die Klasse `mw-gesperrt` (gesetzt von `assets/app.js`, siehe `mwSeiteSperren`). Ohne das scrollt das Mausrad über dem abgedunkelten Rand die Seite DARUNTER weg, während das Fenster selbst stehen bleibt. Damit der Inhalt beim Sperren nicht um die Breite der verschwindenden Bildlaufleiste springt, gleicht `app.js` sie mit einem Innenabstand aus — und nur dann. `scrollbar-gutter:stable` wäre der kürzere Weg, kostet aber DAUERHAFT Platz: gemessen 10 px weniger Inhaltsbreite bei 375 px Fenster, auch wenn gar kein Fenster offen ist. */ body.mw-gesperrt{ overflow:hidden; } /* Und das Fenster muss SELBST scrollen können — sonst ist ein langer Inhalt unerreichbar, sobald die Seite dahinter gesperrt ist. Betrifft den Kasten im Fenster, nicht den abgedunkelten Hintergrund: Der trägt `aria-modal` in aller Regel am inneren Element (`