` razem ze znacznikiem rozwijania, czego recenzent wprost
nie chcial. */
.details-body {
padding: 1em 2em;
}
/* Waski ekran: 2em z kazdej strony zjada miejsce na kod i dlugie adresy, ktore i tak
sa tu najtrudniejsza trescia do zmieszczenia. */
@media (max-width: 640px) {
.details-body { padding: 0.75em 0.75em; }
}
/* UWAGA 68 (runda 8): TREŚĆ ROZWINIĘCIA POTRZEBUJE PRZESTRZENI I PEŁNEGO FONTU.
Recenzent: „w zawartości tych rozwinięć, poza tymi, gdzie znajdują się bloki
, przydałby się mały padding. Teraz nie mam tam żadnej przestrzeni i wszystko
się skleja ze sobą (…) w przypadku tych rozwinięć nie powinny być zastosowane klasy
«meta», które powodują zmniejszenie fontu. W tym miejscu te teksty są mniej
czytelne, a one trochę stanowią opisanie akapitu pod sobą, ewentualnie są pełną
informacją (jak w przypadku sekcji «Tekst i kontekst»)”.
POMIAR PRZED ZMIANĄ (sonda_runda8_rozwiniecia.py, render REALNEGO szablonu
analysis_report.html z prawdziwą funkcją grupującą): w rozwinięciu „Tekst
i kontekst” odstęp pod `summary` wynosił 0 px, wcięcie 0 px, a oba akapity treści
miały font 12 px przy 16 px zwykłego akapitu strony. W „Szczegółach walidatora”
etykieta „Komunikat” też miała 12 px, choć sam blok `` stoi już w
`.details-body` z paddingiem 16/32 px — czyli recenzent trafnie rozpoznał, że
problem dotyczy WYŁĄCZNIE treści poza blokami `pre`.
DWIE RZECZY, KTÓRE `meta` ROBI NARAZ, a kwestionowana jest tylko jedna:
`.meta` daje mniejszy font ORAZ kolor `--muted`. Recenzent pisze o czytelności
tekstu, nie o kolorze, a wyszarzenie pełni tu realną rolę: odróżnia ETYKIETĘ
(„Komunikat”, „Tekst:”) od treści, którą opisuje. Dlatego nie usuwamy klasy
z szablonów (byłaby to zmiana w kilkunastu miejscach czterech plików, z ryzykiem
dla eksportu HTML), tylko ZNOSIMY ZMNIEJSZENIE FONTU tam, gdzie recenzent je
zgłosił: wewnątrz rozwinięć w znaleziskach. Reszta strony (stopki tabel, podpisy,
liczniki) zachowuje `meta` bez zmian, bo tam nikt czytelności nie kwestionował.
PADDING NADAJEMY KONTENEROWI TREŚCI, NIE CAŁEMU `` — ta zasada jest już
w arkuszu wyżej (margines 8 recenzenta) i tutaj obowiązuje tak samo: przesunięcie
całego `` odsunęłoby też `` razem ze znacznikiem rozwijania,
czego recenzent wprost nie chciał. Dlatego celujemy w RODZEŃSTWO `summary`.
Bloki `` wykluczamy z dodatkowego paddingu (`:not(.details-body)` plus reguła
zerująca dla `pre`), bo mają własne marginesy i własny obszar przewijania —
dokładanie im wcięcia zwężyłoby miejsce na kod i długie adresy, czyli najtrudniejszą
tu treść. To też jest wprost w zgłoszeniu: „poza tymi, gdzie znajdują się bloki
”. */
.issue-list details > summary ~ *:not(.details-body):not(pre):not(ul):not(ol) {
padding-left: 0.75em;
padding-right: 0.75em;
}
/* LISTY są tu WYŁĄCZONE i mają własną regułę przy uwadze 69 niżej: ich wcięcie
musi zmieścić także punktor, więc wartość jest inna. Wyłączenie przez `:not`
zamiast nadpisywania jest tu konieczne, patrz komentarz o specyficzności
w regule uwagi 69.
Odstęp GÓRNY treści rozwinięcia ustala reguła uwagi 70 niżej (rozdziela
etykietę od zwykłej treści), więc nie powtarzamy go tutaj. */
/* Pełny rozmiar tekstu w treści rozwinięcia. Kolor `--muted` ZOSTAJE: rozróżnia
etykietę od opisywanej treści, a jego kontrast wobec tła to 9,7:1 w motywie
jasnym (#3a414c na #ffffff), czyli z zapasem powyżej wymaganych 4,5:1. */
.issue-list details .meta,
.issue-list details .meta * {
font-size: inherit;
}
/* UWAGA 69 (runda 9): PUNKTOR LISTY W ROZWINIĘCIU WYCHODZI POZA TREŚĆ.
Recenzent: „jak są wewnątrz rozwinięć jakieś listy, to one nie uwzględniają
miejsca na punktor, przez co on nie ma wcięcia i punktor «wystaje» z lewej
strony. Przez to nie wygląda to, jakby to była część treści w rozwinięciu”.
TO JEST NASZA REGRESJA Z RUNDY 8, nie zastany defekt. Reguła wyżej
(`summary ~ *`) nadaje treści rozwinięcia `padding-left: 0.75em`, czyli 12 px.
Dla akapitu i `div` to działa poprawnie, ale `
` przy domyślnym
`list-style-position: outside` rysuje punktor W SWOIM PADDINGU — a padding
listy jest tu tym samym 12 px, którym ustawiamy wcięcie treści. Wcześniej
lista miała domyślne 40 px przeglądarki i punktor się mieścił.
POMIAR (sonda_runda9_wyrownanie.py, realny szablon analysis_report.html,
1280 px, font 16 px): punktor zajmuje 22 px razem z odstępem za nim, czyli
1,375em. Przy 12 px paddingu jego lewa krawędź stoi 10 px NA LEWO od obrysu
rozwinięcia, podczas gdy etykieta `.meta` zaczyna się na +12 px — stąd
rozjazd 22 px, który recenzent widzi jako „wystający punktor”.
DLACZEGO 2.125em, A NIE „jakaś większa wartość”: to 0.75em wcięcia treści
(wartość z rundy 8, wspólna dla całego wnętrza rozwinięcia) plus 1.375em
zmierzonej szerokości punktora. Zmierzone warianty: 1.75em zostawia 6 px
rozjazdu, 2em zostawia 2 px, 2.125em daje 0 px, 2.25em przechodzi na +2 px
w drugą stronę. Punktor staje więc dokładnie na linii etykiet, a tekst listy
wypada za nim — czyli lista czyta się jako część treści rozwinięcia.
Wartość w `em`, nie w pikselach: punktor skaluje się z rozmiarem tekstu,
więc przy powiększeniu czcionki wcięcie musi rosnąć razem z nim.
SPECYFICZNOŚĆ — pułapka, w którą wpadłem przy pierwszym podejściu i którą ten
arkusz ma już opisaną przy nawigacji: reguła wcięcia treści wyżej ma selektor
`*:not(.details-body):not(pre)`, a każde `:not()` liczy się jak klasa, więc
waży (0,3,2). Sama nazwa elementu `ul` waży (0,1,2) i PRZEGRYWA, niezależnie
od kolejności w pliku. Pierwsza wersja tej poprawki nie dawała więc żadnego
efektu, choć wyglądała poprawnie. Rozwiązaniem NIE jest podbijanie siły
(`!important` ani sztuczne dokładanie klas), tylko UCZYNIENIE SELEKTORÓW
ROZŁĄCZNYMI: tamta reguła wyklucza teraz `ul` i `ol` przez `:not`, więc obie
opisują inne elementy i nie ma między nimi rywalizacji. */
.issue-list details > summary ~ ul,
.issue-list details > summary ~ ol {
padding-left: 2.125em;
}
/* Lista zagnieżdżona (na przykład „Znaleziono na stronach” w „Lokalizacji”)
dziedziczy wcięcie po rodzicu i nie potrzebuje pełnej wartości wyjściowej —
wystarczy jej miejsce na własny punktor. */
.issue-list details ul ul,
.issue-list details ul ol,
.issue-list details ol ul,
.issue-list details ol ol {
padding-left: 1.375em;
}
/* UWAGI 70 i 71 (runda 9): HIERARCHIA ODSTĘPÓW WEWNĄTRZ ROZWINIĘCIA.
Recenzent: „«Popraw co najmniej jeden z poniższych problemów», «Komunikat» są
trochę jakby były nagłówkami opisującymi zawartość znajdującą się pod nimi.
Tylko że są tak trochę pościskane, podczas gdy elementy
mają całkiem
sporo przestrzeni wokół siebie. Burzy to trochę hierarchię wizualną” oraz
„cała zawartość wewnątrz rozwinięcia powinna mieć większy odstęp u dołu, żeby
wizualnie oddzielić ją od następnego elementu rozwijalnego”.
POMIAR STANU PRZED (ta sama sonda): reguła z rundy 8 daje `margin-top: 0.5em`
WYŁĄCZNIE pierwszemu elementowi po `summary` (selektor `summary + *`). Każdy
kolejny element treści miał więc 0 px odstępu od poprzednika, a blok ``
obok nich 16 px marginesu plus 16 px paddingu otoczki. Dokładnie ten kontrast
recenzent opisuje: etykieta ściśnięta, `` z oddechem.
ROZWIĄZANIE ODDZIELA DWIE ROLE, bo etykieta i akapit treści nie potrzebują
tego samego. Etykieta zapowiada blok pod sobą, więc dostaje wyraźny odstęp
GÓRNY (1em) i minimalny dolny — inaczej odkleiłaby się od tego, co opisuje,
i przykleiła do treści nad sobą. Zwykła treść dostaje pół tej wartości.
Pierwszy element po `summary` zachowuje mniejszy odstęp (0.5em), bo nagłówek
rozwinięcia i tak jest wizualnie oddzielony tłem oraz znacznikiem rozwijania.
Odstęp dolny (uwaga 71) nadajemy ``, nie ostatniemu dziecku:
ostatnim elementem bywa ``, `` albo `.details-body`
z blokiem `
`, więc celowanie w treść wymagałoby trzech reguł i i tak
pękłoby przy nowym rodzaju treści. `margin-bottom` na całym rozwinięciu
działa niezależnie od tego, co jest w środku, i nie przesuwa ``,
czego recenzent zabronił już w rundzie 8.
SPECYFICZNOŚĆ, ta sama pułapka co przy uwadze 69: selektor treści zawiera
`:not(.details-body):not(pre)` i waży (0,3,2), więc `~ .meta` o wadze (0,2,2)
sam by go NIE przebił. Dlatego reguła treści wyklucza `.meta` wprost, a każda
z trzech reguł niżej opisuje rozłączny zbiór elementów: zwykłą treść,
etykietę oraz pierwszy element po `summary`. */
.issue-list details > summary ~ *:not(.details-body):not(pre):not(.meta) {
margin-top: 0.5em;
}
/* Etykieta ma odstęp DOLNY tylko wtedy, gdy pod nią coś jeszcze jest: jej zadaniem
jest trzymać się treści, którą opisuje. Gdy etykieta jest OSTATNIM elementem
rozwinięcia, ten margines nie ma czego oddzielać, a dolicza się do przestrzeni
domykającej rozwinięcie (korekta uwagi 71 niżej) i daje 20 px tam, gdzie reszta
rozwinięć ma 16 — zmierzone, patrz komentarz przy tej korekcie.
Rozdzielamy więc ZAKRESY przez `:last-child`, a nie dokładamy reguły zerującej:
osobna reguła `> *:last-child { margin-bottom: 0 }` waży (0,1,2) wobec (0,3,2)
i PRZEGRYWA — zmierzone, wariant z nią wyszedł bajt w bajt jak wariant bez niej. */
.issue-list details > summary ~ .meta:not(.details-body):not(:last-child) {
margin-top: 1em;
margin-bottom: 0.25em;
}
.issue-list details > summary ~ .meta:not(.details-body):last-child {
margin-top: 1em;
margin-bottom: 0;
}
/* Pierwszy element po `summary` — niezależnie od tego, czy jest etykietą, czy
zwykłą treścią — dostaje mniejszy odstęp, bo nagłówek rozwinięcia jest już
oddzielony tłem i znacznikiem rozwijania. Waga (0,4,2) bije obie reguły
wyżej, co jest tu zamierzone: to zawężenie do jednego elementu, nie
rywalizacja o ten sam zbiór. */
.issue-list details > summary + *:not(.details-body):not(pre),
.issue-list details > summary + .meta:not(.details-body) {
margin-top: 0.5em;
}
/* KOREKTA UWAGI 71 (runda 10): PRZESTRZEŃ MA BYĆ W ŚRODKU OTWARTEGO ROZWINIĘCIA,
NIE MIĘDZY ZAMKNIĘTYMI. Recenzent po zobaczeniu rundy 9: „Kiedy mówiłem
o przestrzeni pod treścią w rozwinięciu, miałem na myśli tę treść, która znajduje
się wewnątrz, jak już rozwiniemy dany element. Między zamkniętymi elementami
rozwijalnymi nie było wcześniej przestrzeni, ale wyglądało to dobrze. W tej chwili
między nimi są spore odstępy, przez co moim zdaniem jest to mniej wygodne. Dlatego
też, jak elementy te są zamknięte, to powinny się znajdować jeden pod drugim, bez
dodatkowego marginesu dolnego, ale jak już je rozwiniemy, to treść wewnątrz niech
ma na dole trochę tej przestrzeni (…). Może to być ten 1em, który teraz jest dodany
między zamknięte elementy rozwijalne”.
NASZ BŁĄD Z RUNDY 9 BYŁ REALNY, nie tylko inaczej zrozumiany. `margin-bottom: 1em`
na całym `` działa NIEZALEŻNIE od stanu, więc dawał przestrzeń dokładnie
tam, gdzie recenzent jej nie chciał, i nie dawał jej tam, gdzie prosił.
POMIAR STANU PO RUNDZIE 9 (sonda_runda10_zamkniete_otwarte.py, realny szablon
analysis_report.html, oba stany w jednym przebiegu): rozwinięcia ZAMKNIĘTE miały
między sobą 16 px, a pusta przestrzeń WEWNĄTRZ otwartego pod ostatnią treścią
wynosiła 0 px. Czyli odwrotnie niż wymaganie.
DLACZEGO `padding-bottom` NA `details[open]`, A NIE MARGINES:
- `[open]` to atrybut, który przeglądarka utrzymuje sama, więc rozróżnienie stanów
nie wymaga JavaScriptu ani klasy dokładanej przez skrypt (raport HTML jest też
eksportowany do pliku i tam żaden nasz skrypt nie działa);
- padding jest przestrzenią WEWNĄTRZ elementu, a recenzent prosi o przestrzeń
„w treści”, żeby było widać, że rozwinięcie się kończy. Margines dołożyłby ją
na zewnątrz, czyli między rozwinięciami — czyli powtórzyłby błąd rundy 9;
- zasada z rundy 8 („żadnego paddingu na ``”) dotyczyła paddingu ze
WSZYSTKICH stron, bo przesuwa `` razem ze znacznikiem rozwijania.
`padding-bottom` stoi POD treścią i `summary` nie dotyka. Zmierzone: pozycja
`summary` w obu stanach bez zmian.
BEZ WYJĄTKU DLA OSTATNIEGO ROZWINIĘCIA — i to jest różnica wobec rundy 9, gdzie
`:last-child` wyjątek MIAŁ. Tam margines dokładał się do przerwy 14 px między
znaleziskami i robił większą dziurę niż granica znalezisk. Tutaj przestrzeń jest
wewnątrz, więc niczego nie dokłada. Zmierzone oba warianty: z wyjątkiem ostatnie
rozwinięcie ma do linii znalezisk 14 px przy 16 px między rozwinięciami wewnątrz
znaleziska, czyli odstęp WEWNĄTRZ znaleziska byłby większy niż na jego GRANICY —
odwrócenie hierarchii, którą te rundy porządkują. Bez wyjątku wychodzi 30 px do
linii, czyli granica znalezisk pozostaje najmocniejszym podziałem.
Wartość 1em podał recenzent wprost („może to być ten 1em”). */
.issue-list > li > details[open] {
padding-bottom: 1em;
}
/* IKONY DEKORACYJNE (uwaga 22). `currentColor` znaczy, ze ikona bierze kolor tekstu
obok, wiec dziala w obu motywach ORAZ w stanie hover bez zadnej dodatkowej reguly —
dokladnie to recenzent opisal („w kolorze takim jak tekst, rowniez obejmujacym efekt
hover”). Odstep 0.7em z prawej strony to jego wartosc.
`flex-shrink: 0` chroni ikone przed sciskaniem przy 320 px, a `vertical-align`
wyrownuje ja do linii tekstu, nie do dolnej krawedzi. */
.icon {
color: currentColor;
fill: currentColor;
margin-right: 0.7em;
flex-shrink: 0;
vertical-align: -0.15em;
}
/* PASEK AKCJI RAPORTU (uwagi 20, 21): powrot po lewej, eksport po prawej.
Zawijanie zostawione wlaczone, bo przy 320 px dwa elementy nie zmieszcza sie w linii
i lepiej, zeby zeszly pod siebie, niz zeby rozpychaly strone. */
.report-actions {
display: flex;
flex-wrap: wrap;
align-items: center;
justify-content: space-between;
gap: 10px;
}
.report-actions > .button { display: inline-flex; align-items: center; }
/* Przycisk z ikona musi byc flexem, inaczej `flex-shrink: 0` na ikonie nic nie robi
i przy 320 px ikona zostaje sciśnieta razem z tekstem. */
.icon-button { display: inline-flex; align-items: center; }
/* SEKCJA „PODSUMOWANIE WYNIKOW" - tekst pisany modelem jezykowym.
Ikonka czteroramiennych gwiazd siedzi w PRAWYM GORNYM ROGU sekcji, a nie przed
naglowkiem: recenzent wskazal ten wariant jako spojniejszy z pozostalymi
sekcjami, bo naglowek zostaje taki sam jak wszedzie.
Pozycjonowanie absolutne wzgledem `.inside`, wiec ikona nie wchodzi w przeplyw
tekstu i nie przesuwa naglowka. */
#analysis-summary-panel .inside { position: relative; }
.ai-sparkles {
position: absolute;
top: 16px;
right: 16px;
/* JASNONIEBIESKI, wprost z propozycji recenzenta. Bierzemy zmienna --primary,
ktora w motywie ciemnym jest juz jasnoniebieska (#9fd0ff), a w jasnym
ciemnoniebieska - dzieki temu symbol pozostaje widoczny w OBU motywach.
Krycie 0,75 realizuje druga czesc uwagi („zeby nie wyrozniał sie tak mocno
jak bialy naglowek") bez wchodzenia w kontrast tekstu: to element
DEKORACYJNY, wiec nie podlega wymogowi kontrastu 4,5:1, ale celowo nie
schodzimy nizej, zeby nie zniknal przy filtrach jasnosci. */
color: var(--primary);
opacity: 0.75;
pointer-events: none;
}
/* Naglowek nie moze wejsc pod ikone przy waskim ekranie - inaczej dlugi tytul
sekcji wpadnie na symbol. WARTOSC JEST SPRZEZONA Z ROZMIAREM IKONY: 3,2 em to
szerokosc ikony (32 px, powiekszona 04.09.2026 na prosbe recenzenta z 22 px)
plus odstep. Zmieniajac `width`/`height` w szablonie, popraw TEZ te liczbe -
przy 22 px zostawionych tutaj 2,2 em naglowek "Podsumowanie wynikow" wchodzil
pod symbol na waskim ekranie. */
#analysis-summary-panel h2 { padding-right: 3.2em; }
/* W trybie wymuszonych kolorow (Windows High Contrast) dekoracje maja znikac,
a nie zostawac w losowym kolorze systemowym. */
@media (forced-colors: active) {
.ai-sparkles { display: none; }
}
/* OPIS SEKCJI: wyszarzony klasa `help`, ale z PRZYWROCONYM marginesem dolnym.
Uwaga recenzenta z 04.09.2026, razem z trafna diagnoza skutku ubocznego:
globalne `.help { margin: 6px 0 0 }` ZERUJE margines dolny, wiec opis
przykleilby sie do przycisku albo do zwijanego raportu pod nim.
DLACZEGO OSOBNA REGULA, A NIE ZMIANA `.help`: klasa `help` siedzi w
kilkudziesieciu miejscach produktu (formularze, ustawienia konta, panel
administratora), gdzie zerowy margines dolny jest ZAMIERZONY - opis stoi
tam bezposrednio pod polem, do ktorego sie odnosi. Zmiana globalna
rozjechalaby te miejsca, a naprawiamy JEDEN akapit. */
#analysis-summary-lead { margin-bottom: 1em; }
/* Zwijana tresc podsumowania: dluzszy tekst czyta sie lepiej w wezszej kolumnie,
ale NIE ograniczamy jej sztywno w px, zeby nie psuc powiekszenia do 200%. */
.summary-result > .inside { max-width: 70ch; }
.summary-result > .inside h1 { font-size: 1.25rem; }
.summary-result > .inside h2 { font-size: 1.1rem; }
.summary-result > .inside h3 { font-size: 1rem; }
/* Menu eksportu na ``: dziala bez JavaScriptu. Panel jest pozycjonowany
absolutnie, zeby rozwiniecie NIE zmienialo rozmiaru rodzica — to ta sama pulapka,
ktora recenzent zglosil w uwadze 41 przy menu „Wiecej” w nawigacji. */
.report-export-menu { position: relative; }
.report-export-menu > summary {
display: inline-flex;
align-items: center;
border: 1px solid var(--border);
background: var(--surface);
font-weight: 600;
}
.report-export-list {
position: absolute;
right: 0;
z-index: 30;
min-width: 220px;
margin: 4px 0 0;
list-style: none;
border: 1px solid var(--border);
border-radius: 12px;
background: var(--panel);
box-shadow: 0 10px 24px rgb(0 0 0 / 28%);
/* UWAGA 60 (runda 7): „w panelu zawierającym listę z dostępnymi opcjami jest za duży
margines wewnętrzny (…) usuwając go całkowicie i tak samo lewy padding z listy,
ale w takim przypadku dobrze byłoby też zaokrąglić rogi pierwszej i ostatniej
opcji, żeby po nakierowaniu kursorem podświetlenie pasowało do kształtu panelu”.
Wybrany jego wariant mocniejszy: zero marginesu wewnętrznego. `padding: 0` musi
być JAWNE, bo `` ma domyślny lewy padding przeglądarki (u nas ~40 px) i to on
był głównym źródłem wrażenia „za dużo miejsca”. `overflow: hidden` nie wystarcza
zamiast zaokrągleń pozycji: obcięłoby cień i tło pod obramowaniem, dlatego rogi
dostają skrajne pozycje. */
padding: 0;
}
/* Podświetlenie skrajnych pozycji ma kształt panelu (uwaga 60). Promień o 1 px
mniejszy niż panelu, żeby tło nie wystawało spod obramowania na łuku. */
.report-export-list li:first-child a { border-radius: 11px 11px 0 0; }
.report-export-list li:last-child a { border-radius: 0 0 11px 11px; }
/* Jedna pozycja = wszystkie cztery rogi (menu bywa krótsze dla gościa). */
.report-export-list li:only-child a { border-radius: 11px; }
.report-export-list li + li { border-top: 1px solid var(--border); }
.report-export-list a {
display: block;
padding: 10px 12px;
}
.report-export-list a:hover,
.report-export-list a:focus-visible { background: var(--row-hover); }
/* WCIECIA W ZNALEZISKU (uwaga 26): „sama nazwa bledu bez wciecia, cala zawartosc pod
nia z wcieciem z lewej (1em), a takze dodatkowe wciecia przy kazdym opisie (- )”.
DWIE PULAPKI USTALONE POMIAREM 22.08.2026, nie zalozone:
1. `.issue-card` TO JEST `
` (klasa siedzi na liscie, nie na kontenerze
znaleziska), a `.issue-title` i `` sa jego RODZENSTWEM w `- `.
Selektory `.issue-card dl` i `.issue-card details` byly wiec martwe.
2. Wciecia MUSZA stac w TYCH SAMYCH regulach, co istniejace skroty `margin`.
Pierwsza wersja dodawala osobna regule `.issue-card { margin-left: 1em }` WYZEJ
w arkuszu, a nizej stalo `.issue-card { margin: 0 0 6px }` — skrot `margin`
ustawia takze `margin-left`, wiec zerowal wciecie. Sonda pokazala
`margin-left: 0px` i DWIE pasujace reguly (1em oraz 0px). Wzmocnienie selektora
byloby tu bledna naprawa: pojawilby sie trzeci konkurent i nastepna osoba
czytajaca arkusz nie wiedzialaby, ktora regula rzadzi. Dlatego wciecie wchodzi
do istniejacego skrotu, a nie obok niego. */
/* MARGINES 7: pierwszy `
` w znalezisku przyklejal sie do tresci nad nim.
Celujemy przez `.issue-list > li > details:first-of-type`, bo `` NIE jest
bezposrednim rodzenstwem `.issue-card` — pomiedzy stoi jeszcze `span.meta` z linkami
WCAG (sonda: `nextElementSibling` dla `.issue-card` bylo puste). `:first-of-type`
liczy sie wsrod `` w tym `- `, wiec dalsze rozwiniecia zachowuja swoje
wlasne odstepy. */
.issue-list > li > details:first-of-type { margin-top: 1em; }
details > summary:hover {
background: color-mix(in srgb, var(--surface), var(--primary) 8%);
}
/* Nagłówek wewnątrz summary (sekcja „Ustawienia analizy”): zachowaj semantykę H2,
ale renderuj w jednej linii ze znacznikiem rozwijania zamiast jako osobny blok. */
details > summary > h2 {
display: inline;
font-size: 19px;
font-weight: 700;
letter-spacing: -0.01em;
margin: 0;
}
/* Pole wyboru pliku — czytelne także w trybie odwróconego kontrastu. */
input[type="file"] {
max-width: 100%;
padding: 8px 10px;
border: 1px solid var(--border);
border-radius: 10px;
background: var(--surface);
color: var(--text);
}
.issue-caveat { margin: 0 0 14px; }
#report-details-actions { margin-top: 18px; }
/* Po powrocie ze szczegolow reguly wynik jest przewijany do widoku — zapas od gory,
by nie przykleic sie do krawedzi. Fokus programowy (tabindex=-1) bez natretnej obwodki. */
details[data-report-url] > summary,
ul[data-report-items] > li { scroll-margin-top: 16px; }
ul[data-report-items] > li:focus { outline: none; }
ul[data-report-items] > li:focus-visible { outline: 3px solid var(--focus); outline-offset: 2px; }
/* Oprawa listy (brak punktorow, odstepy, separator, numeracja) przeniesiona do
wspolnej klasy `.issue-list` nizej — uzywa jej TAKZE raport dokumentu (uwagi 55, 56).
Tu zostaja tylko rzeczy zwiazane z INTERAKCJA raportu WWW: przewijanie do wyniku
po powrocie ze szczegolow i widoczny fokus. */
.issue-title {
font-size: 16px;
font-weight: 700;
letter-spacing: -0.01em;
text-wrap: balance;
margin: 4px 0 6px;
}
/* Wciecie 1em z lewej (uwaga 26) wchodzi WPROST do skrotu `margin`, nie osobna regula
nizej/wyzej — inaczej ten skrot zerowalby margin-left (zmierzone: dwie pasujace
reguly, 1em i 0px, wygrywala pozniejsza). Kolejnosc: gora prawo dol lewo. */
.issue-card { margin: 0 0 6px 1em; }
.issue-card dt {
font-weight: 650;
color: var(--muted);
font-size: 13px;
margin-top: 6px;
}
.issue-card dd {
/* Dodatkowe 1em wciecia opisu wzgledem etykiety (uwaga 26) — w tym samym skrocie
`margin`, z tego samego powodu co przy `.issue-card` wyzej. */
margin: 2px 0 0 1em;
/* Uwaga 44: dlugi adres w tresci znaleziska wychodzil poza sekcje rozwijalna
i rozpychal cala strone. Tu `anywhere` jest wlasciwe, w przeciwienstwie do
komorki tabeli: w akapicie nie ma negocjacji szerokosci z sasiednimi kolumnami,
wiec nierozdzielalny token po prostu MUSI byc zlamany. `min-width: 0` chroni
przed drugim mechanizmem tego samego objawu: element siatki albo flexa
z domyslnym `min-width: auto` rozpycha rodzica niezaleznie od lamania tekstu. */
min-width: 0;
overflow-wrap: anywhere;
}
/* WSPOLNA OPRAWA LISTY ZNALEZISK dla raportu strony WWW i raportu dokumentu
(uwagi 55 i 56). Wczesniej raport dokumentu pakowal kazde znalezisko w osobny
panel: doklada padding, boksy sklejaly sie ze soba, a numer wisial poza boksem
i przy 320 px zjadal szerokosc opisu. Raport WWW rozdzielal znaleziska pozioma
linia i to rozwiazanie recenzent wskazal jako lepsze. */
.issue-list {
list-style: none;
padding-left: 0;
margin: 0;
counter-reset: znalezisko;
}
.issue-list > li {
counter-increment: znalezisko;
/* Miejsce na numer wstawiany przez ::before. `ch` skaluje sie z rozmiarem
tekstu, wiec numer nie rozjedzie sie przy wiekszej czcionce. */
padding-left: 3.2ch;
position: relative;
/* UWAGA 66 (runda 8): „w raporcie www teraz wygląda to dobrze, ale przy raporcie
dokumentu wciąż widzę, jak długie adresy URL w znaleziskach (po «Dokument —»)
wychodzą poza obramowanie sekcji”.
PRZYCZYNA, ustalona pomiarem i lekturą kodu walidatora, NIE zgadnięta: „Dokument
—” nie jest ozdobnikiem szablonu. Walidator Office skleja komunikat jako
`f"{location}{context}: {message}"`, gdzie `context` to `f" — {resource_url}"`
(src/utilitia/validations/office.py, funkcja `_message`). Pełny adres siedzi więc
WEWNĄTRZ treści komunikatu i trafia do zwykłego `
`, dla którego nie było
żadnej reguły łamania. Raport WWW był już naprawiony (uwaga 57 dała łamanie na
`summary` i na `dd`), a raport dokumentu pokazuje ten sam adres w innym miejscu
układu i dlatego objaw został.
DLACZEGO REGUŁA STOI TU, A NIE W WIDOKU DOKUMENTU: `.issue-list` jest wspólną
oprawą listy znalezisk dla raportu WWW i raportu dokumentu (uwagi 55, 56).
Adres może wystąpić w treści KAŻDEGO komunikatu walidatora, nie tylko Office
(veraPDF podaje ścieżki, Ace adresy w publikacji), więc łatanie pojedynczego
akapitu w jednym szablonie zostawiłoby ten sam defekt w pozostałych.
POMIAR PRZED ZMIANĄ (sonda_runda8_dokument.py, render REALNEGO szablonu
document_validator.html): przy 320 px akapit komunikatu wylewał się 1424 px poza
obrys sekcji, a cała strona rozpychała się o 1408 px. Przy 768 px nadal 1304 px.
`anywhere`, nie `break-word`: adres z długim tokenem podpisu nie ma ani jednej
spacji, a `break-word` łamie słowo dopiero „gdy trzeba” — to ta sama decyzja co
przy `dd` (uwaga 44) i przy `summary` (uwaga 57).
WAŻNE O DANYCH POMIAROWYCH: pierwsza wersja sondy używała adresu z wieloma
myślnikami i pokazała „objawu nie ma”, bo przeglądarka łamie taki adres nawet
bez naszej reguły. Objaw odsłonił dopiero adres z długim nierozdzielalnym
tokenem, czyli realny przypadek z systemów obiegu dokumentów. Zbyt przyjazne
dane testowe maskują defekt tak samo skutecznie jak brak testu. */
min-width: 0;
overflow-wrap: anywhere;
}
.issue-list > li + li {
margin-top: 14px;
padding-top: 14px;
border-top: 1px solid var(--border);
}
/* Numer liczony licznikiem CSS, a nie punktorem `
`: dzieki temu da sie go
przeniesc nad tresc na waskim ekranie i nie jest czytany jako element listy
dwa razy. */
.issue-list > li::before {
content: counter(znalezisko) ".";
position: absolute;
left: 0;
top: 14px;
color: var(--muted);
font-size: 13px;
font-variant-numeric: tabular-nums;
}
.issue-list > li:first-child::before { top: 0; }
/* POZIOM ZNALEZISKA: kolor ORAZ ikona, nigdy sam kolor (WCAG 1.4.1 — kolor nie
moze byc jedynym nosnikiem informacji). Ikona idzie przez `::before`, wiec jest
dekoracyjna i czytnik ekranu jej nie oglosi; nazwa poziomu zostaje zwyklym
tekstem, ktory czytnik przeczyta normalnie. Zalegla uwaga z listy zbiorczej:
„bledy w raporcie sa bardzo zbite i ciezko je rozroznic”. */
.level-badge {
display: inline-flex;
align-items: baseline;
gap: 6px;
font-weight: 600;
}
.level-badge::before {
content: "\25CF";
font-size: 11px;
line-height: 1;
}
/* Kolory z palety motywu (istnieja w wariancie jasnym I ciemnym, wiec bez wartosci
zapasowych — te tylko zamaskowalyby literowke w nazwie zmiennej). */
.level-badge.error { color: var(--danger); }
.level-badge.error::before { content: "\2716"; }
.level-badge.warning { color: var(--warning); }
.level-badge.warning::before { content: "\26A0"; }
.level-badge.info { color: var(--muted); }
.level-badge.info::before { content: "\2139"; }
/* Waski ekran: numer nad trescia, zeby opis dostal pelna szerokosc (uwaga 55c). */
@media (max-width: 480px) {
.issue-list > li {
padding-left: 0;
padding-top: 26px;
}
.issue-list > li + li { padding-top: 30px; }
.issue-list > li::before {
position: static;
display: block;
margin-bottom: 2px;
}
}
footer {
margin-top: 26px;
color: var(--muted);
font-size: 12px;
}
footer nav { margin-top: 8px; }
footer .footer-links {
display: flex;
flex-wrap: wrap;
gap: 12px;
list-style: none;
padding: 0;
margin: 0;
}
footer a { color: inherit; }
footer a:hover { color: var(--text); }
.legal-content {
display: grid;
gap: 12px;
}
.legal-content h2,
.legal-content h3,
.legal-content h4 {
margin-bottom: 0;
}
.legal-content ol,
.legal-content ul {
margin-top: 0;
padding-left: 1.8rem;
}
.legal-content li {
background: var(--panel);
margin-top: 0.35rem;
padding-left: 0.15rem;
}
@media (max-width: 520px) {
.page-header h1 { font-size: 32px; }
/* 16px, żeby iOS nie powiększał widoku przy wejściu w pole.
Lista typów musi być zgodna ze wspólną regułą wyglądu pól powyżej. */
input[type="text"],
input[type="url"],
input[type="email"],
input[type="password"],
input[type="search"],
input[type="number"],
input[type="month"],
textarea {
font-size: 16px;
}
}
@media (forced-colors: active) {
:root {
--bg: Canvas;
--surface: Canvas;
--panel: Canvas;
--border: CanvasText;
--text: CanvasText;
--muted: CanvasText;
--primary: LinkText;
--primary-hover: LinkText;
--primary-contrast: ButtonText;
--focus: Highlight;
/* W trybie wymuszonego kontrastu kolory ustala system. */
--row-hover: Canvas;
}
.panel,
.card,
.check,
.table,
button,
.button,
input,
input[type="file"],
select,
textarea {
box-shadow: none;
}
button.primary,
.button.primary {
background: ButtonFace;
border-color: ButtonText;
color: ButtonText;
}
}
/* Natywne widgety przegladarki (pola, listy, paski przewijania) czytaja
color-scheme, nie nasze zmienne. Bez tego jawnie wybrany motyw zostawia
jasne pole tekstowe na ciemnym tle. */
:root[data-theme="dark"] { color-scheme: dark; }
:root[data-theme="light"] { color-scheme: light; }
/* Przelacznik motywu w stopce: trzy przyciski jako jedna grupa. */
.theme-switcher {
display: flex;
flex-wrap: wrap;
align-items: stretch;
gap: 8px;
margin: 8px 0 0;
padding: 0;
border: 0;
}
.theme-switcher legend {
padding: 0;
margin: 0 0 6px;
font-size: 12px;
color: var(--muted);
}
.theme-switcher .theme-option {
font: inherit;
font-size: 12px;
padding: 6px 12px;
border: 1px solid var(--border);
border-radius: 999px;
background: var(--surface);
color: var(--text);
cursor: pointer;
}
.theme-switcher .theme-option:hover { border-color: var(--primary); }
/* Stan wybrany czytany przez aria-pressed, a widoczny NIE tylko kolorem:
pogrubienie i obramowanie 2px dzialaja tez w trybie wymuszonych kolorow. */
.theme-switcher .theme-option[aria-pressed="true"] {
border-width: 2px;
border-color: var(--primary);
font-weight: 700;
}
@media (forced-colors: active) {
.theme-switcher .theme-option[aria-pressed="true"] {
border-color: Highlight;
}
}
/* Menu „Więcej” w nawigacji (uwaga 1 Krzysztofa, wariant 3).
HISTORIA DWOCH ITERACJI, wazna przy kolejnej zmianie tego obszaru:
pierwotnie panel byl absolutny TYLKO powyzej 560 px, a nizej wchodzil w uklad
strony, zeby przy 320 px nie wychodzil poza ekran. Uwaga 41 pokazala, ze ta
ostroznosc kosztowala wiecej, niz dawala: panel w przeplywie powiekszal rodzica,
wiec pasek przelamywal sie po rozwinieciu. Teraz panel jest absolutny ZAWSZE,
a wyjscie poza ekran blokuja `max-width` i kotwiczenie do calej nawigacji. */
/* Panel menu kotwiczymy do CALEJ nawigacji, nie do waskiego `- ` (uwaga 41).
Powod: `right: 0` liczy sie od prawej krawedzi kontekstu pozycjonowania. Gdy byl
nim sam `
- ` o szerokosci 94 px, panel o `min-width: 220px`
siegal 126 px w LEWO od niego i na waskim ekranie wychodzil poza krawedz okna.
`nav` konczy sie w tym samym miejscu (przycisk „Wiecej” jest ostatni), wiec panel
nadal jest wyrownany do prawej, ale ma pod soba pelna szerokosc paska. */
.toolbar nav { position: relative; }
.nav-more { position: static; }
.nav-more-toggle { display: inline-flex; align-items: center; gap: 4px; }
/* Strzałka jest dekoracją: kierunek stanu czyta się z aria-expanded. */
.nav-more-toggle::after {
content: "";
width: 0;
height: 0;
border-left: 4px solid transparent;
border-right: 4px solid transparent;
border-top: 5px solid currentColor;
}
.nav-more.is-open > .nav-more-toggle::after {
border-top: 0;
border-bottom: 5px solid currentColor;
}
/* KRYTYCZNE: `display: flex` na tym elemencie NADPISUJE atrybut `hidden`
(przegladarkowe [hidden]{display:none} ma te sama specyficznosc, ale stoi
wczesniej). Zmierzone przed poprawka: lista z `hidden` miala wysokosc
294 px, widoczne odnosniki i po ustawieniu fokusu byla osiagalna tabulacja,
czyli uzytkownik klawiatury wpadal w niewidoczne menu. Reguly ukladu MUSZA
wiec byc warunkowane brakiem `hidden`.
SELEKTOR MUSI BYC TAK SAMO MOCNY jak regula ukladu ponizej. Pierwsza wersja
uzywala `.nav-more-list[hidden]` (0,2,0) i PRZEGRALA z
`.toolbar nav ul.nav-more-list` (0,2,2), ktora sam wzmocnilem, zeby pobic
`.toolbar nav ul`. Zmierzone na plikach POBRANYCH Z BETY: display=flex przy
hidden, wysokosc 79 px, a tabulacja wchodzila w dwie pozycje ukrytego menu.
Poprawka jednej rzeczy przegonila poprawke drugiej - stad `[hidden]` z tym
samym prefiksem. */
.toolbar nav ul.nav-more-list[hidden] { display: none; }
/* Selektor MUSI byc co najmniej tak mocny jak `.toolbar nav ul` (0,2,1),
inaczej panel dziedziczy `gap: 12px` i `align-items: center` z paska
nawigacji. Zmierzone przed poprawka: gap=12px zamiast 2px,
align-items=center, czyli pozycje wysrodkowane i rozstrzelone na 295 px
wysokosci. Widac to bylo na zrzucie, testy na samym CSS tego nie lapaly. */
.toolbar nav ul.nav-more-list {
list-style: none;
margin: 6px 0 0;
padding: 6px;
display: flex;
flex-direction: column;
align-items: stretch;
gap: 2px;
background: var(--surface);
border: 1px solid var(--border);
border-radius: 10px;
box-shadow: var(--shadow-raised);
min-width: 220px;
/* UWAGA 41: panel jest wyjety z przeplywu na KAZDEJ szerokosci, nie tylko powyzej
560 px. Wczesniej ponizej tego progu zostawal w przeplywie, wiec jego
`min-width: 220px` wchodzila do rozmiaru `
- ` i po rozwinieciu
pasek przelamywal sie inaczej. Zmierzone przy 320 px: przycisk „Wiecej” skakal
z (48,214) na (84,0), a rodzic puchl z 94 na 220 px. Przy 480 px przycisk
przypadkiem nie drgal, ale rodzic puchl identycznie — defekt byl wiec szerszy
niz jeden ekran, stad brama pilnuje SZEROKOSCI RODZICA, nie pozycji przycisku.
`max-width` z `calc` domyka drugi, zastany defekt: przy dokladnie 560 px panel
szerszy niz zapas z prawej wystawal za krawedz okna, bo samo `right: 0` nie
ogranicza szerokosci. Odjete 24 px to margines paska po obu stronach. */
position: absolute;
right: 0;
/* POZYCJA PIONOWA — UWAGA 59 (runda 7): „rozwinięte menu pojawia się strasznie
nisko. Problemem jest reguła `top: 100%`. Po jej usunięciu `top` dostaje wartość
`auto` i menu pojawia się tuż pod opcją Więcej”.
Recenzent miał rację w całości, także co do rozwiązania. `top: 100%` liczy się od
kontekstu pozycjonowania, a nim jest CAŁA nawigacja (`.toolbar nav` ma
`position: relative` — konieczne dla uwagi 41), nie przycisk „Więcej”. Dla
zalogowanego po „Więcej” stoją jeszcze „Zalogowano: adres” i „Wyloguj”, więc pasek
łamie się na dwa wiersze i panel spadał pod OBA. Zmierzone (sonda_runda7_menu.py,
odstęp między dolną krawędzią przycisku a górą panelu, pasek zalogowanego z logo
i długim adresem): 135 px przy 320 px i 51 px przy 1280 px; po zmianie 8 px.
DROGA, KTÓRĄ ODRZUCILIŚMY, i to jest tu najważniejsze do zapamiętania: najpierw
zamiast `auto` wstawiliśmy kotwiczenie CSS (`anchor-name` + `top: anchor(bottom)`),
bo `auto` przy pozycjonowaniu absolutnym zostawia element tam, gdzie stałby
w przepływie — obawa była, że pozycja zacznie zależeć od układu paska. Dwa pomiary
ją obaliły:
1. `top: auto` daje 8 px STABILNIE w 21 układach (7 szerokości okna od 320 do
1600 px × 3 warianty paska: długi adres z logo, krótki adres, bez logo), przy
zerowym puchnięciu rodzica i bez wychodzenia poza okno;
2. kotwiczenie WYWRACAŁO NASZ WŁASNY SELFCHECK: walidator CSS (VNU) zgłasza
„Property anchor-name doesn't exist”, „Property position-anchor doesn't exist”
i „anchor(bottom) is not a top value” — czyli arkusz UTILITII przestawał być
poprawnym CSS-em. Narzędzie badające zgodność ze standardami nie może emitować
stylów, których walidator odrzuca; to nie jest kwestia gustu, tylko naszej
wiarygodności. Objaw wyszedł dopiero w CI, bo Chromium renderuje to bez skargi.
LEKCJA OGÓLNA: nowa, „ładniejsza” właściwość CSS bywa droższa niż prosty zapis —
zanim ją wprowadzisz, sprawdź, czy przechodzi przez WALIDATOR, nie tylko przez
przeglądarkę. */
top: auto;
z-index: 20;
max-width: calc(100vw - 24px);
}
.toolbar nav ul.nav-more-list a {
display: block;
padding: 6px 10px;
border-radius: 8px;
text-decoration: none;
color: var(--text);
}
.toolbar nav ul.nav-more-list a:hover { background: var(--row-hover); }
/* Pozycja pod fokusem klawiatury wyróżniona tak samo jak pod myszą — obrys
fokusu zostaje, to tylko dodatkowe tło, żeby było widać, gdzie jesteśmy. */
.toolbar nav ul.nav-more-list a:focus-visible { background: var(--row-hover); }
@media (forced-colors: active) {
.toolbar nav ul.nav-more-list { border-color: CanvasText; }
.toolbar nav ul.nav-more-list a:hover,
.toolbar nav ul.nav-more-list a:focus-visible {
background: Highlight;
color: HighlightText;
}
}