Нативная валидация форм

Содержание материала:

Валидация форм

Поля в форме предназначены для сбора информации от посетителей страницы. Но несмотря на все усилия и объяснения, получение правильной информации может оказаться трудным делом. Нетерпеливые или невнимательные посетители могут пропускать важные поля, заполнять поле или несколько полей не полностью, да и попросту нажимать неправильные клавиши. Заполнив таким образом форму, они нажимают кнопку «Отправить», и серверная программа получает набор данных, с которыми она не знает что делать (если не реализована валидация данных на серверной стороне).

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

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

Создатели HTML5 смогли увидеть эту надобность и изобрели способ привлечь браузеры на помощь, переложив задачу проверки с плеч веб-разработчиков на веб-обозреватели. Создатели HTML5 разработали систему проверки на стороне клиента, которая позволяет вставлять основные правила валидации в любое поле . Лучшее в этой системе — это ее простота и легкость: все, что нужно сделать — так это вставить правильный атрибут.

Как работает проверка HTML5?

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

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

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

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

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

Возникает еще один вопрос: что будет, если нарушено несколько правил проверки, например, не заполнено несколько обязательных полей?

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

Отключение проверки

В некоторых случаях может потребоваться отключить проверку. Например, вы хотите протестировать свой серверный код на правильность обработки поступивших некорректных данных. Чтобы отключить проверку для всей формы, в элемент добавляется атрибут novalidate:

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

Обнаружение незаполненных полей — это только один из нескольких типов проверки. Позже мы рассмотрим обнаружение ошибок в данных разных типов.

Оформление результатов проверки

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

Все, что для этого требуется — это добавить несколько простых CSS3-псевдоклассов. Доступны следующие опции:

required и optional

Применяют форматирование к полю в зависимости от того, использует ли это поле атрибут required или нет;

valid и invalid

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

in-range и out-of-range

Форматирование к полям, для которых используется атрибут min или max, чтобы ограничить их значение определенным диапазоном значений.

Проверка с помощью регулярных выражений

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

Регулярное выражение — это шаблон для сопоставления с образцом, закодированный согласно определенным синтаксическим правилам. Регулярные выражения применяются для поиска в тексте строк, которые отвечают определенному шаблону. Например, с помощью регулярного выражения можно проверить, что почтовый индекс содержит правильное число цифр, или в адресе электронной почты присутствует знак @, а его доменное расширение содержит, по крайней мере, два символа. Возьмем, например, следующее выражение:

Квадратные скобки в начале строки определяют диапазон допустимых символов. Иными словами, группа [A-Z] разрешает любые прописные буквы от А до Z. Следующая за ней часть в фигурных скобках указывает множитель, т.е. <3>означает, что нужны три прописные буквы. Следующее тире не имеет никакого специального значения и означает самое себя, т.е. указывает, что после трех прописных букв должно быть тире. Наконец, [0-9] обозначает цифры в диапазоне от 0 до 9, а <3>требует три таких цифры.

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

Для обозначения начала и конца значения в поле символы ^ и $, соответственно, не требуются. HTML5 автоматически предполагает наличие этих двух символов. Это означает, что значение в поле должно полностью совпасть с регулярным выражением, чтобы его можно было считать корректным.

Таким образом следующие значения будут допустимыми для этого регулярного выражения:

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

Чтобы применить полученное тем или иным путем регулярное выражение для проверки значения поля или

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

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

Далее приводится пример использования этого метода для проверки требования, чтобы значение в поле содержало не менее 20 символов:

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

Поддержка проверки браузерами

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

Поддержка проверки браузерами

Браузер	IE	Firefox	Chrome	Safari	Opera	Safari iOS	Android
Минимальная версия	10	4	10	5	10	—	—

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

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

На странице HTML5 Cross Browser Polyfills можно найти длинный список библиотек JavaScript, которые все, по большому счету, делают то же самое. Одна из лучших среди этих библиотек — это webforms2.

Библиотека webforms2 реализует все рассмотренные на данный момент атрибуты. Для использования библиотеки загрузите все ее файлы в папку своего веб-сайта (а лучше в подкаталог папки веб-сайта) и добавьте в веб-странице ссылку на эту библиотеку.

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

Валидация форм

Что такое валидация форм

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

Топ-пост этого месяца: Как создать прилипающее меню с помощью CSS или JQuery

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

Методы валидации

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

Что нужно валидировать

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

Обязательные поля

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

Не рекомендуется отмечать поля как обязательные после того как пользователь нажмет кнопку “Отправить форму” (submit).

Старайтесь обходиться минимумом обязательных полей. Делайте обязательными только самые необходимые данные и, в целом, стремитесь к подходу “покупка в один клик”.

Вот пример того как может выглядеть определение обязательных полей в HTML и CSS

Правильный формат данных

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

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

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

С большинством задач по проверке формата данных в поле формы может справиться HTML и CSS например вот так для поля email или так для поля пароль.

Например, так можно проверять ввод четного числа от 10 до 20 с помощью :invalid и :out-of-range .

Сообщения об ошибках

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

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

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

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

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

Пользователю гораздо проще стереть несколько введенных символов чем перезаполнять форму сначала.

Предпочтительной будет проверка формата данных непосредственно во время ввода.

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

Если вы используете Javascript для валидации, не забывайте добавлять код, который убирает сообщения об ошибках.

Что еще хорошо

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

Подпишитесь на обновления Student WebCamp

чтобы первым узнавать об обновлениях по теме «Валидация форм» и в сфере css и html

Нативная валидация форм

Итак, в нашем распоряжении имеются различные элементы, которые мы можем использовать на форме. Мы можем вводить в них различные значения. Однако нередко пользователи вводят не совсем корректные значения: например, ожидается ввод чисел, а пользователь вводит буквы и т.д. И для предупреждения и проверки некорректного ввода в 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 :

Валидация форм

Простой пример

Валидация форм нативно поддерживается браузерами, но иногда разные браузеры могут обрабатывать вещи таким образом, что полагаться на них будет сложнее. Даже когда поддержка валидация реализована на отлично — могут потребоваться специальные проверки, и более подходящие решения основанные на Vue. Начнём с простого примера.

Есть форма с тремя полями, сделаем два из них обязательными. Давайте посмотрим на HTML для решения этой задачи:

Начнём с начала. Тег имеет ID, который мы будем использовать для компонента Vue. Есть обработчик события отправки формы (submit), который мы увидим далее, и также атрибут action с временным URL-адресом, который будет указывать на что-то реальное где-нибудь на сервере (где конечно же будет реализована и валидация на стороне сервера).

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

Последнее, что нужно отметить — каждое из трёх полей имеет соответствующую v-model для связи с значениями, с которыми мы будем работать в JavaScript. Теперь давайте посмотрим на код.

Довольно коротко и просто. Мы определяем массив для хранения ошибок и задаём null в качестве значения для всех трёх полей формы. Логика checkForm (которая запускается при отправке формы) проверяет только имя и возраст, оставляя поле выбора фильма опциональным. Если они пусты, то мы проверяем по очереди и устанавливаем конкретную ошибку для каждого поля. И это в принципе всё. Вы можете запустить демо по ссылке ниже. Не забывайте, что при успешной отправке формы будет отправляться POST-запрос на временный URL.

Посмотрите Pen валидация форм 1 от Raymond Camden (@cfjedimaster) на CodePen.

Использование пользовательских проверок

Во втором примере, второе текстовое поле (возраст) было заменено на email, который будет проверяться с помощью специальной логики. Код взят из вопроса на StackOverflow, Как валидировать электронный адрес в JavaScript?. Классный вопрос — на его фоне любые политические/религиозные холивары выглядят как незначительные разночтения насчёт сортов пива. Серьёзно — это безумие. Вот HTML, хотя он действительно близок к первому примеру.

Хотя изменения достаточно малы, обратите внимание на noval наверху. Это важно, потому что браузер будет пытаться валидировать email адрес в поле с типом type=»email» . Честно говоря, в этом случае больше смысла доверять браузеру, но, поскольку нам нужен пример с пользовательской валидацией, мы отключим его. Вот обновлённый JavaScript.

Как вы можете видеть, мы добавили validEmail в качестве нового метода и просто вызываем его из checkForm . Вы можете поиграться с этим примером здесь:

Посмотреть Pen валидации форм 2 от Raymond Camden (@cfjedimaster) на CodePen.

Другой пример пользовательской валидации

Для третьего примера, мы создадим то, что вы вероятно видели в приложениях для опросов. Пользователю предлагается потратить «бюджет» на набор возможностей новой модели Star Destroyer. Сумма должна быть равна 100. Во-первых, HTML.

Обратите внимание на набор полей охватывающих пять разных функций. Обратите внимание на использование .number в атрибуте v-model . Это говорит Vue преобразовывать значение в число, когда вы его используете. Однако, здесь есть ошибка в это функции — когда значение пустое, то оно будет превращаться в строку. Вы увидите ниже как можно обойти эту проблему. Чтобы сделать это немного проще для пользователя, мы также добавили итоговую сумму внизу, чтобы они могли видеть в реальном времени, на какую сумму выбрано возможностей. Теперь давайте посмотрим на JavaScript.

Мы указали итоговую сумму как вычисляемое свойство, и это было достаточно просто реализовать для обхода этой ошибки. Мой метод checkForm теперь просто должен проверять является ли значение total равным 100 им всё. Вы можете поиграться с этим примером здесь:

Топ-пост этого месяца: Как выбрать домен для сайта 3 способа

Посмотрите Pen валидации форм 3 от Raymond Camden (@cfjedimaster) на CodePen.

Валидация на стороне сервера

В последнем примере мы построили что-то, что использует Ajax для валидации на сервере. Форма предложит назвать новый продукт и затем проверит, чтобы имя было уникальным. Мы быстро накидали OpenWhisk serverless действие для этой валидации. Хотя это не очень важно, вот эта логика:

В принципе, любое имя кроме «vista», «empire», и «mbp» приемлемы. Хорошо, давайте посмотрим на форму.

Здесь нет ничего особенного. Давайте посмотрим на JavaScript.

Мы начали с переменной, определяющей URL-адрес нашего API, который работает на OpenWhisk. Теперь посмотрим на checkForm . В этой версии мы всегда предотвращаем отправку формы (что, кстати, можно было бы сделать и в HTML вместе с Vue). Вы можете увидеть простую проверку на случай если this.name пуста, а затем мы делаем запрос на API. Если всё плохо — мы добавляем ошибку, как и раньше. Если всё хорошо — пока ничего не делаем (просто показываем alert), но вы можете перенаправить пользователя на новую страницу с именем продукта в URL или выполнять другие действия. Вы можете посмотреть демо по ссылке ниже:

Посмотрите Pen валидация форм 4 от Raymond Camden (@cfjedimaster) на CodePen.

Альтернативы

В то время как cookbook сосредотачивается на том, чтобы сделать валидацию формы своими руками, существует конечно и много отличных библиотек Vue, которые сделают большую часть работы за вас. Переход к использованию подготовленной библиотеки может повлиять на итоговый размер вашего приложения, но преимущества могут быть огромны. У вас есть код, который (скорее всего) основательно протестирован и регулярно обновляется. Некоторые примеры библиотек для валидации смотрите тут:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы хотим провернуть фокус с :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.

Расширяем возможности HTML за счёт создания собственных тегов

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

Определение доступности атрибута HTML5 с помощью JavaScript

Сегодня мы посмотрим, как можно организовать проверку доступности атрибута HTML5 с помощью JavaScript. Проверять будем работу элементов details и summary.

HTML5: API работы с вибрацией

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

Создание форм с помощью Webix Framework — 4 практических примера

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

Знакомство с фрэймворком Webix

В этой статье мы бы хотели познакомить вас с фрэймворком Webix. Для демонстрации возможностей данного инструмента мы создадим интерфейс online аудио плеера. Не обольщайтесь — это всего лишь модель интерфейса. Исходный код доступен в демо и на странице GitHub.

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

Бесит валидация, которая добавляется к полям формы, если вы пользуетесь HTML5? Её можно без проблем отключить.

5 устаревших фишек в HTML5

В этой статье мы рассмотрим пятёрку элементов HTML5, которые устарели и были удалены из спецификации.

# 8 Валидация формы в Javascript

Мы с вами изучили базовые методы для работы с DOM. в заключение хотелось бы на практике применить то, чему мы научились.

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

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

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

Давайте найдем с вами кнопку Validate

Как вы видите, каждый раз, когда мы захотим находить елемент внутри formWithValidation, нам прийдется указывать его в querySelector. Старайтесь всегда избегать лишних и ненужных повторений кода.

В данном случае мы можем вынести поиск formWithValidation отдельно и все остальные елементы искать относительно него

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

Сейчас нам нужно повесить евент submit на нашу форму. Тогда при нажатии enter на любом поле либо на клик Validate, форма отправится. Мы с вами это уже делали

Если мы посмотрим в браузер, то происходит следующее. Мы видим наш console.log, но только на доли секунды. Это происходит потому, что html по умолчанию отправляет форму и перезагружает при этом страницу.

Нам в javascript, это совсем не нужно. Для этого существует метод preventDefault. То есть он запрещает поведение по умолчанию. В функции, которая срабатывает у нас при submit, первым параметром нам приходит event. На нем то нам и нужно вызвать eventPreventDefault.

Если мы посмотрим сейчас, то у нас срабатывает submit и выводится console.log.

Теперь для начала давайте прочитаем значения всех полей при валидации формы.

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

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

Но это огромное количество кода, которое мы можем упростить. Мы можем пройтить по всем елементам, которые у нас есть и проверить пустой или нет. Для того, чтобы это сделать давайте добавим на каждый елемент формы одинаковый класс. например field.

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

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

Давайте создадим новые елемент. Добавим еще красный цвет и текст Cannot be blank. Теперь, чтобы вставить его перед нашими полями используем insertBefore. А так как нам нужно указать парента, то используем .parentElement.

Топ-пост этого месяца: Кастомный вход на сайт. Как обработать условие «is_wp_error»

Если мы посмотрим в браузер, то у нас вывелась валидация всех полей.

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

Если мы посмотрим в браузер, то ошибки перестали дублироваться.

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

Если мы посмотрим в браузер, то когда пароли разные, у нас выводится ошибка.

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

И теперь мы можем убрать повторяющийся код

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

И вынесем проверку полей на пустоту

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

Вот теперь наш код намного проще читать

Итак в этом уроке мы с вами научились валидировать формы на javascript.

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

Валидация форм

Простой пример

Есть форма с тремя полями, сделаем два из них обязательными. Давайте посмотрим на HTML для решения этой задачи:

Посмотрите Pen валидация форм 1 от Raymond Camden (@cfjedimaster) на CodePen.

Использование пользовательских проверок

Посмотреть Pen валидации форм 2 от Raymond Camden (@cfjedimaster) на CodePen.

Другой пример пользовательской валидации

Посмотрите Pen валидации форм 3 от Raymond Camden (@cfjedimaster) на CodePen.

Валидация на стороне сервера

В принципе, любое имя кроме «vista», «empire», и «mbp» приемлемы. Хорошо, давайте посмотрим на форму.

Здесь нет ничего особенного. Давайте посмотрим на JavaScript.

Посмотрите Pen валидация форм 4 от Raymond Camden (@cfjedimaster) на CodePen.

Альтернативы

Валидация форм в html5.

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

Начнем с последнего, никогда нельзя доверять пользователю. Пусть форма самая простая, там всего 2 — 3 поля. Как кажется не возможно ошибиться. Но обязательно найдется тот, кто либо не правильно заполнит эти поля, либо вообще не заполнит 2 из 3. Если в форме три поля, значит запрашиваемая в них информация необходима для совершения какого-либо действия. Информация с одного поля бесполезна без других двух. И было бы неплохо напомнить пользователю, что поля нужно запомнить. Однако, это не первичное назначение валидации. Самое главное — это безопасность и крайне желательно ограничивать поля на допустимый формат введения данных. И крайне желательно проверить сначала данные не только на сервере, но и на стороне клиента, еще до отправки формы.

В html5 добавили относительно надежный механизм валидации полей, который основан на использовании новых атрибутов у тега input. Познакомимся с ними и попробуем применять на практике.

Но для начала создадим простую форму содержащую в себе несколько полей: Имя, Телефон, E-mail и кнопку отправить.

Вот она самая простая и не красивая форма, поля которой подразумевают что поле имя — будет введен текст, в поле телефон — телефон(т.е. только цифры) и поле e-mail в которое можно ввести как буквы так и цифры, но с одним условием, там должен присутствовать символ @. Теперь посмотрим как html5 позволит нам справиться с задачей и провалидировать данную форму.

Атрибут required.

Данный атрибут у тега input устанавливает обязательное заполнение поля.

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

Теперь при попытке отправки формы появляется сообщение о необходимости заполнить обязательное поле и данное поле подсвечивается красным. Если все обязательные поля заполнены, то форма успешна отправляется. Хорошо, но недостаточно.

Атрибут type.

Данный атрибут добавляет стандартные способы валидации для полей. Для поля почты изменим значение на type=»email» а для телефона type=»tel»

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

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

Атрибут pattern.

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

Например для имени —

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

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

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

Нативная валидация форм

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

«Использовать капчу в формах» (1).

Как заменить маску телефона для других стран читайте здесь.

«Маска телефона для валидации» (3) позволяет задать регулярное выражение для проверки корректности ввода номера телефона в формах обратной связи.

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

«Формат даты» (4) позволяет определить корректность ввода даты в формах обратной связи. Опция работает в браузерах, не поддерживающих HTML5 input[type=date], например Firefox, для остальных браузеров формат даты в этом поле зависит от локализации браузера.

Настройка «Возможных расширений файлов для валидации»(5) позволяет указать разрешенные для загрузки документы через формы обратной связи. Необходимо указать все расширения через вертикальный разделитель.

Например, значения по умолчанию: png|jpg|jpeg|gif|doc|docx|xls|xlsx|txt|pdf|odt|rtf

Если имя файла имеет расширение в верхнем регистре, 1С-Битрикс может не разрешить его загрузку, поэтому рекомендуется использовать расширения файлов в нижнем регистре.