/* ========================================================== Fahrradshop24 – ruhiger Sticky-Header für den globalen Blocksy- Header (siehe inc/header-sticky.php für den Ladeort/die Begründung, warum dies eine Child-CSS-Ergänzung ist statt der Blocksy-eigenen Sticky-Einstellung). Referenz: design-reference/index-mockup.html, ".site-header" (Zeile ~112 Basis-Fassung, Zeile ~1596 finale dunkle Fassung, die in der Kaskade gewinnt) – dort ausschließlich natives CSS: "position:sticky; top:0;", KEIN JavaScript, kein Shrink-/ Transparent-Umschalten beim Scrollen. Genau dieses ruhige Verhalten wird hier repliziert: kein Scroll-Listener, kein Springen, kein Hoch-/Runterschwingen, keine manuelle "padding-top"-Kompensation nötig – "position:sticky" bleibt Teil des normalen Dokumentflusses und reserviert seinen Platz automatisch, im Gegensatz zum alten Ridez-Snippet (Snippet-ID 145, deaktiviert, siehe inc/sticky-header-snippet-145-backup.md), das mit "position:fixed" + hartkodiertem "body{padding-top:160px}" arbeitete. Im Mockup ist ".topbar" (Versand-/Servicezeile) ein separates Geschwisterelement VOR ".site-header" und bleibt dadurch beim Scrollen NICHT sticky – nur der Logo/Suche/Navigation-Block darunter. In unserem Blocksy-Header liegt die Topbar-Zeile ("top-row") technisch INNERHALB desselben "#header"-Elements wie Logo/Suche ("middle-row") und Navigation ("bottom-row"), es gibt also kein separates äußeres Element, das die Topbar automatisch ausschließen würde. Um dasselbe Verhalten (Topbar scrollt weg, Logo/Suche/Nav bleiben sichtbar – Punkt "Mobile ebenfalls sauber, nicht unnötig viel Bildschirmhöhe belegen" aus dem Auftrag) zu erreichen, werden hier gezielt nur "middle-row" und "bottom-row" sticky, "top-row" bleibt im normalen Fluss und scrollt mit weg. Warum keine Blocksy-eigene "Sticky Header"-Einstellung: read-only geprüft (Customizer-Header-Builder-Einstellung "has_sticky_header", siehe wp-content/themes/blocksy/inc/panel-builder/header/ dynamic-styles.php sowie .../components/builder/ builder-header-renderer.php get_header_height()) – der zugehörige PHP-Datenfluss (customizer-builder.php load_dynamic_css_for_section) übergibt die Einstellung ausschließlich verschachtelt als "$atts['has_sticky_header']", die Bedingungsprüfung in dynamic-styles.php liest jedoch die unverschachtelte Variable "$has_sticky_header" – die wird an dieser Stelle nie befüllt. Per direktem PHP-Test (blocksy_output_header(), Blocksy_Manager:: instance()->builder->dynamic_css('header', …)) bestätigt: weder das "data-sticky"-Attribut noch die CSS-Variable "--header-sticky-height" werden erzeugt, unabhängig vom gesetzten theme_mod-Wert – kein Cache-Problem (auch nach Dynamic-CSS- und WP-Fastest-Cache-Purge unverändert, auch per direktem PHP-Aufruf ohne jede HTTP-Cache-Beteiligung reproduzierbar). Da wp-content/themes/blocksy/ geschütztes Parent-Theme ist, wurde dieser Zustand nicht gepatcht; der testweise gesetzte theme_mod (header_placements → sections[0].settings.has_sticky_header) wurde wieder vollständig zurückgesetzt (siehe git-Historie), da er ohne Wirkung blieb. Stattdessen diese kleine, isolierte Child-CSS-Ergänzung, wie im Auftrag ausdrücklich als Rückfalloption vorgesehen ("Nur falls nötig eine kleine isolierte Child-CSS/JS- Ergänzung verwenden"). "top"-Werte unten sind die tatsächlich gemessenen Höhen der "middle-row" (per Playwright/Chrome-Screenshot-Session ermittelt, nicht geschätzt) – Desktop 110px, Mobile 80px – exakt die Höhe, bei der "bottom-row" nahtlos direkt darunter andockt, ohne Lücke oder Überlappung. ========================================================== */ /* Geräte-Wrapper direkt gescopt (statt eine eigene max-width-Grenze zu raten): Blocksy rendert "[data-device=desktop]" und "[data-device=mobile]" immer beide ins Markup und blendet je nach Breite eines davon per eigenem CSS aus (display:none/height:0) – diese Regeln greifen dadurch automatisch nur beim jeweils aktiven Gerät, ohne eine zweite, potenziell abweichende Bruchgrenze zu riskieren. */ /* Voraussetzung, damit "position:sticky" unten überhaupt greift: Blocksys eigenes Parent-Theme-CSS setzt auf "#main-container" sowohl "overflow:hidden" als auch (als Ergänzung/Fallback) "overflow:clip" (wp-content/themes/blocksy/static/bundle/main.min.css) – JEDES "position:sticky" innerhalb eines Vorfahren mit "overflow" ungleich "visible" wird dadurch komplett wirkungslos (CSS-Spezifikation, kein Blocksy-Bug an dieser Stelle). Da wp-content/themes/blocksy/ geschütztes Parent-Theme ist, wird hier NICHT die Vendor-Datei gepatcht, sondern die Standard-Lösung für genau diesen Fall verwendet. Bewusst "overflow-x:clip" statt "overflow-x:hidden": Browser rechnen ein gemischtes Achsenpaar "hidden"/"visible" automatisch zu "auto"/"auto" um (dokumentiertes CSS-Verhalten) – "auto" gilt weiterhin als Scroll-Container und würde "position:sticky" genauso blockieren wie "hidden". "clip" ist die einzige Achsen-Vorgabe, die erstens NICHT auf "auto" umgerechnet wird und zweitens selbst keinen Scroll-Container erzeugt (CSS Overflow Module Level 3) – damit bleibt "overflow-y:visible" tatsächlich "visible" (per Chrome-DevTools-Protocol-Messung bestätigt) und "position:sticky" funktioniert. Die horizontale Clipping-Absicht (kein horizontales Scrollen durch volle Breite ausbrechende Elemente) bleibt über "overflow-x:clip" gleichwertig zu Blocksys eigenem "overflow:clip" erhalten. Betrifft ausschließlich dieses eine Element, keine Änderung an "#main-container"s Layout (display/flex-direction/ min-height) selbst. */ #main-container { overflow-x: clip; overflow-y: visible; } /* KORREKTUR Flacker-Bug (per Playwright/Chrome-Scrolltest auf Staging reproduziert und Ursache messtechnisch verifiziert, siehe unten): Beim Umschaltpunkt begann der kompakte Sticky-Zustand ("fs24-header-stuck") teils sehr schnell zwischen normal und kompakt zu oszillieren (bis zu mehrere hundert Klassenwechsel pro Sekunde gemessen), sowohl bei langsamem Scrollen exakt am Schwellenwert als auch bei schnellem Hoch-/Runterscrollen über den Schwellenwert hinweg. Gemessene Ursache (Playwright, echte Maus-Wheel-Events, GDPR-Consent vorher weggeklickt, "scroll-behavior:smooth" testweise deaktiviert, um Animations-Artefakte auszuschließen - die Oszillation trat trotzdem unverändert auf, ist also kein Test-Artefakt): CSS Scroll Anchoring (Standardverhalten aller modernen Browser, "overflow-anchor:auto"). "middle-row"/"bottom-row" wechseln beim Stuck-Umschalten per "display:none" schlagartig die Höhe von #header um 126px (195px voll <-> 69px kompakt). Diese Höhenänderung passiert exakt an der Stelle, an der Scroll Anchoring aktiv nach einem "Anker"-Element sucht, dessen Position es beim Reflow automatisch kompensiert, um dem Nutzer einen optisch stabilen Scroll-Eindruck zu geben (dasselbe Browser-Feature, das z. B. verspätet nachladende Bilder oberhalb des Viewports abfedert). Direkt gemessen: der Browser passt "window.scrollY" nach jedem Stuck-Umschalten automatisch um einen Betrag nahe der 126px- Höhendifferenz an - dieser künstliche Sprung reißt "scrollY" wieder auf die jeweils andere Seite des Schwellenwerts, wodurch der IntersectionObserver in assets/js/header-sticky.js sofort erneut feuert und exakt umgekehrt umschaltet - eine sich selbst erhaltende Rückkopplungsschleife, angetrieben ausschließlich durch die eigene Höhenänderung des Zustands, nicht durch echtes Scrollen des Nutzers (in einem Kontrolltest bei ruhig gehaltenem "scrollY" wurden bis zu ~280 Klassenwechsel/Testlauf gemessen, alle bei unverändertem "scrollY"). Getestet und verworfen: "overflow-anchor:none" NUR auf "#header" bzw. "#header" + all seine Nachfahren gesetzt behob das Problem NICHT (identische Oszillation weiterhin messbar) - der vom Browser tatsächlich gewählte Anker-Knoten liegt außerhalb des "#header"- Teilbaums (vermutlich im nachfolgenden Seiteninhalt, dessen Viewport-Position sich durch die Höhenänderung von #header ebenfalls verschiebt). "overflow-anchor:none" auf "body" (bzw. gleichwertig "html") unterbindet die Ankerwahl dagegen im gesamten Dokument und behebt die Oszillation vollständig und reproduzierbar (Kontrolltest danach: von ~280 auf exakt 3 Klassenwechsel im identischen Testlauf, jeder einzelne einer echten, beabsichtigten Scroll-Schwellenwert-Überquerung zuordenbar, "scrollY" folgt danach exakt den echten Wheel-Eingaben ohne jeden Offset/Verlust). Kein Debounce, kein Timing-Trick, kein Eingriff in Sticky-Mechanismus oder Design - nur die eine Browser-Funktion abgeschaltet, die nachweislich die Rückkopplung verursacht. Seitenweiter Effekt: Scroll Anchoring greift dadurch auch an anderen Stellen der Seite nicht mehr (z. B. bei spät nachladenden Bildern oberhalb des sichtbaren Bereichs) - eine gezieltere Eingrenzung auf nur den Header-Bereich wurde nachweislich getestet und funktioniert nicht, siehe oben. */ body { overflow-anchor: none; } /* KORREKTUR (per Playwright/Chrome-Scrolltest auf Staging reproduziert): Sticky auf den einzelnen Zeilen ("middle-row"/"bottom-row") wirkte NICHT wie beabsichtigt - der komplette Header rutschte beim Scrollen trotzdem aus dem Viewport. Ursache: Der "containing block" einer position:sticky-Box ist immer ihr nächster Block-Vorfahre (CSS-Spec, unabhängig von dessen eigenem "position"-Wert) - hier also "[data-device=desktop]" bzw. das umschließende "#header"-Element selbst. Dieses Element ist aber exakt so hoch wie seine drei Zeilen zusammen (Topbar + Middle + Bottom = 195px Desktop / 215px Mobile) - es gibt also keinerlei zusätzlichen "Spielraum", innerhalb dessen die sticky Zeile beim Scrollen stehen bleiben könnte. Gemessen: die Zeile blieb dadurch nur für ca. 35-99px Scrollweite stehen und scrollte danach ganz normal mit dem restlichen Header weiter nach oben aus dem Bild - der eigentliche Bug hinter dem gemeldeten Verhalten. Lösung: "position:sticky" stattdessen auf "#header" selbst setzen (dessen Eltern-Element ist "#main-container" mit 6000+px Höhe - genug Spielraum für die ganze Seite) und per negativem "top" exakt um die Höhe der (weiterhin nicht-sticky) Topbar nach oben verschieben. Effekt: Bis Topbar-Höhe scrollt der Header ganz normal mit (Topbar verschwindet sichtbar nach oben, wie bisher gewollt), danach bleibt "#header" komplett fixiert - die Topbar liegt dann exakt außerhalb des Viewports, Middle-/Bottom-Row docken lückenlos bei top:0 an, weil es exakt derselbe, unveränderte interne Zeilen- Stapel ist wie im normalen Fluss - kein separates Zeilen-Timing, keine zwei Sticky-Ebenen, kein Springen. Kein JavaScript, keine "padding-top"-Kompensation, kein negativer Margin - "top" ist bei position:sticky ein regulärer, spezifikationskonformer Sticky- Offset, kein Margin-Hack. Die beiden "top"-Werte sind die live gemessenen Topbar-Höhen (Playwright/Chrome, nicht geschätzt): 35px Desktop, 32px Mobile. Breakpoint 999.98px exakt aus Blocksys eigenem main.min.css übernommen ("#header [data-device=desktop]{display:none}" ab max-width:999.98px), damit kein zweiter, potenziell abweichender Breakpoint entsteht. */ #header { position: sticky; } @media (min-width: 1000px) { #header { top: -35px; } } @media (max-width: 999.98px) { #header { top: -32px; } } /* Sentinel für die Stuck-Erkennung per IntersectionObserver, siehe inc/header-sticky.php (Einfügeort) und assets/js/header-sticky.js (Beobachtungslogik, Begründung gegen einen Scroll-Listener). Rein strukturell, nie sichtbar. */ #fs24-sticky-sentinel { height: 1px; margin: 0; padding: 0; } /* ========================================================== Kompakter Sticky-Zustand (Desktop, min-width:1000px) – Klasse "fs24-header-stuck" wird ausschließlich von assets/js/header-sticky.js gesetzt, genau dann, wenn der obige CSS-Sticky-Clamp bereits greift. Die Navigation ("#header-menu-1") wird von derselben Datei zusätzlich von bottom-row nach middle-row/[data-column="middle"] verschoben (derselbe, unveränderte DOM-Knoten – kein Klon, keine neue Menü-Logik) – nur so ergibt sich EINE kompakte Zeile (Logo/Navigation/Icons) statt zwei gestapelter Blocksy-Zeilen, ohne die verschachtelten display:grid/flex-Wrapper der übrigen Blocksy-Ausgabe anzutasten. Nur Desktop – unter 1000px bleibt das komplett unangetastete Mobile-/Offcanvas-Markup unberührt (siehe header-sticky.js, dort ebenfalls per matchMedia gegen 1000px abgesichert). ========================================================== */ @media (min-width: 1000px) { /* KORREKTUR (per Playwright/Chrome-Messung auf Staging bei scrollY=500 reproduziert): "#header" trägt weiterhin den Topbar-Offset "top:-35px" von oben (kompensiert dort die 35px hohe, weiterhin im Fluss befindliche "top-row"). Sobald "fs24-header-stuck" aktiv ist, wird "top-row" zwei Regeln weiter unten aber per "display:none" komplett aus dem Fluss entfernt - "middle-row" ist dadurch der tatsächlich erste Inhalt von "#header" und beginnt bei 0px relativ zum "#header"-Rahmen, nicht mehr bei 35px. Der weiterhin auf "#header" wirkende Offset "top:-35px" schiebt diesen Inhalt dadurch 35px zu weit nach oben aus dem Viewport (gemessen: "middle-row".getBoundingClientRect().top === -35 statt 0, Logo/Navigation/Icons entsprechend mit negativem "top" abgeschnitten). Da im gestickten Kompakt-Zustand keine ausgeblendete Zeile mehr oberhalb von "middle-row" liegt, für die noch Platz reserviert werden müsste, muss der Offset hier exakt auf 0 zurückgesetzt werden (kein neuer Wert geschätzt - 0 ist exakt die gemessene fehlende Differenz). Höhere Spezifität durch ".fs24-header-stuck" (Klasse + ID) gewinnt automatisch gegen die einfache "#header{top:-35px}"-Regel oben, unabhängig von der Quellreihenfolge - kein "!important" nötig. Betrifft ausschließlich den gestickten Kompakt-Zustand ab 1000px; der normale (nicht gestickte) Header sowie Mobile (siehe eigener "@media (max-width:999.98px)"-Block oben, dort unverändert "top:-32px") sind davon nicht betroffen. */ #header.fs24-header-stuck { top: 0; } #header.fs24-header-stuck [data-device="desktop"] [data-row="top"], #header.fs24-header-stuck [data-device="desktop"] [data-row="bottom"] { display: none; } #header.fs24-header-stuck [data-device="desktop"] [data-row="middle"] > .ct-container { min-height: 0; padding-top: 10px; padding-bottom: 10px; } #header.fs24-header-stuck [data-device="desktop"] [data-row="middle"] [data-column="middle"] { justify-content: center; } /* Logo: dasselbe Bild, dieselbe Verlinkung, nur kleiner (Ziel 32–40px Bildhöhe, siehe Auftrag Abschnitt 4). Bewusst per Höhe auf ".site-logo-container" statt über einen zweiten theme_mod, da "logoMaxHeight" global für den GESAMTEN, nicht gestickten Header gilt und dort unverändert bleiben muss (siehe blocksy-header-preview.css, Abschnitt 3). */ #header.fs24-header-stuck [data-device="desktop"] .site-branding .site-logo-container { height: 36px; padding: 0 10px; border-radius: 8px; } #header.fs24-header-stuck [data-device="desktop"] .site-branding .site-logo-container img { height: 100%; width: auto; } /* Die große Suche bleibt unverändert im DOM (header-sticky.js verschiebt sie nie, nur die Navigation) – im kompakten Zustand aber standardmäßig unsichtbar, an ihrer Stelle steht dann die verschobene Navigation. Sichtbar wird sie nur über den Aufklapp-Zustand weiter unten. */ #header.fs24-header-stuck [data-device="desktop"] [data-row="middle"] [data-column="middle"] > [data-items] { display: none; } /* KORREKTUR (Auftrag "Sticky Header bitte nur noch horizontal feinjustieren" – per Playwright/Chrome computed-style-Messung auf Staging bei scrollY=400 nachgewiesen): "[data-column=middle]" trägt zwar bereits "justify-content:center" (Regel weiter oben, unverändert), zentriert damit aber nur ihr EIGENES Flex-Kind ".menu-container" – und das behält aus Blocksys normaler bottom-row-Regel unverändert "width:1019.92px" (bzw. 859.92px bei 1280px), also exakt die volle Spaltenbreite. Ein bereits volles Flex-Kind lässt sich nicht mehr zusätzlich zentrieren, es füllt den Platz ja schon komplett aus. Die eigentlich sichtbare Nav (".menu-container"s Kind "ul.menu", seit der letzten Korrektur "flex:0 0 auto" mit ihrer natürlichen Inhaltsbreite von gemessen 687px) hing dadurch am linken Rand von ".menu-container" – und damit direkt neben dem Logo – fest, weil ".menu-container" selbst kein eigenes "justify-content" gesetzt hatte (Default "normal"/"flex-start"). Lösung: "justify-content:center" eine Ebene tiefer auf ".menu-container" selbst (den eigentlichen "Nav-Wrapper", wie im Auftrag benannt) statt nur auf die Spalte – zentriert die natürlich breite "ul.menu" jetzt tatsächlich innerhalb der vollen Spaltenbreite, also visuell mittig zwischen Logo und Icon-Block. Betrifft ausschließlich die Positionierung der Gruppe als Ganzes; "ul.menu"s eigenes "justify-content:flex-start" (Regel unten, unverändert) sowie ihr "gap" bleiben unangetastet – da "ul.menu" exakt so breit wie ihr Inhalt ist, hat sie ohnehin keinen zusätzlichen Innenraum mehr zu verteilen, die einzelnen Menüabstände ändern sich durch diese Änderung nicht. */ #header.fs24-header-stuck [data-device="desktop"] [data-row="middle"] [data-column="middle"] > #header-menu-1.menu-container { display: flex; justify-content: center; } /* KORREKTUR (Auftrag "Sticky Header nochmals feinjustieren", Punkt 2 – per Playwright/Chrome computed-style-Messung auf Staging bei scrollY=300 nachgewiesen): Blocksys eigenes main.min.css gibt "ul.menu" hier "flex:1 1 0%" + "justify-content:space-between" vor (dort korrekt, weil "ul.menu" in der normalen bottom-row deren volle Breite allein für sich hat). Sobald header-sticky.js dieselbe UL in die middle-row/[data-column="middle"] verschiebt, erbt sie diese beiden Werte unverändert mit – "flex:1 1 0%" lässt sie auf die volle Breite der middle-Spalte wachsen (gemessen: 1020px statt ihrer natürlichen Inhaltsbreite), "space-between" verteilt die 7 Einträge danach über genau diese volle Breite (gemessene Abstände zwischen den Items 122–222px statt der gewünschten 22px) – exakt das gemeldete "Auseinanderziehen". Das umgebende "justify-content:center" auf "[data-column=middle]" (oben, unverändert) wirkt dabei nie, weil die UL als einziges Flex-Kind mit "flex-grow:1" den gesamten verfügbaren Raum selbst beansprucht, bevor "justify-content" der Elternspalte überhaupt noch etwas auszurichten hätte. Lösung: "flex" hier auf die natürliche Inhaltsbreite zurücksetzen ("0 0 auto", genau wie im normalen Header, siehe blocksy-header-preview.css Abschnitt 8, dort ohne "flex" also Browser-Default "0 1 auto" – hier explizit, weil Blocksys "1 1 0%" sonst gewinnen würde) und "justify-content" auf "flex-start" (die UL ist dadurch nur noch so breit wie ihr Inhalt, "space- between" hat innerhalb der eigenen Breite dadurch keinen zusätzlichen Raum mehr zu verteilen). Das bereits vorhandene "justify-content:center" der Elternspalte übernimmt danach wieder die Zentrierung der jetzt kompakten Gruppe – dieselbe Dichte (22px Gap) wie zuvor beabsichtigt, nur jetzt tatsächlich wirksam statt von "space-between" überschrieben. */ #header.fs24-header-stuck [data-device="desktop"] [data-row="middle"] [data-column="middle"] > #header-menu-1.menu-container > ul.menu { flex: 0 0 auto; justify-content: flex-start; gap: 22px; } } /* KORREKTUR (per Playwright/Chrome-Messung auf Staging bei 1024px nachgewiesen, Nebenwirkung der obigen "flex:0 0 auto"-Korrektur): die kompakte Nav-Gruppe hat bei "gap:22px" eine natürliche Inhaltsbreite von gemessen 687px – die "[data-column=middle]" selbst ist aber nicht konstant breit, sondern schrumpft mit dem Viewport (gemessen 1020px bei 1440px, 860px bei 1280px, nur noch 620px bei 1024px). Ab ca. 1220px Viewport-Breite reicht dieser Platz nicht mehr für 687px – gemessen bei 1024px: Nav-Ende bei 867px, Icon-Spalte beginnt aber bereits bei 832px, also 35–67px Überlappung (je nach genauer Messposition) statt sauberer Trennung. Derselbe Breakpoint (1220px) wie bereits an anderer Stelle dieser Installation etabliert (siehe blocksy-header-preview.css Abschnitt zur Topbar, blocksy-footer-preview.css Grid-Umbau) – kein neuer, zweiter Wert geraten. "gap:12px" (statt 22px) spart 6×10px=60px, reicht bei 1024px (620px verfügbar, danach gemessen 627px Nav- Breite → noch 7px zu breit) knapp nicht aus, deshalb zusätzlich "font-size" der Einträge minimal von 13px auf 12px reduziert (bei dieser Schriftgröße ohnehin bereits die kleinste im ganzen Header verwendete Stufe, siehe Vergleich mit der Topbar-Schrift) – beides zusammen gemessen 596px Nav-Breite bei 1024px (24px Luft zur Icon- Spalte) und weiterhin überlappungsfrei bis zur unteren Grenze dieses Sticky-Mechanismus bei 1000px. Betrifft ausschließlich die verschobene Nav im kompakten Sticky-Zustand in diesem schmalen Zwischenbereich – der normale (nicht gestickte) Header sowie die breiteren Sticky-Zustände ab 1220px (siehe Regel oben, dort unverändert 22px/13px) sind davon nicht betroffen. */ @media (min-width: 1000px) and (max-width: 1220px) { #header.fs24-header-stuck [data-device="desktop"] [data-row="middle"] [data-column="middle"] > #header-menu-1.menu-container > ul.menu { gap: 12px; } #header.fs24-header-stuck [data-device="desktop"] [data-row="middle"] [data-column="middle"] > #header-menu-1.menu-container > ul.menu > li > a.ct-menu-link { font-size: 12px; } } @media (min-width: 1000px) { /* Wunschliste + Widerruf: laut Auftrag NICHT Teil der kompakten Zeile (Wunschliste bleibt exklusiv im großen Header, Widerruf ebenso). Konto + Warenkorb bleiben sichtbar, Suchlupe siehe unten. */ #header.fs24-header-stuck [data-device="desktop"] [data-row="middle"] [data-column="end"] [data-id="fs24-w"], #header.fs24-header-stuck [data-device="desktop"] [data-row="middle"] [data-column="end"] [data-id="fs24-l"] { display: none; } #header.fs24-header-stuck [data-device="desktop"] [data-row="middle"] [data-column="end"] .fs24-header-action, #header.fs24-header-stuck [data-device="desktop"] [data-row="middle"] [data-column="end"] .ct-cart-item { width: 38px; height: 38px; } /* Suchlupe: eigenes, kleines Button-Element (einmalig per JS eingefügt, siehe header-sticky.js) – bekommt automatisch dieselbe Optik wie Konto/Warenkorb über die bereits bestehende ".fs24-header-action"-Regel (blocksy-header-preview.css, Abschnitt 5), weil es dieselbe Klasse trägt – genau DESHALB müssen die beiden folgenden Regeln denselben vollen Selektor- Pfad (inkl. "#header [data-device] [data-row] [data-column]") verwenden statt nur ".fs24-sticky-search-toggle": eine kürzere, weniger spezifische Regel würde gegen jene Abschnitt-5-Regel (dieselbe Spezifität durch dieselbe Selektorlänge, siehe dort) je nach Ladereihenfolge verlieren und "display:flex" von dort gewinnen lassen – kein "!important" nötig, nur passende Spezifität. Sichtbarkeit: im normalen, nicht gestickten Header nie sichtbar. */ #header [data-device="desktop"] [data-row="middle"] [data-column="end"] .fs24-sticky-search-toggle { display: none; } #header.fs24-header-stuck [data-device="desktop"] [data-row="middle"] [data-column="end"] .fs24-sticky-search-toggle { display: flex; } /* Aufklappende Suche: dieselbe reale Such-Box (".fs24-header-search", identisches WooCommerce-Formular wie im großen Header, inkl. der von Doofinder for WooCommerce darauf bereits gebundenen Live-Suche) wird beim Lupen-Klick nicht neu erzeugt, sondern nur sichtbar geschaltet und als volle Breite unter die kompakte Zeile gelegt. "position:absolute" ist relativ zu "#header" (bereits "position:sticky" – und damit selbst ein gültiger Containing Block für absolut positionierte Nachfahren; kein Zwischen-Wrapper in der Kette dazwischen hat selbst ein "position" gesetzt, siehe die bestehenden Regeln in blocksy-header-preview.css). */ #header.fs24-header-stuck.fs24-sticky-search-open [data-device="desktop"] [data-row="middle"] [data-column="middle"] > [data-items] { display: block; position: absolute; top: 100%; left: 0; right: 0; margin-top: 1px; padding: 14px 24px; background: #0c0e0f; border-top: 1px solid rgba(255, 255, 255, 0.09); } }