Zasada 03

Miejsce na błąd

Formularz, który skacze przy walidacji, karze użytkownika za pomyłkę drugi raz. Slot na komunikat błędu jest częścią layoutu od pierwszego renderu. Pusty również zajmuje swoją wysokość i cierpliwie czeka.

Logowanie: błąd, który niczego nie przesuwa

Wyślij oba formularze puste. Lewy skacze przy każdej walidacji, prawy ma sloty na komunikaty od pierwszego renderu.

✕ Bez rezerwacji

✓ Z rezerwacją

Reguły

Pod każdym polem istnieje slot o stałej minimalnej wysokości na komunikat walidacji.
Globalne błędy (sieć, serwer) mają własny zarezerwowany obszar i nie wypychają przycisków.
Pojawienie się i zniknięcie błędu nie przesuwa żadnego innego elementu.
Komunikat mówi, co zrobić dalej, a aria-live ogłasza go czytnikom ekranu.

Wzorzec w kodzie

Slot pod polem istnieje zawsze, pusty też zajmuje wysokość

<label htmlFor="email">E-mail</label>
<input id="email" aria-invalid={Boolean(error)} />
<p className="min-h-lh text-xs text-red-400">
  {error ?? " "}
</p>

Obszar na błąd global nie wypycha przycisku

<div aria-live="polite" className="flex min-h-11 items-center">
  {serverError && (
    <p role="alert" className="rounded-lg bg-red-500/10 px-3 py-2">
      {serverError}
    </p>
  )}
</div>
<button type="submit">Zapisz</button>

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

Zastosuj w moim projekcie zasadę „Miejsce na błąd" z metodologii Liquid Design.

Komunikat błędu nie jest gościem. Ma zarezerwowane krzesło przy stole od samego początku.

Wymagania:
- Pod każdym polem istnieje slot o stałej minimalnej wysokości na komunikat walidacji.
- Globalne błędy (sieć, serwer) mają własny zarezerwowany obszar i nie wypychają przycisków.
- Pojawienie się i zniknięcie błędu nie przesuwa żadnego innego elementu.
- Komunikat mówi, co zrobić dalej, a aria-live ogłasza go czytnikom ekranu.

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/zasady/bledy