/* Tokeny skórki Vataha — jedyne globalne zmienne CSS aplikacji (SKIN-2). Link w `Components/App.razor`. ── Dlaczego JEDNA wartość na oba tryby ── Repozytorium nie ma w CSS ani jednego selektora trybu ciemnego: zero nadpisań `:root`, zero `prefers-color-scheme`, zero `.mud-theme-dark`. Cała różnica jasny/ciemny idzie wyłącznie przez `MudThemeProvider`, który podmienia `var(--mud-palette-*)` — nasze arkusze konsumują te zmienne i dlatego same nie muszą wiedzieć, w którym trybie działają. Złoty akcent jest świadomie identyczny w obu trybach (czyta się tak samo na jasnym i na ciemnym tle), więc nie potrzebuje pary wariantów. Dwa wyjątki od tego „wyłącznie" — oba BEZ selektora trybu, tym samym mechanizmem: zmienna `--mud-native-html-color-scheme` MudThemeProvidera trafia pod `color-scheme` elementu, a gałąź wybiera funkcja `light-dark()`: - aktywny slot w `BottomNav.razor.css` (BNAV-4) bierze INNY token palety w jasnym i w ciemnym motywie; - kolory typów wydarzeń zespołu (TEVT-3, sekcja niżej) — pary tło/tekst per tryb. ── Czego tu jeszcze NIE ma ── To docelowe miejsce na blade tła statusów (`#FAF6E9`, `#ECF4EF`, `#F6EBEA`) oraz silver `#C2CCD0`. Nie dopisujemy ich dzisiaj: Płatności, Przypomnienia i podgląd reguły są poza zakresem tego wątku, a token bez konsumenta to martwy kod (YAGNI). ── Dlaczego globalnie, a nie w scoped CSS ── Ten plik jest jedynym miejscem na nadpisania klas MudBlazora, których `::deep` wyrazić NIE MOŻE. Blazor nadaje atrybut zakresu `b-xxxxx` tylko elementom HTML pisanym wprost w danym `.razor`, a korzeniami `NavMenu.razor`, `MainLayout.razor` i `BottomNav.razor` są komponenty MudBlazora (`MudNavMenu`, `MudLayout`, `MudAppBar`) — nie ma więc elementu, który dostałby atrybut zakresu, i reguła `::deep` rozwinęłaby się do selektora nietrafiającego w nic. */ /* ── Tokeny ──────────────────────────────────────────────────────────────────────────────── */ :root { --vataha-gold-accent: #C9A227; } /* Kolory typów wydarzeń zespołu (TEVT-3) — para tło/tekst na klucz palety `EventTypeColor`. ── Źródło prawdy ── Wartości deklaruje `Vataha.Logic.Teams.Database/Models/EventTypeColorSwatches.cs` (tam kontrasty i powody; companion/09 CMPTYPE-1); `Components/Shared/Ui/EventTypeColorPalette.cs` jest tylko fasadą CSS nad tą paletą. `EventTypeColorPaletteTests` porównuje każdą linię poniżej z paletą i sprawdza kontrast ≥ 4.5:1 w obu trybach. Zmiana koloru = zmiana w obu miejscach, inaczej test jest czerwony. ── Dlaczego zmienna działa tylko z `color-scheme` na elemencie ── `light-dark()` wewnątrz zmiennej rozstrzyga się na elemencie, który zmienną UŻYWA, według JEGO `color-scheme`. Bez `color-scheme: var(--mud-native-html-color-scheme)` na nim (lub na przodku) kafelek w ciemnym motywie zostaje przy parze jasnej. `EventTypeColorPalette.FillStyle` dokłada tę deklarację razem z kolorami — konsument biorący samo `Background`/`Text` musi zrobić to sam. */ :root { --vataha-event-type-unknown-bg: light-dark(#D7DDE0, #455A64); --vataha-event-type-unknown-fg: light-dark(#0A0F1A, #ECEFF1); --vataha-event-type-green-bg: light-dark(#3F8F5F, #6FBF8C); --vataha-event-type-green-fg: light-dark(#0A0F1A, #162126); --vataha-event-type-red-bg: light-dark(#A83A2E, #E8776A); --vataha-event-type-red-fg: light-dark(#FFFFFF, #162126); --vataha-event-type-orange-bg: light-dark(#C77D2A, #E2B15E); --vataha-event-type-orange-fg: light-dark(#0A0F1A, #162126); --vataha-event-type-blue-bg: light-dark(#3E6B89, #7FB0D0); --vataha-event-type-blue-fg: light-dark(#FFFFFF, #162126); --vataha-event-type-purple-bg: light-dark(#7E57A8, #B99BDB); --vataha-event-type-purple-fg: light-dark(#FFFFFF, #162126); --vataha-event-type-teal-bg: light-dark(#26736E, #6CC4BC); --vataha-event-type-teal-fg: light-dark(#FFFFFF, #162126); --vataha-event-type-pink-bg: light-dark(#AD3F74, #E890B8); --vataha-event-type-pink-fg: light-dark(#FFFFFF, #162126); --vataha-event-type-indigo-bg: light-dark(#4A5AA8, #9CA8E6); --vataha-event-type-indigo-fg: light-dark(#FFFFFF, #162126); --vataha-event-type-brown-bg: light-dark(#7D5A44, #C9A68C); --vataha-event-type-brown-fg: light-dark(#FFFFFF, #162126); --vataha-event-type-bluegrey-bg: light-dark(#566A75, #A9BAC3); --vataha-event-type-bluegrey-fg: light-dark(#FFFFFF, #162126); --vataha-event-type-amber-bg: light-dark(#E0AE1F, #F1CC5C); --vataha-event-type-amber-fg: light-dark(#0A0F1A, #162126); --vataha-event-type-lime-bg: light-dark(#A4B83A, #C3D77A); --vataha-event-type-lime-fg: light-dark(#0A0F1A, #162126); } /* ── Nadpisania klas MudBlazora ──────────────────────────────────────────────────────────── */ /* Typografia nawigacji (SKIN-4). Oxanium na nagłówkach i przyciskach idzie z motywu (`VatahaTheme.BuildTypography` → `--mud-typography-h1-family`, `--mud-typography-button-family`). Etykieta pozycji w drawerze tą drogą pójść NIE MOŻE: `MudNavLink` nie ma własnej pozycji w `MudTheme.Typography` i nie czyta żadnej zmiennej `--mud-typography-*` — `.mud-nav-link-text` dziedziczy ambientowy font ciała (Exo). Jedynym sposobem jest reguła CSS. Dlaczego GLOBALNIE, a nie w `NavMenu.razor.css`: korzeniem `NavMenu.razor` jest komponent `MudNavMenu`, więc Blazor nie ma tam ani jednego elementu HTML, któremu nadałby atrybut zakresu `b-xxxxx`. `::deep .mud-nav-link-text` rozwinęłoby się w selektor nietrafiający w nic — reguła wyglądałaby na zrobioną, a font zostałby stary (pułapka P1 planu). MudBlazor sam nie ustawia `font-family` na tej klasie (`.mud-nav-link .mud-nav-link-text` deklaruje tylko szerokość, marginesy i `letter-spacing`), więc niczego tu nie nadpisujemy ani nie potrzebujemy `!important`. */ .mud-nav-link-text { font-family: 'Oxanium', 'Exo', sans-serif; } /* Rozłożenie slotów dolnego paska nawigacji (SKIN-5). `MudAppBar` nie renderuje dzieci wprost — wkłada je do własnego `MudToolBar`, czyli `
`, i to ON jest rodzicem pięciu slotów. Bez `display:flex` i pełnej szerokości `flex:1 1 0` na slotach nie ma się o co oprzeć, a domyślne boczne paddingi toolbara zjadałyby skrajne sloty. Dlaczego GLOBALNIE, a nie w `BottomNav.razor.css`: `.bottom-nav` trafia na parametr `Class` komponentu `MudAppBar`, więc żaden element pisany wprost w `BottomNav.razor` tej klasy nie nosi i `::deep .mud-toolbar` nie miałby czego zaczepić (ta sama pułapka P1 co wyżej). Selektor jest zawężony klasą `.bottom-nav`, więc nie rusza toolbara górnego paska ani żadnego innego. */ .bottom-nav .mud-toolbar { display: flex; width: 100%; padding-left: 0; padding-right: 0; } /* Bottom-sheet dolegający do dolnej krawędzi (SKIN-13) — WYŁĄCZNIE poniżej 600 px. Od 600 px (próg MudBlazor `sm`) kontener i okno wracają na standardowy wyśrodkowany dialog — patrz blok `@media (min-width: 600px)` niżej (DLGCTR-1). Reguły poniżej dotyczą już tylko telefonu; ta sama zależność od kolejności `` w `App.razor` (opisana niżej) obowiązuje też blok DLGCTR-1. ── Skąd brała się szpara ── `DialogPosition.BottomCenter` to w MudBlazorze dokładnie jedna reguła: `.mud-dialog-container.mud-dialog-bottomcenter { align-items: flex-end; justify-content: center; padding-bottom: 32px }`. To ten `padding-bottom` zostawiał 32 px między oknem a dołem ekranu — na zrzucie `mobile-15` prześwitywał tam przyciemniony dolny pasek nawigacji, czyli dokładnie to, czego bottom-sheet ma nie pokazywać. ── Dlaczego selektor jest taki wąski ── Klasa `mud-dialog-bottomcenter` ląduje na kontenerze WYŁĄCZNIE dla `Position = BottomCenter`, czyli dla rodziny formularzy CRUD (`FormDialogOptions.Default` + okna z własnymi opcjami, które powtarzają `Position` ręcznie). Okna wyśrodkowane niosą `mud-dialog-center` i tej reguły nie widzą — potwierdzenia i `ShowMessageBoxAsync` zostają na środku, świadomie. Popup obecności `TodayAttendanceDialog` przeszedł na preset (2026-08-19) i sheet go dotyczy, mimo wpisu w `NotFormDialogs`: ten wpis mówi o skorupie, nie o sposobie wejścia. Dzięki temu poprawka nie wymaga ani jednej zmiany w 25 miejscach otwarcia dialogu. Obie reguły wygrywają z MudBlazorem SAMĄ KOLEJNOŚCIĄ, nie siłą: `padding-bottom` ma dokładnie tę samą specyficzność co reguła Muda (0,2,0), a `App.razor` ładuje `vataha-tokens.css` PO `MudBlazor.min.css`. Mud nie stawia tu `!important`, więc i my nie musimy — ale to znaczy, że przestawienie kolejności `` w `App.razor` cicho cofnęłoby ten krok. ── Pełna szerokość i proste dolne rogi, czyli dlaczego to nie kończy się na `padding-bottom` ── Sam `padding-bottom: 0` nie załatwia sprawy: przy `FullWidth` MudBlazor daje oknu `width: calc(100% - 64px)` (`.mud-dialog-width-full`), więc po dosunięciu do dołu w dwóch dolnych narożnikach dalej widać byłoby paski przyciemnionego paska nawigacji, a 10-piksellowe zaokrąglenia dolnych rogów (`--mud-default-borderradius`) wycinałyby w krawędzi ekranu dwa ciemne wcięcia. Sheet przyklejony do krawędzi zajmuje więc całą dostępną szerokość (do granicy `max-width`), z prostymi dolnymi rogami i zaokrąglonymi górnymi — czyli tak, jak wygląda klasyczny bottom-sheet: krawędź, z której się wysuwa, jest niewidoczna, bo leży poza ekranem. `width: 100%` nie rozpycha okna na desktopie — ogranicznik `max-width` z `MaxWidth` (960 px dla `Medium`, 600 px dla `Small`) zostaje nietknięty, bo `width` i tak przycina go `max-width`. Realna szerokość to `min(100%, max-width)` zamiast `min(100% - 64px, max-width)`, więc różnicę widać WYŁĄCZNIE poniżej progu `max-width + 64 px` — dla `Medium` poniżej 1024 px, dla `Small` poniżej 664 px. Powyżej tego progu okno stało na `max-width` i wygląda dokładnie jak dotąd, tyle że dosunięte do dołu. ── Czego ta reguła NIE zmienia ── Wysokości: `.mud-dialog` ma `max-height: calc(100dvh - var(--mud-appbar-height))`, więc wysoki formularz nadal kończy się 64 px od góry ekranu, treść przewija się wewnątrz `.mud-dialog-content` (`flex: 1 1 auto; overflow: auto`), a stopka z przyciskami zostaje przyklejona (`flex: 0 0 auto`). Warstwy: kontener dialogu siedzi na `--mud-zindex-dialog` (1400), a dolny pasek to `MudAppBar` na `--mud-zindex-appbar` (1300) — okno przykrywa pasek i po dosunięciu, i przed nim. */ .mud-dialog-container.mud-dialog-bottomcenter { padding-bottom: 0; } .mud-dialog-container.mud-dialog-bottomcenter .mud-dialog { width: 100%; border-bottom-left-radius: 0; border-bottom-right-radius: 0; } /* Popup na środku ekranu od 600 px (DLGCTR-1). ── Zakres ── Próg 600 px to breakpoint MudBlazor `sm` (decyzja wizji). Selektor jest ten sam, co w SKIN-13 wyżej — `mud-dialog-bottomcenter` ląduje na kontenerze każdego okna z `Position = BottomCenter`, czyli całej rodziny formularzy CRUD (preset `FormDialogOptions.Default` + 6 wywołań z własnymi opcjami). Dzięki temu ten blok obejmuje wszystkie okna z zakresu automatycznie, bez zmiany w miejscach otwarcia dialogu. `mud-dialog-center` (potwierdzenia, `ShowMessageBoxAsync`) i `CenterRight` (panel boczny edytora sekcji cennika) mają inne klasy — ten blok ich nie dotyka. ── Co wraca do wartości Muda ── `align-items: center` zastępuje `flex-end` z reguły Muda — to jedyna zmiana na kontenerze: `padding-bottom` zostaje przy `0` z SKIN-13 wyżej, bo to dokładnie ta sama wartość, jaką ma wbudowana `.mud-dialog-container.mud-dialog-center` (bez dopychania do dołu), więc nie ma czego nadpisywać drugi raz. Na oknie cofamy DWIE zmiany z SKIN-13, wracając do wartości bazowej reguły `.mud-dialog` Muda (wzięte wprost z `~/.nuget/packages/mudblazor/9.5.0/staticwebassets/MudBlazor.min.css`, nie zgadywane): szerokość `calc(100% - 64px)` to `.mud-dialog-width-full`, a zaokrąglenie obu dolnych rogów `var(--mud-default-borderradius)` to ta sama zmienna, którą bazowa reguła `.mud-dialog` już stosuje na górnych rogach — SKIN-13 zerowało ją tylko na dolnych, tu ją przywracamy. `MaxWidth` (960 px dla `Medium`) zostaje nietknięty — `width` i tak go przycina. ── Czego ten blok NIE zmienia ── Przewijanie długiego okna (`.mud-dialog-content` z `overflow: auto`, stopka przyklejona) i próg wysokości (`max-height: calc(100dvh - var(--mud-appbar-height))`) to reguły bazowe Muda, dotąd nienadpisane — działają tak samo na środku, jak w arkuszu. ── Ta sama pułapka kolejności co SKIN-13 ── Wygrywa z Mudem kolejnością `` w `App.razor` (`vataha-tokens.css` po `MudBlazor.min.css`), nie `!important` — przestawienie kolejności cicho by to cofnęło, tak samo jak SKIN-13 wyżej. */ @media (min-width: 600px) { .mud-dialog-container.mud-dialog-bottomcenter { align-items: center; } .mud-dialog-container.mud-dialog-bottomcenter .mud-dialog { width: calc(100% - 64px); border-bottom-left-radius: var(--mud-default-borderradius); border-bottom-right-radius: var(--mud-default-borderradius); } } /* Akcent klubu na stronie publicznej (strona-publiczna-klubu, PUBCLUB-4) — para tło/tekst na klucz palety `ClubAccentColor`. ── Źródło prawdy ── Wartości deklaruje `Components/Shared/Ui/ClubAccentPalette.cs` (tam zmierzone kontrasty). `ClubAccentPaletteTests` porównuje każdą linię poniżej z paletą i sprawdza: tekst na akcencie ≥ 4.5:1, akcent wobec płótna i kart ≥ 3:1 w obu trybach, brak kolorów statusów motywu. Zmiana koloru = zmiana w obu miejscach, inaczej test jest czerwony. `unknown` = domyślny akcent Vataha (`Primary` motywu w obu trybach). ── `color-scheme` ── Jak przy typach wydarzeń: `light-dark()` rozstrzyga się na elemencie UŻYWAJĄCYM zmiennej, więc konsument potrzebuje `color-scheme: var(--mud-native-html-color-scheme)` — dokłada je `ClubAccentPalette.FillStyle`. */ :root { --vataha-club-accent-unknown-bg: light-dark(#263238, #E9D38A); --vataha-club-accent-unknown-fg: light-dark(#E9D38A, #162126); --vataha-club-accent-navy-bg: light-dark(#1F3A5F, #9DB6DA); --vataha-club-accent-navy-fg: light-dark(#FFFFFF, #162126); --vataha-club-accent-blue-bg: light-dark(#2B5FB0, #86AEEE); --vataha-club-accent-blue-fg: light-dark(#FFFFFF, #162126); --vataha-club-accent-teal-bg: light-dark(#1B6B66, #62C2BA); --vataha-club-accent-teal-fg: light-dark(#FFFFFF, #162126); --vataha-club-accent-green-bg: light-dark(#2E6F3E, #7CC98F); --vataha-club-accent-green-fg: light-dark(#FFFFFF, #162126); --vataha-club-accent-maroon-bg: light-dark(#7A1F2B, #E0909A); --vataha-club-accent-maroon-fg: light-dark(#FFFFFF, #162126); --vataha-club-accent-orange-bg: light-dark(#A8491A, #F0A070); --vataha-club-accent-orange-fg: light-dark(#FFFFFF, #162126); --vataha-club-accent-purple-bg: light-dark(#5E3A8C, #BFA2E2); --vataha-club-accent-purple-fg: light-dark(#FFFFFF, #162126); --vataha-club-accent-graphite-bg: light-dark(#3C4146, #B4BBC1); --vataha-club-accent-graphite-fg: light-dark(#FFFFFF, #162126); }