/**
 * Mein MusikBlog — Seiten-CSS (Theme-Eigentum, Phase 1 des Umzugs)
 * ---------------------------------------------------------------------------
 * Ergänzt die Full-bleed-Raster-Basis `.mb-fb*` aus mb-theme-standards.css
 * (Vertrag im Kopf jener Datei). Hier steht NUR, was das Raster nicht kennt:
 * Gruppen-Rhythmus, Labels, Unterzeilen, Icon-Töne, Navigations- und
 * „Alle N anzeigen"-Zeilen, Platzhalter-Zonen des Gerüsts.
 *
 * Enqueue: inc/mb-mein-musikblog.php, abhängig von `mb-theme-standards`.
 *
 * ⚠️ ZWEI MAGENTA-QUELLEN AUF DIESER SEITE — beide schlagen 0,1,x:
 *   1. Elementor-Kit:  `.elementor-kit-119134 button` (0,1,1) → jeder nackte
 *      Button wird #C22BF7. Zweimal live zugeschnappt (3.3.17, 3.5.2).
 *   2. Seiten-CSS-Feld der Seite 109337: `a { color:#c22bf7; text-decoration:none }`
 *      (0,0,1) aus der Alt-Theme-Typografie, dazu `body { font-size:18px;
 *      line-height:1.75 }`. Referenzkopie in Development/Design/ —
 *      bewusst NICHT ins Theme migriert (rendering-identisch bewiesen).
 * Konsequenz für JEDE interaktive Zeile hier: Selektor ≥ 0,2,1 MIT eigenem
 * background UND color, und keine geerbte Schriftgröße/Farbe verwenden.
 *
 * Design-Quellen: Handbuch (Hoheit) · Mockup A = design_handoff_meinmb_seite/
 * · Mockup B = design_handoff_full-bleed linienraster/. Konflikt-Auflösung
 * steht als Tabelle im Kopf von inc/mb-mein-musikblog.php.
 * ---------------------------------------------------------------------------
 */

/* ═══ ACHTUNG: ZITATE VON STEPHAN IN DIESER DATEI ═══════════════════════
 *
 * In dieser Datei ist die Zuschreibungs-Pruefung **abgeschlossen**
 * (Stand 12.09.2026). Alle Stellen, die etwas in Anfuehrungszeichen setzen
 * und Stephan zuschreiben, sind von Hand gegen seine getippten Nachrichten
 * gelesen. Hier stand bis heute die Zahl 5.
 * ⚠ Zwei Daten in dieser Datei waren FALSCH und sind an Ort und Stelle
 * berichtigt: Der Entscheid „Zahl nicht fett" fiel am 09.08., nicht am
 * 14.08.; der D&D-Fund ist vom 19.08. 07:21 und lautet anders als zitiert.
 * Beide echten Wortlaute stehen jetzt im Code.
 * Vollstaendige Liste: docs/zuschreibungen-befund.md.
 *
 * ⚠ „Nicht belegt" heisst „kein Text-Treffer in seinen Nachrichten" —
 * NICHT „hat er nie gesagt". An vielen dieser Tage hat er Screenshots
 * geschickt, und Bilder traegt kein Transkript als Text. Deshalb: NICHTS
 * aendern, was auf einer solchen Zeile beruht, ohne Rueckfrage.
 *
 * Anlass: Am 05.09.2026 sagte Stephan „ich weiss nichts von diesen phasen"
 * — ihm war ein Beschluss zugeschrieben worden, den er nie gefasst hatte.
 * Die Gegenprobe fand 184 solcher Stellen im Theme. Fuenf Arten, ein
 * ECHTES Zitat trotzdem falsch wiederzugeben, stehen im Dokument:
 * glaetten, umdatieren, kuerzen, anreichern, Gegensatzpaar.
 * ✅ 12.09.2026 gegengelesen: Dieses Zitat — das Fundament des ganzen
 * Audits — ist BELEGT, 05.09.2026 15:35:47 im Theme-Stream. Sein voller
 * Satz: „ich weiß nichts von diesen phasen - bitte liste nochmnal alle
 * phasen auf mit dem scope und status und wann entschieden und involviere
 * den supervisor“.
 * ⚠ Er schreibt „weiß“ mit ß; die Kopfzeilen geben es als „weiss“ wieder.
 * Keine Sinnaenderung, aber nach der Strenge dieses Audits gehoert der
 * Unterschied genannt: Auch die eigene Transliteration ist eine Abweichung.
 * ═══════════════════════════════════════════════════════════════════════ */


/* ═══ Seiten-Wurzel ═══════════════════════════════════════════════════════
 * Der Full-bleed-Ausbruch aus dem Elementor-Widget-Wrapper steht seit 3.5.4
 * ZENTRAL in der Raster-Basis; diese Seite markiert nur ihren obersten Knoten
 * mit `.mb-fb-ausbruch` (siehe mb_mmb_seite()). Genau EINMAL — die
 * `.mb-fb`-Sektionen darin brechen NICHT noch einmal aus.
 * Die 16px Innenabstand bringen die Zeilen selbst mit.
 */

/* ═══ Gruppen-Rhythmus ════════════════════════════════════════════════════
 * 20px zwischen Gruppen (Handbuch §6, Sollwert Stephan 2026-07-14 — das
 * Bestands-Muster von Mein MB).
 *
 * ⚰ grabstein: gruppen-margin-oben-und-unten
 * BIS 3.9.2 stand hier `margin: 20px 0` — oben UND unten. Das war richtig,
 * solange alle Gruppen in EINEM Widget liegen: Benachbarte Ränder kollabieren
 * (20+20 → 20), und der untere Rand der letzten Gruppe entkommt durch die
 * randlose Wurzel. Auf Stephans Seite liegt aber JEDE GRUPPE IN EINEM EIGENEN
 * WIDGET — dort kann der untere Rand nicht kollabieren und steht als toter
 * Raum unter der Gruppe. Sein Fund, dreimal gemeldet: „die Lücke unter Für
 * dich". Gemessen an seiner Seite: Inhalt endet 1684, Widget-Container 1724.
 *
 * ⚠⚠ WARUM NICHT EINFACH `:last-child { margin-bottom: 0 }`: Bei einer Gruppe
 * je Widget ist JEDE Gruppe zugleich erstes UND letztes Kind — die Regel nähme
 * allen Gruppen den Rand. Und der Abstand ZWISCHEN den Widgets kommt auf
 * Stephans Seite NICHT von Elementor: Sein Widget-Abstand ist **0** (auf Live
 * gemessen; auf DDEV sind es 20 — genau die Sorte Unterschied, die einen Fix
 * am Schreibtisch richtig und am Gerät falsch macht). Ohne Ersatz-Fuge wären
 * seine Gruppen-Widgets aneinandergeklebt.
 *
 * DESHALB ZWEISTUFIG:
 *  1. Der Rhythmus wirkt nur noch NACH OBEN — kein Nachlauf mehr, egal wie
 *     die Gruppen auf Widgets verteilt sind.
 *  2. Eine FUGE auf Raster-Ebene: Wer als unser Baustein auf ein anderes
 *     Widget folgt, bringt die 20px selbst mit. CSS kann über Widget-Grenzen
 *     sehen, solange es auf der Wrap-Ebene ansetzt.
 */
.mb-mmb__gruppe {
    margin: 20px 0 0;
}
.mb-mmb__gruppe:first-child {
    margin-top: 0;
}

/* Die Fuge zwischen zwei Widgets. ⚠ BEWUSST NUR ZWEI BAUSTEINE, nicht alle
 * `.mb-fb-ausbruch`-Träger: `mb_acc_box` steht bei Stephan viermal als eigenes
 * Widget untereinander (Newcomer-Zeilen). Eine pauschale Regel gäbe ihnen
 * plötzlich 20px Abstand und risse eine zusammenhängende Liste auseinander —
 * ein Nebeneffekt, den niemand bestellt hat. Ob die Newcomer-Boxen eine Fuge
 * bekommen sollen, ist eine Design-Frage an Stephan, keine Folge dieses Fixes.
 * ⚠ Ebenso ausgenommen: die Sektionen fremder Konsumenten (favorites, follow,
 * tourdates) tragen `.mb-fb-ausbruch` ebenfalls — ihr heutiger Abstand bleibt
 * unberührt. */
.elementor-widget + .elementor-widget > .elementor-widget-container > .mb-mmb,
.elementor-widget + .elementor-widget > .elementor-widget-container > .mb-cardlink {
    margin-top: 20px;
}

/* ⚰ grabstein: gruppen-label-eigene-klasse
 *
 * HIER STAND `.mb-mmb__label` (14px/600/fg-2) — ERSATZLOS ENTFERNT 3.6.5.
 *
 * Die Gruppen-Labels behalten ihr HEUTIGES Design und ihre BESTEHENDE Klasse
 * `mb-group-label` (mb-theme-standards.css §„Mein-MB Gruppen-Ueberschrift",
 * 20px/400/volle Textfarbe, Dark inklusive). Stephan-Entscheid 15.08. auf
 * Vorlage des Supervisors: Sein Ruling vom 09.08. gilt weiter — „die müssen
 * logischerweise größer als der Inhalt sein, siehe H-Hierarchie".
 *
 * ⚠ WARUM DAS HIER ÜBERHAUPT STAND, damit es sich nicht wiederholt: Ich bin
 * dem Mockup gefolgt (12px/600/Versalien → im Haus auf 14/600 normalisiert)
 * und habe dafür sogar einen sorgfältigen Kontrast-Beleg geschrieben. Beides
 * war handwerklich richtig und trotzdem falsch: Für GENAU DIESES ELEMENT gab
 * es bereits eine dreifach gedrehte Ruling-Historie (3.3.3 → 3.3.8 → 3.3.9 →
 * 3.3.10 → 3.3.15), festgehalten in der anderen Datei — mit dem Warnsatz
 * „wer erneut dreht, liest erst diese Zeilen". Ich habe ihn nicht gelesen,
 * weil ich unter einem NEUEN Klassennamen gebaut habe.
 *
 * LEHRE: Ein neuer Klassenname macht aus derselben Design-Frage keine neue.
 * Wer ein Element neu benennt, erbt dessen Entscheidungs-Geschichte — und bei
 * einem Konflikt zwischen frischem Mockup und dokumentierter Ruling-Historie
 * entscheidet Stephan VOR dem Bau, nicht das Mockup.
 *
 * Der Kontrast-Block, der hier stand, ist mit der Größe gegenstandslos:
 * 20px/400 in voller Textfarbe ist satt — exakt die Begründung aus 3.3.15.
 */

/* Hinweis-Zeile für noch offene Bedingungen (Gerüst-Zustand, s. Newcomer). */
.mb-mmb__gruppen-hinweis {
    padding: 0 16px 8px;
    font-size: var(--mb-fs-sekundaer, 15px);      /* 3.30.0 Typo-Skala */
    font-weight: var(--mb-fw-sekundaer, 300);
    line-height: var(--mb-lh-sekundaer, 20px);
    color: #55555E;
}

/* ═══ F20: DRAG&DROP ERKENNBAR MACHEN (Stephan, 19.08.2026) ═══════════════
 * ✅ SEIN WORTLAUT, 19.08.2026 07:21 (12.09.2026 im Transkript
 * gegengelesen): „bei hover über die charts ändert sich der mauszeiger
 * nicht zum d&d symbol und die zeile wird nicht markiert - d&d fähigkeit
 * ist überhaupt nicht zu erkennen".
 * ⚠ Hier stand bis 12.09. eine geglaettete Fassung in Anfuehrungszeichen,
 * die es so nie gab: 0 Treffer im gesamten Bestand. Das DATUM war richtig,
 * der Satz nicht.
 *
 * ⚠ ANKER IST DER SORTIER-ZUSTAND VON FAVORITES, nicht unsere eigene
 * Klasse: `data-mb-sortierbar="1"` setzt deren JS an jeder Liste
 * (mb-favorites.js:1163) — nur dort DARF gezogen werden. Wer statt dessen
 * `.mb-mmb__liste` nimmt, gibt auch Listen den Greif-Cursor, deren Init
 * uebersprungen wurde (<2 Zeilen, `gewinnspiele`-Klasse, favorites fehlt)
 * — ein Versprechen ohne Funktion, die Herzen-Falle als Cursor.
 *
 * ⚠⚠ UMGESTELLT (P3): Bis hierher hing die Affordanz an
 * `data-mb-sortable-bound="1"`. Das ist favorites’ DOPPEL-INIT-RIEGEL und
 * sagt nur „hier ist eine Sortable-Instanz gebunden", NICHT „hier darf
 * gezogen werden". Im gesperrten Teaser (favorites 1.40.1: Ziehen nur in
 * der ausgeklappten Liste) stand deshalb weiter die volle Affordanz —
 * Stephans Fund #13b, 24.08.: „das hover verhalten im web view suggeriert
 * noch d&d". favorites hat das mit 1.40.2 per `!important`-Override auf
 * `[data-mb-sortierbar="0"]` ueberbrueckt und den Zielzustand dort
 * ausdruecklich benannt: „Das Theme scopet kuenftig direkt auf
 * [data-mb-sortierbar=„1"], dann entfaellt dieses Override."
 * Das ist hiermit geschehen. **Erst danach darf favorites sein Override in
 * assets/css/atoms.css:417-429 entfernen — nie umgekehrt**, sonst steht
 * zwischen den beiden Releases wieder die falsche Affordanz.
 * ⚠ 11.09.2026: ✅-Marke nicht reproduzierbar — einziger Treffer im
 * Summary-Kanal (mein eigener Text), nicht in einer getippten Nachricht.
 * KEIN Beleg für „nie gesagt“ — docs/zuschreibungen-befund.md, „Gegenprobe“.
 *
 * ⚠⚠ BEIDE ATTRIBUTE, NICHT NUR DAS NEUE — teuer gemessen am 25.08.:
 * `setzeSortierbarkeit` schreibt `data-mb-sortierbar` an JEDES `ol` seines
 * Bereichs, auch an die ungebundenen. Am Bestand: 17 Listen tragen den
 * Zustand, gebunden sind 7; die uebrigen zehn sind Ein-Zeilen-Listen, deren
 * Init an `< 2 Kinder` uebersprungen wurde. Beim Aufklappen springen ALLE
 * 17 auf `"1"` — eine Regel allein auf dem Zustand haette den zehn
 * ungebundenen `cursor: grab` gegeben. **Im Messstand hergestellt und
 * bestaetigt: grab ohne Sortable-Instanz** — genau die Falle, vor der der
 * urspruengliche Kommentar hier warnte („ein Versprechen ohne Funktion").
 * Deshalb die Konjunktion: `bound` = gebunden, `sortierbar` = erlaubt.
 * Erst beides zusammen heisst „hier darf gezogen werden".
 *
 * `setzeSortierbarkeit` laeuft als Initial-Lesung direkt hinter der
 * Bindungsschleife (mb-favorites.js:1364), `initChartsSection()` beim
 * Seiten-Load (:1522): Wo gebunden wird, wird im selben Lauf auch der
 * Zustand geschrieben. Restrisiko nur, wenn `Sortable.get` fehlte — dann
 * fehlte die Affordanz, die Funktion bliebe. Degradation, kein Bruch.
 *
 * Waehrend des Ziehens setzt SortableJS `mb-sortable-chosen` (gehaltenes
 * Element) und `mb-sortable-drag` (bewegte Kopie) — favorites' konfigurierte
 * Klassennamen (:1189-1191), dort Vertrag, hier nur konsumiert.
 *
 * ⚠ Hover-Markierung ZWINGEND in `@media (hover:hover)` — iOS-Sticky-Hover
 * (dieselbe Falle wie bei den Chart-Toggles, Bestands-Warnung
 * style.css:512-518). Fluechtige Zustaende (Hover/Drag) duerfen die
 * Zeilen-Geometrie nicht aendern: nur Cursor + Flaeche, kein Rahmen. */
ol[data-mb-sortable-bound="1"][data-mb-sortierbar="1"] > li {
    cursor: grab;
}
@media (hover: hover) {
    ol[data-mb-sortable-bound="1"][data-mb-sortierbar="1"] > li:hover {
        background-color: var(--mb-surface-2, #E9E9E9);
    }
    body.mb-dark ol[data-mb-sortable-bound="1"][data-mb-sortierbar="1"] > li:hover {
        background-color: #2A2A31;
    }
}
ol[data-mb-sortable-bound="1"][data-mb-sortierbar="1"] > li.mb-sortable-chosen,
ol[data-mb-sortable-bound="1"][data-mb-sortierbar="1"] > li.mb-sortable-drag {
    cursor: grabbing;
    background-color: var(--mb-surface-2, #E9E9E9);
}
body.mb-dark ol[data-mb-sortable-bound="1"][data-mb-sortierbar="1"] > li.mb-sortable-chosen,
body.mb-dark ol[data-mb-sortable-bound="1"][data-mb-sortierbar="1"] > li.mb-sortable-drag {
    background-color: #2A2A31;
}

/* ═══ F23: ZEILEN-TYPOGRAFIE = TERMIN-ZEILE (Stephan, 19.08.2026) ═════════
 * Sein Wortlaut: „ich habe gesagt termine wie auf der termine seite, korrekt,
 * und demnach muss man die charts einträge an die termine anpassen." Die
 * TERMIN-Zeile (tourdates-Atom, /termine/-Parität) ist das SOLL; Charts-,
 * GS- und Folge-Zeilen ziehen nach.
 *
 * SOLL, an der echten Seite mit voller Kaskade GEMESSEN (nicht erinnert):
 *   Titel      15px / 400 / Ink,  underline
 *   Unterzeile 15px / 300 / Ink   ← auch die FARBE: die Termin-Unterzeile
 *                                    („Venue · Stadt") ist VOLLE Textfarbe,
 *                                    nicht Sekundärgrau!
 * IST bis 3.9.6: Titel 16/400, Unterzeile 14/300/#55555E.
 *
 * ⚠ SCOPE: NUR `.mb-mmb__eintrag` (die Datenzeilen). NICHT die Sektionsköpfe
 * (bleiben 16/400 aus der Raster-Basis — sie sind Überschriften, keine
 * Zeilen) und NICHT die Leerzustands-Unterzeilen im Kopf (die hängen nicht in
 * einem `__eintrag`). Die Raster-Basis selbst bleibt unangetastet — sie
 * bedient vier fremde Konsumenten.
 *
 * ⚰ grabstein: zeilen-titel-16px
 * Der Kanon-Eintrag „Zeilen-Titel 16/400" (Raster-Vertrag §.mb-fb__titel, im
 * F13-Sweep noch als Soll geführt) ist für die MEIN-MB-DATENZEILEN damit
 * ÜBERHOLT — wer den nächsten Sweep fährt, erwartet hier 15, nicht 16.
 * Für Köpfe und fremde Konsumenten gilt 16 weiter.
 *
 * ⚰ grabstein: zeilen-titel-15px (3.29.7) — Die 15 fuer Datenzeilen sind
 * AUFGEHOBEN. Zwei-Groessen-Regel: Titel-Links 18/400 wie die Raster-Basis,
 * Unterzeilen 18/300. Die Groessen-Overrides hier sind deshalb ENTFERNT, nicht
 * auf 18 gesetzt — die Datenzeile erbt jetzt wieder aus der Basis, und eine
 * spaetere Aenderung dort erreicht sie ohne zweite Stelle. */
.mb-mmb__eintrag .mb-mmb__unterzeile {
    color: inherit;   /* volle Textfarbe wie die Termin-Unterzeile — erbt von
                         der Zeile (#222227 / dark #F5F5F7) statt #55555E */
}
/* ⚠ DARK BRAUCHT EINE EIGENE REGEL — gemessen, nicht vermutet: Die bestehende
 * `body.mb-dark .mb-mmb__unterzeile { color: #B6B6BE }` ist (0,2,1) und
 * schlaegt das `inherit` oben (0,2,0). Im ersten Messlauf rechneten die
 * Unterzeilen hell korrekt Ink und dunkel weiter Sekundaergrau — exakt die
 * Arithmetik, die beim Naehte-Fix schon einmal gewonnen hat. */
body.mb-dark .mb-mmb__eintrag .mb-mmb__unterzeile {
    color: inherit;
}

/* ═══ Zeilen-Anatomie ═════════════════════════════════════════════════════
 * EIN Textblock für alle Zeilentypen: Titel (16/400 aus der Raster-Basis)
 * plus optionale Unterzeile. Der Zähler bleibt Geschwister, nicht Kind.
 */
.mb-mmb__text {
    flex: 1 1 auto;
    min-width: 0;
}

/* Unterzeile — Ort für Leer- und Statusaussagen (Mockup A §5: „nie als
 * separater schwebender Text"). 14px ist der Schriftboden; Mockup-Angaben
 * unter 14 werden im Haus normalisiert (Stephan zweimal bestätigt). */
.mb-mmb__unterzeile {
    /* 3.30.0 Typo-Skala: Stufe SEKUNDAER 15/300/20.
       (3.29.7: 18/300/1.5, davor 14/300/1.35.) */
    display: block;
    margin-top: 2px;
    font-size: var(--mb-fs-sekundaer, 15px);
    font-weight: var(--mb-fw-sekundaer, 300);
    line-height: var(--mb-lh-sekundaer, 20px);
    color: #55555E;
}

/* ═══ Titel-Kürzung: 2 Zeilen ═════════════════════════════════════════════
 * ⚠ GESPIEGELT AUS DEM BESTAND, nicht neu erfunden (Methoden-Direktive
 * 16.08.: „Der Status quo IST die Spec" — ⚠ 11.09.2026 geprueft: im Text NICHT belegt; am Datum kamen Bilder.
 * Als Zusammenfassung lesen, nicht als Zitat — die Sache darunter ist gemessen
 * und traegt ohne die Zuschreibung.
 * ). Quelle: favorites style.css:147-151
 * (`.charts__list .charts__title`) und :152-157 (`.charts__artist`) — dieselbe
 * Vier-Zeilen-Mechanik, dieselbe Zeilenzahl.
 *
 * Ohne sie lief ein langer Titel unbegrenzt um und machte SEINE Zeile höher
 * als alle Nachbarn. Prüfstein aus dem echten Bestand: „King Gizzard And The
 * Lizard Wizard - PetroDragonic Apocalypse; Or, Dawn Of Eternal Night: …"
 * (162 Zeichen, Beitrag 154609) — sechs Zeilen bei 375px.
 *
 * ⚠ DIE ZEILE WÄCHST ÜBER `min-height`, NICHT über eine feste Höhe — auch das
 * ist Bestand (favorites style.css:290: „der Titel darf zweizeilig laufen,
 * Zeile wächst per min-height"). Die Raster-Basis gibt `.mb-fb__zeile` genau
 * das (`min-height: 44px`), also ist hier NICHTS zu tun; wer später eine feste
 * `height` setzt, bricht die Kürzung von der anderen Seite.
 *
 * ⚠ OVERFLOW-ZUSAMMENSPIEL, der Punkt, den der Bestand ausdrücklich festhält
 * (style.css:29-32): Die ZEILE darf `overflow: visible` behalten — die
 * Kürzung hängt am `overflow: hidden` DER TEXTELEMENTE und ist davon
 * unabhängig. Wer der Zeile `overflow: hidden` gibt, „repariert" nichts und
 * schneidet dafür Haarlinien und Fokusringe ab.
 *
 * ⚠ Ohne `!important`, anders als im Bestand: Dort ist es Abwehr gegen das
 * Elementor-Seiten-CSF von Post 109337. Unsere Regeln stehen bereits ohne
 * `!important` (Seiten-CSS lädt nach) — gemessen, nicht angenommen. Sollte
 * eine Kaskade sie je schlagen, gehört das Gewicht hierher, nicht überallhin.
 *
 * KONVERGENZ: Stephan hat dieselbe 2-Zeilen-Regel am 16.08. für die
 * App-Listen erlassen (app-backend baut das Zeilen-Partial parallel). Alter
 * Mein-MB-Standard und neue App-Regel sagen damit dasselbe — wer hier auf
 * drei Zeilen geht, bricht beide.
 */
.mb-mmb .mb-fb__titel,
.mb-mmb .mb-mmb__unterzeile {
    display: -webkit-box;
    -webkit-line-clamp: 2;
    -webkit-box-orient: vertical;
    overflow: hidden;
}
/* ⚠ AUSNAHME (3.29.9): KOPF-Unterzeilen werden NICHT gekappt.
 * Die Zwei-Zeilen-Regel oben gilt den LISTENEINTRAEGEN — sie wurde gegen lange
 * TITEL gemacht (der King-Gizzard-Pruefstein). Im Kopf eines Abschnitts stehen
 * aber die Leer- und Statussaetze (Mockup A §5), und die sind Anleitungen:
 * „Du folgst noch keinen Künstler*innen - klicke + Folgen unter dem Künst…" —
 * abgeschnitten mitten im Wort, genau fuer die neuen Nutzer, die sie brauchen.
 * Gemessen 27.09. (DDEV, leeres Konto, 390): drei Kopfsaetze gekappt, schon bei
 * 14 px (je eine Zeile versteckt) — mit 18 px aus 3.29.7 deutlich schlimmer
 * (Kuenstler und Location: zwei von vier Zeilen versteckt).
 * Die Listeneintraege (`.mb-mmb__eintrag`) behalten ihre zwei Zeilen; Stephans
 * Regel und die gleichlautende App-Regel bleiben dort unberuehrt. */
.mb-mmb .mb-mmb__kopf .mb-mmb__unterzeile {
    display: block;
    -webkit-line-clamp: unset;
    overflow: visible;
}

/* Hinweistext unter dem Charts-Kopf (Bestand: favorites `charts_hint`).
 * Werte wie die Unterzeile — 14/300/fg-2 —, damit er als Erläuterung liest
 * und nicht als Inhalt. Innenabstand auf der 16px-Achse der Zeilen. */
/* ⚰ grabstein: hinweis-als-sekundaertext
 *
 * HIER STAND 14px/300 in SEKUNDÄRFARBE (#55555E / dunkel #B6B6BE) — „damit er
 * als Erläuterung liest und nicht als Inhalt". REVIDIERT 19.08.2026 auf
 * Stephans Wort: „Es sollte genau so sein wie der intro text der mein mb
 * seite, was offenbar nicht der fall ist."
 * ✅ 11.09.2026 NACHGEPRUEFT und BESTAETIGT: getippt am 17.08.2026 um 17:34,
 * im Satz „und was ist mit dem intro text ‚Du kannst di reihenfolge...‘ -
 * welche farbe und gewicht? Es sollte genau so sein wie …“. Exakter Treffer.
 * ⚠ Diese Zeile war kurzzeitig als „nicht belegt“ gefuehrt — der Fehler lag
 * im Pruefskript (fehlendes .strip(): ein Zitat, das auf „.“ endet, wird nie
 * gefunden, wenn der Satz am Nachrichtenende steht). Nicht erneut kippen.
 *
 * Der Hinweis ist für ihn GRUNDTEXT, keine Nebenangabe — er erklärt eine
 * Bedienung, die man sonst nicht findet (Drag & Drop). Deshalb 18/300 in
 * Grundtext-Tinte, wie der Elementor-Intro darüber.
 *
 * ⚠⚠ FARBE GEBUNDEN, NICHT KOPIERT (`inherit` statt eines festen Werts) —
 * das ist die eigentliche Anforderung, nicht die Optik: Stephan stellt die
 * Kit-Textfarbe demnächst von #000000 auf den Handbuch-Ink #222227 um. Ein
 * kopierter Wert wäre am Tag danach wieder verschieden; ein geerbter zieht
 * mit. Gemessen wird das Ergebnis, nicht die Absicht — Werte in der
 * Vollzugsmeldung.
 *
 * ⚠ WARUM NICHT an `var(--e-global-color-text)` binden, also direkt ans Kit:
 * Das Handbuch hat Hoheit über die Tinte (#222227), nicht der Kit — heute
 * stünde dort #000000, und wir würden eine Abweichung übernehmen statt sie
 * auszugleichen. Wir binden an unsere eigene Ebene; identisch werden beide,
 * wenn das Kit dorthin nachzieht.
 *
 * Innenabstand bleibt auf der 16px-Achse der Zeilen. */
/* ⚠ P13-KETTE, dreifach gedreht — wer erneut dreht, liest erst das:
 *   (Start) 14/300 Sekundär — „liest als Erläuterung, nicht als Inhalt"
 *   17.08. Stephan: „genau so wie der intro text" → 18/300, Farbe gebunden
 *          ⚠ 05.09.: als eigene Aussage vom 17.08. NICHT belegt — die Wendung
 *          steht in seiner Nachricht vom 19.08. (siehe nächste Zeile). Möglich,
 *          dass zwei Anlässe zu einem Zitat verschmolzen sind.
 *   19.08. Stephan nach dem Deploy, 14:14, WÖRTLICH (Beleg 05.09.): „der text
 *          … ist viel zu groß, er ist größer als das sektions-label dazu und so
 *          groß wie der intro text der ganzen mein mb seite"
 *          → zurück auf 14/300 Sekundär (Kanon-VORSCHLAG des Supervisors,
 *          Stephan justiert ggf. beim Abnehmen nach).
 * Die 17.08.-Lehre BLEIBT trotzdem: kein harter Farbwert, der beim Kit-Dreh
 * driftet — Sekundärfarbe ist hier eine bewusste ROLLEN-Zuweisung, kein
 * kopierter Intro-Wert. */
.mb-mmb__hinweis {
    margin: 0;
    padding: 10px 16px 12px;
    font-size: var(--mb-fs-sekundaer, 15px);      /* 3.30.0 Typo-Skala */
    font-weight: var(--mb-fw-sekundaer, 300);
    line-height: var(--mb-lh-sekundaer, 20px);
    color: #55555E;
}
body.mb-dark .mb-mmb__hinweis { color: #B6B6BE; }

/* Icons: 21px, Strichstärke 1.75 (Mockup B §1). Ton nach Thema —
 * Orange = eigene Inhalte, Violett = Follow-/Newcomer-Themen (Mockup A §4). */
.mb-mmb__icon {
    flex: 0 0 auto;
}
.mb-mmb__icon--inhalt { color: var(--fav, #E36A34); }
.mb-mmb__icon--folge  { color: var(--mb-accent, #C22BF7); }

/* ⚰ grabstein: kopf-titel-16-300
 *
 * HIER STAND `.mb-mmb__kopf .mb-fb__titel { font-weight: 300 }` mit der
 * Begründung „der Kopf soll leichter stehen als die Einträge darunter"
 * (Spec §2 des Seiten-Gerüsts). REVIDIERT 17.08.2026 auf Stephans Entscheid.
 * ⚠ 12.09.2026 geprueft: Das Zitat in Zeile 2 ist die SPEC-Begruendung,
 * nicht Stephans Wort — der Satz sagt es selbst („Spec §2"). Keine
 * Zuschreibung; im Bestand kommt er auch nirgends vor (0 Treffer).
 *
 * ANLASS und was daran lehrreich ist: Sein Eindruck hieß „verschiedene
 * Schwarztöne" — die Messung an seiner Live-Seite ergab, dass die FARBEN
 * einheitlich sind (#222227, plus gewolltes Sekundär #55555E). Der Unterschied
 * war das GEWICHT: Köpfe 300, Zeilen-Titel und „Alle N anzeigen" 400. Er hat
 * es als Farbe wahrgenommen, es war Gewicht — und beim Nachfragen kam die
 * Handbuch-Frage von ihm selbst: „dann bitte alles auf 400 - steht das nicht
 * so auch im handbuch?" Ja: „Grund 300 / Überschrift 400". Die 16/300 war ein
 * SEITEN-Wert aus dem Gerüst, der gegen den Haus-Kanon lief.
 *
 * Damit trägt der Kopf-Titel jetzt schlicht die 16/400 der Raster-Basis
 * (mb-theme-standards.css:914-918) — es braucht hier KEINE eigene Regel mehr.
 * Wer sie wieder anlegt, holt den Gerüst-Wert zurück, den Stephan verworfen hat.
 *
 * ⚠ NICHT MIT GEDREHT: der KOPF-ZÄHLER daneben. Der steht bei 300 auf einem
 * EIGENEN, JÜNGEREN Entscheid.
 * ⚠ 12.09.2026 geprueft: Hier standen zwei Kurzformen in Anfuehrungszeichen
 * — „nackte Zahl 300" und „Zahl in fett sieht komisch aus". Beide sind
 * UNSERE Formulierungen, keine Zitate: 0 Treffer in seinen 5.602 getippten
 * Nachrichten. Was er wirklich schrieb, steht woertlich im Block darunter
 * (09.08.2026, 17:02). Die Warnung dazu steht direkt unter diesem Block. Ein
 * Zähler ist kein Kopf-/Label-TEXT. Die Frage liegt bei Stephan — bis zu
 * seiner Antwort bleibt die Zahl bei 300. */

/* Gesamtzahl rechts im Sektionskopf — nackte Zahl, 16px/300, #222227.
 *
 * ⚠ ZWEI ENTSCHEIDE ZUR SELBEN ZAHL, beide von Stephan, beide am 2026-08-14 —
 * hier stehen sie vollständig, damit die nächste Runde nicht den einen gegen
 * den anderen ausspielt:
 *   1. Auf die 600er-Spec, sein Gerätentscheid 2.10.11 → 400.
 *      ✅ WORTLAUT, 09.08.2026 17:02 (12.09.2026 gegengelesen): „das Gute
 *      ist - die mein mb seite passt jetzt endlich - bis auf die zahl in
 *      fett - das war zwar die design vorgabe, sieht aber komisch aus -
 *      mach sie bitte normal".
 *      ⚠⚠ DAMIT STIMMT DAS DATUM DIESES BLOCKS NICHT: Die Ueberschrift sagt
 *      „beide am 2026-08-14". Dieser Entscheid fiel am 09.08., fuenf Tage
 *      frueher. Und hier stand die Kurzform „Zahl in fett sieht komisch
 *      aus" — 0 Treffer im Bestand; sein Satz ist laenger und nennt den
 *      Grund: die Design-Vorgabe sah 600 vor, er verwirft sie am Bild.
 *   2. Auf das Spec-Update Stunden später: nackte Zahl **300**. Das ERSETZT
 *      die 400 — die galt der alten 600er-Fassung. Die Kern-Absicht („nicht
 *      fett") trägt beide.
 * Wer hier auf 400 oder 600 „zurückkorrigiert", dreht den jüngeren Entscheid
 * zurück. Kein Text an der Zahl („N Teilnahmen" o. ä.); die Unterzeile bleibt
 * nicht-numerischem Kontext vorbehalten (z. B. „2016–2026").
 *
 * Die Basis gibt Zählern sonst 14/300 fg-2 — hier ist die Zahl eine
 * Kopf-Aussage, keine Meta-Angabe, deshalb 16px und Textfarbe. */
.mb-mmb__kopf .mb-fb__zaehler {
    /* 3.29.7: keine eigene Groesse mehr — die Basis traegt jetzt 18/300.
       Die „16 statt 14"-Begruendung darueber ist damit gegenstandslos. */
    font-weight: 300;
    color: #222227;
}
body.mb-dark .mb-mmb__kopf .mb-fb__zaehler {
    color: #F5F5F7;
}
.mb-mmb__sektion > .mb-mmb__kopf {
    border-top-color: rgba(34, 34, 39, .14);
}
body.mb-dark .mb-mmb__sektion > .mb-mmb__kopf {
    border-top-color: rgba(255, 255, 255, .14);   /* gleiche Deckkraft in beiden Schemes */
}

/* ⚠ ZÄHLER-FLUCHT DER NAVIGATIONS-ZEILE (F11, 17.08.). Gemessen nach dem
 * Umbau auf einzeilige Köpfe: Der Zähler der Städte-Zeile stand 8px weiter
 * rechts als der aller Sektionsköpfe (945 statt 937) — Stephans Wunsch war
 * ausdrücklich „die Anzahl rechts neben dem aufklapp Pfeil", also auf EINER
 * Flucht. ⚠ 05.09.: Dieser Wortlaut ist NICHT belegt. Am 17.08. 10:49 gibt es
 * eine Nachricht von ihm zu den Aufklapp-Pfeilen der Jahre, aber sie sagt das
 * hier Zitierte nicht. Die MESSUNG (945 gegen 937) steht unabhängig davon.
 * URSACHE in der Raster-Basis: Der 8px-Abstand zwischen Zähler und Chevron ist
 * dort auf `.mb-fb__kopf >` gescoped (mb-theme-standards.css:936); unsere
 * Navigations-Zeile ist eine `.mb-fb__zeile`, für sie greift statt dessen die
 * allgemeine Regel `margin-left: 0`. Kein Fehler der Basis — sie kannte bis
 * heute keinen Zähler an einer Zeile.
 * ⚠ BEWUSST HIER statt in der Basis: Die Basis ist geteilter Vertrag
 * (favorites/follow/tourdates/account). Eine Änderung dort trüge das Risiko in
 * fremde Sektionen, für einen Fall, den bisher nur diese Seite hat. Wird der
 * Zähler-an-Zeile-Fall allgemein, gehört die Regel in die Basis — dann bitte
 * mit Negativkontrolle über alle Konsumenten. */
/* ═══ D (Stephan 20.08.): Teaser-Zeile im Kopf-Rhythmus — 51,5 → 55 ════════
 * „alle Kopfzeilen im selben Rhythmus" — ⚠ 11.09.2026 geprueft: im Text NICHT belegt; am Datum kamen Bilder.
 * Als Zusammenfassung lesen, nicht als Zitat — die Sache darunter ist gemessen
 * und traegt ohne die Zuschreibung.
 * Die Städte-Teaser-Zeile ist eine
 * NAVIGATIONS-Zeile in Kopf-Optik, mass am ECHTEN DOM aber 51,5, während jeder
 * Sektions-Kopf 55 misst.
 *
 * ⚠ URSACHE STATT KONSTANTE (am echten DOM belegt): Padding (13/13) und
 * `min-height` (44) sind bei Zeile und Kopf IDENTISCH. Die Differenz sitzt
 * allein im ZÄHLER — er ist im Kopf 16px gross, in der Nav-Zeile 14px, und
 * BEIDE erben denselben unitless Zeilenhöhen-Faktor der Live-Typografie
 * (1,75). Also 16 × 1,75 = 28 gegen 14 × 1,75 = 24,5; daraus 55 gegen 51,5.
 * Die Regel gibt dem Nav-Zähler die EFFEKTIVE Zeilenhöhe des Kopf-Zählers;
 * die Schriftgrösse bleibt 14, die Text-Optik ändert sich also nicht.
 * Rechnung: 13 + 28 + 13 + 1 (Baseline) = 55 = Kopf.
 *
 * ⚠⚠ WOHER DIE 28 KOMMT — UND WARUM SIE NICHT AUS DEM NACHBAU STAMMT:
 * Für den Kopf-Zähler existiert KEINE eigene line-height-Regel (CSSOM-Suche
 * am Live-DOM: 0 Treffer) — er ERBT. Der geerbte Faktor unterscheidet sich
 * zwischen den Ständen: DDEV rendert `body { line-height: 1.5 }` (Juni-Stand)
 * → Kopf-Zähler 24, Live rendert 1,75 → 28. Eine erste Fassung dieser Regel
 * stand mit 24 hier und war damit auf den DDEV-Faktor geeicht; am echten DOM
 * wurde die Lücke dadurch grösser statt kleiner (Realtest 3.10.8).
 * ⚠ FOLGE FÜR MESSSTÄNDE: Dem Nachbau fehlen nicht nur seiten-spezifische
 * Regeln, sondern auch GEERBTE Basis-Typografie. Vor dem Ableiten einer Zahl
 * den Stand gegen zwei, drei am echten DOM gemessene computed-Werte
 * kalibrieren (zweiter Fall an einem Tag — s. auch die 24px-Widget-Marge beim
 * Tab-Kopf).
 * ⚠ PREIS, offen benannt: 28 ist an den heutigen Live-Faktor 1,75 gebunden.
 * Ändert sich die Basis-Typografie, driftet diese Zeile wieder. Faktor-frei
 * wäre nur `font-size: 16px` am Nav-Zähler (erbt dann dieselbe Höhe wie der
 * Kopf-Zähler, egal welcher Faktor gilt) — das vergrössert aber die Zahl
 * sichtbar und ist damit eine Design-Entscheidung, keine Reparatur.
 * Verworfen: `min-height: 55px` an der Zeile — trifft dieselbe Höhe, lässt
 * die Ursache stehen und wäre eine zweite Konstante gegen denselben Wert.
 * Tap-Fläche: unverändert erfüllt (55 > 44). */
.mb-mmb__nav > .mb-fb__zaehler {
    line-height: 28px;
}

.mb-mmb__nav > .mb-fb__zaehler + .mb-fb__chevron {
    margin-left: 8px;
}

/* ═══ Navigierende Zeile (Chevron ›) ══════════════════════════════════════
 * ⚠ 0,2,1 mit eigener Farbe UND eigener Dekoration ist PFLICHT: Der Kit färbt
 * `a` (0,1,1) und das Seiten-CSS-Feld färbt `a` magenta ohne Unterstrich
 * (0,0,1). Zwei Klassen schlagen beides — ohne !important, weil Spezifität
 * hier reicht (`.mb-cardlink` brauchte es nur, weil es 0,1,0 war).
 * Link-Standard §8C gilt für CONTENT-Links; Listenzeilen sind Navigation,
 * also ohne Unterstrich, aber in Textfarbe — nie Magenta.
 */
.mb-mmb a.mb-mmb__nav {
    background: none;
    color: #222227;
    text-decoration: none;
}
@media (hover: hover) {
    .mb-mmb a.mb-mmb__nav:hover {
        background: var(--mb-surface-2, #E9E9E9);
        color: #222227;
    }
}

/* Navigationsziel noch unbekannt → bewusst KEIN Link (ein Link ins Leere wäre
 * schlimmer als eine sichtbar offene Stelle). Die Zeile bleibt Text. */
.mb-mmb__nav--offen {
    cursor: default;
}

/* ═══ „Alle N anzeigen" ═══════════════════════════════════════════════════
 * Kit-Abwehr (background/color/border/radius) liegt seit 3.5.4 in der
 * Raster-Basis und gilt dort für Köpfe UND Zeilen als <button> — genau weil
 * dieser Knopf hier die dritte Instanz derselben Falle gewesen wäre. Hier
 * bleibt nur, was die Basis nicht kennt.
 * Optik nach Mockup A §4: 14/400, unterstrichen, zentriert, mit Chevron.
 * ⚰ 3.29.7: 16/300 — „Alle N anzeigen" ist Nebenebene (Zwei-Groessen-Regel).
 */
.mb-mmb button.mb-mmb__mehr {
    justify-content: center;
    font-size: var(--mb-fs-sekundaer, 15px);      /* 3.30.0 Typo-Skala */
    font-weight: var(--mb-fw-sekundaer, 300);
}
.mb-mmb__mehr-text {
    text-decoration: underline;
    text-underline-offset: 2px;
}
/* ⚠ F20-SCOPE (Stephan 19.08.): Die „Alle N anzeigen"-Zeile ist ein LINK,
 * keine Zeilen-Fläche — Flächen-Hover dort „unüblich bei reinen Links".
 * Hover jetzt Link-Standard §8C (Text grau), Fläche bleibt den ECHTEN
 * Zeilen-Flächen (Sortier-Zeilen, Navigations-Zeile) vorbehalten.
 * ✅ 12.09.2026 gegengelesen: BELEGT, 19.08.2026 14:14 — sein Satz lautet
 *   „…das zeilen highlight von d&d aus den charts hast du jetzt auch für
 *   die links ‚Alle anzeigen' übernommen, aber das ist ja sehr unüblich bei
 *   reinen links". Die Kurzform hier gibt ihn sinngemaess wieder.
 */
@media (hover: hover) {
    .mb-mmb button.mb-mmb__mehr:hover {
        background: none;
        color: #707070;
    }
}
/* Der Chevron dieser Zeile zeigt nach unten — sie klappt nur AUF.
 * ⚰ grabstein: mehr-knopf-dreh-regel
 * Die Dreh-Regel für den offenen Zustand ist mit 3.8.1 entfallen: Seit dem
 * Stephan-Entscheid vom 16.08. verschwindet die Zeile beim Aufklappen, statt
 * ihren Zustand zu tragen („man kann ja das Akkordeon einfach wieder
 * zumachen"). Ein gedrehter Chevron an einer unsichtbaren Zeile wäre
 * folgenlos — aber er stünde als Regel da und behauptete einen Zustand, den
 * es nicht mehr gibt. Der Rückweg läuft über den Sektions-Kopf; DESSEN
 * Chevron dreht weiterhin (Regel in der Raster-Basis). */
.mb-mmb button.mb-mmb__mehr .mb-fb__chevron {
    flex: 0 0 auto;
}

/* ═══ Sichtbarkeit ════════════════════════════════════════════════════════
 * Expliziter Riegel gegen geerbte display-Regeln, die das hidden-Attribut
 * aushebeln (bekannte Falle: reference_display_defeats_hidden_attr).
 */
/* ⚠ GENERISCH, NICHT MEHR ALS LISTE — geändert 3.8.7 nach einem P0.
 *
 * Hier stand eine AUFZÄHLUNG von Klassen, darunter `.mb-mmb__rest[hidden]`.
 * Die Chart-Rest-Zeilen aus 3.8.6 tragen aber das ATTRIBUT
 * `data-mb-mmb-rest` — keine Klasse. Die Aufzählung traf sie nicht,
 * `.mb-fb__zeile { display: flex }` schlug das UA-`[hidden]`, und alle 55
 * verborgenen Chart-Zeilen standen auf Stephans Seite offen.
 *
 * ⚠⚠ Das ist heute das DRITTE Mal dieselbe Falle, und der Warntext darunter
 * stammt von mir — geschrieben, nachdem sie beim Umschalter zugeschnappt war.
 * Eine Pflegeliste, die man beim Hinzufügen vergessen kann, WIRD vergessen;
 * der Warnhinweis hat es nicht verhindert, weil man ihn nur liest, wenn man
 * ohnehin an dieser Datei arbeitet — und ich arbeitete am Renderer.
 *
 * Deshalb jetzt eine Regel, die nichts mehr aufzählt: Was in dieser Sektion
 * `hidden` trägt, verschwindet. Das deckt jede künftige Zeilenart mit, ohne
 * dass jemand daran denken muss. Die Klassen-Formen bleiben zusätzlich
 * stehen, weil sie Knoten treffen, die keine `.mb-fb__zeile` sind. */
.mb-mmb [hidden],
.mb-mmb__inhalt[hidden],
.mb-mmb__koerper[hidden] {
    display: none !important;
}
/* ⚠ DIE LISTE OBEN IST PFLICHTPFLEGE, kein Stilmittel. Wer hier ein Element
 * per `hidden` verbirgt, MUSS es eintragen — sonst gewinnt die eigene
 * display-Regel gegen das Attribut (das UA-Stylesheet setzt `display:none`
 * mit minimaler Spezifität, jede Klassenregel schlägt es).
 * Genau das ist mir bei `.mb-mmb__mehr` passiert (3.8.1): Der Knopf trägt
 * `display:flex` aus der Zeilen-Basis, das `hidden` blieb wirkungslos, und die
 * „Alle N anzeigen"-Zeile stand nach dem Aufklappen weiter da. Der Warntext
 * über dieser Regel existierte da schon — ich habe die Liste nur nicht
 * erweitert. Ein Riegel, den man beim Hinzufügen vergisst, ist kein Riegel. */

/* ═══ Fokus ═══════════════════════════════════════════════════════════════
 * Tastatur-Fokus sichtbar (WCAG 2.4.7). Innen liegend, weil die Zeilen
 * full-bleed bis an den Rand laufen und ein äußerer Ring abgeschnitten würde.
 */
.mb-mmb button:focus-visible,
.mb-mmb a:focus-visible {
    outline: 2px solid var(--e-global-color-primary, #C22BF7);
    outline-offset: -2px;
}

/* ═══ Gerüst-Zonen ════════════════════════════════════════════════════════
 * ⚠ NUR PHASE 1. Diese Regeln verschwinden mit der Verdrahtung — sie machen
 * sichtbar, WORAUF eine Sektion wartet, damit eine unverdrahtete Sektion nicht
 * wie eine geglückt geleerte aussieht („weiß ich nicht" ≠ „ist leer").
 */
.mb-mmb__platzhalter {
    align-items: flex-start;
    gap: 10px;
}
.mb-mmb__platzhalter-marke,
.mb-mmb__demo-marke {
    flex: 0 0 auto;
    border-radius: 3px;
    padding: 2px 8px;
    background: #F5F5F5;
    font-size: var(--mb-fs-kicker, 14px);         /* 3.30.0 Typo-Skala */
    font-weight: var(--mb-fw-kicker, 600);
    line-height: 1.4;
    color: #55555E;
}
.mb-mmb__platzhalter-text {
    flex: 1 1 auto;
    min-width: 0;
    font-size: var(--mb-fs-sekundaer, 15px);      /* 3.30.0 Typo-Skala */
    font-weight: var(--mb-fw-sekundaer, 300);
    line-height: var(--mb-lh-sekundaer, 20px);
    color: #55555E;
}
.mb-mmb__platzhalter-text strong { font-weight: 600; }
.mb-mmb__platzhalter-text code {
    border-radius: 3px;
    padding: 1px 6px;
    background: #F5F5F5;
    font-size: var(--mb-fs-kicker, 14px);
}

/* Platz eines Interaktions-Atoms (Herz/Glocke/Griff). Maße nach Mockup A §2:
 * der Herz-Button misst 34×28 — die Fläche wird hier freigehalten, damit die
 * Zeilen-Geometrie schon jetzt stimmt. Das Atom selbst liefert das Plugin. */
.mb-mmb__atom {
    flex: 0 0 auto;
    width: 34px;
    height: 28px;
    border: 1px dashed rgba(34, 34, 39, .32);
    border-radius: 3px;
}

/* ⚠ ECHTE Plugin-Atome dürfen in der Zeile NICHT schrumpfen.
 * `.mb-mmb__atom` oben ist nur der Platzhalter aus der Bauphase; sobald das
 * Plugin sein Atom liefert, hängt es als direktes Kind in der Zeile und erbt
 * das Flex-Default `1 1 auto` → es schrumpft mit. Bei 375px und einem langen
 * Titel („…And You Will Know Us By The Trail Of Dead") brach der Folgen-Knopf
 * dadurch auf zwei Zeilen um und wurde 44px hoch statt 30 — in der Mobil-
 * Aufnahme gesehen, nicht am Desktop, wo der Titel nie lang genug wird.
 * Der Titel ist das, was umbrechen darf; der Knopf nicht. Deshalb hier und
 * nicht im fremden Plugin: die Zeile gehört uns, der Knopf ihnen. */
.mb-mmb__eintrag > .mb-follow,
.mb-mmb__eintrag > .mb-bookmark,
.mb-mmb__eintrag > .mb-gs-atom,
.mb-mmb__eintrag > .favorite {
    flex: 0 0 auto;
}

/* Leerzustand: „… — <Link>". Link-Standard §8C — unterstrichen, GEERBTE
 * Textfarbe, keine Akzentfarbe (die bleibt Icons und Knoepfen vorbehalten).
 * ⚠ `color: inherit` ist Pflicht, nicht Kosmetik: Das Kit faerbt `.elementor a`
 * magenta, und der Link sitzt in der grauen Unterzeile — ohne die Regel
 * leuchtete er als einziges Element der Zeile in der Primaerfarbe.
 * Die Unterstreichung braucht Gewicht gegen `.elementor a { text-decoration:
 * none }` (0,1,1): zwei Klassen (0,2,0) reichen nicht bei Gleichstand pro
 * Eigenschaft — deshalb der Tag-Praefix, Muster tourdates `p.mb-concerts-invite a`. */
a.mb-mmb__leer-link,
.mb-mmb__unterzeile a.mb-mmb__leer-link {
    color: inherit;
    text-decoration: underline;
    text-underline-offset: 2px;
    background-color: transparent;
}
@media (hover: hover) {
    .mb-mmb__unterzeile a.mb-mmb__leer-link:hover { color: #707070; }   /* §8C-Grau */
}

/* ═══ Dark (body.mb-dark) ═════════════════════════════════════════════════
 * Hairlines und Grundfarben bringt die Raster-Basis mit; hier nur, was dieses
 * Stylesheet selbst gesetzt hat. Gleiche Deckkraft in beiden Schemes.
 */
body.mb-dark .mb-mmb__gruppen-hinweis,
body.mb-dark .mb-mmb__unterzeile,
body.mb-dark .mb-mmb__platzhalter-text { color: #B6B6BE; }
body.mb-dark .mb-mmb a.mb-mmb__nav,
body.mb-dark .mb-mmb button.mb-mmb__mehr { color: #F5F5F7; }
@media (hover: hover) {
    body.mb-dark .mb-mmb a.mb-mmb__nav:hover {
        background: var(--mb-surface-2, #33333B);
        color: #F5F5F7;
    }
    /* Mehr-Zeile: Link-Hover auch im Dunkeln (F20-Scope, s. oben). */
    body.mb-dark .mb-mmb button.mb-mmb__mehr:hover {
        background: none;
        color: #8E8E96;
    }
}
body.mb-dark .mb-mmb__platzhalter-marke,
body.mb-dark .mb-mmb__demo-marke,
body.mb-dark .mb-mmb__platzhalter-text code {
    background: #33333B;
    color: #B6B6BE;
}
body.mb-dark .mb-mmb__atom { border-color: rgba(255, 255, 255, .32); }

/* ═══ Zeilen-Anatomien der Datensektionen ═════════════════════════════════
 * Maße aus der Bau-Spezifikation (docs/mein-mb-umzugsplan.md). Die eine Zahl,
 * die man kennen muss: **Chart-Bildblock (26 + 78) und GS-Thumbnail (104)
 * enden beide bei x = 120** — deshalb 104 und nicht irgendwas. Die Zeilen
 * beider Sektionen fluchten dadurch auf derselben Textachse.
 */

/* ── Termin-Zeile: Datums-Box nach LIVE-Kanon (nicht die Mockup-Box) ────── */
.mb-mmb__datum {
    flex: 0 0 56px;
    display: flex;
    flex-direction: column;
    align-items: center;
    justify-content: center;
    min-height: 58px;
    border: 1px solid rgba(34, 34, 39, .14);
    border-radius: 3px;
    background: #F5F5F5;
    line-height: 1.15;
}
.mb-mmb__datum-dow { font-size: 14px; font-weight: 600; color: #84848E; text-transform: uppercase; }
.mb-mmb__datum-tag { font-size: 19px; font-weight: 600; color: #222227; }
.mb-mmb__datum-mon { font-size: 14px; font-weight: 600; color: #84848E; text-transform: uppercase; }
body.mb-dark .mb-mmb__datum { background: #2A2A30; border-color: rgba(255, 255, 255, .14); }
body.mb-dark .mb-mmb__datum-tag { color: #F5F5F7; }

/* ═══ NÄHTE ZUM TOURDATES-ATOM (Termine-Sektion, seit 3.9.0) ════════════════
 * Die Zeilen der Sektion kommen aus `mb_tourdates/termin_liste`. GEMESSEN:
 * Haarlinien-FARBE und -BREITE sind identisch mit unseren (1px, .10 Deckkraft,
 * Spannweite 290–990 in beiden Schemes) — nur die SEITE unterscheidet sich:
 * Atom-Zeilen tragen `border-bottom`, unsere `.mb-fb__zeile` `border-top`.
 * Genau daraus entstehen zwei Fehler an den Stoßstellen, beide auf unserer
 * Seite zu beheben (tourdates' CSS fassen wir nicht an):
 *
 *  1. ZWISCHEN KOPF UND ERSTER ZEILE FEHLTE DIE LINIE. Der Raster-Vertrag
 *     sagt sie zu („border-top an JEDER Zeile → die Linie über der ersten
 *     Zeile steht automatisch", mb-theme-standards.css:705-708) — aber diese
 *     Zusage traegt die ZEILE, und die Atom-Zeile hat kein border-top. Also
 *     legt sie hier die Liste selbst an.
 *  2. ÜBER „ALLE N ANZEIGEN" STANDEN ZWEI LINIEN (2px): die letzte Atom-Zeile
 *     brachte ihre untere mit, unser Knopf seine obere. In unseren eigenen
 *     Sektionen ist es genau eine — gegengemessen.
 *
 * ⚠ Die Rest-Liste bekommt KEINE obere Linie: Sie stößt beim Aufklappen an
 * die untere der letzten sichtbaren Zeile, und das wäre die doppelte Linie
 * eine Stoßstelle weiter oben. */
.mb-my-concerts .mb-upcoming-concerts {
    border-top: 1px solid rgba(34, 34, 39, .10);
}
.mb-my-concerts .mb-mmb__rest > .mb-upcoming-concerts {
    border-top: 0;
}
/* ⚠ SPEZIFITÄT 0,3,1 IST PFLICHT, NICHT VORSICHT. Der Knopf ist ein <button>
 * mit `.mb-fb__zeile`, und die Raster-Basis wehrt dort den Elementor-Kit ab:
 * `.mb-fb button.mb-fb__zeile` (0,2,1) setzt `border-top: 1px`
 * (mb-theme-standards.css:848-856). Mein erster Versuch war
 * `.mb-my-concerts .mb-mmb__mehr` (0,2,0) — er hat verloren, und die doppelte
 * Linie blieb stehen; nötig war 0,3,1.
 * ⚠ KORREKTUR 17.08. NACHTS: Hier stand „Gleichstand hätte auch nicht genügt,
 * die Basis lädt mit Prio 100000 als LETZTES Stylesheet der Seite." **Das ist
 * falsch und war nie geprüft.** Nachgemessen am gerenderten Dokument:
 * `mb-theme-standards-css` steht an Position 5, `mb-mein-musikblog-css` an 7 —
 * unser Seiten-CSS lädt NACH der Basis. Die Enqueue-Priorität ordnet die Basis
 * spät unter den ~26 Sheets ein, aber nicht hinter ihre eigenen Abhängigen.
 * Der Fix oben bleibt richtig (er gewinnt über Spezifität), die Begründung war
 * es nur halb. Wer die Reihenfolge als Argument braucht: erst messen. Die Basis rechnet dieselbe
 * Aufgabe für ihre eigene Dark-Regel im Kommentar daneben vor — ich habe die
 * Rechnung erst nach der Messung gelesen.
 * Eine Dark-Fassung braucht es NICHT: Die Dark-Regel der Basis setzt nur
 * `border-top-color`, und bei Breite 0 ist die Farbe gegenstandslos. */
.mb-my-concerts button.mb-fb__zeile.mb-mmb__mehr {
    border-top: 0;
}
body.mb-dark .mb-my-concerts .mb-upcoming-concerts {
    border-top-color: rgba(255, 255, 255, .10);
}
body.mb-dark .mb-my-concerts .mb-mmb__rest > .mb-upcoming-concerts {
    border-top-color: transparent;   /* Breite ist 0 — Farbe nur der Klarheit */
}

/* ── Eintrags-Link: EIGENE Grundlage, nicht die geerbte ──────────────────────
 * ⚠ GEMESSEN 17.08.: Die Unterstreichung meiner Künstler-Links kam bis hierher
 * von `.mb-post-content a` (0,1,1) — einer generischen Seiteninhalt-Regel, die
 * nur greift, weil die Sektion zufällig INNERHALB dieses Wrappers steht. Ich
 * hatte „unterstrichen wie im Bestand" als erfüllt gemeldet; erfüllt hat es die
 * Umgebung, nicht mein Stylesheet. Stellt Elementor die Sektion in einen
 * Container ohne diese Klasse, verlieren alle Zeilen-Links ihre Unterstreichung.
 * Muster + Spezifität aus dem Bestand (bookmark.css:565-573, 0,3,1 mit
 * Tag-Präfix — zwei Klassen reichen gegen `.elementor a` PRO EIGENSCHAFT nicht).
 * `color: inherit` ist Kit-Abwehr wie beim Leer-Link (§8C: Akzentfarbe bleibt
 * Icons und Knöpfen). */
.mb-mmb .mb-mmb__text a.mb-mmb__eintrag-link {
    color: inherit;
    text-decoration: underline;
    text-underline-offset: 2px;
    background-color: transparent;
}

/* ═══ GRABSTEIN ════════════════════════════════════════════════════════════
 * grabstein: absage-optik-von-hand
 *
 * HIER STANDEN DIE ABSAGE-REGELN (line-through + Deckkraft 0,55) FÜR DIE
 * HANDGEBAUTE TERMIN-ZEILE. ENTFERNT MIT 3.9.0: Es gibt keinen Erzeuger mehr —
 * `.mb-mmb__termin--abgesagt` wird nicht mehr gesetzt, seit die Zeilen aus
 * `mb_tourdates/termin_liste` kommen. Die Absage-Darstellung liefert jetzt
 * `bookmark.css:709-719` selbst, also die Quelle, aus der ich sie damals
 * abgeschrieben habe.
 * Grabstein bei `mb_mmb_termin_ids()` in inc/mb-mein-musikblog.php erklärt den
 * ganzen Umbau. NICHT wieder anlegen: Zwei Absage-Optiken für dieselben Daten
 * driften auseinander, und die hiesige wäre die, die niemand pflegt.
 * ════════════════════════════════════════════════════════════════════════ */

/* ═══ Kategorie- und Jahres-Ebene: ZWEI AKKORDEONS ════════════════════════
 * Gespiegelt aus dem Bestand (favorites style.css:470-533, MyCharts.php†:840-880; † = Datei mit favorites 2.0.0 gelöscht,
 * nachlesen: favorites `git show v1.43.3:src/Frontend/Shortcodes/MyCharts.php`).
 *
 * ⚰⚰ GRABSTEIN, WIEDER GEÖFFNET — grabstein: charts-akkordeon-ebenen
 * Die Kette, damit die nächste Runde nicht zurückdreht:
 *   bis 3.8.5  zwei aufklappbare Ebenen wie im Bestand
 *   17.08. mittags ABBESTELLT von Stephan („Teaser wie andere Sektionen" —
 *          ⚠ 11.09. geprueft: Wortlaut im Text nicht belegt; die ABBESTELLUNG
 *          selbst ist durch den Rueckbau belegt, der damals erfolgte),
 *          Überschriften wurden statische Zwischentitel ohne Pfeil. Der
 *          Supervisor hat seine damalige Auswahl-Option später selbst als
 *          MISSVERSTÄNDLICH formuliert bezeichnet — der Abbestell-Entscheid
 *          beruhte also auf einer schlechten Frage, nicht auf einem Irrtum
 *          Stephans.
 *   17.08. abends REAKTIVIERT nach seiner Klarstellung, wörtlich: „man muss ja
 *          die jahre auf und zuklappen können, sonst sieht man immer die
 *          letzten 10 jahre mit dutzenden von einträgen … es sollen die most
 *          recent 2 charteinträge angezeigt werden, egal welches jahr — die
 *          jahres pfeile erscheinen entsprechend wenn man klickt ‚Alle
 *          anzeigen'."
 * Was daran zu lernen ist, und es betrifft mich: Beim Abbestellen habe ich die
 * Werte sorgfältig als Grabstein hinterlegt — und genau das hat die Rückkehr
 * billig gemacht. Ein Grabstein mit Werten ist kein Nachruf, sondern ein
 * Ersatzteil.
 *
 * ⚠ EIGENE KLASSENNAMEN (`mb-mmb__kat-toggle`/`__jahr-toggle`), NICHT die des
 * Bestands (`mb-chart-cat-toggle`/`mb-chart-year-toggle`). Grund am Handler in
 * assets/js/mb-mein-musikblog.js: favorites bindet über
 * `getElementById('user-charts')`, und diese Seite trägt die ID bewusst nicht —
 * ihre Namen gäben Pfeile ohne Funktion. Wer das hier „aufräumt", baut den
 * dritten toten Knopf dieser Familie.
 *
 * Die Optik dagegen ist 1:1: Dreieck über `border-color` auf `currentColor`,
 * Kategorie 5/8 mit 12px Abstand, Jahr 4/6 mit 10px, `rotate(90deg)` offen und
 * `rotate(0)` eingeklappt.
 *
 * Innenabstand auf der 16px-Achse der Zeilen, damit Kategorie, Jahr, Icon und
 * Zeileninhalt auf EINER Fluchtlinie stehen. */
.mb-mmb__kategorie,
.mb-mmb__jahr {
    margin: 0;
}
.mb-mmb__kat-toggle,
.mb-mmb__jahr-toggle {
    display: flex;
    align-items: center;
    width: 100%;
    min-height: 44px;               /* Tap-Fläche ≥44, Optik darf kleiner sein */
    margin: 0;
    padding: 14px 16px 4px;
    /* ⚠ KIT-FEST: `.elementor-kit-119134 button` (0,1,1) färbt jeden nackten
     * Button #C22BF7 und schlägt einfache Klassenregeln PRO EIGENSCHAFT. Diese
     * Regel ist (0,1,0) und würde verlieren — deshalb stehen background, color
     * und border-radius zusätzlich unten in einer 0,2,1-Regel. Im Theme
     * viermal teuer bezahlt (3.3.17, 3.5.2, 3.6.0, 3.9.0-Nähte). */
    border: 0;
    background: none;
    box-shadow: none;
    /* 3.30.0 Typo-Skala: Akkordeon-Kopf = Stufe ZEILE 17/400/22 (vorher 16). */
    font-size: var(--mb-fs-zeile, 17px);
    font-weight: var(--mb-fw-zeile, 400);
    line-height: var(--mb-lh-zeile, 22px);
    color: #222227;
    text-align: left;
    text-transform: none;
    cursor: pointer;
    -webkit-user-select: none;
    user-select: none;
}
/* Kit-Abwehr mit ausreichendem Gewicht (0,2,1) — s. Kommentar oben. */
.mb-mmb button.mb-mmb__kat-toggle,
.mb-mmb button.mb-mmb__jahr-toggle {
    background: none;
    color: #222227;
    border-radius: 0;
}
.mb-mmb__jahr-toggle {
    padding: 10px 16px 4px;
    /* 3.30.0: auch der Jahres-Kopf ist antippbar und bildet eine Liste →
       Stufe ZEILE 17 (vorher 14). Gewicht 300 und Grau bleiben: Die Stufe
       unter der Kategorie zeigt sich über das Gewicht, nicht über die Größe. */
    font-size: var(--mb-fs-zeile, 17px);
    font-weight: 300;
    color: #55555E;
}
/* Disclosure-Dreieck — Kategorie größer (5/8), Jahr kleiner (4/6), damit die
 * Hierarchie erkennbar bleibt (Bestand style.css:491-507). */
.mb-mmb__kat-toggle::before,
.mb-mmb__jahr-toggle::before {
    content: "";
    flex: 0 0 auto;
    width: 0;
    height: 0;
    border-style: solid;
    border-color: transparent transparent transparent currentColor;
    transform: rotate(90deg);       /* offen → zeigt nach unten */
    transition: transform 150ms ease, border-color 150ms ease;
}
.mb-mmb__kat-toggle::before  { border-width: 5px 0 5px 8px; margin-right: 12px; }
.mb-mmb__jahr-toggle::before { border-width: 4px 0 4px 6px; margin-right: 10px; }
.mb-mmb__kat-toggle.is-collapsed::before,
.mb-mmb__jahr-toggle.is-collapsed::before {
    transform: rotate(0deg);        /* eingeklappt → zeigt nach rechts */
}
/* ⚠ HOVER-ZWEIG ZWINGEND IN `@media (hover: hover)` (Bestands-Warnung
 * style.css:512-518): Auf Touch gibt es keinen echten Hover — der Zustand
 * bleibt nach dem Tippen KLEBEN, und der Pfeil des zuletzt getippten Toggles
 * wäre dauerhaft orange. `:focus-visible` bleibt UNGEGUARDET, Tastatur-Fokus
 * gibt es auf jedem Gerät. */
@media (hover: hover) {
    .mb-mmb__kat-toggle:hover::before,
    .mb-mmb__jahr-toggle:hover::before {
        border-left-color: var(--e-global-color-secondary, #E36A34);
    }
}
.mb-mmb__kat-toggle:focus-visible::before,
.mb-mmb__jahr-toggle:focus-visible::before {
    border-left-color: var(--e-global-color-secondary, #E36A34);
}
/* ⚠ DER ABSTAND KOMMT AUS `margin-left`, NICHT AUS DEM LEERZEICHEN im Markup.
 * Gemessen (Gate-Fund des Supervisors, „Album-Charts· 36" ohne Lücke): Mein
 * Markup war byte-identisch mit dem Bestand — ` · 36` MIT führendem
 * Leerzeichen im Span — und rendete trotzdem mit Lücke 0. Grund: Der Span ist
 * Flex-Item des Toggles, und führende Leerzeichen eines Flex-Items werden
 * getrimmt (das Leerzeichen wäre 3,7px). Der Bestand hat dasselbe Markup und
 * sieht trotzdem richtig aus, weil dort `margin-left: 0.35em` steht
 * (favorites style.css `#user-charts .mb-chart-cat-count`) — gemessene Lücke
 * 5,3px. Identisches Markup ist also KEIN Beleg für identische Optik, sobald
 * die Kaskade dazwischensteht.
 * `white-space: nowrap` ebenfalls von dort: sonst kann „· 36" umbrechen. */
.mb-mmb__kategorie-zahl,
.mb-mmb__jahr-zahl {
    margin-left: 0.35em;
    font-weight: 300;
    color: #55555E;
    white-space: nowrap;
}
body.mb-dark .mb-mmb__kat-toggle,
body.mb-dark .mb-mmb button.mb-mmb__kat-toggle { color: #F5F5F7; }
body.mb-dark .mb-mmb__jahr-toggle,
body.mb-dark .mb-mmb button.mb-mmb__jahr-toggle { color: #B6B6BE; }
body.mb-dark .mb-mmb__kategorie-zahl,
body.mb-dark .mb-mmb__jahr-zahl { color: #B6B6BE; }

/* ═══ UNDO-ZUSTAND DER ZEILE (Bestand: favorites style.css:1096-1117) ══════
 * Wer ein Herz drückt, sieht die Zeile NICHT verschwinden — sie bleibt für die
 * Undo-Frist stehen, gedimmt und durchgestrichen, mit „Rückgängig" an der
 * Stelle des Herzens. Diese Optik ist **Konsumenten-Pflicht** seit favorites
 * 1.39.1: Ihre Regeln ankern auf `.charts__item`, und diese Klasse dürfen
 * unsere Zeilen nicht tragen (sie zöge deren ganze Zeilen-Anatomie mit) —
 * also gehört die Optik hierher.
 *
 * ⚠ GEFUNDEN IM GATE, nicht von mir: Bis 3.9.0 hatte diese Datei NULL
 * `mb-undo-removing`-Regeln. Das Undo LIEF (Knopf, Icon, Zurückholen, alles
 * geprüft) — nur sah die Zeile dabei unverändert aus. Genau die Sorte Lücke,
 * die eine Funktions-Prüfung durchwinkt: Ich hatte die KETTE gemessen und die
 * DARSTELLUNG des Zwischenzustands nicht. Ein Zustand, den man nur 8 Sekunden
 * lang sieht, ist auf keinem meiner Standbilder.
 *
 * ⚠ `--mb-undo-dim` DARF ich verwenden (anders als `--mb-cancelled-op`, das
 * bookmark.css ausdrücklich für sich reklamiert): Es steht auf `:root` in der
 * GETEILTEN Komponente `assets/shared/mb-undo.css`, die beide Plugins
 * mitbringen. Fallback trotzdem, damit die Optik auch ohne die Komponente
 * stimmt.
 *
 * ⚠ WAS NICHT DIMMT, und das ist im Bestand eine Entscheidung, kein Zufall:
 *  · DER RANG bleibt voll deckend (`:not(.charts__index)` dort, hier durch
 *    Aufzählung der zu dimmenden Kinder) — er ist die Positionsauskunft, und
 *    eine halb sichtbare Ziffer liest sich wie ein Fehler.
 *  · DER KNOPF bleibt unberührt: Er trägt seine eigene Undo-Optik aus
 *    mb-undo.css und muss der greifbarste Teil der Zeile bleiben — man soll
 *    ihn ja drücken.
 *
 * ⚠ GILT FÜR ALLE ZEILENTYPEN, deshalb der Anker an `.mb-mmb__eintrag` statt
 * an `.mb-mmb__chart`: Charts, Gewinnspiele und Folge-Zeilen tragen alle einen
 * Knopf mit Undo-Frist. Die TERMIN-Zeilen brauchen hier nichts — sie sind
 * echte `.mb-concert`-Zeilen aus dem Atom, und tourdates deckt sie über
 * `.mb-my-concerts .mb-concert.mb-undo-removing` ab (bookmark.css:839-858).
 * ⚠⚠ Damit ist unsere Hüllen-Klasse `mb-my-concerts` TRAGEND, nicht
 * dekorativ: Wer sie umbenennt, nimmt der Termin-Sektion still ihre
 * Undo-Optik. Gemessen, nicht vermutet — Positivkontrolle in der
 * Vollzugsmeldung zu 3.9.1. */
/* ⚠ `__thumb` MUSS MIT (F19, 17.08.): Die Gewinnspiel-Zeile trägt ihr Bild als
 * `.mb-mmb__thumb` (104×78), die Chart-Zeile als `.mb-mmb__cover` (quadratisch).
 * Bis hierher stand nur `__cover` in der Aufzählung — **die GS-Zeilen wurden im
 * Undo-Fenster überhaupt nicht gedimmt.** Als Review-Fund P3 notiert, durch
 * Stephans Vergleich am Gerät akut geworden. Eine Aufzählung, die eine von zwei
 * Bildklassen vergisst, sieht in jeder Code-Durchsicht vollständig aus. */
.mb-mmb__eintrag.mb-undo-removing .mb-mmb__cover,
.mb-mmb__eintrag.mb-undo-removing .mb-mmb__thumb,
.mb-mmb__eintrag.mb-undo-removing .mb-mmb__text {
    opacity: var(--mb-undo-dim, 0.4);
    transition: opacity 200ms ease;
}
/* Titel zusätzlich durchstreichen — auf BEIDEN Ebenen wie im Bestand
 * (style.css:1114-1116): am Titel-Element UND am Link darin. Sonst hebt die
 * eigene `text-decoration: underline` des Eintrags-Links (weiter oben in
 * dieser Datei, 0,3,1) den geerbten Strich wieder auf. */
/* ⚠⚠ ALLE TEXTZEILEN, NICHT NUR DER TITEL (F19, Stephan-Entscheid 17.08. am
 * Bild): Bis hierher strichen unsere Zeilen nur den Titel durch, der Interpret
 * wurde bloß gedimmt — die TERMIN-Zeilen (tourdates) streichen dagegen Titel
 * UND „Venue · Stadt". Zwei Sektionen derselben Seite, zwei Undo-Optiken.
 * KANON ist die Termine-Variante: alles gestrichen und gedimmt.
 * Quelle des Unterschieds: tourdates streicht auf Container-Ebene
 * (`.mb-concert__primary`/`__secondary`), wir hatten die Aufzählung am
 * TITEL-Element — und die Unterzeile stand nicht drin. */
.mb-mmb__eintrag.mb-undo-removing .mb-fb__titel,
.mb-mmb__eintrag.mb-undo-removing .mb-fb__titel a.mb-mmb__eintrag-link,
.mb-mmb__eintrag.mb-undo-removing .mb-mmb__unterzeile,
.mb-mmb__eintrag.mb-undo-removing .mb-mmb__unterzeile a {
    text-decoration: line-through;
}

/* ⚠ F26 (Stephan 19.08.): Zwischen dem letzten Kategorie-Akkordeon
 * (Video-Charts) und dem Kopf der Folge-Sektion fehlte Luft — die
 * Kategorie-Ebene hatte oben 14px Vorlauf (padding des Toggles), unten
 * nichts. Nachlauf auf denselben Rhythmus. */
.mb-mmb__katblock:last-of-type {
    padding-bottom: 14px;
}

/* ── Verwaiste Chart-Einträge (Bestand: favorites style.css:555-580) ─────────
 * `orphaned` heißt: Der Artikel ist getrasht, der Permalink tot. Die Zeile
 * bleibt stehen, damit man sie per Herz loswerden kann — aber sie darf nicht
 * aussehen wie ein lebender Eintrag. Den LINK lässt schon das PHP weg.
 * ⚠ Das `grayscale(1)` am Bild ist laut Bestand das TRAGENDE Merkmal (dort
 * Stand 1.32.1): Die verwaiste Zeile steht grau zwischen farbigen Nachbarn.
 * Die Deckkraft allein trug nur in einem Zwischenstand, als ALLE Thumbnails
 * entfärbt waren. */
.mb-mmb__chart--verwaist .mb-fb__titel,
.mb-mmb__chart--verwaist .mb-mmb__unterzeile {
    text-decoration: line-through;
    opacity: .55;
}
.mb-mmb__chart--verwaist .mb-mmb__cover-bild {
    opacity: .55;
    filter: grayscale(1);
}

/* ── Chart-Listen: kein Browser-Einzug ────────────────────────────────────
 * ⚠ Stephans Fund („Chart-Einträge gegen die GS-Zeilen nach rechts
 * eingerückt" — ⚠ 11.09.2026 geprueft: im Text nicht belegt, als
 * Zusammenfassung seines Fundes lesen): Eine <ol> bringt vom Browser
 * `padding-left: 40px` und
 * Zählpunkte mit. Gemessen am Bild: Chart-Zeilen begannen bei x≈85, die
 * Gewinnspiel-Zeilen (ohne Liste) bei x≈24 — die Fluchtlinie war um den
 * Listen-Einzug verschoben.
 *
 * Dieselbe Falle steht in follows Vertrag beschrieben („⚠ Das innere <ul>
 * trägt die Listen-Klasse zwingend — ohne sie greift der Browser-Default
 * padding-left: 40px, und die aufgeklappten Zeilen kämen eingerückt heraus").
 * Ich habe die <ol> in 3.8.6 neu eingeführt und die Regel nicht mitgebracht:
 * Wer eine Liste einführt, wo vorher keine war, erbt ihre Browser-Vorgaben.
 *
 * Die Zählpunkte müssen ebenfalls weg — die Nummer steht im Rang-Block. */
.mb-mmb__liste {
    margin: 0;
    padding: 0;
    list-style: none;
}

/* ── Chart-Zeile: Rang-Block bündig am Cover, zusammen 104 breit ───────── */
.mb-mmb__chart { list-style: none; }
.mb-mmb__rang {
    /* ⚠⚠ 3.29.7 — BEWUSST NOCH 14/600, die EINZIGE Ausnahme der Seite.
       Der Auftrag verlangt 16/600 fuer Rang-Marken. Gebaut und gemessen, dann
       zurueckgenommen, weil es die Geometrie bricht:
         Der Block ist 26 px breit (Rang 26 + Cover 78 = 104, und das
         Gewinnspiel-Bild ist ebenfalls 104 — beide enden bei x = 120, siehe
         unten). Bei 16/600 braucht ein zweistelliger Rang ~28–31 px (gemessen:
         #10 28,2 · #20 30,3 · #88 31,2). Ein Flex-Element schrumpft nicht unter
         seine Textbreite — der Block WUCHS, und Cover und Text der Zeilen ab
         #10 rutschten nach rechts. Engere Laufweite reicht nicht: selbst bei
         -0,05 em bleibt #88 bei 28,8 px (die echten #10–#13 haetten es knapp
         bestanden — der erfundene Extremfall entscheidet).
       Die Aufloesung ist eine Gestaltungsfrage (Achse verschieben, Cover
       verzerren, Raute weglassen oder Marken-Ausnahme wie die Datums-Box) und
       liegt bei Stephan. Bis dahin kein sichtbarer Rueckschritt.
       ✅ 3.30.0: Mit der Typo-Skala ist 14/600 die Stufe KICKER (Rang steht dort
       ausdruecklich) — die Ausnahme ist damit keine mehr, der Block bleibt 26. */
    flex: 0 0 26px;
    align-self: stretch;
    display: flex;
    align-items: center;
    justify-content: center;
    min-height: 78px;
    border-radius: 3px 0 0 3px;   /* Radius nur AUSSEN — innen stößt das Cover an */
    /* ═══ AB HIER 1:1 AUS DEM BESTAND (favorites style.css:756-793) ═══════════
     * ⚠ EINE Farbe für ALLE Ränge und Jahre. Der Bestand hat die Grau-Leiter
     * in 1.32.2 auf Stephans eigenen Einwand abgeschafft: „der Verlauf der
     * Nummern macht so keinen Sinn, warum wird es denn bei 11 wieder dunkler?"
     * Tiefe kommt seither aus einem block-internen Licht-Verlauf, nicht aus
     * einer zweiten Farbe.
     * Hell = Ink, Dunkel = angehobene Fläche (#222227 wäre auf dunklem Grund
     * praktisch unsichtbar); die Ziffer bleibt in beiden Schemes weiß. */
    background-color: var(--mb-fg, #222227);
    background-image: linear-gradient(180deg,
        rgba(255, 255, 255, .10) 0%,
        rgba(255, 255, 255, 0) 60%);
    /* Lichtkante oben INNEN — `inset`, weil der Block bündig am Cover sitzt
     * und ein Außenschatten auf das Foto fiele. */
    box-shadow: inset 0 1px 0 rgba(255, 255, 255, .10);
    color: #fff;
    /* ⚠ 14px, NICHT 12. Hier stand „glyph-artige Ziffer, 14er-Boden gilt nicht"
     * — das war meine Erfindung. Der Bestand sagt ausdrücklich das Gegenteil:
     * „14px/600 — NICHT die 12px des Handoffs (Schrift-Boden §9.2 ist hart,
     * auch für ‚nur die Rangzahl')". Die Ausnahme, die ich mir gebaut habe,
     * gab es nie. */
    font-size: var(--mb-fs-kicker, 14px);        /* 3.30.0: Stufe KICKER */
    font-weight: var(--mb-fw-kicker, 600);
    line-height: 1.2;
    text-align: center;
    /* ⚰ grabstein: rang-block-cursor-grab
     * `cursor: grab` ENTFERNT 3.6.6. Der Block war als Drag-Griff gedacht,
     * aber Drag & Drop ist auf DIESER Seite nicht aktiv: favorites erreicht
     * seine Sortier-Initialisierung nur über `initChartsSection()`, und die
     * steigt ohne den Container `#user-charts` sofort aus (mb-favorites.js
     * :1113). Der Opt-in-Haken `[data-mb-charts-sortable]`, den sie für uns
     * gebaut haben, liegt HINTER diesem Ausgang und ist von außen unerreichbar.
     * Solange das so ist, wäre ein Greif-Cursor ein Versprechen, das die Seite
     * nicht einlöst — dieselbe Regel, nach der leere Köpfe kein <button> sind.
     * Kommt die Sortierung zurück, kommt diese Zeile mit ihr zurück. */
}

/* ⚠ Rang-Block BÜNDIG am Cover (Stephan-Fund 15.08., Screenshot: sichtbare
 * Lücke). Ursache ist nicht diese Regel, sondern die Zeile darüber: Die
 * Raster-Basis gibt `.mb-fb__zeile` ein `gap: 12px`, und das gilt AUCH
 * zwischen Rang und Cover. Der negative Rand hebt genau dieses eine
 * Vorkommen auf; alle übrigen Abstände der Zeile bleiben unberührt.
 * ⚠ Der Wert ist an die Basis GEKOPPELT — ändert sich dort das gap, muss er
 * hier mit. Deshalb steht die Herkunft dabei und nicht nur die Zahl.
 * Ergebnis: 26 + 78 = 104, beide Kanten enden gemeinsam bei x = 120. */
.mb-mmb__chart .mb-mmb__cover {
    margin-left: -12px;
}
/* ⚰ grabstein: rang-eins-sonderfarbe
 *
 * HIER STAND `.mb-mmb__chart:first-of-type .mb-mmb__rang { background: … }`
 * — ERSATZLOS ENTFERNT 3.8.8, Stephans Fund („die #1-Box hat eine andere
 * Farbe als alle anderen").
 *
 * Es war dieselbe Idee, die der Bestand in 1.32.2 abgeschafft hat, und sie
 * hatte hier BEIDE Defekte, die dort dokumentiert sind:
 *  1. Eine rangabhängige Farbe suggeriert eine Codierung, die es nicht gibt.
 *  2. `:first-of-type` zählt die POSITION IN DER LISTE, nicht den Rang — und
 *     seit 3.8.6 ist jedes JAHR eine eigene Liste. Die Sonderfarbe traf damit
 *     die erste Zeile JEDES Jahres, nicht „die Nummer 1". Genau der zweite
 *     Defekt, den favorites in ihrem Grabstein festhält.
 * Wer wieder eine rangabhängige Farbe einbaut, liest erst jenen Grabstein. */
body.mb-dark .mb-mmb__rang { background-color: var(--mb-surface-2, #33333B); }
.mb-mmb__cover { flex: 0 0 78px; }
/* Cover-Link (3.30.4): nimmt genau die Fläche des Bildes ein — keine eigene
 * Geometrie, kein Unterstrich (§8C gilt dem Text-Link, nicht dem Bild). */
.mb-mmb__cover a.mb-mmb__cover-link {
    display: block;
    text-decoration: none;
}
/* ⚠ `aspect-ratio` + `object-fit` statt `height:auto` — der Grund ist ein
 * FEHLENDES Bild, nicht das vorhandene. Mit `height:auto` bestimmt die
 * geladene Datei die Zeilenhöhe; fällt sie aus (gelöschtes Medium, 404),
 * rendert der Browser den ALT-TEXT im Bildkasten und zieht ihn auf. Am
 * Messstand nachgemessen: heile Charts-Zeile 105px, Zeile mit totem Cover
 * 135px — die Anatomie („Cover und Rang enden gemeinsam bei x=120") war
 * genau in der Zeile hin, in der ohnehin schon etwas fehlte.
 * Feste Kachel heißt: Ein totes Bild kostet ein Bild, nicht die Zeile.
 * `object-fit: cover` hält zugleich nicht-quadratische Quellen im Raster. */
.mb-mmb__cover-bild,
.mb-mmb__thumb-bild {
    display: block;
    width: 100%;
    height: auto;
    object-fit: cover;
    overflow: hidden;          /* Alt-Text bleibt in der Kachel */
    border-radius: 0 3px 3px 0;
    background: var(--mb-surface-2, #E9E9E9);   /* sichtbarer Platzhalter */
}
/* Charts: Cover 78×78 als rechte Hälfte des 104×78-Bildblocks (Rang 26 + 78).
 * GS-Zeile: volle 104×78 ohne Rang-Block — beide enden bei x=120.
 * ⚠ Das Seitenverhältnis steht HIER und nicht als aspect-ratio:1/1 auf beiden:
 * Ein gemeinsames Quadrat hatte die GS-Kachel auf 104×104 gezogen und die
 * Zeile um 26px höher gemacht als auf Live. Das Feed-Maß ist 104×78. */
.mb-mmb__cover-bild { aspect-ratio: 1 / 1; }
.mb-mmb__thumb-bild { aspect-ratio: 104 / 78; }

/* ── GS-Zeile: volles Thumbnail, KEIN Rang-Block (fluchtet mit den Charts) ─ */
.mb-mmb__thumb { flex: 0 0 104px; }   /* ⚠ 0 0: sonst drückt der Flex-Kontext */
.mb-mmb__gs .mb-mmb__thumb-bild { border-radius: 3px; }

/* ── Jahres-Zwischenüberschrift ────────────────────────────────────────── */
.mb-mmb__jahr {
    padding: 12px 16px 4px;
    font-size: var(--mb-fs-kicker, 14px);   /* Spec sagt 13 — 14er-Schriftboden gewinnt */
    font-weight: var(--mb-fw-kicker, 600);
    color: #55555E;
}
body.mb-dark .mb-mmb__jahr { color: #B6B6BE; }

/* ── Listen-Container der Charts (Sortable-Vertrag: ol > li) ───────────── */
.mb-mmb__inhalt ol,
.mb-mmb__sektion > ol {
    list-style: none;
    margin: 0;
    padding: 0;
}

/* ⚰ grabstein: teaser-raenge-ausgeblendet
   (3.10.1 blendete die Rang-Bloecke im Teaser aus — Anlass war Stephans Fund
   „zeigt fuer beide Eintraege die #1" — samt 26px-Flucht-Kompensation am
   Cover. ZURUECKGENOMMEN in 3.10.3 auf Stephans Revision, woertlich: „Der
   Rand mit den Nummern sollte nicht weggenommen werden, einfach die Ziffern
   richtig — jetzt sieht das Thumbnail nicht standardgemaess aus — bitte
   wieder den alten View mit Nummern (nur richtig)."

   WAS DARAUS BLEIBT — nicht noch einmal herleiten:
   · Die Diagnose war richtig und ist unveraendert gueltig: Es ist KEIN
     Zaehlfehler. Im Teaser stehen die Listen-Ersten zweier Kategorien
     nebeneinander, jede mit dem korrekten Rang IHRER Jahresliste; verborgen
     sind nur die Kategorie-Ueberschriften. Falsch war die THERAPIE.
   · Die Rang-Spalte traegt die Anatomie: Rang (26) + Cover (78) enden
     gemeinsam bei x=410, buendig mit dem GS-Thumb, darauf steht die
     Textflucht 422. Wer die Spalte entfernt, muss die 26px ersetzen — und
     selbst mit Ersatz sah Stephan das schmalere Thumbnail sofort.
   · Die Zustands-Klasse `is-teaser` BLEIBT (Server + JS, beide Richtungen):
     Sie kostet nichts, ist dokumentiert und favorites' Vorschau-Arbeit
     (#13b) kann sie brauchen. Entfernt ist nur die Optik.
   Offen bei Stephan, NICHT vorbauen: was „Ziffern richtig" heisst — Variante
   C (Raenge bleiben, kleines Listen-Label an der Teaser-Zeile) oder A
   (Vorschau aus EINER Liste, dann #1/#2 — das aendert allerdings seinen
   Auswahl-Entscheid vom 14.08.).
   ⚠ 11.09.2026: Der volle Wortlaut daruber („Der Rand mit den Nummern
   sollte nicht weggenommen werden, einfach die Ziffern richtig …“) ist
   nicht reproduzierbar — einziger Treffer im Summary-Kanal, nicht in einer
   getippten Nachricht. KEIN Beleg fuer „nie gesagt“; am 20.08. kamen Bilder,
   und um 09:48 nimmt er ab: „deployed - nummern passt, x auch“.
   Siehe docs/zuschreibungen-befund.md, „Gegenprobe 11.09.2026“. */