/* Korrekturen am geerbten Theme-CSS — Register M5.
 *
 * WOZU DIESE DATEI EXISTIERT. Drei Darstellungsfehler der WordPress-Seite
 * werden auf Nutzerwunsch behoben (Befunde der Assistentin, PDF vom
 * 2026-09-08; Einordnung Paritaetskontrolleur 1754 §3/§4). Alle drei sitzen
 * in `assets/css/full.css` — und genau diese Datei ist byte-paritaetisch zur
 * Referenz (`36d19e2952942178` auf Referenz, Bau und Live, Register E12/F).
 * Eine Korrektur dort braeche eine gemessene Byte-Gleichheit auf allen
 * Flaechen. Deshalb bleibt `full.css` unangetastet und die Korrekturen
 * stehen hier, in einer eigenen Datei, die NACH `full.css` geladen wird
 * (Koordinator-Entscheidung 2026-09-14 zum Auftrag 1802).
 *
 * WIE SIE WIRKT. Kaskade: `fontawesome.css` (Kopf, vor `full.css`) ->
 * `full.css` -> diese Datei. Alle drei Regeln unten wuerden ihr Gegenstueck
 * in `full.css` schon ueber die Reihenfolge schlagen; wo es ohne Mehrkosten
 * ging, tragen sie zusaetzlich die hoehere Spezifitaet (B-1), damit die
 * Wirkung nicht allein an der Ladereihenfolge haengt. Kein `!important`:
 * es gibt keine konkurrierende Regel, die eines noetig machte, und es waere
 * genau die Abkuerzung, die spaetere Korrekturen unmoeglich macht.
 *
 * WAS HIER NICHT HINEINGEHOERT. Kein neues Aussehen, keine Aufraeumarbeit,
 * kein Vorgriff auf spaetere Register-Punkte. Jede Regel hat ein Befund-
 * kuerzel, einen Beleg und einen gemessenen Sollwert. Was kein Befund ist,
 * bleibt so, wie WordPress es ausgeliefert hat.
 *
 * SOLLWERTE (gemessen, Chromium 145.0.7632.6 / playwright 1.58.0, dsf 1;
 * Belege im Bericht `koordination/berichte/2026-09-14-1802-umsetzer-m5-…`):
 * keine der drei Regeln aendert die Hoehe einer Seite in irgendeinem der
 * drei Viewports 390/900/1280. Sie aendern Pixel, keine Geometrie der
 * Umgebung — das ist Absicht und war das Auswahlkriterium unter den
 * moeglichen Loesungen.
 */

/* S-2 — Schlafrechner: zweistellige Eingaben werden abgeschnitten.
 *
 * Beleg 1754 §4.1: Die Felder sind 22 px (Eingabe) bzw. 23 px (Auswahl)
 * breit, die Schrift ist 20 px. Gemessen mit Roboto 500/20 px:
 * „15" = 22 px, „25" = 24 px, „30" und „40" = 25 px Textbreite. Die
 * Assistentin hatte 40 und 30 eingetragen und sah „4C" / „3C" — die
 * rechten 3 px waren abgeschnitten. Die Auswahlfelder tragen 00–24 bzw.
 * 00–55, also ebenfalls zwei Ziffern.
 *
 * 26 px ist der gemessene Bedarf (25) plus 1 px Reserve; mehr waere
 * Geschmack, weniger schnitte weiter ab. Die Zeilen brechen dadurch nicht
 * um: die weiteste Zeile (Auswahl + „:" + Auswahl + „ Uhr") waechst um
 * 6 px und bleibt auch bei 390 px Viewport weit von der Umbruchgrenze
 * entfernt (gemessen: Hoehe der vier Optionszeilen 89/50/49/49 px vorher
 * wie nachher).
 *
 * GRENZE, bewusst nicht behoben: eine dreistellige Eingabe (etwa 120 min
 * Einschlafdauer) braucht 34 px und wird weiterhin beschnitten. Das war
 * kein Befund; eine Breite fuer drei Ziffern verschoebe das Erscheinungs-
 * bild der Zeile deutlich staerker als der Fehler es rechtfertigt.
 */
.c_sleep-timer .c_sleep-timer__form input,
.c_sleep-timer .c_sleep-timer__form select {
  width: 26px;
}

/* M-1 — Empfehlungskarten: das Bild ragt aus seinem Kasten auf die
 * Ueberschrift.
 *
 * Beleg 1754 §4.2: Der Bildkasten ist 200 x 120 px und zentriert seinen
 * Inhalt; das Bild bekommt volle Breite und freie Hoehe. Ein nahezu
 * quadratisches Foto (beco-gel, 300 x 294) rendert damit 200 x 196 px,
 * ragt 38 px aus dem Kasten, davon 19 px nach unten, und deckt nach Abzug
 * des Aussenabstands 22 px der H3 zu (auf allen elf gemessenen Breiten
 * 320–1280, in Referenz und Bau pixelgleich).
 *
 * Die Korrektur begrenzt das Bild auf beide Kastenmasse statt nur auf die
 * Breite. Damit passt jedes Bild hinein, unabhaengig von seinem
 * Seitenverhaeltnis, und der Kasten behaelt seine 120 px:
 * die Karte wird nicht hoeher, die Seite nicht laenger, nichts darunter
 * verschiebt sich. Drei der sechs Bilder (in sieben Karten, eine ohne Bild)
 * werden sichtbar kleiner — beco-gel 200x196 -> 122x120, fan 200x156 ->
 * 154x120, mozart-bett 200x154 -> 156x120 —, die uebrigen drei bleiben auf
 * das Pixel gleich, weil sie schon vorher in den Kasten passten.
 *
 * VERWORFENE ALTERNATIVE: `min-height` am Kasten statt der Begrenzung am
 * Bild. Sie erhielte die Bildgroesse, machte aber drei Karten 76, 36 bzw.
 * 34 px hoeher und beide Seiten entsprechend laenger — eine Hoehen-
 * aenderung als Nebenwirkung einer Ueberlappungskorrektur, die niemand
 * gefordert hat.
 */
.c_recommendation .c_recommendation__image img {
  width: auto;
  height: auto;
  max-width: 100%;
  max-height: 100%;
}

/* B-1 — /welches-bett/: der „mehr erfahren"-Knopf traegt einen hellblauen
 * Balken und wirkt zweifarbig.
 *
 * Beleg 1754 §4.3: `full.css:400` legt ueber jeden Verweis, der direkt in
 * einem Absatz des Artikeltextes steht, einen Textmarker-Balken
 * (`inset 0 -10px #badbf8`). Bei zwei der drei Empfehlungen hat WordPress
 * (`wpautop`) den Knopf mit in den Fazit-Absatz gezogen — er erbt den
 * Balken und erscheint als violette Pille mit hellblauem Streifen; beim
 * Ueberfahren wechselt der Streifen zusaetzlich die Farbe. Der Knopf der
 * ersten Empfehlung steht direkt im umgebenden Kasten und ist einfarbig.
 *
 * Die Ausnahme gilt genau diesem Knopf, in beiden Zustaenden, und aendert
 * an den Textmarkern der Fliesstext-Verweise nichts (gemessen: 2 von 3
 * Knoepfen auf /welches-bett/ betroffen, 0 von 4 auf /welche-matratze/,
 * kein Fliesstext-Verweis beruehrt). Die uebrigen Deklarationen der
 * Textmarker-Regel (Farbe, Ueberlauf, Uebergang) bleiben stehen: sie
 * verlieren gegen die eigenen Regeln des Knopfes und sind nicht der
 * Befund.
 */
.c_article__content p > a.c_recommendation__button,
.c_article__content p > a.c_recommendation__button:hover {
  box-shadow: none;
}