<form>
<input type="email" id="addr" required>
<input type="submit" value="Zapisz">
</form>
Na podstawie przedstawionego kodu formularza HTML można powiedzieć, że pole edycyjne:
W tym fragmencie kodu HTML masz dwa bardzo ważne atrybuty: type="email" oraz required. To właśnie one razem powodują, że poprawna jest odpowiedź, że pole nie może być puste i wymaga wpisania tekstu ze znakiem @.
Atrybut required oznacza, że pole jest obowiązkowe. Przeglądarka, zgodnie ze specyfikacją HTML5, nie pozwoli wysłać formularza, dopóki pole nie będzie wypełnione. Użytkownik kliknie przycisk „Zapisz”, a formularz po prostu się nie wyśle – pojawi się komunikat walidacyjny po stronie przeglądarki. To jest tzw. walidacja po stronie klienta, domyślnie wbudowana w HTML.
Z kolei type="email" uruchamia specjalny mechanizm sprawdzania formatu wpisanego tekstu. Przeglądarka sprawdza, czy ciąg znaków wygląda jak adres e‑mail: musi zawierać co najmniej znak @ i jakąś część przed i po nim. To nie jest super zaawansowana walidacja, ale wystarcza jako pierwszy filtr, np. "[email protected]" przejdzie, a "jan.domena.pl" już nie. Moim zdaniem to bardzo wygodne, bo nie trzeba od razu pisać własnego JavaScriptu tylko po to, żeby odsiać oczywiste błędy.
W praktyce w aplikacjach webowych zwykle łączy się tę prostą walidację HTML5 z dodatkowymi sprawdzeniami po stronie serwera (np. w PHP czy w innym backendzie), bo dane z formularza zawsze trzeba traktować z ograniczonym zaufaniem. Dobrym nawykiem jest też dodanie atrybutu name, np. name="email", żeby serwer mógł poprawnie odebrać wartość pola.
Warto też wiedzieć, że niektóre przeglądarki mobilne, gdy widzą type="email", podpowiadają użytkownikowi specjalną klawiaturę z łatwym dostępem do znaku @ i kropki, co realnie poprawia wygodę wpisywania adresu. To taki mały szczegół, ale w profesjonalnych projektach UX ma znaczenie. Podsumowując: required blokuje puste wysłanie formularza, a type="email" wymusza poprawny, podstawowy format adresu ze znakiem @ – dokładnie to opisuje poprawna odpowiedź.
Atrybut required oznacza, że pole jest obowiązkowe. Przeglądarka, zgodnie ze specyfikacją HTML5, nie pozwoli wysłać formularza, dopóki pole nie będzie wypełnione. Użytkownik kliknie przycisk „Zapisz”, a formularz po prostu się nie wyśle – pojawi się komunikat walidacyjny po stronie przeglądarki. To jest tzw. walidacja po stronie klienta, domyślnie wbudowana w HTML.
Z kolei type="email" uruchamia specjalny mechanizm sprawdzania formatu wpisanego tekstu. Przeglądarka sprawdza, czy ciąg znaków wygląda jak adres e‑mail: musi zawierać co najmniej znak @ i jakąś część przed i po nim. To nie jest super zaawansowana walidacja, ale wystarcza jako pierwszy filtr, np. "[email protected]" przejdzie, a "jan.domena.pl" już nie. Moim zdaniem to bardzo wygodne, bo nie trzeba od razu pisać własnego JavaScriptu tylko po to, żeby odsiać oczywiste błędy.
W praktyce w aplikacjach webowych zwykle łączy się tę prostą walidację HTML5 z dodatkowymi sprawdzeniami po stronie serwera (np. w PHP czy w innym backendzie), bo dane z formularza zawsze trzeba traktować z ograniczonym zaufaniem. Dobrym nawykiem jest też dodanie atrybutu name, np. name="email", żeby serwer mógł poprawnie odebrać wartość pola.
Warto też wiedzieć, że niektóre przeglądarki mobilne, gdy widzą type="email", podpowiadają użytkownikowi specjalną klawiaturę z łatwym dostępem do znaku @ i kropki, co realnie poprawia wygodę wpisywania adresu. To taki mały szczegół, ale w profesjonalnych projektach UX ma znaczenie. Podsumowując: required blokuje puste wysłanie formularza, a type="email" wymusza poprawny, podstawowy format adresu ze znakiem @ – dokładnie to opisuje poprawna odpowiedź.
Kod formularza, który został pokazany w pytaniu, wykorzystuje dwa mechanizmy walidacji wbudowane w HTML5: typ pola ustawiony na email oraz atrybut required. Jeśli się je dobrze rozumie, to łatwo odrzucić wszystkie błędne interpretacje. Spójrzmy na to bardziej od strony tego, co faktycznie robi przeglądarka.
Pomysł, że pole może być puste, jest sprzeczny z działaniem atrybutu required. Ten atrybut wprost oznacza, że użytkownik musi coś wpisać. Jeżeli zostawi pole puste i kliknie przycisk „Zapisz”, przeglądarka zablokuje wysłanie formularza i wyświetli swój komunikat, np. „Wypełnij to pole”. To nie jest kwestia „dobrej praktyki”, tylko twardej reguły zapisanej w specyfikacji HTML. W praktyce to bardzo przydatne, bo od razu na froncie wymusza uzupełnienie danych.
Stwierdzenie, że pole nie powinno zawierać znaków numerycznych, też jest błędne. Pole typu email dopuszcza cyfry, bo wiele poprawnych adresów e‑mail zawiera liczby, np. [email protected]. Przeglądarka nie ma żadnego zakazu cyfr w takim polu, patrzy tylko na ogólny format adresu.
Nieprawidłowy jest też pogląd, że wymagane są „jedynie znaki alfanumeryczne”. Adres e‑mail zawiera zwykle kropki, znak @, czasem myślniki, podkreślenia i inne dopuszczalne znaki. Gdyby przeglądarka pozwalała tylko na litery i cyfry, większość realnych adresów zostałaby odrzucona. Walidacja typu email jest skoncentrowana na strukturze (część przed @, znak @, część po @), a nie na tak prymitywnym ograniczeniu jak „tylko litery i cyfry”.
Typowy błąd myślowy przy takich pytaniach to mylenie różnych poziomów walidacji: jedni zakładają, że HTML w ogóle nie sprawdza formatu, inni z kolei wyobrażają sobie zbyt restrykcyjne reguły, które w praktyce by uniemożliwiły wpisanie normalnego adresu. Dobrym nawykiem jest patrzenie na to, co gwarantuje przeglądarka: w tym wypadku wymagane jest, żeby pole nie było puste (required) oraz żeby wpisany tekst przypominał adres e‑mail, czyli zawierał m.in. znak @ w odpowiednim miejscu. Wszystkie inne interpretacje wychodzą poza to, co naprawdę wynika z kodu formularza.
Pomysł, że pole może być puste, jest sprzeczny z działaniem atrybutu required. Ten atrybut wprost oznacza, że użytkownik musi coś wpisać. Jeżeli zostawi pole puste i kliknie przycisk „Zapisz”, przeglądarka zablokuje wysłanie formularza i wyświetli swój komunikat, np. „Wypełnij to pole”. To nie jest kwestia „dobrej praktyki”, tylko twardej reguły zapisanej w specyfikacji HTML. W praktyce to bardzo przydatne, bo od razu na froncie wymusza uzupełnienie danych.
Stwierdzenie, że pole nie powinno zawierać znaków numerycznych, też jest błędne. Pole typu email dopuszcza cyfry, bo wiele poprawnych adresów e‑mail zawiera liczby, np. [email protected]. Przeglądarka nie ma żadnego zakazu cyfr w takim polu, patrzy tylko na ogólny format adresu.
Nieprawidłowy jest też pogląd, że wymagane są „jedynie znaki alfanumeryczne”. Adres e‑mail zawiera zwykle kropki, znak @, czasem myślniki, podkreślenia i inne dopuszczalne znaki. Gdyby przeglądarka pozwalała tylko na litery i cyfry, większość realnych adresów zostałaby odrzucona. Walidacja typu email jest skoncentrowana na strukturze (część przed @, znak @, część po @), a nie na tak prymitywnym ograniczeniu jak „tylko litery i cyfry”.
Typowy błąd myślowy przy takich pytaniach to mylenie różnych poziomów walidacji: jedni zakładają, że HTML w ogóle nie sprawdza formatu, inni z kolei wyobrażają sobie zbyt restrykcyjne reguły, które w praktyce by uniemożliwiły wpisanie normalnego adresu. Dobrym nawykiem jest patrzenie na to, co gwarantuje przeglądarka: w tym wypadku wymagane jest, żeby pole nie było puste (required) oraz żeby wpisany tekst przypominał adres e‑mail, czyli zawierał m.in. znak @ w odpowiednim miejscu. Wszystkie inne interpretacje wychodzą poza to, co naprawdę wynika z kodu formularza.