HTML5 валидация форм на стороне клиента


Содержание

Валидация форм через HTML

Для проверки полей формы на валидность средствами HTML используют атрибут pattern. В нем можно указать любое регулярное выражение согласно которому будут проверятся данные в поле.

Синтаксис использования атрибута таков:

Регулярные выражения для распространенных видов данных

Выражение Значение
[A-Za-zА-Яа-яЁё] любая буква
^[a-zA-Z]+$ только латиница
^[a-zA-Z0-9]+$ только цыфры и латинские буквы
^[а-яА-ЯёЁa-zA-Z0-9]+$ цифры+латиница+кириллица
^[ 0-9]+$ только цифры
^\(\d<3>\)\d<3>-\d<2>-\d<2>$ телефон в формате (ХХХ)XXX-XX-XX
/^([a-z0-9_\.-]+)@([a-z0-9_\.-]+)\.([a-z\.]<2,6>)$ email
[0-9]<4>-(0[1-9]|1[012])-(0[1-9]|1[0-9]|2[0-9]|3[01]) дата в формате YYYY-MM-DD
(0[1-9]|[12][0-9]|3[01])[- /.](0[1-9]|1[012])[- /.](19|20)\d\d дата в формате DD/MM/YYYY
^([0-1]\d|2[0-3])(:[0-5]\d)<2>$ время в формате HH:MM:SS
\-?\d+(\.\d<0,>)? целые числа и числа с плавающей точкой с разделителем точкой
^[a-zA-Z][a-zA-Z0-9-_\.]<1,20>$ имя пользователя (с ограничением 2-20 символов, которыми могут быть буквами и цифрами, первый символ обязательно буква)
^(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(. *\s).*$ пароль (Строчные и прописные латинские буквы, цифры)
(?=^.<8,>$)((?=.*\d)|(?=.*\W+))(?![.\n])(?=.*[A-Z])(?=.*[a-z]).*$ пароль (Строчные и прописные латинские буквы, цифры, спецсимволы. Минимум 8 символов)

Ограничение количества вводимых символов

Атрибут maxlength устанавливает ограничение на максимальное количество символов, которые можно ввести в поле:

HTML5 валидация форм на стороне клиента

Итак, в нашем распоряжении имеются различные элементы, которые мы можем использовать на форме. Мы можем вводить в них различные значения. Однако нередко пользователи вводят не совсем корректные значения: например, ожидается ввод чисел, а пользователь вводит буквы и т.д. И для предупреждения и проверки некорректного ввода в HTML5 существует механизм валидации.

Преимущество использования валидации в HTML5 заключается в том, что пользователь после некорректного ввода может сразу получить сообщение об ошибке и внести соответствующие изменения в введенные данные.

Для создания валидации у элементов форм HTML5 используется ряд атрибутов:

required : требует обязательного ввода значения. Для элементов textarea, select, input (с типом text, password, checkbox, radio, file, datetime-local, date, month, time, week, number, email, url, search, tel)

min и max : минимально и максимально допустимые значения. Для элемента input с типом datetime-local, date, month, time, week, number, range

pattern : задает шаблон, которому должны соответствовать вводимые данные. Для элемента input с типом text, password, email, url, search, tel

Атрибут required

Атрибут required требует обязательного наличия значения:

Если мы не введем в эти поля никаких данных, оставив их пустыми, и нажмем на кнопку отправки, то браузер высветит нам сообщения об ошибке, а данные не будут отправлены на сервер:

В зависимости от браузера визуализация сообщения может несколько отличаться. Также границы некорректного поля ввода могут окрашиваться в красный цвет. Например, поведение при отправке пустых сообщений в Firefox:

Атрибуты max и min

Для ограничения диапазона вводимых значений применяются атрибуты max и min:

Атрибут pattern

Атрибут pattern задает шаблон, которому должны соответствовать данные. Для определения шаблона используется язык так называемых регулярных выражений. Рассмотрим самые простейшие примеры:

Здесь для ввода номера телефона используется регулярное выражение \+\d-\d<3>-\d<3>-\d <4>. Оно означает, что первым элементом в номере должен идти знак плюс +. Выражение \d представляет любую цифру от 0 до 9. Выражение \d <3>означает три подряд идущих цифры, а \d <4>— четыре цифры подряд. То есть это выражение будет соответствовать номеру телефона в формате «+1-234-567-8901».

Если мы введем данные, которые не соответствуют этому шаблону, и нажмем на отправку, то браузер отобразит ошибку:

Отключение валидации

Не всегда валидация является желаемой, иногда требуется ее отключить. И в этом случае мы можем использовать либо у элемента формы атрибут novalidate , либо у кнопки отправки атрибут formnovalidate :

Формы HTML5: Java Script и проверка с Constraint Validation API

  • CSS — CSS3
  • HTML — HTML5
  • Flexbox CSS — уроки
  • JavaScript
  • Плагины и расширения
  • Шпаргалки по Битрикс
  • Продвижение сайтов
  • Web-ДИЗАЙНЕРУ
  • ЗАРАБОТОК в интернете
  • Виды интернет-сайтов
  • Разное

Дата публикации: 14.06.2015

В последней статье из цикла статей, посвященных веб-формам в HTML5, мы разберем интеграцию с JavaScript и валидацию с Constraint Validation API. Убедитесь, что вы уже ознакомились со статьями о разметке в HTML5 и CSS в HTML5 и имеете о них представление.

HTML5 позволяет нам осуществлять валидацию форм со стороны клиента без применения кодов Java Script. Тем не менее, нам необходимо усилить встроенную проверку при создании более сложных форм, поскольку:

  • • Не все виды полей ввода в HTML5и CSS селекторы поддерживаются во всех браузерах;
  • • В блоках сообщений об ошибке, всплывающих рядом с полем, используется базовый текст (такой как «пожалуйста, заполните это поле»), и к ним сложно применить какие-либо стили;
  • • Стили :invalid и :required применяются при загрузке веб-страницы до того, как юзер начнет взаимодействовать с формой.

Магия JavaScript и Constraint Validation API поможет гарантировать, что у пользователя отобразится все максимально правильно. Учтите, что будет довольно сложно обеспечить одновременную поддержку многих видов полей ввода во многих браузерах, но мы попытаемся это сделать.

Перехват при передаче форм

До появления HTML5 валидация со стороны клиента включала прикрепление к форме элемента submit , который бы проверял поля, показывал ошибки и предотвращал момент инициализации.

В HTML5 браузер в первую очередь осуществит свою проверку – момент инициализации не наступит, пока в форму не будет введено действительное значение. Поэтому, если вы хотите установить какую-либо сложную операцию, такую как собственное отображение ошибок, сличением с исходным текстом или авто-заполнение полей, вы должны отключить родную валидацию, присвоив свойству формы noValidate значение true:

Конечно, это означает, что вы должны проверить код на наличие ошибок в полях, но, как мы убедимся позже, вы все равно можете использовать собственную валидацию браузера.

Свойство поля .willValidate

Каждому полю ввода присваивается свойство .willValidate . Оно принимает значения:

  • true, когда браузер будет проводить собственную валидацию поля ввода;
  • false, когда браузер не будет проводить валидацию поля, или;
  • undefined, когда браузер не поддерживает родную валидацию HTML5, как например, в IE8;

Поскольку выше мы отключили родную валидацию, каждое поле примет значение false. Давайте создадим свой элемент управления validateForm , который будет проходить цикл через все поля и проверять возможность осуществления собственной валидации:

Оператор проводит цикл через все поля в группе elements поля и проверяет, являются ли они полями ввода, а не другими элементами, например, кнопками или значениями полей. Следующий пример особенно важен:

Оба значения, и false, и undefined являются неверными, поэтому вы не можете проверить только свойство field.willValidate !
Теперь мы знаем, что код внутри первого блока будет считан, когда будет доступна родная валидация. Тем не менее…

Поддерживает ли браузер различные типы полей ввода?

Если вы прочитали первую статью из цикла, вы вспомните, что типы полей, не поддерживаемые браузером, возвращаются к обычному текстовому полю. Например, код:

не поддерживается в браузерах Firefox 29 и IE11. В действительности эти браузеры сгенерируют следующий код:

Однако оба браузера поддерживают валидацию для текстовых полей, поэтому field.willValidate не примет значение undefined . Поэтому мы должны убедиться, что атрибут нашего типа (type) подходит к свойству объект. Type – если нет, то мы должны выполнить резервную валидацию, например:

Метод присвоения полю свойства .checkValidity()

Если доступна родная валидация, для проверки поля можно использовать метод .checkValidity . Если нет несоответствий, свойство принимает значение true, если есть – false.

Также есть метод со свойством поля .reportValidity , которое преобразует текущее состояние проверки в состояние повторной проверки, но оно менее полезное и поддерживается не всеми браузерами.

Также оба метода:

  • 1. устанавливают объект поля .validity , благодаря чему ошибки можно проверить более детально и
  • 2. инициируют присвоение значения invalid , когда не удается провести валидацию. Можно использовать это для того, чтобы отобразить ошибки, изменить цвета и т.д.

Заметьте, что соответствующего значения valid нет, поэтому при необходимости не забывайте перезагружать ошибочные стили и сообщения.

Объект поля со свойством .Validity

Объект со свойством .validity может иметь следующие свойства:

.valid – значение true принимается, если в поле нет ошибок, в ином случае принимается значение false.
.valueMissing – значение true принимается, если заполнение поля обязательно, а значение не введено.
.typeMismatch – значение true принимается, если значение имеет неправильный синтаксис, например, это плохо отформатированный e-mail.
.patternMismatch – значение true принимается, если значение не соответствует регулярному выражению атрибута pattern .
.tooLong – значение true принимается, если значение имеет большую длину, чем максимальная установленная длина (maxlength) .
.tooShort – значение true принимается, если значение имеет меньшую длину, чем установленная минимальная длина (minlength) .
.rangeUnderFlow – значение true принимается, если значение ниже, чем установленный минимум.
.rangeOverflow – значение true принимается, если значение выше, чем установленный максимум.
.badInput – значение true принимается, если введенные данные нельзя преобразовать в формат значения.
.customError – значение true принимается, если у поля есть собственный набор ошибок.

Не все свойства поддерживаются во всех браузерах, поэтому будьте внимательны при присвоении многих свойств. В большинстве случаев, использования свойств .valid или .checkValidity() будет достаточно для того, чтобы отобразить или скрыть сообщения об ошибке.

Поддержка свойства .validity в старых браузерах

Вы можете вручную эмулировать объект со свойством .validity в устаревших версия браузеров, например:

Это гарантирует, что объекты со свойством .validity.valid будут проверены во всех браузерах.

Метод присвоения полю свойства .setCustomValidity()

Метод со свойством .setCustomValidity может быть осуществлен путем введения:

  • • пустой строки. Она указывает на то, что поле имеет действительное значение, поэтому свойства .checkValidity и .validity.valid примут значение true, или;
  • • строки с сообщением об ошибке, которое будет отображаться в блоке для сообщений (если таковое используется).

Сообщение также отмечает поле как ошибочное, поэтому свойства . checkValidity() и .validity.valid примут значении false, и будет инициировано присвоение свойства .invalid .

Имейте в виду, что кроме этого можно проверить и текущее сообщение, для этого нужно использовать свойство поля .validationMessage .

Выводы

Теперь мы имеем представление об основах простой, базовой системы валидации кросс-браузерных форм:

Проверку LegacyValidation намеренно сделали простой; она проверяет регулярные выражения required , minlength , maxlength и pattern , но вам понадобится дополнительный код для проверки адресов e-mail, URL, дат, чисел, диапазонов и т.д.

В связи с чем возникает вопрос: если вы пишете код для валидации поля в устаревших браузерах, зачем вообще нужно использовать родную API проверку браузера? Логичный вывод! Рассмотренный выше код является обязательным только в том случае, если вы хотите гарантировать поддержку всеми браузерами, начиная с IE6 и выше, и гарантировать пользователю правильное отображение. В иных случаях он не является обязательным…

Как запустить HTML5 валидацию формы перед AJAX?

Есть форма входа, которая при подключенном JS вместо сабмита запускает AJAX запрос:

Проблема — перед запуском AJAX не производится валидация формы. У меня всё прописано в HTML5 — required, minlength — и я не хочу еще лишний раз писать валидацию на JS.
Как запустить из JS HTML5 валидацию формы, и чтоб выскакивали нативные сообщения браузера в случае неправильно введенных данных?

  • Вопрос задан более двух лет назад
  • 318 просмотров

Старайтесь не использовать ид для такого рода вещей / вообще не использовать ид

Наконец-то нашёл более-менее простой способ.

Нужно прописать нечто такое перед инструкциями в tryToLogin():

Т.е. если браузер сообщает, что проверка не пройдена, мы анбиндим функцию с клика на сабмит, кликаем сабмит (браузер покажет нативные сообщения), и сразу же биндим функцию обратно.

Всё проще — нужно ловить не клик по сабмиту, а сабмит формы.

Плохо:
$(‘button.submit’).on(‘click’, function(e)<. >);
Хорошо:
$(‘form’).on(‘submit’, function(e)<. >);

Посторонним В., Вы не поняли. Никакого трюка не надо.
Сначала происходит HTML5 валидация, потом сабмит формы.
Если вы отслеживаете событие submit на форме, то у вас HTML5 валидация сначала отработает. Если валидация не прошла, сабмита не будет.

Если вы ловите клик на кнопке, то к отправке формы это отношения не имеет, потому что вы глушите это событие. а раз нет отправки, то нет и валидации. Кроме того клик не сработает при отправке формы клавишей Энтер.

Получаем и проверяем данные из формы в PHP

Здравствуйте уважаемый посетитель!

В предыдущих статьях мы подготовили форму оформления заказа используя инструменты проверки корректности ввода данных на стороне клиента. Для этого сначала использовали встроенные возможности HTML5, а затем для проверки ввода пароля дополнительно создали скрипты JavaScript.

Таким образом мы обеспечили проверку ввода данных без перегрузки страницы и, соответственно, без лишней потери времени для пользователя. А кроме того обеспечили блокировку отправки формы в случае наличия каких либо ошибок.

Однако, только одной такой проверки на стороне клиента будет недостаточно. Требуется также выполнять валидацию формы и на стороне сервера. Это обусловлено в первую очередь соображениями безопасности от действий злоумышленников.

Ведь при желании совсем несложно изменить в браузере загруженный HTML-код веб-страницы сайта с целью отключения в нем проверки данных в форме, предусмотренные языком описания структуры веб-страниц. В данном случае HTML5.

В случае же если на сайте для проверки формы на стороне клиента применены специально созданные скрипты, то не трудно в браузере отключить JavaScript и вводить в поля все, что заблагорассудится. Включая различные теги и другие запрещенные комбинации символов, которые могут нанести серьезный вред работе сайта.

Поэтому, для защиты сайтов от злоумышленников в части, касающейся вводимых данных в формы, и применяется их валидация на стороне сервера.

Существует большое количество разных вариантов проверок форм на серверной стороне. Достаточно для этого в поиске сделать соответствующий запрос. В нашем же случае мы создадим такой инструмент на PHP с использованием универсальной пользовательской функции. Что позволит существенно сократить объем используемого PHP-кода, необходимый для реализации требуемого алгоритма проверки.

Думаю, что представленный здесь вариант валидации формы на стороне сервера будет интересен пользователям. Тем более, что с помощью предложенной функции можно выполнять проверку и обработку данных форм различных вариантов. А при необходимости, можно ее дополнить и другими функциональными возможностями.

  • Получаем данные от элементов формы в PHP
  • Создаем универсальную функцию проверки и обработки данных формы
  • Выполняем валидацию формы на стороне сервера
  • Проверяем валидацию на практических примерах
  • Исходные файлы сайта

Получаем данные от элементов формы в PHP

Ранее при формировании формы мы использовали метод POST. Поэтому получить данные в PHP можно с помощью ассоциативного массива $_POST[], который содержит все значения, передаваемые из формы этим методом.

При этом в качестве индекса массива должны применяться значения атрибута «name» соответствующих элементов . Например, для поля «Марка автомобиля» это будет «marka», для поля «Модель» — «model» и т.д.

PHP-код скрипта, предназначенного для получения данных из рассматриваемой нами формы онлайн заказа представлен в следующей таблице.

if (! empty ($_POST[ «righting-button» ])) <

$marka = $_POST[ «marka» ];

$model = $_POST[ «model» ];

$year = $_POST[ «year» ];

$insurance = $_POST[ «insurance» ];

$order = $_POST[ «order» ];

if ($order == «1» ) $namer_order = «Набор для самостоятельной маркировки» ;

if ($order == «2» ) $namer_order = «Противоугонная маркировка специалистом в сервис-центре» ;

if ($order == «3» ) $namer_order = «Маркировка с индивидуальным дизайном» ;

$center_price = $_POST[ «center_price» ];

$discount_price = $_POST[ «discount_price» ];

$client_name = $_POST[ «client_name» ];

$client_email = $_POST[ «client_email» ];

$client_login = $_POST[ «client_login» ];

$client_password_1 = $_POST[ «client_password_1» ];

$client_password_2 = $_POST[ «client_password_2» ];


echo nl2br ($marka. «\n» .$model. «\n» .$year. «\n» .$vin. «\n» .$insurance. «\n» .$namer_order. «\n» .$center_price. «\n» .$discount_price. «\n» .$client_name. «\n» .$client_email. «\n» .$client_login. «\n» .$client_password_1. «\n» .$client_password_2 );

Рис.1 PHP-код для получения данных из формы

Как было выше отмечено, данные из формы извлекаются из ассоциативного массива $_POST[] в виде соответствующих переменных (поз.3÷8, поз.12÷15 ). Причем это происходит в момент отправки формы при нажатии на кнопку «submit» при непустом ее значении !empty($_POST[ «righting-button» ]) (поз.2).

При этом можно обратить внимание на то, что для поля «Вид заказа» (name=»order») получение данных в виде текста формируются исходя из цифровых значений атрибута «value» выделенных пунктов списка .

Обусловлено это тем, что атрибут «value» в этих элементах также используется и для получения соответствующих значений через созданный ранее JavaScript-скрипт. В котором значения «value» для упрощения определены порядковой последовательностью чисел от 1 до 3.

Поэтому используя условный оператор if несложно полученную «1» в переменной $order преобразовать в текст «Набор для самостоятельной маркировки» переменной $namer_order (поз.9). При «2» — переменная $namer_order будет уже содержать «Противоугонная маркировка специалистом в сервис-центре» (поз.10). А при «3» — «Маркировка с индивидуальным дизайном» (поз.11).

И далее при обработке данных будет использоваться не первоначальная переменная $order с цифровым значением, а новая переменная $namer_order с соответствующим сохраненным тестом.

Кроме того в строке 16, дополнительно, для возможности проверки полученных данных здесь применена функция echo nl2br . С помощью которой соответствующие полям значения переменных можно временно вывести на страницу для сравнения их с введенными данными. Очевидно, что в рабочем состоянии данную строку следует закомментировать.

На скриншоте видно, что выведенные на страницу данные из формы в PHP полностью соответствуют заполненным полям.

Рис.2 Отправка формы при неправильном вводе пароля

После того, как мы получили данные, теперь можно перейти и к решению вопроса валидации.

Создаем универсальную функцию проверки и обработки данных формы

При валидации на стороне сервера в нашем варианте будут предусмотрены следующие проверки и преобразования данных, полученных из формы:

  • Определение пустых полей для элементов, которые обязательны для заполнения;
  • Удаления пробелов из начала и конца строки;
  • Удаление экранированных символов (данные возвращаются с вырезанными обратными слешами, например \’ становится ‘ и т.п., а двойные обратные слеши \\ становятся одинарными \);
  • Удаление HTML и PHP тегов;
  • Преобразование специальных символов в HTML-сущности (‘&’ преобразуется в ‘&amρ;’ и т.д.);
  • Проверка на соответствие данных заданному шаблону.

Конечно, при наличии в форме незначительного количества полей, вышеуказанные преобразования можно выполнять отдельно для каждого элемента. В таком случае увеличением объема кода можно пренебречь.

А вот когда их существенное количество, например, в рассматриваемой нами формы онлайн заказа 13 полей, то применять преобразования отдельно для каждого элемента будет совсем нерационально. Ведь такой скрипт будет насыщен большим количеством однотипного кода.

Поэтому, как ранее было отмечено, для проверки данных в PHP при отправке формы на стороне сервера мы будем использовать отдельную функцию.

При таком построение инструмента валидации можно все преобразования сформировать в отдельном блоке, используя для этого пользовательскую функцию. Которая будет вызываться с заданными параметрами, определенными для каждого конкретного поля. Что позволит достаточно оптимально сформировать необходимый PHP-код.

Ниже показан вариант PHP-кода такой универсальной функции с именем «check_symbol», которая может быть использоваться для разных типов полей формы.

//—-Функция проверки и преобразования данных из формы—-

function check_symbol ($value, $field_name, $required, $pattern)<

$GLOBALS [‘alert’] = $GLOBALS [‘alert’] . ‘Поле \»‘ .$field_name. ‘\» не заполнено’.’\n’ ;

$value = trim ($value);

$value = stripslashes ($value);

$value = strip_tags ($value);

$value = htmlspecialchars ($value);

Рис.3 PHP-код универсальной функции валидации данных, полученных из формы

Как видно, в данной функции определено четыре параметра (поз.3) с помощью которых осуществляется передача значений аргументов, а именно:

  • $value — проверяемые данные;
  • $field_name — наименование поля;
  • $required — флаг обязательного заполнения поля («0» — не обязательно, «1» — обязательно);
  • $pattern — шаблон регулярного выражения (при «0» проверка на соответствие шаблону не производится).

Сам PHP-код функции достаточно простой. В первую очередь с помощью условного оператора if производится проверка на заполнение поля (поз.4). И если при значении флага обязательного заполнения ( $required ) равного «1» поле окажется пустым ( empty($value) ), то в переменной глобальной области видимости $GLOBALS [‘alert’] добавится соответствующая запись с указанием имени поля ( $field_name ) (поз.5). После чего оператором return работа функции завершится (поз.6).

Если же поле будет заполнено, то с помощью функций trim (поз.8), stripslashes (поз.9), strip_tags (поз.10) и htmlspecialchars (поз.11) поочередно будут выполнены вышеуказанные преобразования данных по удалению ненужных пробелов и символов.

А затем при ненулевом значении шаблона с помощью функции preg_match выполняется проверка на соответствие регулярному выражению. И если заданный шаблон ( $pattern ) не соответствует значению поля ( $value ), то аналогичным образом в глобальной переменной $GLOBALS [‘alert’] об этом добавится запись (поз.13).

Завершается же работа функции возвращением результата в виде переменной $value с сохраненными данными после выполнения всех преобразований (поз.15).

И последнее на что стоит обратить внимание, это применение в данной функции глобальной переменной $GLOBALS, которая используется в виде ассоциативного массива $GLOBALS[] . По-существу она является суперглобальной, так как доступна в любом месте, будь это PHP-скрипт, функция или метод.

Такая необходимость обусловлена тем, что полученное значение этой переменной будет в дальнейшем использоваться в работе скрипта, расположенного в другой области. И если бы в этой части функции использовать не глобальную, а локальную переменную, то для скрипта эти данные были бы просто не доступны.

Теперь, после того, как мы создали функцию, разместим ее код в отдельном файле с наименованием «functions.php», расположив его в отдельной папке, скажем под именем «php».

А для того, чтобы можно было обращаться к созданной функции, с помощью инструкции «require_once» подключим этот файл, аналогично тому, как мы это делали ранее при подключении функций для работы с базой данных MySQL.

Ниже показан соответствующий PHP-код, который необходимо добавить в начало шаблона главной страницы.

Рис.4 Подключение созданной функции

В итоге необходимая пользовательская функция создана и готова к использованию.

Выполняем валидацию формы на стороне сервера

Как ранее отмечалось, основное преимущество использования универсальной функции, это то, что для валидации данных, полученных из формы, достаточно ее только вызывать определяя для каждого поля заданные параметры.

В этом случае для проверки полей не нужно выполнять каких-либо отдельных преобразований, и соответственно, не потребуется значительного увеличения кода в ранее созданном скрипте, изображенном на рис.1. Так как для этого необходима будет всего лишь одна дополнительная строка для каждого поле.

В следующей таблице показан дополненный PHP-код скрипта, в котором добавлены соответствующие строки для всех имеющихся полей формы онлайн заказа (добавленные строки обозначены светлым фоном).

if (! empty ($_POST[ «righting-button» ])) <

$marka = $_POST[ «marka» ];

$marka = check_symbol ($marka, «Марка автомобиля» , «1» , «/^[ A-ZА-ЯЁ]+\z/iu» );

$model = $_POST[ «model» ];

$model = check_symbol ($model, «Модель» , «1» , «/^[0-9A-ZА-ЯЁ]+\z/iu» );

$year = $_POST[ «year» ];

$year = check_symbol ($year, «Год выпуска» , «1» , «/^[0-9]<4>\z/» );

$vin = check_symbol ($vin, «Последние 6 цифр VIN» , «1» , «/^[0-9]<6>\z/» );

$insurance = $_POST[ «insurance» ];

$insurance = check_symbol ($insurance, «Страховая компания» , «1» , «/^[ 0-9A-ZА-ЯЁ-]+\z/iu» );

$order = $_POST[ «order» ];

if ($order == «1» ) $namer_order = «Набор для самостоятельной маркировки» ;

if ($order == «2» ) $namer_order = «Противоугонная маркировка специалистом в сервис-центре» ;

if ($order == «3» ) $namer_order = «Маркировка с индивидуальным дизайном» ;

$namer_order = check_symbol ($namer_order, «Вид заказа» , «1» , «/^[ А-ЯЁ-]+\z/iu» );

$center_price = $_POST[ «center-price» ];

$center_price = check_symbol ($center_price, «Цена сервис-центра» , «0» , «/^[0-9]+р\.\z/» );

$discount_price = $_POST[ «discount-price» ];

$discount_price = check_symbol ($discount_price, «Цена со скидкой» , «0» , «/^[0-9]+р\.\z/» );

$client_name = $_POST[ «client-name» ];

$client_name = check_symbol ($client_name, «Имя» , «1» , «/^[А-ЯЁ]<3,>\z/iu» );

$client_email = $_POST[ «client-email» ];

$client_email = check_symbol ($client_email, «E-mail» , «0» , «/^[A-Z0-9._%+-]+@([A-Z0-9-]+\.)+[A-Z]<2,6>\z/i» );

$client_login = $_POST[ «client-login» ];

$client_login = check_symbol ($client_login, «Логин» , «1» , «/^[0-9A-Z]<3,>\z/i» );

$client_password_1 = $_POST[ «client-password_1» ];

$client_password_1 = check_symbol ($client_password_1, «Пароль» , «1» , «/^[0-9A-Z]<6,>\z/i» );

$client_password_2 = $_POST[ «client-password_2» ];

$client_password_2 = check_symbol ($client_password_2, «Подтверждение пароля» , «1» , «/^[0-9A-Z]<6,>\z/i» );

if ($client_password_1 != $client_password_2) $GLOBALS [‘alert’] = $GLOBALS [‘alert’] . ‘Значения в полях ввода пароля не совпадают’ ;

//echo nl2br($marka. «\n» .$model. «\n» .$year.»\n».$vin. «\n» .$insurance. «\n» .$namer_order. «\n» .$center_price. «\n» .$discount_price. «\n» .$client_name. «\n» .$client_email. «\n» .$client_login. «\n» .$client_password_1. «\n» .$client_password_2);

$GLOBALS [‘alert’] = ‘Данные из формы не отправлены. Обнаружены следующие ошибки: \n’ .$GLOBALS [‘alert’] ;

Рис.5 PHP-код получения и валидации данных из формы

Здесь видно, что при вызове пользовательской функции «check_symbol» для каждого поля задаются определенные значения параметров.

Например, для поля «Марка автомобиля» (поз.4) первый параметр имеет значения данных, полученных из этого поля в виде переменной $marka , второй — название самого поля, третий «1», означающее обязательное заполнение поля и четвертый — регулярное выражение «/^[ A-ZА-ЯЁ]+\z/iu», в котором предусмотрено использование только букв латинского и русского алфавита и пробелов.

Для сравнения в поле «E-mail» (поз.25) первый параметр имеет значения данных в виде переменной $client_email , второй — название самого поля, третий «0», соответствующее необязательному заполнению поля и четвертый — регулярное выражение /^[A-Z0-9._%+-]+@([A-Z0-9-]+\.)+[A-Z]<2,6>\z/i», в котором определен шаблон допустимого написания адреса электронной почты.

Что касается регулярных выражений, то это достаточно обширная тема, достойная отдельного серьезного рассмотрения. Ранее при преобразовании входящих ЧПУ с помощью модуля MOD_REWRITE мы уже касались этого вопроса и использовали большинство включенных в данный скрипт символов регулярных выражений.

Поэтому не будем повторяться, дополнительно отметив лишь применение здесь модификаторов, таких как: «i» для игнорирования регистра, что позволяет указывать в шаблонах лишь только строчные или прописные буквы и «u», необходимый в данном случае для корректности проверки на соответствие букв на кириллице в кодировке UTF-8.

Кроме того, в данном коде PHP для выделения шаблона используются символы специального разделителя «/» (можно также «|», «<", "!" и т.п ), а начало и конец строки обозначены символами "^" и "\z", соответственно.

Ну, а если у кого возникнут какие-либо вопросы по составленным здесь регулярным выражениям, то можно их оставить в комментариях. Постараюсь на них ответить как можно подробнее.

Ранее отмечалось, что в нашем случае проверки и преобразования данных выполняются с помощью функции. Однако, есть исключение. Касается это проверки на идентичность введенных данных при подтверждении пароля.

Дело в том, что указанную проверку необходимо выполнить только один раз, а именно: определить, одинаковы ли данные в полях ввода пароля (первичный ввод и подтверждение). И наверное, будет не логично дополнять такой единичной проверкой алгоритм универсальной функции.

Поэтому она реализована отдельно (поз.32). Для этого используется условный оператор if в котором сравниваются значения переменных ( $client_password_1 ) и ( $client_password_2 ). И в случае их несоответствия, в глобальную переменную $GLOBALS [‘alert’] добавится соответствующая запись.

Следует отметить, что после объявления в функции глобальной переменной $GLOBALS [‘alert’] , в PHP-скрипте можно использовать ее и в виде обычной локальной переменной, соответствующей имени индекса массива. В данном случае это будет переменная $alert. Но мы так поступать не будем, преднамеренно обозначив, что это именно глобальная переменная, не путая ее с локальной.

И последнее, на чем здесь необходимо остановиться, это как в случае возникновения каких-либо шибок при отправке формы осуществить вывод соответствующего сообщения в браузере.

Для этого после проверок данных всех полей в нижней части скрипта с помощью условного оператора if оценивается состояние глобальной переменной $GLOBALS [‘alert’] (поз.34), в которую ранее записывались сообщения об ошибках.

И если эта переменная не пустая, то к ее значению добавляется шапка сообщения с текстом «Данные из формы не отправлены. Обнаружены следующие ошибки:» (поз.35). А кроме этого вызывается некий файл «alert.php» (на данный момент такого файла не существует, его нужно создать).

Здесь следует сделать некоторые пояснения. Дело в том, что PHP серверный язык, а вывод на экран пользователя предупреждающего диалогового окна выполняется с использованием клиентского языка JavaScript. Поэтому мы не можем непосредственно при выполнении PHP-скрипта браузеру послать сообщение.

А для того, чтобы решить эту проблему мы перенесем данные о сообщении из PHP в JavaScript. Для этого создадим в корневом каталоге отдельный файл с именем «alert.php» и запишем в него следующий код:

Рис.6 Формирование вывода сообщения в диалоговом окне браузера из переменной PHP

Таким образом в случае ошибки при отправке формы данные из глобальной переменной PHP $GLOBALS [‘alert’] будут использоваться методом «alert» языка JavaScript в качестве параметра для отображения в диалоговом окне текст сообщения. И при неуспешной валидации данных отправляемой формы пользователь должен получить сообщение о возникшей проблеме с указанием допущенной ошибки.

В итоге мы создали на стороне сервера инструмент, с помощью которого при отправке формы данные сначала сохраняются в соответствующих переменных PHP, а затем преобразуются с удалением ненужных символов и проверяются на соответствие заданным критериям заполнения полей. Осталось это только проверить.

Проверяем валидацию на практических примерах

Чтобы иметь возможность практически проверить, работает ли валидация данных из формы на стороне сервера, необходимо на время отключить ранее предусмотренные нами проверки на стороне клиента с использованием встроенных возможностей языка HTML5 и созданных скриптов JavaScript.

Для этого нужно временно удалить в элементах формы все имеющиеся атрибуты «required», определяющие обязательность заполнения полей и «pattern», задающие шаблон соответствия регулярному выражению. А также удалить из тега

Другие статьи из рубрики «Как сделать сайт»

Валидация форм на HTML и CSS

Вы можете добиться внушительных результатов в вопросе проверки форм исключительно при помощи HTML-атрибутов. Вы можете сделать пользовательский опыт простым и понятным при помощи CSS-селекторов. Но вам потребуется несколько трюков, чтобы все получилось правильно!

(Вы можете) сделать label похожим на placeholder

Во-первых: всегда используйте настоящий элемент . Игнорирование одного этого правила из соображений UX портит очень много форм. Плейсхолдер — всего лишь подсказка того, как должна выглядеть валидная информация в поле ввода, типа “введи Москва в поле под названием Город”.

Я бы сказал, что если форма короткая и с понятным паттерном поведения (вход или регистрация), то вы можете сделать названия полей в виде плейсхолдеров, но используйте для этого реальные элементы label.

Вам не нужно хитро изворачиваться и беспокоиться об установке курсора в поле ввода, все уже сделано семантикой. Если пользователь нажимает на название поля — активируется поле ввода. Если нажимает на само поле — курсор устанавливается в поле ввода. Оба варианта верны.

Фишка в том, чтобы поставить поле ввода первым (семантически допустимо). Таким образом вы сможете скрывать label при фокусе:

Сделайте определенные поля обязательными

Пожалуй, самым простым способом проверки формы является использование атрибута required. Нет более быстрого пути отлова ошибок, кроме как позволить браузеру сделать это самому!

Подсвечивайте верно заполненные поля

Дайте пользователю знать, что поле было заполнено верно. Браузер может предоставить нам эту информацию по CSS-псевдоклассу :valid.

:val > показывает, что выполнено условие required. Но селектор так же подойдет для проверки данных по типу поля.

Покажите напоминание о виде вводимых данных

Вы также можете установить определенное требуемое значение. Вроде email или number. Здесь перечислены все возможные варианты.

Это поле является обязательным для заполнения и вводимая информация будет проверяться на соответствие адресу электронной почты. Давайте улучшим UX:

  1. Сообщим пользователю о требуемом формате, когда фокус находится в поле ввода
  2. Напомним ему, если введенные данные не будут валидными

Но еще… не показывайте никаких подсказок, если поле пустое. И не считайте его неверно заполненным. Это может создать ощущение назойливости и будет только раздражать. Для того, чтобы соблюсти эту рекомендацию, мы должны будем узнать, пустое поле или нет.

Проверяем заполнено поле или нет

Мы хотим провернуть фокус с :val >:invalid, но мы не хотим опережать события и считать поле невалидным до того, как оно было заполнено.

Есть ли CSS-селектор для проверки пустоты поля? Вообще-то нет! Вы можете подумать на :empty, но ошибетесь. Этот псевдокласс предназначен для проверки ситуаций когда элемент

не содержит в себе ничего. Поля ввода и так пусты по умолчанию.

Трюк в том, чтобы проверить поле на видимость атрибута placeholder:

Мы не использовали плейсхолдер в нашем примере, но это правило сработает, если мы зададим значение из одного пробела:

:placeholder-shown супер полезен для нас! Это в целом секретный селектор, позволяющий проверить, есть ли в поле значение или нет.

IE и Firefox пока не поддерживают его, что немного осложняет задачу. Обычно спасителем является новая функция @ supports, но…

Вы не можете использовать @supports для селекторов, только для свойства/значения (например @supports (display: flex)).

Проверить плейсхолдер при помощи JavaScript довольно легко:

Но это не кажется самым простым способом имитации :placeholder-shown. Поэтому…возможно, просто стоит подождать поддержки всеми браузерами.

Представим, что поддержка уже повсеместная и посмотрим, как это будет выглядеть…

Вы можете создать более сильную проверку

Это уже не просто required или type=”email” (и подобные). Вы можете проверить на клиентской стороне такие вещи, как длину (например минимальную длину пароля или максимальное количество символов в textarea>) и даже использовать полноценное регулярное выражение.

Вот статья об этом. Скажем, вы хотите проверку пароля по параметрам:


  • Состоит из 6 символов
  • Содержит хотя бы одну прописную букву
  • Содержит хотя бы одну строчную букву
  • Содержит хотя бы одну цифру

Вы можете это сделать следующим образом:

Я оставил в этом примере :placeholder-shown, так что в Firefox и IE может работать не очень хорошо. Это просто пример! Не стесняйтесь брать по частям или менять под свои нужды.

P.S. Если вам понравилась эта статья — нажмите зеленое сердечко. Это много значит для меня. Спасибо!

Нашли ошибку? Воспользуйтесь функцией Private notes: выделяете текст с ошибкой, нажимаете на символ замка в появившемся дудле и оставляете свой комментарий. Спасибо!

Валидация форм средствами HTML5

Введение

Используя формы в HTML5, Вы часто используете методы проверки (валидации) данных, ведь их игнорирование может привести: к потерям пользователей,к мусору в базе данных или к взлому сайта. Исторически сложилось, что создание форм с хорошей валидацией – сложная задача.

В HTML5 есть инструменты обработки данных для форм, с их помощью можно производить валидацию, включающую в себя специальные атрибуты и новые типы входных данных. Давайте разберем их детальнее.

1. Специализированные типы входных данных

В HTML5 введены несколько новых типов ввода. Они используются для создания поля ввода, принимающего только определенные типы данных.

Новые типы входных данных выглядят следующим образом:

input type =»email»/>

Если браузер не поддерживает данный тип ввода, поле будет вести себя, как обычное поле ввода текста.

2. Обязательные поля для заполнения

Просто добавив атрибут » required » к input > , select > или textarea >. , Вы говорите браузеру, что значение должно быть заполнено.

input type =»checkbox» name =»terms» required >

3. Лимиты

Мы можем установить некоторые ограничения и лимиты, например, максимальные и минимальные значения для числовых полей. Чтобы ограничить длину поля ввода надо использовать атрибут » maxlength «.

input type =»text» name =»name» required maxlength =»15″>

Поле input type =»number» /> использует атрибуты » max «и » min «, чтобы создать диапазон возможно-допустимых значений (в примере минимально допустимый возраст 18)

input type =»number» name =»age» min =»18″ required >

4. Стилизирование

CSS3 псевдо-классы позволяют украсить форму в не зависимости от ее состояния. Это:

В примере мы объединили селекторы » valid » и » invalid » с псевдо-классом » focus » для закрашивания поля формы в красный или зеленый, в зависимости от того, что делает пользователь: выбирает или печатает.

border : solid 2px #F5192F ;

border : solid 2px #18E109 ;

5. Подсказки

Вы замечали всплывающее окно с подсказкой при отправлении неправильно заполненной формы? Установив атрибут » title » для поля ввода, можно добавить подсказки, указывающие на ошибки при нарушении тех или иных правил валидации.

Обратите внимание, что разные браузеры отображают всплывающие подсказки по-разному. В браузере Chrome значение названия атрибута будет отображаться мелким шрифтом, под основным сообщением об ошибке. В Firefox другая проблема: использовав атрибут “pattern” после того как он берется в качестве шаблона, Вы не получите всплывающую подсказку.

input type =»text» name =»name» title =»Пожалуйста введите имя пользователя.»>

6. Шаблоны

Атрибут » pattern «, разрешает разработчикам задавать регулярное выражение, которое браузер сравнивает с данными ввода, прежде чем отправить форму заявки.

Вот как это можно использовать:

input type =»email» name =»email» required pattern =»^\S+@\S+\.\S+$» title =»example@mail.com»>

С функцией фильтрования входных данных мы можем принимать только полный e-mail адрес.

Техники валидации форм

Это перевод статьи Ире Адеринокун — «Form validation techniques».

Ни для кого не секрет, что онлайн-формы могут стать серьёзным испытанием для пользователей. Особенно когда они выглядят как список полей для ввода без каких-либо подсказок. Однако мы, как разработчики, можем значительно облегчить жизнь посетителям наших сайтов.

Используем CSS

В CSS существует четыре специальных псевдокласса, применимых к полям формы: :valid (валидное поле), :invalid (невалидное), :required (обязательное) и :optional (необязательное). Их можно использовать, чтобы добавлять некоторые — хотя и весьма ограниченные — подсказки пользователям, заполняющим форму.

Используя :valid и :invalid , мы можем показать пользователю, правильно ли заполнено поле по мере ввода.

Стилизация псевдоклассов :valid и :invalid

Однако с этим способом связана одна проблема: стили применяются до того, как пользователь начнёт работу с формой. Поля, обязательные для заполнения, сразу подсветятся нам как :invalid , а необязательные — как :valid . Это значит, что пользователь, даже не приступив к заполнению формы, может сразу же получить негативную обратную связь. Не очень-то хорошо.

Стилизация состояний :required и :optional сама по себе не особо полезна, поскольку эта информация обычно указывается в подписях к полям формы. Однако мы можем объединить эти состояния с псевдоклассами :valid / :invalid и стилизовать их комбинации. Например, мы хотим показывать лишь положительный результат, когда валидно обязательное к заполнению поле.

Стилизация по :valid и :required

Используем JavaScript

JavaScript даёт намного больше возможностей для улучшения работы пользователей с формами. Давайте рассмотрим в качестве примера три числовых поля, у каждого из которых установлен минимум в 10, максимум в 100 и шаг в 10 единиц.

Устанавливая атрибуты min , max и step , мы можем быть уверены в правильности значения только тогда, когда пользователь использует специальные контролы числового поля. Но что мешает пользователю ввести вручную некорректные данные? Вот что произойдёт, если он вставит 1 , 12 и 123 в три поля и отправит форму:

Стандартный тултип валидации

В результате всё, что получит пользователь — это сообщение об ошибке для первого поля. Кроме того, в этом сообщении будет указано лишь одно несоответствие из двух требуемых. Такое поведение можно исправить, изменяя показываемые валидатором сообщения.

Добавляем несколько сообщений об ошибках в один тултип

Валидируя поля, браузер проверяет их по определённому списку потенциальных ошибок. В каждом поле содержится специальный объект validity , включающий в себя список булевых значений, характеризующих ту или иную проверку на валидность. Например, вот такой validity -объект будет у поля, когда пользователь введёт в него 1 :

Примечание переводчика: Слово «mismatch» переводится как «несоответствие». Поэтому в значениях patternMismatch , stepMismatch и typeMismatch обратная логика: true — значение не удовлетворяет атрибуту, false — удовлетворяет.

По умолчанию браузер отобразит лишь одну ошибку. Что мы можем сделать, так это проверить все эти значения самостоятельно и, если найдутся ошибки, сохранить их. Как только мы сохраним все ошибки для одного поля, мы можем отобразить весь их список в виде специального сообщения об ошибке при помощи функции setCustomValidity() .

Теперь при попытке отправить форму мы увидим вот это:

Отображаем несколько ошибок в одном тултипе

Стало лучше, поскольку теперь будут показываться все сообщения об ошибках, связанные с конкретным полем. Однако другая проблема всё ещё не решена: ошибки по-прежнему показываются лишь для первого поля.

Это ограничение валидации, устанавливаемое браузером. Чтобы его побороть, нам нужно пойти другим путём.

Показываем все ошибки для всех полей.

Вместо того, чтобы использовать встроенный тултип, мы можем добавлять сообщения об ошибках напрямую в DOM. Таким образом, все ошибки будут выводиться рядом с соответствующим полем.

Этого можно добиться какой-то парой дополнительных строчек в нашем коде:

Вот что происходит при клике на submit теперь:

Отображаем все ошибки для всех полей в DOM

Используем нестандартные проверки валидности

Иногда встроенной в браузер валидации бывает недостаточно. Нам может понадобиться, чтобы вводимые данные удовлетворяли некоторым дополнительным правилам. Например, чтобы в текстовом поле требовалось указать особые символы.

Так как мы уже проверяем все возможные ошибки вручную в нашей функции CustomValidation.prototype.checkValidity , мы можем просто-напросто добавить туда ещё несколько проверок.

Валидация в реальном времени

Хотя текущий способ выглядит намного лучше, он тоже не без изъянов. Наихудший из недочётов заключается в том, что пользователь не сможет увидеть никаких сообщений, пока не нажмёт на кнопку отправки формы. Было бы гораздо лучше, если бы валидация поля происходила сразу же при его заполнении. Можно выделить три правила для того, чтобы с формой было удобно работать:

  1. Требования для каждого поля чётко видны до того, как пользователь начал печатать.
  2. Как только пользователь начинает вводить данные, соблюдая требования, он сразу видит индикатор успешного заполнения поля или подсказки, если есть ошибки.
  3. Нужно отображать сообщения об ошибках таким образом, чтобы пользователь не мог отправить некорректно заполненную форму.

В статье на следующей неделе (оригинал, перевод готовится) я покажу, как реализовать валидацию в реальном времени, переделав вот такую простую форму регистрации:

Пример валидации в реальном времени

Если вы хотите попробовать свои силы (и даже сделать получше), вы можете воспользоваться вот этим шаблоном.

HTML5 Form Val > March 07, 2015

К вопросу о типах форм в HTML5, регулярных выражениях и валидации форм на основе регулярных выражений. Философское рассуждение на ночь глядя.

Атрибут required

Наиболее простой способ реализации валидации html-форм — это добавить к атрибут .

Данный атрибут сообщает браузерам, что содержимое поля ввода необходимо для заполнения. Теперь браузеры будут проверять содержимое поля ввода — то есть, выполнять его валидацию.

Заметьте — браузеры сами будут это выполнять, без какого-либо участия Javascript/jQuery с нашей стороны (это и есть одна из многогранных сторон HTML5).

В CSS3 для форм ввода разработаны два псевдо-класса:

Оба псевдокласса предназначены для управления видом форм ( , , помещения маркеров внутрь или снаружи формы) в случае валидности или невалидности содержимого этой формы.

Например, такой простейший код будет изменять фон поля ввода при валидности или невалидности содержимого:

Тут возникает законный вопрос — а каким образом браузер определяет, валидное или невалидное содержимое у этого поля?

В данном случае — очень просто и примитивно (для наглядности примера). Если поле не содержит никакого (любого) символа, то поле считается невалидным и браузер генерирует для данного поля псевдо-класс .

Если же поле содержит хотя бы один символ (любой — не обязательно текстовый), то данное поле уже считается валидным и браузер генерирует для этого поля псевдо-класс .

Note! Содержимое атрибута не рассматривается браузером как содержимое формы. Другими словами, если поле ввода имеет атрибут с каким-то значением, то это поле будет считаться браузером все равно невалидным.

Типы input

Конечно, на практике такое поведение браузера имеет мало смысла, поэтому для валидации форм были созданы различные способы фильтрации введенных данных.

Одним из таких способов фильтрации введенных данных является задание для элемента его типа. Это также одна из “фишек” HTML5 и заключается она в том, что для поля ввода можно указать, какого типа данные ожидаются в нем.

Например, говорит о том, что в это поле нужно вводить только адреса электронной почты; — только числа; — только номера телефонов; — только дату; — только URL-адреса; и так далее.

Краткий список HTML5-типов ’ов:

Эти различные типы input’ов в HTML5 — не просто блаж в угоду призрачной HTML-семантики, как я сам воспринимал их ранее. На самом деле — это именованные регулярные выражения.

Ну как — испугал я читателя? На самом деле регулярные выражения — это очень просто. Фактически — это набор символов, собранных воедино по определенному правилу и записанных в определенном синтаксисе.

Грубо говоря — — это уже регулярное выражение. Если этому регулярному выражению присвоить имя , то получится именованное регулярное выражение .

Фактически типы ’ов, которые были рассмотрены выше — это именованные регулярные выражения, предустановленные разработчиками HTML5\браузеров.

И когда для элемента устанавливается тип (к примеру), то этим фактом браузеру всего лишь указывается предустановленное регулярное выражение, которое браузер должен будет использовать при проверке введенных данных.

Вот я и подошел к самому интересному моменту — для чего нужны регулярные выражения? А нужны они для проверки введенных данных. Это маска, которую браузер накладывает на введенные пользователем данные. Совпала маска и данные — данные валидные; не совпала маска и введенные данные — данные невалидные.

Помимо предустановленных регулярных выражений, можно создавать свои собственные, для определенных задач. Но для этого необходимо использовать соответствующий синтаксис и другие несложные знания по этой теме.

Подключаются пользовательские регулярные выражения в HTML с помощью атрибута и выглядит это таким образом (регулярное выражение для проверки IPv4-адреса):

Note! Использование пользовательского совместно с любым HTML5-типом (email, date, range, tel, number и так далее) для элемента input почти никогда не имеет смысла по определению.

RxJs — map

Первый «серьезный» метод в моей RxJs-копилке знаний. На самом деле все просто — этот метод получает на вход поток, обрабатывает каждый ev. … Continue reading

Формы HTML5: JavaScript

В последней статье о веб-формах HTML5 мы рассмотрим интеграцию JavaScript и Constraint Validation API. Напомню, что две предыдущие были посвящены основам CSS и разметки HTML. Ознакомиться с ними можно, пройдя по ссылкам:

HTML5 позволяет производить валидацию форм на клиентской стороне без использования JavaScript. Для сложных форм, однако, встроенная валидация нуждается в определенных преобразованиях (усилении). Это связано с тем, что:

  • браузеры поддерживают не все типы HTML5 для полей ввода, и не все селекторы CSS
  • всплывающие блоки с ошибками содержат типовой текст («пожалуйста, заполните это поле»/«please fill out this field»); правка стиля для таких блоков несет в себе определенные трудности
  • стили :invalid и :required применяются после загрузки страницы, еще до того как пользователь начнет работать с формой

Облегчить работу пользователя с формами помогут JavaScript и Constraint Validation API. В статье мы попытаемся реализовать поддержку для как можно большего количества браузеров и типов полей ввода. Поэтому не стоит удивляться, если код получится не совсем прозрачным.

Перехват форм

До появления HTML5 валидация на клиентской стороне нуждалась в прикреплении к форме обработчика submit . Обработчик производил валидацию полей, показывал ошибки и предотвращал отправку данных формы.

В HTML5 браузер сперва выполняет свою собственную валидацию; событие submit запускается только после успешной валидации формы. Поэтому для того чтобы сделать что-то нестандартное, как то: отобразить свои ошибки, сравнение или автозаполнение полей – родную валидацию надо отключать, для этого свойству noValidate нужно задать значение true :

jQuery or Javascript

То есть можно сделать вывод, что проверку полей на наличие ошибок придется осуществлять в коде, однако, как мы увидим позже, и встроенная валидация браузера все еще возможна.

Свойство поля .willValidate

Каждое поле ввода имеет свойство .willValidate . Оно возвращает:

  • true когда браузер будет использовать встроенную валидацию для полей ввода
  • false встроенная валидация браузером не производится или
  • undefined поддержка родной HTML5 валидации в браузере не реализована (пример, IE8).

Так как выше мы отключили встроенную валидацию, каждое поле будет возвращать false . Давайте создадим обработчик validateForm , который будет проходить в цикле через все поля и проверять доступность у поля встроенной валидации:

jQuery or Javascript

Цикл проходит через все поля формы посредством свойства формы elements (любой элемент формы form можно получить, используя свойство form.elements , ); при прохождении осуществляется проверка, являются ли они полями ввода или нет (например, кнопками, select , и т.д. ). Следующему блоку кода следует уделить особое внимание.

Javascript

Теперь мы знаем, что код внутри первого блока будет задействован, только когда будет доступна встроенная валидация. Однако.

Поддерживает ли браузер тип полей ввода?

В первой статье говорилось, что вместо неподдерживаемых типов ввода используется тип text . Пример:

Если тип не поддерживается, например, в firefox 29 и IE11. Браузеры выведут:

Но, оба браузера поддерживают валидацию для типа text , поэтому field.willValidate не вернет undefined ! Следовательно, нужно проверить, что атрибут type соответствует свойству .type . В случае несоответствия надо создать резервную валидацию. Пример:

Javascript

Метод поля .checkValidity()

Если встроенная браузерная валидация поддерживается, проверить поле можно методом .checkValidity() . В случае успешного прохождения валидации метод возвращает true , если же валидация не удалась, то – false .

Также есть метод .reportValidity() . Он возвращает текущее состояние без повторной проверки. Этот метод поддерживается не всеми браузерами и не столь эффективен, как метод .checkValidity() .

Также оба метода будут:

  1. устанавливают полям объект .validity , результатом чего является возможность проводить более полный анализ ошибок, и
  2. запускают событие invalid при неудачной валидации. Это можно использовать для показа ошибок, изменить цвета и т.д. Параллельного события valid не существует, поэтому при необходимости сообщения и стили для ошибок следует сбросить.

Объект поля .validity

Объект .validity имеет следующие свойства:

  • .valid – возвращает true , если поле не содержит ошибок, и false — если содержит.
  • .valueMissing – возвращает true , когда у поля есть required , а значение еще не было введено.
  • .typeMismatch – возвращает true при ошибочном синтаксисе значения (пример, неправильно форматированный адрес email)
  • .patternMismatch – возвращает true , если значение не соответствует шаблону регулярного выражения атрибута pattern .
  • .tooLong – возвращает true , если значение превышает maxlength .
  • .tooShort – возвращает true , если значение меньше minlength .
  • .rangeUnderFlow – возвращает true , если значение меньше, чем min .
  • .rangeOverflow – возвращает true , если значение больше, чем max .
  • .stepMismatch – возвращает true , если значение не соответствует step .
  • .badInput – возвращает true , если введенные данные не конвертируются в значение.
  • .customError – возвращает true , если поле имеет ошибки пользователя.

Некоторые свойства браузерам не поддерживаются. Как правило для вывода и сокрытия сообщения об ошибке достаточно свойства .valid или результата от .checkValidity() .

Поддержка .validity в старых браузерах

В устаревших браузерах объект .validity можно сэмулировать вручную:

Javascript

Благодаря чему .validity.valid можно протестировать во всех браузерах.

Метод поля .setCustomValidity()

Метод .setCustomValidity() может принимать:

  • пустую строку. Поле становится валидным, поэтому .checkValidity() и .validity.valid возвращают true , или
  • строку, которая содержит сообщение об ошибке, будет выведена в блоке с ошибкой (если оно используется). Сообщение также отмечает поле как дефектное, поэтому .checkValidity() и .validity.valid возвращают false и запускается событие invalid .

Текущее сообщение также можно проверить с помощью свойства поля .validationMessage .

Мы сделали простую кроссбраузерную систему валидации формы:

Javascript

LegacyValidation сознательно сделана простой. Она проверяет регулярное выражения pattern , required , minlength , maxlength ; но чтобы проверить email, URL, даты, числа, ранг, понадобится дополнительный код.

Отсюда возникает вопрос: если пишется код валидации полей для устаревших(всех) браузеров, зачем использовать родные APIs браузера? Логично. Код выше необходим только в том случае, если требуется поддержка всех браузеров, начиная с IE6 и выше, когда нужно, чтобы сайт был одинаково удобен для всех пользователей вне зависимости от используемых ими браузеров. Необходимо это не всегда.

  • для простых форм иногда можно обойтись без JavaScript кода. Что касается устаревших браузеров, то тут на помощь придет валидация со стороне сервера.
  • для более сложных форм, но когда поддерживаются только новые браузеры (IE10+), весь код для устаревших браузеров можно удалить. Дополнительный JavaScript понадобится только в случае использования формами дат. В настоящий момент поддержка дат в Firefox и IE не реализована.
  • даже если вы используете код для проверки полей типа email, цифр и т.д. в браузерах IE9 и старше, делайте его как можно проще. Когда поддержка браузера прекращается, код следует удалить.

Всегда используйте корректный HTML5 тип поля. В будущем в браузерах будет реализована поддержка встроенной валидации для элементов ввода, а валидация на стороне пользователя станет еще быстрее (даже при отключенном JavaScript).

Цукерберг рекомендует:  Забавное меню с помощью jQuery
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих