(2rem, typowy odstęp .wp-block-group z theme.json) potrafi "przeciekać" (collapse) przez header/`.wp-site-blocks`/ aż do , jeśli żaden z nich nie ma paddingu/bordera blokującego to zjawisko. Nasze własne szablony mają już punktową łatę (`main.gd-main { margin-block-start: 0 !important }`, style.css) — ale KAŻDY przyszły endpoint WooCommerce (albo innej wtyczki), który wyrenderuje się przez CUDZY szablon blokowy bez klasy `gd-main`, odziedziczy ten sam błąd, dopóki ktoś go nie zgłosi z osobna. `display: flow-root` na ustanawia własny block formatting context — margines żadnego potomka nie może już "uciec" poza , niezależnie od źródła szablonu. Zero efektów ubocznych: to jedyny cel tej właściwości, nie zmienia niczego widocznego tam, gdzie kolizji i tak nie było (np. strony z gd-main, które już mają nadmiarowe zabezpieczenie punktowe). Celowo GLOBALNE (samo , bez selektora na klasę woocommerce-*) — style.css jest plikiem chronionym (§18 CLAUDE.md), więc reguła współdzielona przez całą witrynę ląduje tutaj, w nie-chronionym pliku, zamiast tam. */ body { display: flow-root; } /* Jaśniejszy pasek pod nagłówkiem na mobile (Safari/Chrome iOS, zgłoszenie Piotra ze zrzutu ekranu telefonu) — WYŁĄCZNIE strona główna (.gd-hero + main.gd-main--flush). Nie udało się tego wiernie odtworzyć w tym środowisku (Chrome desktop nie ma prawdziwego env(safe-area-inset-top), a resize_window nie zmienia realnego viewportu strony w tym embedzie — window.innerWidth zostaje przy 1920px niezależnie od żądanego rozmiaru), więc to poprawka DEFENSYWNA, nie potwierdzona co do dokładnej geometrii przyczyny, tylko co do koloru:

na stronie głównej ma dziś background: transparent (dziedziczy z .wp-block-group), a leży bezpośrednio na , którego tło (--gd-bg, #16132A — jaśniejsze) różni się od tła .gd-hero (--gd-void, #0E0C1D — ciemniejsze, to samo co ). Jeśli na realnym urządzeniu (z innym niż tu safe-area-inset-top i inną dynamiką paska adresu Safari) .gd-hero nie sięga idealnie do y=0, w tej szczelinie prześwituje jaśniejsze tło zamiast ciemnego tła hero — dokładnie taki pasek, jaki widać na zrzucie. Wymuszenie tego samego ciemnego tła na

usuwa kolizję kolorów niezależnie od tego, gdzie dokładnie leży szczelina — do potwierdzenia przez Piotra na telefonie. */ main.gd-main--flush { background: var(--gd-void, #0E0C1D); } /* Koszyk i kasa nie mają własnego szablonu w motywie (brak templates/page-cart.html / page-checkout.html) — WordPress dociąga domyślny blokowy szablon z samej wtyczki WooCommerce, którego

nie ma naszej klasy `gd-main`, więc reguła `main.gd-main { padding-top: calc(var(--gd-header-offset) + 1.5rem) }` (style.css) nigdy się nie stosuje. Efekt: treść (a przede wszystkim pierwszy komunikat "dodano do koszyka") zaczyna się w punkcie 0 dokumentu, czyli dokładnie pod przezroczystym na starcie, fixed nagłówkiem — komunikat wizualnie wchodzi w menu. Celujemy przez klasy na , które WooCommerce dodaje niezależnie od źródła szablonu. DRUGA WARSTWA TEGO SAMEGO PROBLEMU (zgłoszenie Piotra po pierwszej poprawce): to

ma jeszcze WŁASNY, domyślny margin-top: 2rem (globalny odstęp bloku .wp-block-group z is-layout-constrained). Skoro nic nad nim (header.wp-block-template-part — bez wysokości, bo jedyne dziecko .gd-header jest fixed — ani .wp-site-blocks, ani ) nie ma paddingu/bordera, ten margines "przecieka" przez wszystkie z nich (collapsing) aż do . A ma INNE tło niż (zweryfikowane w DevTools: html=rgb(14,12,29), body=rgb(22,19,42)) — stąd widoczny, ciemniejszy pasek na samej górze strony, kończący się dokładnie tam, gdzie zaczyna się (jaśniejsze) tło . Zerujemy margin-top na

i przenosimy cały odstęp na padding-top (już był powyżej) — padding nie collapse'uje, więc dodatkowo domyka block formatting context. */ /* :not(.woocommerce-order-received) w obu selektorach niżej — WooCommerce nadaje TĘ SAMĄ klasę body.woocommerce-checkout całemu procesowi kasy, łącznie ze stroną "Zamówienie otrzymane" (endpoint order-received to wciąż strona Checkout, ID 9). Ta strona ma jednak WŁASNY, kompletny szablon (templates/order-confirmation.html, main.gd-order-confirmation) z pełną, od-krawędzi-do-krawędzi sekcją aury (.gd-order-confirmation__status) — doliczanie jej naszego padding-inline dla "gołego" szablonu Koszyka/Kasy ściskało tę sekcję i ucinało łunę .gd-blob po prawej stronie (zgłoszenie Piotra). Strona potwierdzenia sama zarządza swoim odstępem przez .gd-section (style.css) — nie powinna być tu w ogóle dotykana. */ body.woocommerce-cart main, body.woocommerce-checkout:not(.woocommerce-order-received) main { margin-top: 0; /*

ma klasę has-global-padding, ale --wp--style--root--padding-left/ right rozwiązuje się na 0px (nieustawione w theme.json) — has-global-padding nic więc nie daje. Stąd treść styka się z krawędziami ekranu na mobile (zgłoszenie Piotra). */ padding-inline: var(--gd-pad-x, 1.25rem); } /* TYLKO Koszyk ma nasz właściwy .gd-header (position:fixed, przezroczysty na starcie) — main potrzebuje paddingu równego jego wysokości, żeby treść nie chowała się pod nim. Kasa renderuje INNY, uproszczony nagłówek (header.wp-block-template-part:not(.gd-header) wyżej w tym pliku) — to zwykły, statyczny (position:static, zweryfikowane w DevTools) element w przepływie dokumentu, który sam rezerwuje swoje miejsce. Doliczanie mu tego samego --gd-header-offset (myślanego pod fixed .gd-header) dawało podwójny odstęp — dokładnie tę "za dużą przerwę u góry", którą zgłosił Piotr. Kasa dostaje więc tylko odrobinę oddechu, nie pełną kompensację. */ body.woocommerce-cart main { padding-top: calc(var(--gd-header-offset, 5rem) + 1.5rem); } body.woocommerce-checkout:not(.woocommerce-order-received) main { padding-top: 1.5rem; } @media (max-width: 560px) { body.woocommerce-cart main { padding-top: calc(var(--gd-header-offset, 5rem) + 3rem); } body.woocommerce-checkout:not(.woocommerce-order-received) main { padding-top: 1rem; } } /* --- Formularze (kasa, konto, kontakt Woo) --- */ .woocommerce form .form-row input.input-text, .woocommerce form .form-row textarea, .wc-block-components-text-input input, .wc-block-components-textarea textarea, textarea.wc-block-components-textarea { background: rgba(244, 239, 230, 0.04) !important; border: 1px solid rgba(244, 239, 230, 0.16) !important; border-radius: 8px !important; color: var(--gd-cream, #F4EFE6) !important; padding: 0.85rem 1rem; font-family: var(--gd-font-body, sans-serif); transition: border-color 0.3s ease; } /* ma niespójny, zależny od OS/silnika wygląd — wyłączamy ją, ale WC Blocks i tak rysuje WŁASNĄ strzałkę jako osobny