Современные браузеры позволяют нам указывать правила проверки для наших полей ввода с помощью атрибутов поля. При реализации проверки полей в наших HTML-формах нашим первым импульсом часто является обращение к библиотеке проверки javascript. Мы склонны упускать из виду встроенную способность браузера выполнять проверку данных без использования JavaScript. Правила, которые мы определяем через атрибуты поля ввода, используются браузером для определения достоверности данных, введенных пользователем в поле. Если данные недействительны, браузер предотвратит отправку формы и отобразит пользователю сообщение об ошибке.
Атрибут типа
Чтобы выполнить проверку данных через браузер, первое ограничение, которое мы можем разместить в наших полях ввода, — это атрибут тип. HTML5 определяет множество типов семантического ввода, которые мы можем указать в качестве типов полей ввода, включая: кнопку, флажок, адрес электронной почты, пароль, телефон, текст, URL-адрес и многие другие. Посетите MDN для получения полного списка доступных форм типы ввода:
<input type=“email">
Обязательный атрибут
Если поле ввода должно иметь данные перед отправкой формы, мы можем использовать обязательный атрибут, чтобы запретить отправку формы с пустым полем.
<input type=“password” required>
Атрибут шаблона
Атрибут шаблона позволяет нам определить шаблон регулярного выражения, по которому браузер будет проверять данные в поле ввода. Ниже приведен пример шаблона регулярного выражения для положительных или отрицательных сумм в долларах США:
<input type=‘number’ pattern=“^[+-]?[0–9]{1,3}(?:,?[0–9]{3})*\.[0–9]{2}$” required>
Ошибки стиля
Когда дело доходит до оформления наших полей, если они содержат недопустимые данные, API проверки ограничений предоставляет псевдоселектор CSS :invalid. Этот селектор позволяет стилизовать фактические поля ввода, но одним из недостатков использования собственного механизма проверки браузера является то, что невозможно стилизовать сообщения об ошибках браузера. Единственная часть сообщения об ошибке, которую можно настроить с помощью атрибутов поля, — это текст сообщения. Чтобы указать текст сообщения об ошибке, мы используем атрибут title. Ниже приведен пример использования псевдоселектора :invalid для рисования красной рамки вокруг поля с недопустимыми данными и использования атрибута title для настройки текста сообщения об ошибке.
# CSS
input[name=”state”]:not(:focus):invalid {
border-color: red;
}
# HTML
<input type=“text” name=“state” id=“state” minLength=“2” maxLength=“2” title=“Enter A 2 Letter State Abbreviation”>
Настройка сообщений об ошибках
API проверки ограничений предоставляет объект состояния валидности, который позволяет нам проверять соответствие определенным нами правилам атрибутов ограничений. Доступ к объекту осуществляется через свойство validity поля ввода.
const stateField = document.querySelector(“input[name=’state’]”); const stateFieldValidity = stateField.validity;
Следующий объект состояния достоверности содержит значения, которые мы получили бы, если бы получили доступ к объекту поля предыдущего примера, когда в поле была только одна буква. Обратите внимание, что свойство two short истинно:
{
badInput: false
customError: false
patternMismatch: false
rangeOverflow: false
rangeUnderflow: false
stepMismatch: false
tooLong: false
tooShort: true
typeMismatch: false
valid: false
valueMissing: false
}
Используя этот объект состояния проверки и обработчики событий, мы можем создавать сценарии проверки формы, которые отображают пользовательские сообщения об ошибках. Эта статья Криса Фердинанди о CSS-TRICKS полностью описывает упрощенный способ программирования скрипта проверки, подобного этому.
Даже если мы в конечном итоге используем наш собственный код javascript для настройки сообщений об ошибках, использование встроенного API-интерфейса проверки ограничений браузера позволяет получить окончательные размеры сценариев, которые обычно намного меньше, чем сторонние библиотеки проверки, на которые мы часто полагаемся. Кроме того, использование ограничений через атрибуты поля ввода избавляет нас от необходимости реализовывать пользовательскую логику проверки в наших сценариях.
