
Форма на любительский турнир должна объяснять, какие данные нужны и что произойдёт после кнопки. Начнём с двух полей и браузерных ограничений. Пример проверяет ввод локально и ничего не отправляет: надёжная регистрация требует отдельного сервера и понятного порядка обработки данных.
Рабочая локальная проверка
index.html
<!doctype html>
<html lang="ru"><meta charset="utf-8"><title>Заявка на турнир</title>
<form id="entry">
<label>Имя участника, обязательно <input name="name" required maxlength="80"></label>
<label>Электронная почта, обязательно <input name="email" type="email" required></label>
<button>Проверить учебную заявку</button></form>
<p id="message" aria-live="polite"></p>
<script>
const form = document.querySelector('#entry');
const nameField = form.elements.namedItem('name');
nameField.addEventListener('input', () => nameField.setCustomValidity(''));
form.addEventListener('submit', event => {
event.preventDefault();
nameField.setCustomValidity(nameField.value.trim() ? '' : 'Введите имя, не только пробелы');
if (!form.reportValidity()) return;
document.querySelector('#message').textContent =
'Поля проверены. Это демо, заявка никуда не отправлена.';
});
</script></html>
Пустые поля и некорректный формат электронной почты останавливает встроенная валидация. Для имени добавлена проверка строки из одних пробелов. setCustomValidity очищается при вводе: иначе исправленное поле могло бы оставаться ошибочным. Текст результата прямо говорит, что заявки на сервере нет.
| Что сравнить | На что смотреть | Что сделать |
|---|---|---|
| HTML | Обязательность и базовый формат | required, type и ограничения длины |
| JavaScript | Дополнительное правило интерфейса | Объяснить пробельное имя |
| Сервер | Проверка фактического запроса и бизнес-правил | Обязательна для реальной отправки |
| Организация | Понятный результат для участника | Не выдавать проверку полей за регистрацию |
Не изобретайте лишние ограничения
Имя не стоит проверять регулярным выражением только на один алфавит без реальной причины. Оно может содержать пробелы, дефисы и другие допустимые символы. Сбор дополнительных сведений должен иметь ясную задачу. Дата рождения или медицинская информация не нужны просто потому, что такие поля встретились в чужом образце.
- Попробовать пустые поля.
- Отправить имя из пробелов и затем исправить его.
- Проверить ошибочный и корректный формат email.
- Пройти весь сценарий клавиатурой.
MDN подчёркивает, что клиентскую проверку легко обойти. При реальной разработке сервер должен заново проверить вход, ограничения турнира и допустимость операции. Нужны также обработка повторной отправки, ошибок сети и понятное подтверждение. Успешный локальный submit не доказывает ни доставки сообщения, ни появления участника в списке.
Вопросы и ответы
Почему без собственной проверки email?
Для базового формата достаточно соответствующего типа поля. Это не подтверждает существование ящика.
Можно ли включить реальные данные в демо?
Используйте вымышленные тестовые значения. Никакой регистрации здесь нет.
Что означает сообщение об успехе?
Только то, что локальные правила примера выполнены. Сервер не подключён.
Нужно ли проверять на сервере повторно?
Да. Клиентский интерфейс помогает пользователю, но не является границей доверия.
Источники: developer.mozilla.org.




