/* Optik des Slider-Bausteins (siehe slider.js). Bewusst mit CSS-Variablen wie bei der Galerie (galerie-render.css) - eine Kundenseite ueberschreibt nur, was nicht passt, statt den ganzen Block neu zu schreiben. Struktur (Klassennamen) ist FEST, das ist der Vertrag mit slider.js. */ .shop-slider { position: relative; overflow: hidden; border-radius: var(--slider-radius, 10px); width: 100%; /* In einem Flex-Elternelement mit align-items:center (statt dem Default "stretch") wuerde der Slider sonst ohne eigene Breite auf die Bildgroesse aufgeblasen (z.B. ein 3000px-Handy- foto sprengt die Karte). align-self:stretch erzwingt die volle Breite unabhaengig vom Eltern-align-items. */ align-self: stretch; aspect-ratio: 1 / 1; background: var(--slider-bg, #f2f2f2); margin-bottom: 1.25rem; /* Kilian, live (14.07.2026): bei einem Foto mit WEISSEM Hintergrund (Flatlay-Produktfoto) war nicht mehr zu erkennen, dass hier ueberhaupt ein Bild sitzt - es "ging einfach ins Modul ueber". ERSTER ANLAUF (verworfen, noch am selben Tag): derselbe Ruhe-Schatten (--shadow), den jede andere Karte traegt. Kilian, live: "dass es abhebt", "sieht aus wie ein Overlay", "sieht nicht aus, als waere es eingefuegt" - ein Schlagschatten hat Y-Versatz UND Weichzeichnung, das ist genau das Vokabular fuer "schwebt ueber der Flaeche". Fuer ein FOTO im normalen Leseluss ist das der falsche Eindruck, auch wenn er leise dosiert ist - Karten mit Aktion (Knopf, Klick) duerfen erhoeht wirken, ein Foto soll flach TEIL der Seite bleiben. ZWEITER ANLAUF (verworfen, technisch nicht sichtbar): ein Ring per box-shadow:inset statt Schatten - kein Y-Versatz, kein Blur, also keine Tiefen-/Schwebe-Anmutung. War aber am echten Foto UNSICHTBAR: ein inset-Schatten liegt in derselben Schicht wie der Hintergrund, UNTER dem normalen Fluss der Kind-Elemente. .shop-slide fuellt die Flaeche randlos bis auf den letzten Pixel (width/height 100%, object-fit:cover, kein Abstand) - das Bild deckt den Ring deshalb vollstaendig zu, bevor er ueberhaupt sichtbar wird. DRITTER ANLAUF (dieser Stand): ein ECHTER border statt box-shadow. border liegt (dank box-sizing:border-box, globaler Reset in style.css) in einer EIGENEN Schicht ausserhalb der Inhaltsflaeche - .shop-slide rutscht dadurch selbst 1px nach innen und kann den Rahmen strukturell nicht mehr ueberdecken, ganz unabhaengig vom Fotoinhalt. Weiterhin kein Y-Versatz/Blur (keine Schwebe-Anmutung), nur eine flache Kante. Nutzt denselben Trennlinien-Ton wie ueberall sonst (style.css --border, #DDDDDD) statt eines neuen Farbtons - dieselbe Sprache wie Footer-Trenner/Link-Zeilen, nur hier als Ring statt als Linie. */ border: 1px solid var(--slider-border, rgba(0, 0, 0, 0.1)); } .shop-slider-track { display: flex; height: 100%; transition: transform 0.35s ease; } /* width UND min-width, nicht nur min-width: min-width ist bloss eine UNTERGRENZE - ein echtes Handyfoto (nach dem Verkleinern in bild-verkleinern.js bis zu 1600px lang) hat als ohne festes width seine eigene Intrinsic-Groesse als "Wunschbreite" im Flex-Layout, und flex-shrink:0 verbietet dem Element, davon abzuruecken - es kann also breiter werden als sein Platz und in die naechste Folie hineinragen (Kilian, live: "das komische Bild zieht sich auf die naechste Seite mit rueber, das Zweite wird nicht mehr richtig angezeigt"). width:100% macht die Breite FEST, object-fit:cover schneidet den Bildinhalt darin zu - unabhaengig von der Originalgroesse. */ .shop-slide { width: 100%; min-width: 100%; height: 100%; object-fit: cover; flex-shrink: 0; } .shop-slide-fallback { color: var(--slider-text-muted, #777); font-size: 0.9rem; text-align: center; padding: 0 1rem; } /* Alle Bilder eines Eintrags optional UND leer (z.B. ein Slider mit 3 Slots, von denen keiner befuellt ist): die Lese-Schicht ENTFERNT jeden leeren optionalen Slot (liste-render.js, data-bild-optional -> el.remove()), die Bild-Elemente sind also wirklich weg, nicht nur versteckt. Ohne diese Regel bliebe eine leere graue Box mit Pfeilen ins Nichts stehen - genau das Verhalten, das ein einzelnes optionales Bild (ohne Slider) nie hatte: leer = ganz weg. NUR auf der oeffentlichen Seite (body ohne .editor-bearbeiten): im Bearbeiten-Modus baut liste-inline.js die Karte selbst (baueKarte(), nicht fuelleKarte()) und zeigt jeden leeren Slot als "+ Bild"-Platzhalter - der muss sichtbar bleiben, sonst kann niemand ein Bild hinzufuegen. :not([hidden]) ist entscheidend (live per Bildschirmaufnahme gefunden, 23.07.2026): die drei Bild-Plaetze stehen im rohen HTML IMMER, nur mit "hidden" - bis die Lese-Schicht sie nach dem Laden entfernt. Ohne diesen Zusatz zaehlt :has(.shop-slide) sie schon VOR dem Entfernen als vorhanden, die Regel greift also noch nicht - und genau in dieser Ladeluecke stand der leere Kasten samt Pfeilen und Punkt kurz sichtbar da, obwohl kein einziges Bild existierte. */ body:not(.editor-bearbeiten) .shop-slider:not(:has(.shop-slide:not([hidden]))) { display: none; } /* Schlagschatten am Rand: der helle Kreis geht sonst auf einem HELLEN/weissen Foto unter (Kilian, live: "wenn ich ein weisses Bild einfuege, kann ich die Pfeile nicht mehr sehen"). Die ganze Sprache (heller Kreis auf Fotos) geht davon aus, dass ein Foto meist DUNKLER ist als Weiss - bei einem hellen Produktfoto (z.B. weisses T-Shirt) stimmt das nicht mehr. Ein Schatten schafft IMMER eine sichtbare Kante, unabhaengig davon, was darunter liegt (hell oder dunkel) - anders als bei der Muelltonne (liste-inline.css), wo der feste weisse Karten-Rand einen einfacheren Grauton-Tausch erlaubte: hier ist der Untergrund nie bekannt im Voraus. ERSTER ANLAUF (nicht ausreichend): nur der Schatten, opacity:0.5 im Ruhezustand blieb stehen. CSS opacity wirkt auf das GANZE Element inklusive seines eigenen Schattens - im Ruhezustand kam von 0.45 Schatten-Deckkraft nur noch ~0.22 an, kaum staerker als vorher (Kilian, live: "man sieht's ja immer noch nicht so richtig"). Und genau dieser Ruhezustand ist am Handy der EINZIGE Zustand, den es gibt - :hover existiert dort gar nicht (siehe DESIGN.md: "kein Hover noetig, die Kunden sind am Handy"). Ein Knopf, der erst bei Hover richtig sichtbar wird, ist fuer den Handy- Nutzer also IMMER im schlechteren Zustand. Deshalb jetzt vollstaendig sichtbar von Anfang an, kein Ein-/Ausblenden mehr noetig. ZWEITER ANLAUF (zu laut): Deckkraft UND Schatten gleichzeitig auf Maximum gedreht (0.9 / 0 1px 6px 0.5), um das obige Problem sicher zu erschlagen - loeste es, wirkte dann aber auf einer ruhigen Karte (T-Shirt-Strichzeichnung) selbst zu praesent (Kilian, live: "sehr ueberladen"). Nur der SCHATTEN traegt die Sichtbarkeits-Garantie (er schafft die Kante); die hohe Fuellfarben- Deckkraft war zusaetzliche, unnoetige Tinte obendrauf - DESIGN.md 5d: "Wirkt ein Zeichen zu schwer, ist der Hebel die TINTE, nicht die GROESSE." Beide Regler jetzt zurueckgenommen, nicht nur einer - durchgerechnet (WCAG-Naeherung): selbst auf einem fast schwarzen Foto bleibt der Kreis effektiv ~189/255 hell, der dunkle Strich (--slider-btn-ink) hat dort immer noch ~9:1 Kontrast, weit ueber den ~3:1 fuer ein Icon. Kleinerer Blur (3px statt 6px) buendelt die Tinte in eine schaerfere Kante statt eines weichen Schleiers - dadurch wahrnehmbar trotz weniger Alpha. DRITTER ANLAUF (verworfen, 14.07.2026): sichtbaren Kreis auf 32px verkleinert, Tippflaeche per unsichtbarem 44px-Rahmen drumherum erhalten. Technisch begruendbar, aber falsch verstanden: 44px ist hier keine reine Mindest-Tippflaeche, die man durch einen unsichtbaren Rand "erfuellen" kann - es ist eine VEREINBARTE DESIGNGROESSE fuer den sichtbaren Kreis selbst (Kilian, live: "das ist eine Designregel... wir haben uns auf 44 Pixel geeinigt"). Zurueckgenommen, ohne Ersatz - die Flaeche bleibt 44px sichtbar, wie ueberall sonst im System. VIERTER ANLAUF (14.07.2026 abends, dieser Stand): der eigentliche Fehler in ANLAUF 2/3 war, dass eine TEILDURCHSICHTIGE Flaeche das Foto immer ein Stueck durchscheinen laesst - Fuellfarbe UND Schatten muessen dann GLEICHZEITIG gegen den Fotoinhalt ankaempfen: hoch genug fuer ein weisses Foto gedreht, wirkt es auf einem ruhigen Foto sofort zu praesent (das "sehr ueberladen" oben). Recherche (drei Agenten, u.a. Airbnb/Booking/Amazon/Zalando/Instagram/Apple - deren fertig gebaute Karussell-Pfeile) zeigt den strukturellen Ausweg: Airbnbs Karussell-Pfeil ist ein VOLL DECKENDER Kreis, keine Transparenz. Das Foto scheint dort gar nicht mehr durch - der Kreis ist ein blickdichter Aufkleber, kein Fenster. Dadurch entfaellt der Kampf komplett: die Fuellfarbe garantiert die Lesbarkeit unabhaengig vom Foto, der Schatten muss nur noch die Kante zeichnen, nicht mehr die Sichtbarkeit selbst tragen - er darf deutlich leiser sein. (Amazon/Apple loesen es anders - Pfeil neben statt auf dem Foto, auf einem plattform-eigenen Rand/Verlauf -, das passt hier nicht: die Kundenfotos sind randlos, der Slider liegt direkt auf dem ganzen Foto. Instagram/Zalando-Mobile lassen den Knopf ganz weg (Wischen + Fortschrittsbalken) - saubere Loesung, aber sie hebt die vereinbarte 44px-Kreis-Regel auf, das ist ein separater Entscheid, kein Feintuning.) FUENFTER ANLAUF (14.07.2026, dieser Stand): Kilian am echten T-Shirt-Foto - der blickdichte Kreis aus Anlauf 4 loeste die Lesbarkeit, wirkte am echten Foto aber wieder als eigenstaendiger Aufkleber, der mehr Aufmerksamkeit zieht als das Foto selbst ("man achtet mehr auf die Knoepfe als aufs Bild"). Der Fehler in Anlauf 2/4 war derselbe Reflex in beide Richtungen: Deckkraft rauf = sicher lesbar, aber ein Objekt AUF dem Foto; Deckkraft runter = Teil des Fotos, aber unzuverlaessig lesbar. Matte-Glas-Loesung (Recherche: iOS-Bedienelemente, Instagram-Stories- Antwortleiste) loest den Widerspruch STRUKTURELL statt graduell: backdrop-filter weichzeichnet den Fotoinhalt UNTER dem Kreis, bevor die halbtransparente Fuellung draufliegt - dadurch verliert der Fotoausschnitt seine Kontrastspitzen (das war das eigentliche Lesbarkeits-Risiko bei reiner Transparenz), der Kreis bleibt aber sichtbar TEIL des Fotos statt eines separaten Aufklebers. DESIGN.md 5d: "Wirkt ein Zeichen zu schwer, ist der Hebel die TINTE, nicht die GROESSE" - deshalb zusaetzlich der Pfeil selber duenner (stroke-width 1.5 statt 2), 44px-Kreisflaeche unveraendert (vereinbarte Groesse aus Anlauf 3 bleibt stehen, nur was DARIN passiert wird leiser). Faellt backdrop-filter weg (aeltere Browser ohne Unterstuetzung): @supports-Fallback auf den blickdichten Anlauf-4-Kreis, damit die Lesbarkeits-Garantie nie verloren geht. Kilian, live (nach Anlauf 5): Richtung stimmt, noch leiser/transparenter. Deckkraft von 0.55 auf 0.32 gesenkt; Blur von 6px auf 8px angehoben, damit der Fotoinhalt trotz weniger Fuellfarbe nicht wieder seine Kontrastspitzen durchdrueckt (derselbe Mechanismus wie in Anlauf 5, nur staerker dosiert). Schatten minimal mitgesenkt (0.18 -> 0.14), reine Kantenzeichnung. SECHSTER ANLAUF (14.07.2026): Kilian, live, am WEISSEN Produktfoto (Flatlay-T-Shirt auf weissem Grund, nicht das Skatepark-Foto) - bei 0.32 Deckkraft war der Kreis dort fast unsichtbar. Ursache strukturell, nicht nur "noch mehr Deckkraft rauf/runter drehen": Blur weichzeichnet nur vorhandene Kontraststruktur im Hintergrund - eine FLAECHIG einfarbige weisse Flaeche hat keine Struktur zum Weichzeichnen, Blur ist dort wirkungslos, und 0.32 Weiss auf Weiss bleibt praktisch unsichtbar (dasselbe Grundproblem wie ganz am Anfang, Anlauf 1). Deshalb nicht an der Fuellung weiterdrehen, sondern am SCHATTEN: der haengt nicht vom Fotoinhalt ab und zeichnet die Kante auch auf reinem Weiss. Zwei Ebenen statt einer: ein weicher Schlagschatten fuer Tiefe (blur 3px) PLUS ein hauchduenner 1px-Ring bei niedriger Deckkraft, der die Kante GARANTIERT zeichnet, unabhaengig davon, ob der Foto-Untergrund Struktur zum Weichzeichnen bietet oder nicht. Fuellflaeche/Blur unveraendert (0.32 / 8px) - die bleiben fuer strukturierte Fotos (Skatepark) die leise Matte-Glas-Optik, der Ring greift zusaetzlich ueberall dort, wo Blur allein nichts zu tun haette. NOCH OFFEN: Kilian muss auch DIESEN Stand an BEIDEN Fototypen (Flatlay weiss + Skatepark) absehen, bevor gesynct wird. */ .slider-btn { position: absolute; top: 50%; transform: translateY(-50%); background: var(--slider-btn-bg, rgba(255, 255, 255, 0.32)); -webkit-backdrop-filter: blur(8px) saturate(180%); backdrop-filter: blur(8px) saturate(180%); border: none; border-radius: 50%; box-shadow: 0 1px 3px rgba(0, 0, 0, 0.22), 0 0 0 1px rgba(0, 0, 0, 0.1); width: 44px; height: 44px; cursor: pointer; color: var(--slider-btn-ink, #222); display: flex; align-items: center; justify-content: center; z-index: 2; } /* Ohne backdrop-filter (aeltere Browser) traegt eine teildurchsichtige Flaeche allein die Lesbarkeit nicht zuverlaessig (siehe Anlauf 1/2 oben) - Rueckfall auf den blickdichten Kreis. */ @supports not ((backdrop-filter: blur(1px)) or (-webkit-backdrop-filter: blur(1px))) { .slider-btn { background: var(--slider-btn-bg-fallback, #fff); } } .slider-btn svg { stroke-width: 1.5; } .slider-prev { left: 10px; } .slider-next { right: 10px; } /* Dunkle Kapsel hinter den Punkten: sonst verschwinden helle Punkte auf einem hellen/weissen Foto (dasselbe Grundproblem wie bei .slider-btn oben). Bleibt so unabhaengig vom Bildinhalt lesbar. War bisher nur als Kundenseiten-Ueberschreibung auf der Shopseite geloest - jetzt Standard fuer jede Seite mit Slider. Etwas leiser als die Pfeile (0.28 statt 0.38, knapperes Polster): die Punkte sind die NEBENSAECHLICHE Lage-Anzeige, die Pfeile die primaere Bedienung - beide gleich laut waere keine Hierarchie (Kilian, live: "sehr ueberladen", siehe .slider-btn oben). */ .slider-dots { position: absolute; bottom: 8px; left: 50%; transform: translateX(-50%); display: flex; gap: 6px; background: rgba(0, 0, 0, 0.28); padding: 4px 7px; border-radius: 999px; } .slider-dot { width: 6px; height: 6px; border-radius: 50%; background: var(--slider-dot, rgba(255, 255, 255, 0.5)); cursor: pointer; transition: background 0.2s; } .slider-dot.active { background: var(--slider-dot-active, rgba(255, 255, 255, 0.95)); } /* Bearbeiten-Modus (Liste-Baustein): der Liste-Baustein packt jedes Bild in