Wzorzec 16

Walidacja bez JavaScript

Formularz potrafi zgłosić większość błędów, zanim powstanie pierwsza linia JavaScript. :user-invalid zapala się dopiero po opuszczeniu pola, :has pokazuje komunikat obok, a slot na tekst błędu i tak jest zarezerwowany, więc nic nie skacze.

FormPanel walidowany samym CSS

Kliknij w pole, zostaw je puste albo wpisz zły format i wyjdź. Podświetlenie i komunikat włącza :user-invalid z :has, w tym demo nie ma ani linii JavaScript.

Reguły

:user-invalid zamiast :invalid, żeby nie krzyczeć, zanim użytkownik skończy pisać.
Komunikat włącza reguła z :has na kontenerze pola, bez nasłuchiwania zdarzeń.
Slot komunikatu ma stałą wysokość, widoczność przełącza visibility, nie display.
JavaScript zostaje na walidację biznesową, nie na formaty i wymagalność.

Wzorzec w kodzie

Trzy reguły CSS zamiast obsługi zdarzeń

.field .error { visibility: hidden; }
.field:has(input:user-invalid) .error { visibility: visible; }
.field input:user-invalid { border-color: var(--color-danger-400); }

Slot na błąd zarezerwowany, widoczność przełącza visibility

<div className="field">
  <label htmlFor="email">Adres e-mail</label>
  <input id="email" type="email" required />
  <p className="error min-h-lh">
    Podaj poprawny adres z małpą.
  </p>
</div>

Prompt dla Claude

Wklej do Claude Code w swoim projekcie. Prompt niesie komplet reguł tej lekcji i ogólne zasady Liquid Design, więc implementacja trafia w metodologię bez tłumaczenia jej od zera.

Prompt do wklejenia

Zaimplementuj w moim projekcie wzorzec „Walidacja bez JavaScript" z metodologii Liquid Design.

Pseudoklasy :user-invalid i :has stylują błędy dopiero po interakcji, z komunikatem w zarezerwowanym slocie, zanim uruchomi się jakikolwiek skrypt.

Wymagania:
- :user-invalid zamiast :invalid, żeby nie krzyczeć, zanim użytkownik skończy pisać.
- Komunikat włącza reguła z :has na kontenerze pola, bez nasłuchiwania zdarzeń.
- Slot komunikatu ma stałą wysokość, widoczność przełącza visibility, nie display.
- JavaScript zostaje na walidację biznesową, nie na formaty i wymagalność.

Ogólne reguły Liquid Design, których implementacja nie może złamać:
- HTML jest semantyczny: button, a, nav, form, label, dialog, details, ul, dl i nagłówki h1-h6 zamiast div z onClick i ARIA dopisywanym ręcznie. div i span służą wyłącznie do layoutu, nigdy do interakcji ani struktury treści.
- Layout jest umową: treść, która dociera później, ma miejsce zarezerwowane od pierwszego renderu. Nic nie skacze.
- Stany ładowania, pustki, błędu i treści dzielą jeden layout.
- Typografia pochodzi z nazwanej, płynnej skali opartej o clamp(), nie z gołych rozmiarów.
- Animacje dotyczą wyłącznie transform i opacity, a prefers-reduced-motion redukuje je do natychmiastowej zmiany stanu.
- Breakpoint jest ostatecznością: najpierw container queries i repeat(auto-fit, minmax(...)).

Sposób pracy – zanim napiszesz pierwszą linię kodu:
- Sprawdź w plikach projektu, jak stylowane są komponenty (Tailwind, CSS Modules, vanilla-extract, styled-components, Sass, czysty CSS...) i pisz wyłącznie w tej konwencji. Niczego nie zakładaj z góry i nie dodawaj nowych zależności.
- Wymagania powyżej opisują właściwości CSS i atrybuty HTML, nie klasy narzędziowe. Przełóż je na system stylowania zastany w projekcie.
- Sprawdź framework komponentów, wersję i konwencje nazewnictwa, zamiast zakładać konkretny stack.
- Używaj istniejących tokenów projektu (kolory, typografia, odstępy). Jeśli czegoś brakuje, zaproponuj minimalne uzupełnienie w duchu istniejącego kodu, nie osobny system.
- Nie używaj klas, tokenów ani API, których nie znalazłeś w tym projekcie.

Pełny opis z żywym demo i kodem: https://liquid-design.website/wzorce/walidacja-css