/* dobre.audio — szerokość i układ panelu rozwijanego mega-menu (.js-sub-menu), wzorowane na zachowaniu menu na x-kom.pl. Sprawdzone na żywo, wrzesień 2026. Stan PRZED poprawką (natywny CSS motywu Hummingbird): panel rozwijanego podmenu miał "left:0; right:0" względem
— czyli zawsze pełną szerokość strony, niezależnie którą kategorię pierwszego poziomu się najechało. Dla kategorii po prawej stronie paska nawigacji dawało to efekt, że jej podkategorie wyświetlały się po SKRAJNIE LEWEJ stronie ekranu, daleko od najechanego linku — zgłoszenie użytkownika: "u nas ma całą szerokość strony i wybierając ostatnią kategorię po prawej, jej podaktegorie są po skrajnej lewej [...] Rzuć okiem na menu rozwijane na x-kom - jest ono wąskie i pole menu przesuwa się wraz z wybraną kategorią". Poprawki poniżej (w kolejności wdrażania, każda sprawdzona na żywo): 1) Panel przypięty do lewej krawędzi SWOJEJ kategorii (nie całego headera) i wąski (dopasowany do treści, max-width jako górny limit) — ".ps-mainmenu__tree > li" dostaje "position:relative", więc ".js-sub-menu" (jego potomek w DOM) pozycjonuje się względem NIEGO, a nie względem całego
. Dla dwóch ostatnich pozycji w menu panel jest zamiast tego przypięty do PRAWEJ krawędzi (nth-last-child), żeby nie wychodził poza widoczny obszar strony. 2) Naprawa: "top" musi być "100%" (a nie sztywne px odziedziczone z poprzedniej wersji, liczone względem headera) — inaczej, po zmianie kontekstu pozycjonowania w punkcie (1), między linkiem a panelem powstawała ~67px pionowa szczelina, przez którą mysz "wypadała" z obszaru hover i menu zamykało się, zanim dało się dojechać do podkategorii. Zgłoszenie użytkownika: "nie moge zjechac myszka na subkategorie bo menu znika". 3) Lewa kolumna (".submenu__left", lista podkategorii 2. poziomu) poszerzona do 260px (była ciasna, nazwy się ściskały) i zaokrąglone rogi całego panelu (były proste) — zgłoszenie: "Lewa czesc z subkategoriami jest za waska [...] pole menu powinno być ladnie wykonczone, rogi zaokrąglone". 4) "max-width" panelu podniesiony z pierwotnej wersji do "min(860px, calc(100vw - 40px))" — przy węższym limicie treść prawej kolumny (siatka najniższego poziomu) renderowała się szerzej niż sam panel i była niewidocznie ucinana przez "overflow:hidden" (potrzebny dla zaokrąglonych rogów) — sprawdzone na żywo na "Instrumenty → Akcesoria do instrumentów", zgłoszenie: "czesc kategorii najnizszego poziomu przylega do prawej krawędzi". 5) "padding-right:16px" na ".submenu__right-items" — sam tekst już nie dotykał krawędzi (po punkcie 4), ale kolorowe "pole" podświetlenia hover (z ujemnymi marginesami w mainmenu-hover.css, które wizualnie poszerzają je poza box samego tekstu) nadal się z nią stykało. Zgłoszenie: "pole kolorove po nejechaniu nadal jest blisko krawędzi". 6) Prawa kolumna (".submenu__right") dynamicznie dopasowana szerokością do treści zamiast sztywnej — i CAŁKOWICIE ukrywana, gdy dana kategoria pierwszego poziomu nigdzie (w żadnej z pozycji 2. poziomu) nie ma podkategorii 3. poziomu (np. "Domowe audio", "Kable", "Słuchawki") — w takim wypadku lewa kolumna dostaje dodatkową szerokość (400px zamiast 260px), bo prawa i tak nigdy się nie pojawi. Zgłoszenie: "czy to prawe pole [...] mogloby być szerokością dopasowwyane dynamicznie lub znikać jeśli nie ma subkategorii?". WAŻNE (techniczne, sprawdzone przez element.matches() na żywo): CSS ":has()" NIE MOŻE być zagnieżdżone w innym ":has()" — nawet pośrednio przez ":not()" — w tej wersji Chromium takie selektory rzucają SyntaxError i cała reguła jest cicho ignorowana. Np. ":has(.submenu__right:not(:has(.submenu__right-items.active > *)))" jest NIEPRAWIDŁOWE. Rozwiązanie: sprawdzać obecność potomków zawsze płaskim selektorem z kombinatorem dziecka jako JEDYNĄ zawartością pojedynczego ":has()", np. ".submenu__right-items > *" — nigdy nie zagnieżdżać w nim kolejnego ":has()"/":not(:has())". 7) Podkategorie 3. poziomu (prawa kolumna) zamienione z siatki (grid-template-columns: repeat(4,1fr)) na układ listy — siatka przy różnych długościach nazw łamała się nierówno w wierszach i wyglądała chaotycznie. Zgłoszenie: "są trochę chaotycznie pokazywane przez rozne ldugosci nazw [...] Może by zrobić je też w liście zamiast tak rozrzucone?". Domyślnie 1 kolumna; automatycznie 2 kolumny (CSS column-count) TYLKO gdy pozycji w danej grupie jest naprawdę dużo (5 i więcej, przez ":has(> :nth-child(5))") — zgłoszenie: "nadal miejscami są niepotrzebnie 2 kolumny". Uwaga techniczna: łączenie "column-count"/"column-width" z "width:fit-content" na tym samym elemencie zawodzi w tej przeglądarce (kolumny "zwijają się" do mniejszej liczby niż zadana, sprawdzone na żywo) — element z kolumnami musi mieć jawną szerokość w px (496px). 8) Odstępy między pozycjami na liście zwiększone (10px marginesu dawało tylko ~2px realnego odstępu wizualnego, bo ujemny margines z hover- pigułki w mainmenu-hover.css go "zjadał" — poprawione na 20px, co daje ok. 12px odstępu) i prawa kolumna poszerzona (496px w wariancie 2-kolumnowym), żeby dłuższe nazwy mniej się zawijały. Zgłoszenie: "troszkę za blisko siebie są te subkatgorie [...] prawa kolumna może być iut szersza, zeby pokazać dłuższe nazwy". 9) Poprawka "skakania" szerokości panelu (błąd wprowadzony przy punkcie 6/8, zgłoszenie: "coś się rozjechało, podczas najezdzania na kategorie niektore zmieniaja nagle szerokosc i nazwa na np2 linie po najechaniu i skacze"): rezerwacja szerokości prawej kolumny musiała być liczona dla CAŁEJ kategorii na raz (czy GDZIEKOLWIEK w niej jest grupa z 5+ pozycjami), a nie tylko dla aktualnie najechanej pozycji 2. poziomu (".active") — inaczej przechodzenie myszką między pozycją "pustą" a pozycją z podkategoriami w TEJ SAMEJ, już otwartej kategorii powodowało widoczne zmienianie szerokości panelu w locie. Naprawione przez wyliczanie obu warunków (chować prawą kolumnę / rezerwować dla niej 544px) na podstawie WSZYSTKICH grup ".submenu__right-items" w danym panelu, nie tylko aktywnej. Druga, drobniejsza przyczyna tego samego objawu: rezerwowana szerokość dla wariantu "dużo pozycji" była ustawiona na 496px (sama szerokość treści), ale ".submenu__right" ma własny padding 24px+24px (box-sizing:border-box) — więc gdy pojawiała się grupa z wymuszoną szerokością 496px, kolumna i tak musiała urosnąć do 544px, żeby ją pomieścić. Naprawione przez podniesienie rezerwacji od razu do 544px (496 + padding), żeby panel od otwarcia miał docelową, stałą szerokość niezależnie od tego, na którą pozycję w lewej kolumnie najedziesz. Zweryfikowane programowo (symulacja najechania na każdą pozycję w każdej z 8 kategorii menu) oraz ręcznie na żywo. Ładowane globalnie przez hookDisplayHeader() w dobre_audio_assets.php, zaraz obok mainmenu-hover.css (ten sam mega-menu, osobny plik bo inny zakres — tu układ/szerokość, tam kolory na hover) — NIE edytujemy plików motywu Hummingbird bezpośrednio. */ .ps-mainmenu.ps-mainmenu--desktop .ps-mainmenu__tree > li { position: relative; } .ps-mainmenu.ps-mainmenu--desktop .js-sub-menu.submenu { left: 0 !important; right: auto !important; top: 100% !important; width: fit-content !important; max-width: min(860px, calc(100vw - 40px)) !important; border-radius: 12px !important; overflow: hidden !important; } .ps-mainmenu.ps-mainmenu--desktop .ps-mainmenu__tree > li:nth-last-child(-n+2) .js-sub-menu.submenu { left: auto !important; right: 0 !important; } .ps-mainmenu.ps-mainmenu--desktop .js-sub-menu.submenu .submenu__row { flex-wrap: nowrap !important; } .ps-mainmenu.ps-mainmenu--desktop .js-sub-menu.submenu .submenu__left.col-sm-3 { flex: 0 0 260px !important; width: 260px !important; max-width: 260px !important; } .ps-mainmenu.ps-mainmenu--desktop .js-sub-menu.submenu .submenu__right.col-sm-9 { flex: 0 1 auto !important; width: auto !important; max-width: none !important; } .ps-mainmenu.ps-mainmenu--desktop .js-sub-menu.submenu .submenu__right-items { padding-right: 16px !important; } /* Podkategorie trzeciego poziomu jako lista (nie siatka) — jedna kolumna domyślnie, 2 kolumny tylko gdy pozycji jest naprawdę dużo (5+). */ .ps-mainmenu.ps-mainmenu--desktop .js-sub-menu.submenu .submenu__right-items.active { display: block !important; width: fit-content !important; max-width: 260px !important; } .ps-mainmenu.ps-mainmenu--desktop .js-sub-menu.submenu .submenu__right-items.active > * { margin-bottom: 20px !important; break-inside: avoid !important; } .ps-mainmenu.ps-mainmenu--desktop .js-sub-menu.submenu .submenu__right-items.active:has(> :nth-child(5)) { width: 496px !important; max-width: 496px !important; column-count: 2 !important; column-gap: 32px !important; } /* Kategoria CAŁKOWICIE płaska (żadna pozycja w całym tym menu nigdzie nie ma podkategorii trzeciego poziomu) - prawe pole nigdy nie będzie potrzebne, więc chowamy je na stałe i oddajemy tę przestrzeń lewej liście. Sprawdzone na całym menu (nie tylko aktualnie najechanej pozycji), więc szerokość NIE zmienia się w trakcie najeżdżania na kolejne pozycje w tym samym menu. */ .ps-mainmenu.ps-mainmenu--desktop .js-sub-menu.submenu:not(:has(.submenu__right-items > *)) .submenu__right { display: none !important; } .ps-mainmenu.ps-mainmenu--desktop .js-sub-menu.submenu:not(:has(.submenu__right-items > *)) .submenu__left.col-sm-3 { flex: 0 0 400px !important; width: 400px !important; max-width: 400px !important; } /* Kategoria MIESZANA (część pozycji ma podkategorie, część nie) - prawe pole ma zarezerwowaną stałą szerokość (dopasowaną do najszerszego wariantu w tej kategorii), żeby menu nie "skakało" przy przechodzeniu między pozycjami z zawartością i bez. Gdy najechana pozycja nie ma podkategorii, prawe pole jest po prostu puste, ale panel nie zmienia szerokości. */ .ps-mainmenu.ps-mainmenu--desktop .js-sub-menu.submenu:has(.submenu__right-items > *) .submenu__right { display: block !important; min-width: 260px !important; } .ps-mainmenu.ps-mainmenu--desktop .js-sub-menu.submenu:has(.submenu__right-items > :nth-child(5)) .submenu__right { min-width: 544px !important; }