/* ============================================================================ 03-kontrolki.css — przyciski i pola. JEDEN wygląd dla całej aplikacji. Każda kontrolka ma tę samą wysokość (--h-control) i te same rogi, więc wiersz „etykieta + pole + guzik" składa się sam, bez poprawek w widokach. ============================================================================ */ /* Strzałka — kursor domyślny. ZASADY tego bloku: · combo: rączka DOPÓKI pole nie jest w edycji — po kliknięciu (focus) wraca kursor tekstowy, bo wtedy człowiek pisze, żeby filtrować. To rozstrzyga też strzałkę: ona jest częścią pola, więc dostaje rączkę razem z nim; · `[data-action]` = klikalne z definicji (wielki nasłuch kliknięć w 10-events łapie wszystko z tym zaczepem) — ALE z wyjątkiem pól do pisania: 13 pól tekstowych w aplikacji MA data-action (zmierzone), stąd :not(input/textarea). Kratki i suwaki są , więc dostają rączkę osobną regułą niżej; · wyłączone kontrolki NIE dostają rączki: reguły `:disabled { cursor: default / not-allowed }` mają wyższą wagę i wygrywają — sprawdzone, nie zakładane; · celowe wyjątki przeżywają: `.chat-reply-preview { cursor: auto }` (17-czat) i `.message-hub-twisty.is-empty { cursor: default }` stoją w arkuszach ładowanych PÓŹNIEJ albo mają wyższą wagę — wygrywają z tym blokiem. ⛔ Nowy klikalny element = zaczep `data-action` albo role="button" — wtedy rączka przychodzi SAMA z tego bloku. Nie dopisywać `cursor: pointer` po arkuszach. */ summary { cursor: pointer; } select { cursor: pointer; } .combo-input:not(:focus) { cursor: pointer; } input[type="checkbox"], input[type="radio"], input[type="range"] { cursor: pointer; } [data-action]:not(input):not(textarea), [data-view], [data-tab], [data-stage-expand], [role="button"], [role="tab"], th[data-sort], th[data-sort-key] { cursor: pointer; } /* ⭐ DOKŁADKA 18.08.2026 — zgłoszenie właściciela: „w Blokach najechanie na rekord nie daje łapki, a klik otwiera rekord — i takich miejsc jest dużo więcej". WIERSZE KARTOTEK — JEDNA REGUŁA DLA WSZYSTKICH. Klik w dowolny wiersz kartoteki otwiera edycję przez wspólny nasłuch (10-events: „Klik w dowolny wiersz kartoteki = edycja" — wciska ukryty przycisk Edytuj tego wiersza). Czyli klikalny jest DOKŁADNIE ten wiersz, który MA przycisk edycji — i to samo mówi selektor: `:has` łapie wiersze z przyciskiem, a wiersze puste/grupujące zostają bez łapki. Jedna reguła obejmuje Bloki, Materiały, Klientów, Dostawców i każdą PRZYSZŁĄ kartotekę, bo wszystkie renderują się w ten sam sposób. (`:has` jest już w tym arkuszu — patrz `.combo:has(...)` niżej.) */ [data-catalog-table-wrap] tbody tr:has([data-action="edit-catalog"]) { cursor: pointer; } /* ROZWIJANE WIERSZE I KAFLE spoza wzorca data-action — zaczepy zebrane z nasłuchów kliknięć (10-events, public/js/widoki/projekty-lista.js, public/js/czat/, public/js/zadania/), nie zgadnięte: zwijanie projektu/etapu/designu/konstrukcji na liście projektów, rozwijanie kafla, zakładki osi czasu, karta osoby w wyborze uczestników. */ [data-toggle-project], [data-toggle-stage], [data-toggle-design], [data-toggle-construction], [data-tile-expand], [data-timeline-tab], [data-project-participant-card] { cursor: pointer; } /* ⭐ TOKEN `data-klik` — dla KAŻDEGO przyszłego miejsca, które reaguje na klik, a nie pasuje do żadnego wzorca wyżej. Dopisujesz atrybut w szablonie i łapka przychodzi sama — zamiast kolejnej reguły kursora w kolejnym arkuszu. */ [data-klik] { cursor: pointer; } /* --- POLA ------------------------------------------------------------------- Wspólna reguła trzyma pola tekstowe i rozwijane w jednej linii. Checkbox i radio wyłączone — nie są pudełkiem na tekst i mają własny rozmiar. */ /* BEZ `min-width: 0` — monolit też go tu nie ma. Z zerem lista rozwijana kurczyła się poniżej swojej treści (filtry „Status" i „Rodzaj": 103 px zamiast 132). Tam, gdzie pole MA się kurczyć, monolit dodaje `min-width: 0` punktowo na konkretnym komponencie — i tak samo robimy my. */ /* Monolit (371): `min-height: 32px` + `padding: 7px 9px` — NIE sztywna wysokość. Dzięki temu pole rośnie, gdy treść tego wymaga (np. dłuższa opcja listy), zamiast obcinać. Nasze sztywne `height` + 12 px wcięcia dawało inne szerokości list rozwijanych niż w v8. */ /* NAPRAWA 11.08.2026 — `line-height: var(--lh-tight)`. Zmierzone na żywej stronie: pola miały 32,75 px, a przyciski obok 32 px — pole było o piksel wyższe od przycisku w KAŻDYM pasku narzędzi aplikacji (widoczne jako nierówna dolna krawędź rzędu). Powód: wysokość naturalna = interlinia 17,16 px (1,32 × 13) + 14 px wyściółki + 1,6 px ramki = 32,76, czyli WIĘCEJ niż `min-height: 32`, więc min-height nic nie robił. Przy 1,25 wychodzi 31,85 → min-height przejmuje i daje równe 32. Pole nadal ROŚNIE, gdy treść tego wymaga (o to chodziło w regule v8 niżej) — zmienia się tylko to, że przy jednym wierszu tekstu trafia w tę samą wysokość co reszta kontrolek. */ /* POPR3-pola (28.09.2026): JEDEN wygląd pola wszędzie — tło --pole-tlo (białe / ciemna powierzchnia), ramka --pole-ramka (00-tokens). W oknie zmienia się tylko róg (--okno-pole-r = 12 px, 05-komponenty §3). Zmienne --okno-pole-tlo/-ramka/ -obrys zostały jako furtka dla pól osadzonych w innej kontrolce (np. lista w pasku edytora tekstu, 17-czat) — nikt ich nie ustawia dla zwykłych pól. Pola w opakowaniach z własną ramką (szukajki) mają swoje reguły o większej wadze. */ input:not([type="checkbox"]):not([type="radio"]), select, textarea { min-height: var(--h-control); padding: 7px 9px; border: 1px solid var(--okno-pole-ramka, var(--pole-ramka)); border-radius: var(--okno-pole-r, var(--r)); background: var(--okno-pole-tlo, var(--pole-tlo)); box-shadow: var(--okno-pole-obrys, none); color: var(--text); font-size: var(--t-base); line-height: var(--lh-tight); transition: border-color var(--szybko), box-shadow var(--szybko); } /* 20.10.2026: kropki hasła — pismo systemowe (kropki zwykłego rozmiaru); w kroju programu na telefonie wychodziły ogromne. */ input[type="password"] { font-family: system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; letter-spacing: .04em; } /* SUWAKI — JEDEN wygląd dla całej aplikacji, U ŹRÓDŁA (12.08.2026). Suwak to nie pole tekstowe: reguła wyżej dawała mu ramkę, białe tło i 32 px wysokości, więc w KAŻDYM nowym miejscu trzeba ją było odkręcać osobno — stąd „biały pasek z ramką" na tle zaznaczonej konstrukcji. Rysuje go przeglądarka sterowana tokenem przez `accent-color`; dzięki temu tor ma natywne WYPEŁNIENIE od zera do uchwytu. Własne ::track/::thumb wymagają `appearance: none`, a to wypełnienie wyłącza — dlatego ich tu NIE ma. ⚠️ Te dwa `:not()` NIE filtrują niczego (suwak nie jest checkboxem ani radiem) — wyrównują SPECYFICZNOŚĆ do reguł wyżej: 0-3-1 dla widoków i 0-4-1 dla okien. Pierwsza próba szła inaczej: dopisano `:not([type="range"])` do reguł bazowych. To podniosło ICH siłę o jeden człon i zbiło kilka reguł kalkulatora (0-3-1), przez co znak „%" znów wchodził na cyfry. Reguł bazowych NIE RUSZAĆ. */ input[type="range"]:not([type="checkbox"]):not([type="radio"]), .modal input[type="range"]:not([type="checkbox"]):not([type="radio"]) { --okno-pole-obrys: none; width: 100%; height: var(--s-3); min-height: 0; margin: 0; padding: 0; border: 0; background: transparent; accent-color: var(--accent-strong); cursor: pointer; } input[type="range"]:disabled { opacity: .45; cursor: default; } /* POLA W OKNACH: wyściółka 6/10 i waga 500 (w widokach zostaje bazowe 7/9 i 400). To DOCELOWE wartości v8, wyliczone z renderu, nie przepisane z jednej reguły: monolit ustawia je trzykrotnie i reguły biją się nawzajem — `.modal input` (24995) daje 12,5 px i ramkę `--line`, ale późniejsza reguła dla pól tekstowych (25499, czternaście selektorów) podbija z powrotem na 13 px, wagę 500 i ramkę `--line-strong`. Efekt końcowy dla każdego WIDOCZNEGO pola to właśnie 13 px / 500 / `--line-strong` — i tylko to tu zapisujemy, jedną regułą zamiast czternastu. Rozmiar i ramka zostają z reguły bazowej wyżej. */ .modal input:not([type="checkbox"]):not([type="radio"]), .modal select, .modal textarea { padding: 6px 10px; font-weight: var(--w-medium); } /* Poświata zamiast grubszej ramki — grubsza ramka przesuwa treść o piksel. */ /* W1: w oknie fokus jak na telefonie — ramka akcentu, poświata 3 px (zmienne z 05-komponenty §3). Tło zostaje --pole-tlo. */ input:focus, select:focus, textarea:focus { border-color: var(--okno-pole-fokus-ramka, var(--accent-strong)); box-shadow: 0 0 0 var(--okno-pole-fokus-pierscien, var(--s-1)) color-mix(in srgb, var(--accent) 18%, transparent); } /* --- POLE WEWNĄTRZ OPAKOWANIA Z RAMKĄ (szukajki, „Dla kogo", pole kwoty) ----- Zasada: podświetla się OPAKOWANIE, nigdy pole w środku. Pole nie ma własnej ramki (patrz reguły `:not(...)` w arkuszach 14/15/17), więc gdyby dostało poświatę albo systemowy `outline` z resetu, narysowałby się KWADRAT bez zaokrągleń w środku zaokrąglonego opakowania. Dlatego zdejmujemy z niego jedno i drugie, a ramkę i poświatę bierze na siebie rodzic przez `:focus-within` (reguła niżej — jedna dla wszystkich opakowań). */ /* NAPRAWA 11.08.2026 — `.search` WYPISANE z tej grupy. Zmierzone na zywej stronie: opakowanie `.search` ma `border: 0px none` i `border-radius: 0px` (definiuje je tylko `position: relative`, arkusz 06), a mimo to dostawalo poswiate `0 0 0 4px`. Poswiata na elemencie bez zaokraglenia rysuje sie jako PROSTOKAT 340x33 z ostrymi rogami — stad „podswietlenie szukajki inne niz w liscie rozwijanej". Pozostale opakowania w tej grupie MAJA wlasna ramke i `--r`, wiec dla nich wzorzec „podswietla sie rodzic" jest poprawny i zostaje. Pole w `.search` wraca do zwyklej reguly `input:focus` wyzej — dostaje zaokraglona poswiate 9 px, identyczna jak kazde inne pole i jak combobox. */ .tree-search input:focus, .tree-search input:focus-visible, .timeline-search input:focus, .timeline-search input:focus-visible, .mh-search input:focus, .mh-search input:focus-visible, .checklist-add input:focus, .checklist-add input:focus-visible, .asel-input:focus, .asel-input:focus-visible { outline: none; box-shadow: none; border-color: transparent; } /* W1: opakowanie ma własną ramkę — pole w środku nie dostaje włosowego obrysu skórki okna. */ .tree-search, .timeline-search, .mh-search, .checklist-add, .asel-input { --okno-pole-obrys: none; } .tree-search:focus-within, .timeline-search:focus-within, .mh-search:focus-within, .checklist-add:focus-within, .asel-trigger:focus-within { border-color: var(--accent-strong); box-shadow: 0 0 0 var(--s-1) color-mix(in srgb, var(--accent) 18%, transparent); } /* Wyłączone pole ma WYGLĄDAĆ na wyłączone, ale zostać czytelne — jego wartość nadal jest informacją dla użytkownika. */ /* BŁĄD (W1, 27.09, zgłoszenie b14): ta reguła (0,1,1) przegrywała z regułą pól wyżej (0,2,1) — wyłączone pole („Dział (z funkcji)” w oknie osoby, plan produkcji u Dyrektora) wyglądało jak zwykłe pole do wpisania. `:not()` wyrównuje wagę do reguł pól (0,3,1). POPR3-pola: jedno tło zablokowane w oknie i poza nim (00-tokens). */ input:disabled:not([type="checkbox"]):not([type="radio"]), select:disabled, textarea:disabled { --okno-pole-obrys: none; border-color: var(--pole-ramka-zablokowane); background: var(--pole-tlo-zablokowane); color: var(--pole-napis-zablokowane); cursor: not-allowed; } /* Pole TYLKO DO ODCZYTU wygląda na wyliczone, nie na puste pole do wpisania (skan 13.09.2026: „Waga" bloku, „Numer projektu (auto)", ceny wyliczone — białe jak zwykłe pola, a pomoc mówi „nie wpisujesz"). Tekst zostaje pełnym kolorem: to informacja, nie wyłączona kontrolka. */ /* POPR3-pola: pole tylko do odczytu = pole zablokowane (szare tło, słabsza ramka, kursor not-allowed) — w oknie, w widoku i na telefonie tak samo. Wyjątek: pole wyboru, które samo jest tylko do odczytu, a otwiera listę (combo, lista osób). */ input[readonly]:not([type="checkbox"], [type="radio"], [type="range"], [type="hidden"], [data-combo-input], .combo-input, .asel-input), textarea[readonly] { --okno-pole-obrys: none; border-color: var(--pole-ramka-zablokowane); background: var(--pole-tlo-zablokowane); cursor: not-allowed; } ::placeholder { color: var(--text-faint); } /* Textarea rośnie w dół, więc wysokość kontrolki jest dla niej tylko minimum. */ textarea { height: auto; min-height: calc(var(--h-control) * 2); padding: var(--s-2) var(--s-3); line-height: var(--lh-base); resize: vertical; } /* Natywna strzałka wygląda inaczej w każdej przeglądarce — podmieniamy ją na własną i rezerwujemy jej miejsce po prawej. Ta sama reguła obsługuje pole comboboxa, żeby obie listy wyglądały identycznie. */ /* `padding-right` MUSI być większy niż miejsce zajęte przez strzałkę: odsunięcie od krawędzi (--s-3) + jej szerokość (--s-4) + odstęp od tekstu (--s-2). Sztywne --s-6 (32 px) było mniejsze od tej sumy, więc w wąskich polach — „Tekst", „Skala” w pasku edytora — tekst wchodził pod strzałkę. Liczone z tokenów, więc zmiana rozmiaru strzałki nie rozjedzie tego ponownie. */ /* NAPRAWA 11.08.2026 — combobox nie mial strzalki. Zmierzone na zywej stronie: `background-image: none`, `padding-right: 9px`. Przyczyna to SPECYFICZNOSC: regula bazowa pol `input:not([type=checkbox]):not([type=radio])` ma (0,2,1), a `.combo-input` tylko (0,1,0) — baza wygrywala i nadpisywala padding-right z powrotem na 9px, wiec strzalka nie miala gdzie sie zmiescic. Powtarzamy tu wzorzec bazy, zeby wyjsc na (0,3,1) i wygrac uczciwie specyficznoscia, a nie `!important`. Miejsce na strzalke = odsuniecie (--s-3) + szerokosc (--s-4) + odstep od tekstu (--s-2) = 36 px. Strzalka ma 16x16 i siedzi 12 px od krawedzi, wiec NIE wchodzi na tekst i nie wypelnia pola. */ select, input.combo-input:not([type="checkbox"]):not([type="radio"]) { appearance: none; padding-right: calc(var(--s-3) + var(--s-4) + var(--s-2)); background-image: var(--strzalka); background-repeat: no-repeat; background-position: right var(--s-3) center; background-size: var(--s-4) var(--s-4); } /* E3 (27.09.2026): lista, której wybrana wartość się nie mieści, kończy się wielokropkiem zamiast cięcia w pół litery (Użytkownicy na telefonie: „wszystkie kon:”, „Kierownik Pro”). Pełną wartość widać po otwarciu listy. */ input.combo-input:not([type="checkbox"]):not([type="radio"]) { text-overflow: ellipsis; } /* STRZAŁKI POLA LICZBOWEGO ZDJĘTE W CAŁEJ APLIKACJI. Przeglądarka dokłada do `input[type=number]` parę strzałek góra/dół. W polu szerokim na 36-70 px (filtry kolumn, pola stanu w tabelach) zajmują one większość szerokości i zasłaniają wpisaną liczbę — użytkownik nie widzi, co wpisał. Do tej pory zdejmowały je trzy osobne arkusze, każdy dla swojego okna; tu jest jedna reguła dla wszystkich pól liczbowych. Liczbę i tak wpisuje się z klawiatury, a strzałki krok po kroku są w tej aplikacji bezużyteczne (ceny, wagi, pojemności to nie liczniki). */ input[type="number"] { appearance: textfield; -moz-appearance: textfield; } input[type="number"]::-webkit-outer-spin-button, input[type="number"]::-webkit-inner-spin-button { -webkit-appearance: none; margin: 0; } /* Checkbox i radio zostają NATYWNE — accent-color barwi je tokenem, a ptaszek, tryb ciemny i kontrast rysuje przeglądarka. Mniej kodu, więcej zgodności. */ input[type="checkbox"], input[type="radio"] { width: var(--s-4); height: var(--s-4); margin: 0; flex: none; accent-color: var(--accent-strong); cursor: pointer; } /* --- POLE FORMULARZA -------------------------------------------------------- Grid, nie flex: potomek domyślnie rozciąga się na całą szerokość, więc kontrolka wypełnia pole bez ani jednego width: 100%. */ /* Monolit (linia 1252): grid + gap 3px, BEZ `min-width: 0`. Nasze zero pozwalało polu kurczyć się poniżej treści — w pasku narzędzi wychodziło 103 px zamiast 132 px. */ .field { display: grid; gap: 3px; } /* Podpowiedź pod polem: format, jednostka, skutek zmiany. */ .field-hint { font-size: var(--t-sm); color: var(--text-muted); } /* --- COMBO: pole tekstowe z listą podpowiedzi ------------------------------ */ .combo { position: relative; min-width: 0; } /* ⛔⛔ POLE COMBO MUSI WYPEŁNIAĆ SWÓJ POJEMNIK — 18.08.2026, zgłoszenie właściciela: „dlaczego te dropdowny dalej są na sobie". ZMIERZONE: pole tekstowe combo nie miało NIGDZIE szerokości poza oknami (`.modal .combo-input { width: 100% }` działa tylko w oknach), więc w kartotece brało szerokość WRODZONĄ przeglądarki (~184–204 px, zależnie od czcionki) i ROZLEWAŁO SIĘ poza swój pojemnik: lista „Normy" (kolumna 124 px) wchodziła 60 px w kolumnę pieniędzy, a pole funkcji w wierszu osoby nachodziło 36 px na cennik — 24 kolizje w samej kartotece Użytkowników. Wrapper `.combo` zawsze dostaje szerokość od otoczenia (kolumny, siatki, paska), więc pole w środku ma ją po prostu wypełniać — wszędzie, nie tylko w oknach. Reguła z okien zostaje (nie szkodzi), ale przestaje być jedyna. */ .combo-input { width: 100%; min-width: 0; } /* Natywny rozciągniętym na całą powierzchnię: klikalne jest CAŁE pudełko, a natywny „Wybierz plik" nigdy się nie pokazuje. */ /* Wcięcie 0 9px jak w bazowym przycisku monolitu (linia 1267) — nasze 12 px robiło każdy przycisk paska górnego o 7 px szerszym niż w v8 (Pomoc, Dark, PL — razem ~22 px na całym pasku). */ .ghost-button, .upload-button, .theme-toggle { display: inline-flex; align-items: center; justify-content: center; gap: var(--s-2); height: var(--h-control); padding: 0 9px; white-space: nowrap; cursor: pointer; border: 1px solid transparent; border-radius: var(--okno-przycisk-r, var(--r)); background: var(--btn-2); color: var(--text); font-size: var(--t-base); font-weight: var(--w-bold); text-decoration: none; transition: background var(--szybko), border-color var(--szybko), color var(--szybko); } .ghost-button:hover, .upload-button:hover, .theme-toggle:hover { background: var(--btn-2-hover); text-decoration: none; } .ghost-button:active, .upload-button:active, .theme-toggle:active { transform: scale(.97); } /* Ton niesie znaczenie akcji, wygląd liczy się z tonu — nowy kolor to linijka. */ /* NAPRAWA 11.08.2026 — TON DZIAŁA NA WSZYSTKICH PRZYCISKACH, NIE TYLKO NA `.ghost-button`. `public/js/ui/tony-przyciskow.js` przechodzi po WSZYSTKICH przyciskach w dokumencie (`querySelectorAll("button, a.button, a.primary-button, a.ghost-button, a.danger-button")`) i stempluje im `data-btn-tone` na podstawie tego, co robią. CSS czytał ten atrybut wyłącznie na `.ghost-button` — czyli na jednym wariancie z czterech. Skutek zgłoszony przez użytkownika: „Zapisz" w oknie kalkulacji ma `data-btn-tone="green"` i mimo to jest BIAŁY, bo żadna reguła go nie łapie. To samo dotyczyło „Anuluj" z `data-btn-tone="red"`. Teraz atrybut obowiązuje na każdym przycisku, więc system tonów wreszcie robi to, co miał robić od początku. MIEJSCE TONÓW W SYSTEMIE KOLORÓW (całość opisana w 03-kontrolki.css): niebieski `.button.primary` — GŁÓWNA akcja okna, jedna na okno zielony `[data-btn-tone="green"]` — pozostałe akcje zapisujące czerwony `[data-btn-tone="red"]` i `.danger` — kasuje dane pomarańczowy `[data-action="close-modal"]` — wyjście bez zapisu Napis liczony jako `--ton` zmieszany z `--text` w 70% — sam ton na własnym 12-procentowym tle daje kontrast poniżej progu czytelności (ta sama zasada co w pigułkach statusu, 05-komponenty.css). */ /* ⚠️ 13.09.2026 — ZIELEŃ WYCOFANA (decyzja właściciela: jeden system przycisków, wzorzec telefonu). Ton „green" (zapis/dodanie) daje teraz AKCJĘ GŁÓWNĄ — pełny niebieski — ale tylko tam, gdzie akcja główna ma sens: w stopce okna i w potwierdzeniu. Poza stopką („+ Wiersz", „Dodaj etap" w liście) zielony ton wygląda jak zwykły szary przycisk, żeby na ekranie nie było kilku „głównych" akcji. Ton „red" (usuwanie) = czerwony napis na jasnoczerwonym tle. Komentarze niżej opisują stary system. */ [data-btn-tone="red"] { --ton: var(--danger); } .button[data-btn-tone="red"], .ghost-button[data-btn-tone="red"], .upload-button[data-btn-tone="red"], .primary-button[data-btn-tone="red"], .danger-button[data-btn-tone="red"] { border-color: transparent; background: var(--danger-soft); color: var(--danger); } .button[data-btn-tone="red"]:hover, .ghost-button[data-btn-tone="red"]:hover, .upload-button[data-btn-tone="red"]:hover, .primary-button[data-btn-tone="red"]:hover, .danger-button[data-btn-tone="red"]:hover { border-color: transparent; background: color-mix(in srgb, var(--danger) 16%, var(--surface)); } .icon-button[data-btn-tone="red"] { background: var(--btn-2); color: var(--danger); } .modal > footer [data-btn-tone="green"]:is(.button, .ghost-button, .primary-button), .app-confirm-actions [data-btn-tone="green"]:is(.button, .ghost-button, .primary-button) { border-color: transparent; background: var(--accent); color: var(--on-accent); } .modal > footer [data-btn-tone="green"]:is(.button, .ghost-button, .primary-button):hover, .app-confirm-actions [data-btn-tone="green"]:is(.button, .ghost-button, .primary-button):hover { background: var(--accent-hover); } /* Stopka kalkulatora ma własne pomocnicze zapisy (profil kosztów, „Zapisz wersję") — zostają szare. Niebieskie są tylko dwie akcje oznaczone w markupie jako główne: „Zapisz" i „Generuj prezentację" (decyzja 12.08.2026). */ .modal > footer.project-cost-footer [data-btn-tone="green"]:not(.primary, .presentation-copy-link-button):is(.button, .ghost-button, .primary-button) { background: var(--btn-2); color: var(--text); } .modal > footer.project-cost-footer [data-btn-tone="green"]:not(.primary, .presentation-copy-link-button):is(.button, .ghost-button, .primary-button):hover { background: var(--btn-2-hover); } /* Okno potwierdzenia usunięcia: „Usuń" to jedyna akcja główna tego okna, więc jest pełny czerwony (jasnoczerwony obok szarego „Anuluj" wyglądał na słabszy od anulowania). Poza tym oknem usuwanie zostaje jasnoczerwone. */ .app-confirm-actions [data-confirm-ok]:is([data-btn-tone="red"], .danger-button, .button.danger) { border-color: transparent; background: var(--danger); color: var(--on-accent); } .app-confirm-actions [data-confirm-ok]:is([data-btn-tone="red"], .danger-button, .button.danger):hover { background: color-mix(in srgb, var(--danger) 85%, var(--text)); } /* Główna akcja okna wygrywa z tonem — `.button.primary` zostaje niebieski nawet jeśli skrypt nada mu ton. Jedna akcja główna na okno. */ .button.primary[data-btn-tone]:not([data-btn-tone="red"]) { border-color: transparent; background: var(--accent); color: var(--on-accent); } /* …Z JEDNYM WYJĄTKIEM: ZAPIS JEST ZAWSZE ZIELONY (11.08.2026). ZGŁOSZENIE: „przyciski zapisz mają być zielone, bo teraz w Edytuj projekt jest niebieski". ZMIERZONE: „Zapisz projekt" MIAŁ już poprawny ton zielony (`data-btn-tone="green"`), ale reguła linijkę wyżej przemalowywała go na niebiesko — tło rgb(234,240,254), napis rgb(47,89,214). Zasada „jedna akcja główna = niebieska" jest tu podporządkowana ważniejszej: KOLOR MA MÓWIĆ, CO PRZYCISK ROBI. Zielony = zapisuje. Jeśli akcją główną okna jest zapis, to zielony wygrywa — inaczej ten sam „Zapisz" byłby zielony w jednym oknie, a niebieski w drugim, zależnie od tego, czy ktoś nadał mu klasę akcji głównej. Ta sama szczegółowość co reguła wyżej (0,3,0), więc decyduje kolejność — dlatego stoi bezpośrednio po niej, a nie gdzieś dalej w pliku. */ .button.primary[data-btn-tone="green"]:hover { background: var(--accent-hover); } /* TA SAMA ZASADA DLA POMARAŃCZOWEGO — dopisane 11.08.2026. ZMIERZONY DEFEKT (szkicownik, na żywej stronie): zaraz po otwarciu okna „Anuluj" miał tło rgb(255,243,207), czyli pomarańczowe zgodnie z systemem. Po pierwszym przebiegu `public/js/ui/tony-przyciskow.js` dostawał `data-btn-tone="red"` i robił się CZERWONY — skrypt klasyfikuje po SŁOWIE („anuluj" łapie się w RED_TEXT), a nie po tym, co przycisk faktycznie robi. Ten sam guzik miał więc dwa kolory, zależnie od tego, czy skrypt zdążył przelecieć po renderze. To łamie ustaloną kolorystykę (03-kontrolki.css:66): pomarańczowy = WYJŚCIE BEZ ZAPISU, czerwony = KASUJE DANE. „Anuluj" w szkicowniku niczego nie kasuje — zamyka okno, więc ma być pomarańczowy. Zasada identyczna jak linijkę wyżej: jeśli ktoś nadał przyciskowi JAWNĄ klasę koloru, to była decyzja, a nie przypadek — automat jej nie nadpisuje. ZAKRES: wyłącznie przyciski z klasą `.warn`. Zwykłe „Anuluj" bez tej klasy zachowują się dokładnie jak dotąd — ta zmiana nie przemalowuje okien w reszcie aplikacji. */ .button.warn[data-btn-tone] { border-color: transparent; background: var(--btn-2); color: var(--text); } .button.warn[data-btn-tone]:hover { background: var(--btn-2-hover); } /* WYŁĄCZONY PRZYCISK GŁÓWNY WYGLĄDA JAK KAŻDY WYŁĄCZONY (przegląd decyzji v14, 26.09). „Dodaj etap” bez wolnych etapów albo bez prawa zostawał pełnym akcentem i tylko bladł (opacity 0,5) — wyglądał jak jasnoniebieski przycisk do kliknięcia, a obok wyłączone „Przelicz wszystkie projekty” i kosz są szare. Teraz szare tło przycisku zwykłego + przygaszenie z `.button:disabled` (03-kontrolki). Stoi po regułach tonu, bo ma tę samą wagę co `.button.primary[data-btn-tone]` wyżej — także najechanie kursorem nie zmienia koloru. */ .button.primary:disabled, .button.primary[data-btn-tone]:disabled, .primary-button:disabled { border-color: transparent; background: var(--btn-2); color: var(--text); box-shadow: none; } .upload-button { position: relative; overflow: hidden; } .upload-button input:not([type="checkbox"]):not([type="radio"]) { position: absolute; inset: 0; width: 100%; height: 100%; padding: 0; opacity: 0; cursor: inherit; } .theme-toggle.active { border-color: var(--accent-strong); background: var(--accent-soft); color: var(--accent-strong); } /* Pasek „przycisk + nazwa pliku": guzik ma stałą szerokość, nazwa bierze resztę. */ .upload-strip { display: grid; grid-template-columns: auto minmax(0, 1fr); align-items: center; gap: var(--s-3); } .pdf-upload-row { display: flex; flex-wrap: wrap; align-items: center; gap: var(--s-2); } /* Wersje mini — wiersz tabeli i komórka BOM-u. `:not([hidden])` jest konieczne: bez niego display bije [hidden] z 01-reset i schowany „Usuń" byłby widoczny. */ .upload-button.mini-upload, .mini-remove { height: var(--h-control-sm); padding: 0 var(--s-2); font-size: var(--t-xs); } .mini-remove:not([hidden]) { display: inline-flex; align-items: center; cursor: pointer; border: 1px solid color-mix(in srgb, var(--danger) 40%, var(--line)); border-radius: var(--r-sm); background: var(--danger-soft); color: var(--danger); font-weight: var(--w-bold); } .mini-remove:hover { background: color-mix(in srgb, var(--danger) 18%, var(--surface)); } /* === LISTA WYSZUKIWALNA (podmiana natywnego