Constraint Validation API

HTML5 wprowadził wbudowaną walidację formularzy za pomocą atrybutów: required, type="email", type="number", min, max, pattern, minlength, maxlength. Przeglądarka automatycznie przeprowadza walidację podczas wysyłania formularza i wyświetla komunikaty o błędach — bez konieczności używania JS.

:invalid dopasowuje pola, które nie przechodzą walidacji, a :valid — pola, które ją przechodzą. :user-invalid (nowoczesny selektor) dopasowuje pola dopiero po interakcji użytkownika, dzięki czemu nietknięty formularz nie jest od razu oznaczany czerwonym obramowaniem. Do stylizowania błędów należy używać tych pseudoklas.

Każdy element formularza udostępnia właściwość validity — obiekt ValidityState z flagami logicznymi: valid, valueMissing, typeMismatch, patternMismatch, rangeUnderflow, tooShort itd. Należy je sprawdzać, aby zdecydować, który błąd wyświetlić.

input.checkValidity() zwraca true, jeśli wartość spełnia wszystkie ograniczenia, a w przeciwnym razie zwraca false. form.checkValidity() sprawdza cały formularz. Jest to przydatne podczas programowych kontroli przed wykonaniem żądania AJAX lub przed zezwoleniem użytkownikowi na przejście dalej w wieloetapowym formularzu.

input.reportValidity() działa podobnie jak checkValidity, ale dodatkowo wyświetla wbudowaną podpowiedź przeglądarki i ustawia fokus na pierwszym nieprawidłowym polu. Należy użyć tej metody, gdy chcą Państwo bez dodatkowej pracy korzystać z natywnego interfejsu; checkValidity sprawdzi się wtedy, gdy wyświetlanie błędów ma być w pełni niestandardowe.

Domyślne komunikaty przeglądarki ("Please fill out this field") mogą nie pasować do przyjętego tonu ani języka. Można je zastąpić za pomocą input.setCustomValidity("Enter a valid coupon code"). Pole pozostaje nieprawidłowe, dopóki komunikat nie zostanie wyczyszczony przez setCustomValidity("").

Dodanie atrybutu novalidate do formularza wyłącza domyślne zachowanie przeglądarki związane z walidacją. Jest to przydatne podczas implementowania w pełni niestandardowego wyświetlania błędów — formularz nadal zostanie wysłany niezależnie od tego, czy przeszedłby walidację, dlatego przed wysłaniem należy sprawdzić go programowo.

Każdy element formularza emituje zdarzenie invalid, gdy walidacja się nie powiedzie. Należy go obsłużyć, aby wyłączyć domyślną podpowiedź i wyświetlić niestandardowy komunikat: input.addEventListener("invalid", (e) => { e.preventDefault(); showError(input); }).

Atrybut pattern zawiera wyrażenie regularne JavaScriptu, któremu wartość musi odpowiadać w całości (nie trzeba dodawać kotwic ^ i $ — są stosowane niejawnie). Warto połączyć go z atrybutem title, aby opisać użytkownikom oczekiwany format.

Walidacja HTML jest udogodnieniem dla użytkowników — każdy może ją ominąć, edytując DOM. Zawsze należy ponownie przeprowadzać walidację na serwerze. Ograniczenia HTML służą poprawie UX (natychmiastowej informacji zwrotnej i zmniejszeniu liczby żądań), a nie zapewnieniu bezpieczeństwa.

Ograniczenia się łączą: <input type="number" min="18" max="120" required step="1"> musi mieć wartość, która jest liczbą całkowitą z zakresu od 18 do 120. Przeglądarka udostępnia informacje o tym, które konkretne ograniczenie nie zostało spełnione, za pomocą flag ValidityState, dzięki czemu można wyświetlić właściwy komunikat.

Czym pseudoklasa CSS :user-invalid różni się od :invalid?

Natywne atrybuty walidacji (required, type, pattern, min, max) oraz API ValidityState zapewniają rozbudowaną walidację po stronie klienta, domyślnie bez JS. CSS :user-invalid stylizuje błędy dopiero po interakcji użytkownika. checkValidity/reportValidity służą do programowych kontroli. setCustomValidity zastępuje domyślne komunikaty. Zawsze należy ponownie przeprowadzać walidację na serwerze.