/* ========================================================================= Munich Metal Underground — Gestaltung ========================================================================= Leitidee: kritische Ausgabe. Die Seite ist ein Verzeichnis, kein Magazin, und zwei Drittel der Bandseiten tragen keine Kurzvorstellung. Legte man das gestalterische Gewicht auf den Fliesstext, saehen 230 von 343 Seiten aus wie ein Fehler. Also traegt der APPARAT die Seite — Datenkarte, Belege, Statusvermerke — und die Prosa ist die Zutat. Eine Bandseite ohne Portraet ist dann vollstaendig und nicht lueckenhaft. Daraus folgt die eine Struktur, die sich durch alles zieht: [ Register 9.5rem ][ Spalte 36rem ] WAS ES IST WAS ES SAGT Bezeichner, Ueberschriften und Fussnotenziffern stehen links im Register, die Werte rechts in der Spalte. Datenkarte, Quellenblock und Konzertliste benutzen dasselbe Raster — deshalb wirkt die Seite ruhig, obwohl sie dicht ist. Haerte kommt aus Kontrast und Kante: Haarlinien, keine Schatten, keine runden Ecken, kein Verlauf. */ /* ------------------------------------------------------------------------- 1. Merkmale ------------------------------------------------------------------------- Die Farben kommen aus theme.json und stehen dort als WordPress-Merkmale bereit. Die Rueckfallwerte sind KEINE Zierde: Sie halten dieses Stylesheet allein lauffaehig — in einer statischen Entwurfsdatei, im Editor, und falls theme.json einmal nicht greift. Zwei Wahrheiten entstehen dadurch nicht, weil beide Seiten denselben Wert tragen. */ :root { /* ⚠️ Die Seite meldet ihre Farbgebung an. Ohne diese Zeile dunkeln mobile Browser sie von sich aus ab — Chrome auf Android nennt das „Automatisches dunkles Design fuer Webinhalte" und wendet es auf jede Seite an, die sich nicht aeussert. Solange die Seite selbst dunkel war (bis 18.08.2026), fiel das nicht auf. Nach der Umkehrung auf hellen Grund meldete der Betreiber am 19.08.2026: „auf dem Handy ist die Seite immer noch dunkel" — obwohl Server, Stylesheet und Versionsstempel nachweislich hell auslieferten. Das Telefon drehte sie zurueck. `dark` und nicht `light dark`: Die Seite hat genau eine Fassung, und die ist seit dem 30.09.2026 wieder dunkel. `light dark` behauptete eine helle Variante, die es nicht gibt. ⚠️ Der Grund fuer diese Zeile bleibt derselbe wie 2026 auf hellem Grund, nur andersherum: Eine Seite, die sich nicht aeussert, wird vom Browser behandelt. Dass die Angabe jetzt zur Lage passt, macht sie nicht entbehrlich. */ color-scheme: dark; --mmu-grund: var(--wp--preset--color--grund, #000000); --mmu-flaeche: var(--wp--preset--color--flaeche, #0f0f15); --mmu-tafel: var(--wp--preset--color--tafel, #000000); --mmu-text: var(--wp--preset--color--text, #e8e8ea); /* ⚠️ ZURUECK AUF DUNKEL am 30.09.2026: schwarzer Grund, helle Schrift. Zwischen dem 18.08. und dem 30.09.2026 war die Seite hell. 🔴 Das ist die ZWEITE Umkehrung, und sie hebt die erste auf. Wer hier etwas aendert, sollte beide Vorgeschichten kennen — die von 2026/08 steht gleich darunter und ist NICHT erledigt, nur ueberstimmt. Anlass: Betreiberentscheidung vom 30.09.2026 zur Umsetzung des Zeitungsoptik-Handoffs ("Version 2"), der durchgehend fuer dunklen Grund gezeichnet ist — bis hin zu den neuen Papier-Flaechen (#ece8df), die ihren Reiz nur auf dunklem Grund entfalten. Die Entscheidung fiel auf Vorlage, in der das Handy-Leseproblem von 2026/08 ausdruecklich als Folge benannt war. Wie es dazu kam, steht in der Vorgeschichte, und sie ist lehrreich: Am selben Tag wurde zweimal nachgebessert, weil der Betreiber die Seite auf dem Handy schlecht lesen konnte. Erst --mmu-gedimmt von #a0a0a8 auf #b4b4bc, dann --mmu-text von #e8e8ea auf #ffffff — bis zu 21:1 auf reinem Schwarz, dem theoretischen WCAG-Maximum. Es half nicht: „der Hintergrund ist auf dem Handy zu dunkel". Der Kontrast war nie das Problem, die Grundhelligkeit war es. Ein Bildschirm bei Tageslicht gewinnt gegen jedes Verhaeltnis, wenn die Flaeche selbst dunkel bleibt. Gemessen nach der Rueckkehr (30.09.2026): Text #e8e8ea auf Grund #000000 17,16:1 auf Kachel #0f0f15 15,61:1 Gedimmt #a0a0a8 auf Grund 8,09:1 auf Kachel 7,36:1 --mmu-gedimmt haelt damit auf BEIDEN Gruenden AAA (7:1) fuer Fliesstext — dieselbe bindende Bedingung wie bei der ersten Umkehrung, und sie geht mit 8,09 gegen 8,10 praktisch unveraendert durch. Die beiden Farbwelten sind darin gleichwertig; der Unterschied lag nie im Verhaeltnis, sondern in der Grundhelligkeit — siehe oben. ⚠️ Der Text verliert gegenueber der hellen Fassung (17,16 statt 21,00). Das ist kein Mangel: 21:1 ist das theoretische Maximum und war hier ein Nebenprodukt von reinem Schwarz auf reinem Weiss. Der Handoff setzt #e8e8ea statt #ffffff mit Absicht — reines Weiss auf Schwarz blendet und laesst Serifenschrift ausfransen. ⚠️ Der Wert steht ZWEIMAL: hier als Notfassung und in theme.json als WordPress-Preset. Das Preset gewinnt. Wer nur hier aendert, aendert nichts — beide muessen mit. */ --mmu-gedimmt: var(--wp--preset--color--gedimmt, #a0a0a8); --mmu-akzent: var(--wp--preset--color--akzent, #c0392b); --mmu-kante: var(--wp--preset--color--kante, #6a6a72); --mmu-linie: var(--wp--preset--color--linie, #26262c); /* ⚠️ ZWEI Akzentfarben, und die Trennung ist eine Kontrastfrage. Zeitungsoptik-Entwurf, 17.08.2026. Die ROLLEN HABEN ZWEIMAL GETAUSCHT: am 18.08.2026 von Schwarz auf Weiss, am 30.09.2026 wieder zurueck. Das ist der unscheinbarste und gefaehrlichste Teil der Umkehrung: Auf dunklem Grund traegt die HELLERE Variante den Text, auf hellem die DUNKLERE. Gemessen: auf Schwarz (heute) auf Weiss #c0392b 3,86:1 5,44:1 #d9604b 5,73:1 3,67:1 #a5301f 2,93:1 6,90:1 Die Tabelle liest sich in beide Richtungen, und das ist ihr Zweck: Jede der drei Farben faellt auf EINEM der beiden Gruende durch. Wer den Grund tauscht und die Roettoene stehen laesst, macht ausgerechnet die Links unlesbar — beim ersten Mal (2026/08) haette es #d9604b getroffen, beim zweiten (2026/09) traf es #a5301f mit 2,93:1. --mmu-akzent (#c0392b) bleibt in beiden Welten unveraendert und traegt auf Schwarz 3,86:1. Das genuegt fuer Striche und Rahmen (WCAG 1.4.11: 3:1), NICHT fuer Text (1.4.3: 4,5:1) — auf Weiss war es fuer beides tauglich. Es ist hier also reine Flaechen- und Kantenfarbe. --mmu-akzent-text (#d9604b) traegt 5,73:1 auf dem Grund und 5,21:1 auf der Kachelflaeche. Es traegt alles, was gelesen wird — Links, Fokusring, Beschriftungen, Ziffern. ⚠️ Als FLAECHE gilt weiterhin --mmu-akzent: Weisser Text darauf steht bei 5,44:1. Wer stattdessen die dunklere nimmt, muss den Text darauf nachrechnen. Wer eine der beiden Farben aendert, rechnet beide Richtungen nach — als Schrift UND als Flaeche. */ --mmu-akzent-text: var(--wp--preset--color--akzent-text, #d9604b); /* Schrift AUF der Akzentflaeche — nicht daneben. --mmu-akzent-text ist fuer Akzentschrift auf dem GRUND gedacht; auf dem Akzent selbst stuende sie Rot auf Rot. Handoff v3 fuehrt mit dem „Neu"-Block die erste solche Flaeche ein, und die Gummistempel der Eintrittskarten werden die zweite. 📏 Weiss auf --mmu-akzent (#c0392b) ergibt 5,44:1 — AA, nicht AAA. Wer das anhebt, aendert die Akzentflaeche mit, nicht diesen Wert: Heller als Weiss geht nicht. ⚠️ Als Token und nicht als `#ffffff` an der Fundstelle: Reines Weiss in der dunklen Welt ist genau das Muster, nach dem test/farbwelt.test.mjs sucht, um Reste der hellen Welt zu finden. Eine harte Farbe waere dort ein Fund gewesen, den niemand von einem echten unterscheiden kann — benannt sagt sie, dass sie gemeint ist. */ --mmu-auf-akzent: #ffffff; /* Die Logotafel als Klecks statt als Rechteck. Betreiberwunsch vom 18.08.2026, nachdem der Wechsel auf hellen Seitengrund die vorher unsichtbare schwarze Flaeche zu einem harten Kasten gemacht hat. 🔴 SEIN ANLASS IST AM 30.09.2026 ENTFALLEN: Auf schwarzem Grund ist die schwarze Flaeche wieder unsichtbar, ein Rechteck faellt nicht mehr auf. Der Klecks bleibt trotzdem stehen — er war ein ausdruecklicher Betreiberwunsch, und ihn stillschweigend zu entfernen hiesse, eine Entscheidung durch eine andere zu ersetzen, ohne zu fragen. Vorgelegt am 30.09.2026; bis zur Antwort gilt der Wunsch. Eine MASKE, kein Hintergrundbild: Der schwarze Grund steckt bei 157 von 179 Logos fest im Bild und laesst sich nicht hinterlegen, nur beschneiden. ⚠️ Die Mitte der Form ist voll deckend. Der unregelmaessige Rand greift hoechstens 9 % der Hoehe und 4 % der Breite nach innen — beides liegt innerhalb des Innenabstands, damit kein Logo angeschnitten wird. Wer den Innenabstand verkleinert, schneidet Logos an; wer die Form aendert, muss diese Reserve nachrechnen. `preserveAspectRatio='none'`: Die Form wird mit dem Element gedehnt. Bei einem breiten Logo wird der Klecks entsprechend breit — gewollt, sonst saesse eine quadratische Form auf einem 3:1-Logo. */ /* ----------------------------------------------------------------------- Papier (Handoff v2, "Neue Tokens") ----------------------------------------------------------------------- Die zweite Materialebene der Seite. Alles, was man anfassen koennen soll — Flyer an der Pinnwand, Eintrittskarten, die Merkliste, das Eselsohr unter jeder Seite — liegt auf Papier statt auf dem Zeitungsgrund. 🎯 Das ist der Grund, warum die Rueckkehr auf dunklen Grund (30.09.2026) fuer Version 2 noetig war: Auf weissem Grund waere Papier #ece8df kaum vom Grund zu unterscheiden gewesen. Auf Schwarz steht es bei 17,17:1 und hebt sich wie ein aufgelegtes Blatt ab. Gemessen (WCAG), auf Papier #ece8df: Papier-Text #17171b 14,62:1 Fliesstext AAA Akzent #a93226 5,42:1 Text AA Kante hell #b9b3a6 1,71:1 ⚠️ siehe unten Kante dunkel #8d887d 2,89:1 ⚠️ siehe unten ⚠️ Die beiden KANTEN unterschreiten die 3:1 aus WCAG 1.4.11, und das ist kein Mangel: Die Regel gilt fuer bedeutungstragende grafische Elemente und die Grenzen von Bedienelementen. Diese Kanten umranden eine Flaeche, die selbst 17:1 gegen den Grund traegt — das Papier ist auch ohne sie zweifelsfrei zu sehen, sie geben ihm nur Rand und Schatten. Wer eine Kontrastpruefung ueber diese Tokens baut, muss Dekoration ausnehmen, sonst erzeugt sie Fehlalarme und wird bald ueberlesen. */ --mmu-papier: #ece8df; --mmu-papier-kante: #b9b3a6; --mmu-papier-falz: #8d887d; --mmu-papier-text: #17171b; --mmu-papier-akzent: #a93226; /* 🔴 LEISE SCHRIFT AUF PAPIER — und der Grund, warum es sie geben muss: Am 30.09.2026 live gemessen, nach der Auslieferung um 19:52: --mmu-papier-falz (#8d887d) auf Papier 2,89:1 <- unter AA --mmu-papier-kante (#b9b3a6) auf Papier 1,71:1 --mmu-papier-text (#17171b) auf Papier 14,62:1 Ich hatte --mmu-papier-falz an vier Stellen als TEXTFARBE benutzt: die Zahl im Register-Reiter, die Beschriftungen auf den Vereins- zetteln, der Ort im Schriftplakat und eine vierte. Der Name sagt, was es ist — ein FALZ, und ein Falz ist DEKORATION. Er trennt nichts, was man sonst nicht unterscheiden koennte: Das Eselsohr nennt seine Richtung zusaetzlich als Wort („Vorige Seite" / „Naechste Seite"), und das Schriftplakat grenzt sich durch seinen Papiergrund ab, nicht durch den Rahmen. Fuer Dekoration gilt keine Kontrastgrenze — WCAG 1.4.11 nimmt sie ausdruecklich aus. ⚠️ HIER STAND ZUERST ETWAS ANDERES, und es trug nicht: „Eine Linienfarbe muss 3:1 halten (WCAG 1.4.11)." Das waere ein Argument gewesen, wenn 2,89 die 3:1 hielte — tut es aber auch nicht. In beiden Lesarten ging der Satz daneben: Waere der Falz bedeutungstragend, waere die Behebung unvollstaendig; da er Dekoration ist, war die Begruendung ueberfluessig und als Regel irrefuehrend. (Befund der Orte-Sitzung, 30.09.2026, mit dem Hinweis auf ihren eigenen Fall vom selben Morgen: Ihr Pruefskript meldete eine dekorative Trennlinie mit 1,40:1 als Durchfaller.) 🎯 Die Unterscheidung ist NICHT messbar, sondern eine Entscheidung ueber die Rolle des Elements. Eine Kontrastpruefung, die Dekoration nicht ausnimmt, erzeugt Fehlalarme; eine, die zu grosszuegig ausnimmt, uebersieht echte Maengel. Als SCHRIFT dagegen gilt 4,5:1, und 2,89 faellt durch. Der Token war richtig gewaehlt und falsch verwendet. ⚠️ Das ist die vierte Fundstelle desselben Tages in der Papierwelt, aber eine andere Ursache als die drei davor: Dort wurde eine Farbe GEERBT, die nicht gemeint war. Hier wurde eine gesetzt, die gemeint war und nicht taugt. Ein Kontrastwert gehoert gemessen, auch wenn die Farbe aus der richtigen Welt kommt. 📏 #615d55 ergibt 5,36:1 — leise genug, um neben --mmu-papier-text zurueckzutreten, und ueber der Textgrenze. */ --mmu-papier-leise: #615d55; /* Die Feder aus dem Handoff, als Token statt zwanzigmal abgeschrieben: "cubic-bezier(.2,1.5,.4,1), leichtes Ueberschwingen, 250-500ms". */ --mmu-feder: cubic-bezier(.2, 1.5, .4, 1); --mmu-klecks: url("data:image/svg+xml,%3Csvg%20xmlns%3D'http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg'%20viewBox%3D'0%200%20200%2080'%20preserveAspectRatio%3D'none'%20fill%3D'%23000'%3E%3Cpath%20d%3D'M8%2C18%20C12%2C8%2026%2C4%2042%2C5%20C56%2C1%2074%2C4%2092%2C3%20C112%2C1%20134%2C5%20152%2C4%20C170%2C3%20186%2C7%20192%2C15%20C198%2C23%20199%2C40%20196%2C52%20C193%2C64%20184%2C74%20168%2C76%20C150%2C79%20130%2C75%20110%2C77%20C88%2C79%2066%2C76%2048%2C77%20C30%2C78%2014%2C74%208%2C64%20C2%2C53%203%2C29%208%2C18%20Z'%2F%3E%3C%2Fsvg%3E"); /* Die Schriften des Zeitungsentwurfs. Alle vier liegen lokal als WOFF2 (§5.2: nichts von fremden Servern) und sind in theme.json angemeldet; die Tokens hier machen sie im Stylesheet greifbar, ohne dass jede Regel den ganzen Stapel wiederholt. */ --schrift-ui: var(--wp--preset--font-family--grundschrift, "IBM Plex Sans", system-ui, sans-serif); --schrift-prosa: var(--wp--preset--font-family--serifenschrift, "IBM Plex Serif", Georgia, serif); --schrift-mono: var(--wp--preset--font-family--schreibmaschine, "IBM Plex Mono", ui-monospace, monospace); --schrift-titel: var(--wp--preset--font-family--titelschrift, "UnifrakturCook", "IBM Plex Serif", serif); /* Der Seitengrund IST das Schwarz der Logos, nicht ein dunkles Grau daneben. Damit verschwindet die Logotafel vollstaendig — 130 der 158 undurchsichtigen Logos tragen reines Schwarz am Rand, sie gehen nahtlos in die Seite ueber. --mmu-tafel bleibt trotzdem ein eigenes Merkmal, obwohl es jetzt denselben Wert traegt: Es haelt die Zusage fest, dass Logos auf reinem Schwarz sitzen. Wuerde der Seitengrund je aufgehellt, schuetzt die Tafel die Logos weiterhin, ohne dass jemand den Zusammenhang neu entdecken muss. Flaeche und Linie sind mitgezogen: Auf einem dunkleren Grund wirkt jede Aufhellung staerker. #1b1b1f stand 1.099:1 ueber dem alten Grund, #0f0f15 stand ueber Schwarz bei denselben 1.099:1 — die Abstufung blieb also genau so leise wie vorher, statt sich ungewollt zu verschaerfen. Fuer die Linie ebenso: 1.400 -> 1.396. ⚠️ Historisch, gilt fuer die dunkle Fassung bis 18.08.2026. Seither ist der Grund weiss: Kachel #f4f4f6 steht bei 1.075:1 darunter, die Linie #d5d5da bei 1.457:1. Dasselbe Prinzip, dieselbe Groessenordnung, nur andersherum — die Kachel ist jetzt minimal DUNKLER als der Grund statt heller. */ /* Zwei Linienstaerken, und das ist eine Zugaenglichkeitsfrage, keine Geschmacksfrage: Eine Trennlinie in einer Liste ist Zierde und darf leise sein (1.40:1). Der Umriss eines Bedienelements muss nach WCAG 1.4.11 mindestens 3:1 erreichen — --mmu-kante liegt bei 3.52:1. Das alte, einheitliche #444 lag bei 1.94:1 und trug beides. */ --mmu-register: 9.5rem; /* Bezeichnerspalte */ --mmu-spalte: 36rem; /* Lesespalte: rund 75 Zeichen in Plex Sans */ --mmu-luecke: 1.5rem; --mmu-rahmen: 72rem; /* Aussenmass, deckungsgleich mit alignwide */ --mmu-rand: clamp(1rem, 4vw, 2rem); --t-mikro: 0.75rem; --t-klein: 0.8125rem; --t-neben: 0.875rem; --t-prosa: 1.0625rem; --t-gross: 1.375rem; --raum-1: 0.25rem; --raum-2: 0.5rem; --raum-3: 0.75rem; --raum-4: 1rem; --raum-5: 1.5rem; --raum-6: 2rem; --raum-7: 3rem; } /* ------------------------------------------------------------------------- 2. Der Seitenrahmen ------------------------------------------------------------------------- Gemessen am 11.08.2026:
steht direkt unter , ausserhalb jedes begrenzten Containers — ohne Innenabstand, ueber die volle Fensterbreite. Der Kopfbereich sitzt dagegen in einer 72rem-Spalte. Auf einem breiten Schirm klebte die Bandliste an der Fensterkante, waehrend die Navigation darueber ordentlich eingerueckt war. Die Rechnung mit calc() ist der Punkt: alignwide im Kopfbereich ist 72rem OHNE Innenabstand. Ein blosses max-width:72rem hier ergaebe 72rem INKLUSIVE Abstand — Kopf und Inhalt saessen um zweimal --mmu-rand versetzt. Deshalb wird der Abstand aufgeschlagen. */ main[class^="mmu-"], main[class*=" mmu-"], .mmu-kopf, .mmu-fuss, /* .mmu-ticker haengt direkt unter , wie
— ohne ihn hier waere er das einzige Seitenelement ohne Spaltenbegrenzung: "NEU" begaenne bei x = 0, waehrend Kopf, Rubrikenleiste und
eingerueckt sitzen. */ .mmu-ticker { /* Den Randabstand NICHT selbst erfinden, sondern den des Themes uebernehmen. Gemessen: Ein eigener Wert (clamp(1rem,4vw,2rem) = 32px) setzte den Inhalt 16px links neben den Kopfbereich, der bei 48px begann — sichtbar als Versatz zwischen Navigation und Liste. WordPress legt --wp--style--root--padding-right auf BODY ab, nicht auf :root. Deshalb steht die Zuweisung hier und nicht oben bei den Merkmalen: In :root ist die Variable nicht sichtbar, der Rueckfallwert haette immer gegriffen. */ --mmu-rand: var(--wp--style--root--padding-right, clamp(1rem, 4vw, 2rem)); max-width: calc(var(--mmu-rahmen) + 2 * var(--mmu-rand)); margin-inline: auto; padding-inline: var(--mmu-rand); box-sizing: border-box; } main[class^="mmu-"], main[class*=" mmu-"] { padding-block: var(--raum-6) var(--raum-7); } /* ------------------------------------------------------------------------- 2a. Die Grundgroesse gehoert dieser Seite, nicht dem Elterntheme ------------------------------------------------------------------------- Twenty Twenty-Five setzt `body { font-size: var(--wp--preset--font-size-- large); font-weight: 300 }`. Die GEERBTE Groesse war damit 22px, nicht die 16, gegen die die Skala unten gebaut ist. Alle rem-Werte stimmten trotzdem, weil rem an haengt (16px) — aber jedes Element OHNE gesetzte Groesse erbte 22px. Gemessen auf der Bandseite, bevor diese Regel stand: Bandname 34px Datenkartenwert 22px <- geerbt Konzertzeile 22px <- geerbt Kurzvorstellung 17px <- gesetzt (--t-prosa) Quellenangabe 14px Bezeichner 13px Der Lesetext war also KLEINER als die Metadaten daneben, und der Datenkarten-Bezeichner stand mit 13px neben einem 22px-Wert. Eine Skala, die nur fuer die Haelfte der Seite gilt, ist keine. font-weight ebenso: Der Body deklariert 300, ausgeliefert werden 400 und 600. Der Browser waehlt dann 400 — sichtbar richtig, aber nur zufaellig. Kaeme je eine 300er-Datei dazu, wuerde die ganze Seite duenner, ohne dass jemand etwas geaendert haette. */ main[class^="mmu-"], main[class*=" mmu-"], .mmu-kopf, /* 📏 Entwurf: 0.8125rem auf #a0a0a8. Gemessen waren 1rem in der Textfarbe -- der Fuss sprach damit so laut wie der Inhalt. Er traegt Rechtliches und einen Satz ueber fremde Server; beides darf leiser stehen. */ .mmu-fuss { font-size: 0.8125rem; font-weight: 400; color: var(--mmu-gedimmt); } /* ------------------------------------------------------------------------- 2b. Die zwei Blockseiten gehoeren dazu ------------------------------------------------------------------------- /ueber/ und /impressum/ laufen ueber Block-Vorlagen und tragen kein main.mmu-*. Die Regel darueber erreichte sie deshalb nicht, und weil die Navigation beide Typen nebeneinander auffuehrt, sprang beim Wechsel die halbe Seite. Vom Betreiber in der Bedienung bemerkt, am 12.08.2026 nachgemessen: /bands/ /ueber/ Kopfzeile 57 57 (stimmte schon) Inhalt beginnt 57 345 <- 288px Sprung Grundschrift 16px 22px <- geerbt von Twenty Twenty-Five Beide Haelften stammen aus dieser Arbeit: Die Grundgroesse wurde in Abschnitt 2a nur fuer die Plugin-Seiten geradegerueckt, und contentSize ging von 44rem auf 36rem — was die Blockseiten schmaler machte, ohne dass sie den 72rem-Rahmen der Plugin-Seiten bekommen haetten. Der Einzug: Das Blockthema zentriert die Inhaltsspalte per `margin-inline: auto`. Auf einer Seite, deren ganzes Raster an einer linken Registerkante haengt, ist zentrierter Text der Fremdkoerper — nicht umgekehrt. Deshalb linksbuendig statt zentriert, und die Lesespalte bleibt bei 36rem: Prosa darf schmaler laufen als eine Bandliste, das ist kein Widerspruch, sondern derselbe Wert wie in der Lesespalte der Bandseite. Ausgenommen bleibt, was der Site-Editor ausdruecklich anders ausrichtet (alignwide, alignfull, alignleft, alignright) — sonst braeche diese Regel jede spaetere Gestaltung im Editor. */ main.wp-block-group { /* Denselben Rahmen wie die Plugin-Seiten, sonst beginnt der Text bei 50px statt bei 57: Dort sorgt max-width plus margin:auto dafuer, dass der Inhalt mittig im Fenster sitzt und dadurch um wenige Pixel einrueckt. Ohne diese zwei Zeilen bliebe ein Restsprung von 7px gegen Kopf und Fuss — klein, aber genau die Art Unruhe, um die es hier geht. */ --mmu-rand: var(--wp--style--root--padding-right, clamp(1rem, 4vw, 2rem)); max-width: calc(var(--mmu-rahmen) + 2 * var(--mmu-rand)); margin-inline: auto; font-size: 1rem; font-weight: 400; } /* Die zentrierten Elemente sind NICHT die direkten Kinder von
. Der Aufbau der Blockseite ist dreistufig, und die mittleren Ebenen sind selbst alignfull: main.is-layout-constrained └─ div.wp-block-group.alignfull.has-global-padding ├─ h1.wp-block-post-title <- zentriert └─ div.entry-content.alignfull ├─ h2.wp-block-heading <- zentriert └─ p.wp-block-paragraph <- zentriert Ein Selektor, der nur am
ansetzt, trifft davon nichts — die direkten Kinder sind gerade die alignfull-Container, die ausgenommen gehoeren. Deshalb greift die Regel auf JEDEN begrenzten Container innerhalb von
, egal wie tief. Auf main beschraenkt, damit Kopf- und Fussbereich unberuehrt bleiben: Deren Gruppen sind ebenfalls is-layout-constrained, und dort ist die Zentrierung richtig. */ /* !important, und zwar nachgewiesen noetig, nicht vorsorglich: Ein margin-left:0 direkt am Element (inline, also staerker als jede Autorenregel) bewegte den Absatz NICHT — erst mit Vorrang sprang er an die linke Kante. Es existiert also eine !important-Regel im Blocklayout. In den auslesbaren Stylesheets ist sie nicht zu finden; document.styleSheets liefert sie nicht. Gegen eine unauffindbare Vorrangregel hilft nur Vorrang. Geprueft, dass es nichts anderes mitreisst: Kopf- und Fussbereich bleiben unveraendert bei 57px, kein waagerechter Ueberlauf. */ main.is-layout-constrained > :not(.alignwide):not(.alignfull):not(.alignleft):not(.alignright), main .is-layout-constrained > :not(.alignwide):not(.alignfull):not(.alignleft):not(.alignright) { margin-left: 0 !important; margin-right: auto !important; } /* ========================================================================= 2c. Der Zeitungskopf ========================================================================= Steht bei Abschnitt 2, weil er die OBERE KANTE desselben Rahmens ist: Er teilt die 72rem-Spalte und das Randmass der Regel oben, sonst saesse der Titel neben der Liste darunter statt ueber ihr. Zwei Haelften, und die Trennung ist keine Willkuer: .mmu-kopf Zeichen, Name, Unterzeile, Datumszeile — aus header.php, weil es gerechnete Angaben sind Rubrikenleiste die Navigation des Site-Editors, hier nur neu gestaltet — kein neues Menue Der Entwurf setzt den Namen als h1. Hier ist er ein Absatz: Jede Seite fuehrt bereits eine eigene h1 (Bandname, Archivtitel), und eine zweite auf 760 Seiten waere ein Rangfehler. Die Groesse macht die Gestaltung. */ .mmu-kopf { padding-top: 1.25rem; } /* Der Doppelstrich als erzeugter Inhalt, nicht als leeres
: 3px Linie, 4px Luft, 1px Linie. Er ist Zierde und hat im Markup nichts verloren. */ .mmu-kopf::before { content: ""; display: block; height: 4px; border-top: 3px solid var(--mmu-text); border-bottom: 1px solid var(--mmu-text); } .mmu-kopf-titel { display: flex; align-items: center; justify-content: center; gap: var(--raum-5); padding: 1.75rem 0 1.25rem; } /* Das Zeichen darf nicht schrumpfen, wenn der Name lang wird. */ .mmu-zeichen { flex: none; } .mmu-kopf-name { margin: 0; font-family: var(--schrift-titel); font-weight: 700; font-size: clamp(2.5rem, 7vw, 4.5rem); /* UnifrakturCook traegt hohe Oberlaengen. Ohne feste Zeilenhoehe reisst die Vorgabe des Browsers den Kopf bei 4.5rem sichtbar auseinander. */ line-height: 1.1; letter-spacing: 0.01em; color: var(--mmu-text); } /* Handoff v3: Serif KURSIV statt gesperrter Versalien. „München rockt und zwar gewaltig" ist ein Zuruf, kein Rubrikenetikett — die Versalien liessen ihn wie eine Beschriftung aussehen. 📏 Kontrast steigt dabei mit: --mmu-text auf dem Grund ergibt 17,16:1 statt der 8,09:1 von --mmu-gedimmt. Beides war AAA, aber die Zeile ist jetzt groesser und soll gelesen werden, nicht nur dastehen. ⚠️ Mit den Versalien faellt auch die Sperrung weg — und mit ihr der `text-indent`, der nur ihren Ueberhang hinter dem letzten Zeichen ausglich. Die Ausrichtung auf die Wortmarke weiter unten bleibt dagegen: Die haengt am Zeichen links, nicht an der Schrift. */ .mmu-kopf-unterzeile { margin: 0 0 0.9rem; text-align: center; font-family: var(--schrift-prosa); font-style: italic; font-size: clamp(1rem, 2.4vw, 1.25rem); color: var(--mmu-text); /* Ausrichtung auf die WORTMARKE, nicht auf die Seitenmitte (17.08.2026). .mmu-kopf-titel zentriert Zeichen UND Wortmarke als Gruppe. Die Mitte der Wortmarke liegt dadurch um die halbe Breite von Zeichen + Abstand rechts der Seitenmitte — die Unterzeile stand um genau diesen Betrag zu weit links, sichtbar als schiefer Kopf. Der Einzug halbiert sich: Er verkuerzt die Zeilenbreite am Anfang, die zentrierte Zeile rueckt danach um die HAELFTE nach rechts. Deshalb steht hier die volle Summe und nicht ihre Haelfte — dieselbe Rechnung, die schon hinter dem 0.22em darueber steckt. ⚠️ Die 64px sind kein freier Wert: Sie stehen in functions.php als mmu_zeichen_svg( 64 ). Wer die Zeichengroesse dort aendert, muss sie hier mitfuehren, sonst steht die Unterzeile wieder schief. */ padding-inline-start: calc(64px + var(--raum-5)); } /* Rechts aussen das Gebiet, wo eine Zeitung ihren Preis traegt. ⚠️ Bewusst OHNE Zahl: Die Mitte derselben Zeile zaehlt die Landkreise bereits (gemessen ueber die Taxonomie, mit hide_empty). Eine zweite Zahl rechts waere eine zweite Wahrheit — und sie veraltete bei der naechsten Gebietserweiterung still. Betreiberentscheidung 30.09.2026, Variante B. */ .mmu-kopf-gebiet { white-space: nowrap; } .mmu-kopf-daten { display: flex; justify-content: space-between; gap: var(--raum-4); padding: 0.4rem var(--raum-1); border-top: 1px solid var(--mmu-kante); border-bottom: 1px solid var(--mmu-kante); font-size: var(--t-klein); color: var(--mmu-gedimmt); } .mmu-kopf-bestand { text-align: center; } /* ------------------------------------------------------------------------- Der Logo-Tritt (Handoff v2, Interaktion 1) ------------------------------------------------------------------------- „Hover → Fuss hebt sich (translateY -8px, rotate -12deg, Feder). Klick → Stauchung (scaleY .82, 70ms), Kopfbereich ruckt 4px nach unten, an zufaelliger Stelle ein grosser Abdruck." Die Hebung steckt HIER und nicht im Skript: Sie braucht kein JavaScript, und eine Seite, deren Skript nicht laedt, soll trotzdem reagieren. Das Skript (assets/logo-tritt.js) macht nur, was CSS allein nicht kann — den Klick abfangen, den Abdruck setzen, danach navigieren. ⚠️ @media (hover: hover): Auf einem Touchgeraet gibt es kein Verlassen mit der Maus. Der zuletzt beruehrte Link bliebe im Hover-Zustand haengen, und das Logo stuende schief, bis man woanders hintippt. */ @media (hover: hover) { .mmu-kopf-link .mmu-zeichen { /* Die Feder aus dem Handoff: „cubic-bezier(.2,1.5,.4,1), leichtes Ueberschwingen". Der Fuss schnellt also ein Stueck ueber seine Endlage hinaus und faellt zurueck — das macht die Bewegung koerperlich statt mechanisch. */ transition: transform 320ms cubic-bezier(.2, 1.5, .4, 1); } .mmu-kopf-link:hover .mmu-zeichen { transform: translateY(-8px) rotate(-12deg); } } /* Die Tastaturbedienung bekommt dieselbe Hebung, und zwar AUSSERHALB der hover-Abfrage: Wer mit der Tabulatortaste auf dem Logo landet, soll sehen, dass es sich um dasselbe Element handelt — auch auf einem Touchgeraet mit angestecktem Keyboard, wo (hover: hover) nicht greift. */ .mmu-kopf-link:focus-visible .mmu-zeichen { transform: translateY(-8px) rotate(-12deg); transition: transform 320ms cubic-bezier(.2, 1.5, .4, 1); } /* Der Tritt selbst. transform-origin unten, sonst staucht der Fuss um seine Mitte und sieht aus, als schrumpfe er — er soll auf den Boden treten. */ .mmu-kopf-link.mmu-tritt .mmu-zeichen { transform: scaleY(0.82); transform-origin: 50% 100%; transition-duration: 70ms; } /* Der Ruck des Kopfes. 4px, wie im Handoff — genug, um den Aufschlag zu spueren, zu wenig, um den Satz zu verschieben. */ .mmu-kopf { transition: transform 90ms cubic-bezier(.2, 1.5, .4, 1); } .mmu-kopf.mmu-kopf-geruckt { transform: translateY(4px); } /* Der Abdruck. position: fixed und pointer-events: none — er liegt ueber der Seite, aber er faengt keinen Klick ab: Wer waehrend des Tritts auf einen Link zielt, soll ihn treffen und nicht den Abdruck. 🔴 Das Element ist rein dekorativ und traegt aria-hidden (im Skript). Es steht am Ende von , ausserhalb jeder Landmarke. */ .mmu-abdruck { position: fixed; z-index: 60; pointer-events: none; opacity: 0.2; fill: var(--mmu-text); transform: rotate(var(--mmu-abdruck-dreh, 0deg)) scale(1); /* Von 1.6 auf 1, wie der Handoff es zeichnet: Der Abdruck faellt auf die Seite, statt auf ihr zu wachsen. */ animation: mmu-abdruck-setzen 420ms cubic-bezier(.2, 1.5, .4, 1); } .mmu-abdruck-weg { opacity: 0; transition: opacity 400ms linear; } @keyframes mmu-abdruck-setzen { from { opacity: 0; transform: rotate(var(--mmu-abdruck-dreh, 0deg)) scale(1.6); } to { opacity: 0.2; transform: rotate(var(--mmu-abdruck-dreh, 0deg)) scale(1); } } /* ------------------------------------------------------------------------- Der Logo-Tritt, Stufen 1 bis 3 (Handoff v3) ------------------------------------------------------------------------- 1. Beim Laden laeuft eine Spur von Hufabdruecken ueber den Schirm. 2. Beim Klick springt der Huf brennend davon, schlaegt ein und brennt ein Loch in die Seite. 3. Danach schiebt ein Mensch einen Scheinwerfer ins Bild und wirft den Huf als Signal an den Himmel. ⚠️ Alles hier ist Zier und traegt aria-hidden (im Skript). Die Elemente stehen am Ende von , ausserhalb jeder Landmarke. */ /* Die Spur beim Laden: dieselbe Gestalt wie der einzelne Abdruck, nur etwas blasser — es sind viele auf einmal. */ .mmu-abdruck-spur { opacity: 0.16; } /* 🔴 Die Feuer-Leinwand liegt UEBER der Seite, aber UNTER dem Signal (z-index 79 gegen 75 … 80). Sie nimmt keine Klicks an und raeumt sich selbst weg, sobald kein Teilchen mehr lebt. */ .mmu-feuer { position: fixed; inset: 0; width: 100vw; height: 100vh; pointer-events: none; z-index: 79; } /* Der fliegende Huf. Der Schein um ihn herum sind drei gestaffelte Schlagschatten — innen gelb, aussen das Rot des Hauses. */ .mmu-huf-flug { position: fixed; left: 0; top: 0; pointer-events: none; z-index: 80; will-change: transform; } .mmu-huf-flug .mmu-zeichen { width: 100%; height: 100%; display: block; /* ⚠️ --mmu-text statt #fff: Das Stylesheet hat eine eigene Zusage gegen harte Farben aus der Gegenwelt, und sie hat zu Recht angeschlagen. Der Huf im Kopf erbt dieselbe Farbe — der fliegende soll derselbe sein. */ fill: var(--mmu-text); filter: drop-shadow(0 0 4px #ffb040) drop-shadow(0 0 14px #e0501a) drop-shadow(0 0 30px rgb(192 57 43 / 0.8)); } /* ⚠️ Waehrend der Huf fliegt, ist der im Kopf unsichtbar — sonst waere er zweimal da. `visibility` und nicht `display`: Der Platz bleibt stehen, und die Kopfzeile springt nicht. */ .mmu-kopf-link.mmu-huf-weg .mmu-zeichen { visibility: hidden; } /* Das eingebrannte Loch. Es liegt ABSOLUT (nicht fixed): Es gehoert zur Seite und soll mit ihr scrollen — ein Brandloch wandert nicht mit dem Blick. */ .mmu-brandloch { position: absolute; pointer-events: none; z-index: 30; } .mmu-brandloch .mmu-glutrand { filter: drop-shadow(0 0 7px #ff7a1a) drop-shadow(0 0 14px #c0392b); } /* ── Das Batsignal ───────────────────────────────────────────────────── */ .mmu-signal { position: fixed; inset: 0; pointer-events: none; z-index: 75; overflow: hidden; } /* 🔴 `screen`: Licht ADDIERT sich, es deckt nicht ab. Ohne das laege ein milchiges Dreieck ueber der Seite statt eines Strahls. */ .mmu-signal-strahl { position: absolute; inset: 0; opacity: 0; mix-blend-mode: screen; overflow: visible; } /* Die Signalscheibe am Himmel: ein Lichtkreis mit dem Huf als Schattenriss. Der Verlauf laeuft nach aussen ins Nichts, damit keine Kante entsteht. */ .mmu-signal-scheibe { position: absolute; left: 0; top: 0; opacity: 0; border-radius: 50%; background: radial-gradient(ellipse at center, rgb(255 248 220 / 0.96) 0%, rgb(255 238 178 / 0.9) 42%, rgb(255 214 130 / 0.5) 62%, rgb(255 190 90 / 0.12) 70%, rgb(255 190 90 / 0) 74%); display: flex; align-items: center; justify-content: center; will-change: transform, opacity; } /* ⚠️ Der Huf IM Signal ist schwarz, nicht weiss: Er ist der Schatten in der Lampe, nicht das Licht. Der leichte Weichzeichner nimmt ihm die Schaerfe, die eine Projektion ueber diese Entfernung nicht haette. */ .mmu-signal-huf { width: 46%; height: 56%; filter: blur(0.6px); opacity: 0.9; } /* 🔴 DIE GRUPPE IM SVG, nicht nur das SVG. Das Zeichen bringt sein eigenes fill-ATTRIBUT mit (filter.php: ``). Ein Praesentationsattribut verliert zwar gegen jede CSS-Regel — aber nur gegen eine, die DIESES Element trifft. Eine Regel am darueber nuetzt nichts: Die Gruppe erbt nicht, weil sie selbst etwas sagt. 📏 Gemessen: auf rgb(0,0,0), die Pfade darin auf rgb(232,232,234). Der Huf stand hell im hellen Licht und war kaum zu sehen. 🎯 Schwarz, nicht gedimmt: Er ist der Schatten IN der Lampe. Je dunkler, desto klarer hebt er sich vom Lichtkreis ab. */ .mmu-signal-huf g, .mmu-signal-huf path { fill: #000; } .mmu-signal-trupp { position: absolute; left: 0; bottom: 0; overflow: visible; } /* ⚠️ Der Ausschalter, und er gehoert zu jeder Bewegung dieser Seite: „prefers-reduced-motion: reduce → Wackeln, Umblaettern, Abriss- und Stempelanimation aus" (Handoff v2). Das Skript meldet sich dann gar nicht erst an; diese Regeln fangen den Rest — den reinen Hover-Effekt, der ohne Skript auskommt. Beide Haelften sind noetig: Ein Skript, das schweigt, nimmt die CSS-Bewegung nicht mit. */ @media (prefers-reduced-motion: reduce) { .mmu-kopf-link .mmu-zeichen, .mmu-kopf-link:hover .mmu-zeichen, .mmu-kopf-link:focus-visible .mmu-zeichen, .mmu-kopf-link.mmu-tritt .mmu-zeichen, .mmu-kopf, .mmu-kopf.mmu-kopf-geruckt { transform: none; transition: none; } .mmu-abdruck { display: none; } } /* ------------------------------------------------------------------------- Die Rubrikenleiste ------------------------------------------------------------------------- Gestaltet wird, was der Site-Editor liefert. Der Zugriff laeuft ueber :has(> .wp-block-site-title), weil der Vorlagenteil KEINE eigene Klasse traegt — gemessen am 17.08.2026 rendert er als blosses div.wp-block-group.alignfull, und darauf lassen sich Regeln nicht verlaesslich haengen. Der Seitentitel dagegen hat eine stabile Blockklasse und steht genau einmal im Dokument. */ .wp-block-group:has(> .wp-block-site-title) { justify-content: center; border-bottom: 3px double var(--mmu-kante); /* !important, und nachgewiesen noetig: Der Vorlagenteil setzt die Innenabstaende ALS INLINE-STIL (padding-top/-bottom aus spacing|30). Inline schlaegt jeden Selektor; ohne Vorrang bliebe die Leiste rund dreimal so hoch wie der Entwurf sie zeichnet. */ padding-block: 0.35rem !important; } /* Der Name steht schon gross im Kopf darueber. Ein zweites Mal klein daneben waere eine Dopplung — aber nur DORT, wo der Kopf tatsaechlich steht: Auf einer Blockseite ohne [mmu_kopf] bliebe sonst eine Seite voellig ohne Namen. Die Regel loest sich von selbst auf, sobald der Vorlagenteil den Shortcode traegt. */ body:has(.mmu-kopf) .wp-block-site-title { display: none; } /* ⚠️ Der lange Selektor ist gemessen, nicht vorsorglich. WordPress liefert fuer den Navigationsblock diese Regel aus: .wp-block-navigation .wp-block-navigation-item__content.wp-block- navigation-item__content { color: inherit } Die Klasse steht ZWEIMAL darin — der Kern erhoeht damit absichtlich auf 0-3-0, um Themes zu ueberstimmen. Der kurze Selektor (0-2-0) verlor dagegen, und der Link erbte die Farbe des Vorlagenteils: gemessen am 17.08.2026 stand die inaktive Rubrik auf rgb(232,232,234) statt gedimmt, und die AKTIVE trug dieselbe Farbe wie die uebrigen — die Leiste sagte also nicht, wo man ist. Statt !important hier die echte Struktur als Selektor: nav > li > a ergibt 0-3-3 und gewinnt unabhaengig von der Ladereihenfolge. !important waere der kuerzere Weg und der schlechtere — es gaebe der naechsten Regel keinen Ausweg mehr. */ /* 🔴 DER MESSRAHMEN FÜR DIE SCHRIFTGRÖSSE DER LEISTE. Ohne diese eine Zeile ist `cqi` weiter unten ungültig, und die Leiste bleibt klein. ⚠️ UND SIE DARF NIRGENDS SONST STEHEN. `container-type: inline-size` setzt `contain: inline-size`: Der Inhalt trägt dann nicht mehr zur Breite bei. Fünf Ebenen weiter innen wurde das am 03.10.2026 gemessen, und alle fünf fielen auf 0 px (Nullprobe im selben Lauf: 1024 px): __responsive-container-content 1024 → 0 __responsive-dialog 1024 → 0 __responsive-close 1024 → 0 __responsive-container 1024 → 0 nav.wp-block-navigation 1024 → 0 Der Grund ist die Regel weiter oben, die `min-width: 0` an genau diese Kette schreibt — erlaubt zu schrumpfen UND kein Inhaltsbeitrag ergibt 0. `width: 100%` und `flex: 1 1 100%` heilen es NICHT, beides geprüft. Die alignwide-Hülle steht als einzige nicht in jener Kette. 🔵 Warum `cqi` und nicht `vw`: Die Hülle wächst mit dem Fenster nur bis 1152px und steht dann still. Ihr Anteil am Fenster fällt dabei von 0,900 auf 0,641 (gemessen bei 620 bis 1600px) — eine Schriftgröße in `vw` trifft deshalb entweder die schmalen oder die breiten Fenster, nie beide. `cqi` misst den Platz, den es wirklich gibt. */ .wp-block-group.alignwide:has(nav.wp-block-navigation) { container-type: inline-size; } nav.wp-block-navigation li.wp-block-navigation-item > a.wp-block-navigation-item__content { display: flex; align-items: center; /* 40px Trefferflaeche, wie jede Bedienflaeche dieser Seite. */ min-height: 40px; /* 🔴 `em`, NICHT `rem` — und das ist der Kern, nicht Feinschliff. Ein festes Polster verschiebt sich gegen eine mitwachsende Schrift: Mit `0.45rem` traf ein einzelner cqi-Wert nur eine Fensterbreite und war bei den anderen zu gross. Gemessen am 03.10.2026, Füllung der Zeile: Fenster 1366 1024 880 760 rem (fest) 99,6 % 102,3 % 104,4 % 106,4 % ← rollt em (mitwachsend) 98,5 % 98,5 % 98,5 % 98,9 % Mit `em` ist die ganze Leiste ein Vielfaches der Schriftgrösse, und das Verhältnis bleibt über jede Breite dasselbe. */ padding-inline: 0.3em; font-family: var(--schrift-ui); /* 🔴 DIE LEISTE FÜLLT DIE ZEILE AUS — Betreiberanweisung vom 03.10.2026 („so groß dass die gesamte Zeile ausgefüllt wird und bündig abschließt"). Vorher stand hier `var(--t-neben)` (14px) fest. Gemessen füllte die Leiste damit bei 1366px nur 77,3 % der Zeile — und bei 1024px rollte sie trotzdem, weil der Platz in die Lücken ging statt in die Wörter. 🔵 Die Untergrenze IST `--t-neben`, nicht nur zufällig gleich: Unter etwa 760px Fensterbreite reicht die Zeile nicht mehr für acht Rubriken, und dann rollt die Leiste weiter (Betreiberentscheidung vom 01.10.2026, Regel weiter unten). Die Schrift dort mitschrumpfen zu lassen hätte das Rollen abgeschafft und die Leiste unlesbar gemacht — bei 620px wären es 10,8px gewesen. ⚠️ Die Obergrenze 1.6rem wird im Normalfall NIE erreicht: Bei der gedeckelten Hülle von 1152px ergibt 2.04cqi 23,5px, also 1,47rem. Sie ist das Netz für den Fall, dass `:has()` oder die Containerabfrage fehlen — dann fällt `cqi` auf das Fenster zurück und würde sonst über die Zeile hinauswachsen. 📏 Füllung der Zeile, gemessen am 03.10.2026 (Nullprobe im selben Lauf, dieselbe Messung ohne die Regel): Fenster Hülle Schrift neu vorher 1600px 1152 23,5px 98,5 % 77,3 % 1366px 1152 23,5px 98,5 % 77,3 % 1024px 909 18,5px 98,5 % 98,0 % (rollte) 880px 777 15,9px 98,5 % 114,6 % (rollte) 760px 684 14,0px 98,9 % 130,2 % (rollte) 620px 558 14,0px 121,2 % 159,6 % (rollt weiter) Kopfhöhe (54px), Trefferfläche (40px) und Seitenfluss blieben in jeder Zeile unverändert. */ font-size: clamp(var(--t-neben), 2.04cqi, 1.6rem); /* ⚠️ 600 UND NICHT 700, obwohl der Betreiber am 03.10.2026 „in fetter Schrift" verlangt hat. Der Schnitt ist nicht da: theme.json lädt für IBM Plex Sans genau 400, 400 italic und 600 — eine Bold-Datei gibt es weder im Theme noch im Entwurfsordner (gesucht). `font-weight: 700` wäre deshalb wirkungslos und nicht bloss ungenau: Gemessen ergaben 400/600/700/800 die Textbreiten 875/891/891/891px — ab 600 ändert sich nichts mehr, der Browser nimmt 600 und synthetisiert nicht. Eine Regel, die nichts tut, sieht beim nächsten Lesen wie eine erfüllte Anweisung aus. 🔵 ENTSCHEIDUNG DES BETREIBERS vom 03.10.2026: bei 600 bleiben. Zur Wahl stand, IBM Plex Sans Bold (OFL) zu beschaffen, auf den Zeichenvorrat zu kürzen und in theme.json einzubinden — rund 30 bis 40 KB mehr beim ersten Aufruf. Abgelehnt; die Leiste wirkt durch die um 68 % gewachsene Schrift ohnehin deutlich kräftiger. ⚠️ Das Fehlen von „fett" ist damit KEIN offener Punkt mehr. Wer hier eine Bold-Datei nachrüstet, hebt eine Betreiberentscheidung auf. */ font-weight: 600; letter-spacing: 0.14em; text-transform: uppercase; color: var(--mmu-gedimmt); text-decoration: none; } nav.wp-block-navigation li.wp-block-navigation-item > a.wp-block-navigation-item__content:hover { color: var(--mmu-text); } /* Die aktive Rubrik traegt die HELLERE Akzentfarbe. #c0392b laege bei 3,86:1 und damit unter den 4,5:1, die WCAG 1.4.3 fuer Text verlangt — ausgerechnet an dem Wort, das den Ort angibt. */ nav.wp-block-navigation li.wp-block-navigation-item > a[aria-current="page"] { color: var(--mmu-akzent-text); } /* Auf schmalen Geraeten QUERSCROLLEN statt umbrechen (Handoff v3). Mit acht Rubriken brach die Leiste sonst auf zwei, auf sehr schmalen Geraeten auf drei Zeilen um — der Kopf wuchs dadurch auf Kosten des Inhalts, und eine zweizeilige Rubrikenleiste liest sich nicht mehr als eine Reihe. 🔴 `safe center` und nicht `center` — das ist der Kern und kein Feinschliff. Bei `justify-content: center` zentriert der Browser den Inhalt AUCH dann, wenn er breiter ist als der Kasten: Der Ueberhang verteilt sich auf beide Seiten, und was links hinausragt, liegt vor dem Scrollanfang. Es ist dann durch Scrollen NICHT erreichbar — die erste Rubrik („Start") waere auf schmalen Geraeten unerreichbar gewesen. `safe` faellt bei Ueberlauf auf flex-start zurueck und gibt genau diesen Fall frei. ⚠️ `flex: none` an den Eintraegen muss dazu: Flex-Kinder schrumpfen sonst unter ihre Inhaltsbreite, statt einen Ueberlauf zu erzeugen — es gaebe nichts zu scrollen, die Woerter wuerden nur enger. */ /* 🔴 KEIN `>` — die Regel hat bis zum 01.10.2026 NICHTS getan. WordPress schiebt zwischen