возможно ли проверять данные в форме с помощью html
Защита от дурака
«Защитой от дурака» называется комплекс мер по пресечению ввода неправильной информации в форме. Например, если в поле требуется ввести положительное число от 0 до 10, то следует проверить, чтобы пользователь не ввёл текст или число, которое не лежит в указанном диапазоне, т.е. число не должно быть меньше нуля и больше десяти.
Почему происходит ввод неправильной информации? Это в основном совершается по трём причинам.
Следует понимать, что точные и правильные формулировки хотя и снижают вероятность возникновения ошибок, но никак не спасают от них. Только технические средства на стороне сервера позволяют получить требуемый результат и избежать ввода неправильной информации. Тем не менее, ревизия или, как её ещё называют, валидация на стороне клиента позволяет быстро проверить данные, вводимые пользователем, на корректность, без отправки формы на сервер. Таким образом экономится время пользователя и снижается нагрузка на сервер. С позиции юзабилити тоже имеются плюсы — пользователь сразу получает сообщение о том, какую информацию он указал неверно и может исправить свою ошибку.
Обязательное поле
Пример 1. Атрибут required
HTML5 IE 10+ Cr Op Sa Fx
Обязательные поля должны быть заполнены перед отправкой формы, иначе форма на сервер не отправится и браузер выдаст об этом предупреждение. Вид сообщения зависит от браузера, например Chrome выводит всплывающую подсказку, как показано на рис. 1.
Рис. 1. Обязательное поле не заполнено
Корректность данных
Исходно имеется два поля, в котором вводимые пользователем данные проверяются автоматически. Это веб-адрес и адрес электронной почты. Браузер Chrome также проверяет на корректность поле с календарными данными, но только потому, что у него не предусмотрен интерфейс выбора календаря щелчком мыши. Для этих элементов характерны следующие правила.
У браузеров несколько различается политика по проверке данных пользователя. К примеру, Opera подставляет протокол http:// перед введённым текстом автоматически, тогда как другие браузеры ждут его от пользователя. Chrome и Opera требуют, чтобы в почтовом адресе была точка, для Firefox она не обязательна.
В примере 2 показана форма с обязательными полями, в которой два поля проверяется браузером.
Пример 2. Корректность данных
HTML5 IE 10+ Cr Op Sa Fx
Opera проверяет элемент формы только при наличии атрибута name.
Что происходит в Opera при вводе неверных данных показано на рис. 2.
Рис. 2. Предупреждение о неправильных данных
Шаблон ввода
| Шаблон | Описание |
| ^[a-zA-Z]+$ | Любые латинские буквы. |
| ^[ 0-9]+$ | Любое количество цифр. |
| \d<1,3>\.\d<1,3>\.\d<1,3>\.\d | IP-адрес. |
| 8 | Почтовый индекс. |
| \d+(,\d<2>)? | Цена в формате 1,34 (разделитель запятая). |
| \d+(\.\d<2>)? | Цена в формате 2.10 (разделитель точка). |
В примере 3 просят ввести шестнадцатеричное значение цвета (#ffcc00) и если оно не лежит в этом диапазоне, браузер выводит сообщение об ошибке.
Пример 3. Шаблон ввода
HTML5 IE 10+ Cr Op Sa Fx
На рис. 3 показано предупреждение в браузере Chrome.
Рис. 3. Введённые данные не соответствуют шаблону
Отмена валидации
Валидация не всегда требуется для формы, к примеру, разработчик пожелает использовать универсальное решение на JavaScript и дублирующая проверка браузером ему уже ни к чему. В подобных случаях необходимо отключить встроенную валидацию. Для этого применяется атрибут novalidate тега
Техники валидации форм
Это перевод статьи Ире Адеринокун — «Form validation techniques».
Ни для кого не секрет, что онлайн-формы могут стать серьёзным испытанием для пользователей. Особенно когда они выглядят как список полей для ввода без каких-либо подсказок. Однако мы, как разработчики, можем значительно облегчить жизнь посетителям наших сайтов.
Используем CSS
В CSS существует четыре специальных псевдокласса, применимых к полям формы: :valid (валидное поле), :invalid (невалидное), :required (обязательное) и :optional (необязательное). Их можно использовать, чтобы добавлять некоторые — хотя и весьма ограниченные — подсказки пользователям, заполняющим форму.
Стилизация псевдоклассов :valid и :invalid
Стилизация состояний :required и :optional сама по себе не особо полезна, поскольку эта информация обычно указывается в подписях к полям формы. Однако мы можем объединить эти состояния с псевдоклассами :valid / :invalid и стилизовать их комбинации. Например, мы хотим показывать лишь положительный результат, когда валидно обязательное к заполнению поле.
Стилизация по :valid и :required
Используем JavaScript
JavaScript даёт намного больше возможностей для улучшения работы пользователей с формами. Давайте рассмотрим в качестве примера три числовых поля, у каждого из которых установлен минимум в 10, максимум в 100 и шаг в 10 единиц.
Стандартный тултип валидации
В результате всё, что получит пользователь — это сообщение об ошибке для первого поля. Кроме того, в этом сообщении будет указано лишь одно несоответствие из двух требуемых. Такое поведение можно исправить, изменяя показываемые валидатором сообщения.
Добавляем несколько сообщений об ошибках в один тултип
Теперь при попытке отправить форму мы увидим вот это:
Отображаем несколько ошибок в одном тултипе
Стало лучше, поскольку теперь будут показываться все сообщения об ошибках, связанные с конкретным полем. Однако другая проблема всё ещё не решена: ошибки по-прежнему показываются лишь для первого поля.
Это ограничение валидации, устанавливаемое браузером. Чтобы его побороть, нам нужно пойти другим путём.
Показываем все ошибки для всех полей.
Вместо того, чтобы использовать встроенный тултип, мы можем добавлять сообщения об ошибках напрямую в DOM. Таким образом, все ошибки будут выводиться рядом с соответствующим полем.
Этого можно добиться какой-то парой дополнительных строчек в нашем коде:
Вот что происходит при клике на submit теперь:
Отображаем все ошибки для всех полей в DOM
Используем нестандартные проверки валидности
Иногда встроенной в браузер валидации бывает недостаточно. Нам может понадобиться, чтобы вводимые данные удовлетворяли некоторым дополнительным правилам. Например, чтобы в текстовом поле требовалось указать особые символы.
Валидация в реальном времени
Хотя текущий способ выглядит намного лучше, он тоже не без изъянов. Наихудший из недочётов заключается в том, что пользователь не сможет увидеть никаких сообщений, пока не нажмёт на кнопку отправки формы. Было бы гораздо лучше, если бы валидация поля происходила сразу же при его заполнении. Можно выделить три правила для того, чтобы с формой было удобно работать:
Если вы хотите попробовать свои силы (и даже сделать получше), вы можете воспользоваться вот этим шаблоном.
Валидация в HTML5
Интерактивные веб-сайты и приложения невозможно представить без форм, которые позволяют нам общаться с нашими пользователями и получать данные, необходимые для обеспечения гладких сделок с ними. В то время как мы можем улучшить удобство и простоту использования наших форм с удачно выбранным шаблоном проектирования UX. HTML5 также имеет собственный механизм для ограничения проверки, который позволяет нам поймать ошибки ввода прямо на фронт энде.
Проверка ввода имеет основную цель — безопасность. Когда речь идет о безопасности, это означает, что мы должны предотвратить инъекции вредоносного контента — будь то преднамеренные или случайные.При проверке внешнего интерфейса ввода, наша работа состоит в том, чтобы установить разумные ограничения на ввод данных пользователем.
Валидация в HTML5
До появления HTML5 фронт-энд разработчики были ограничены в проверке пользовательского ввода использованием JavaScript. Это был утомительным и подверженный ошибкам процесс. Для улучшения проверки на стороне клиента, HTML5 ввел алгоритм проверки ограничений, который работает в современных браузерах, и проверяет правильность пользовательского ввода.
Благодаря функции проверки ограничений в HTML5, мы можем выполнить все стандартные задачи проверки входных данных на стороне клиента без JavaScript, исключительно с HTML5.
Кроме тех типов входных данных, которые уже существовали до HTML5 (text, password, submit, reset, radio, checkbox, button, hidden), мы можем также использовать следующие смысловые HTML5 типы: email, tel, url, number, time, date, datetime, datetime-local, month, week, range, search, color.
Мы можем безопасно использовать типы входных данных в формате HTML5 со старыми браузерами, так как они будут вести себя как поле в браузерах, которые не поддерживают их.
Пара примеров атрибутов для валидации
Использование следующих семантических атрибутов для валидации может быть очень полезным и даже может помочь нам больше, чем мы думаем:
1) required
Required является самым известным атрибутом в валидации HTML. У него не может быть значения. Просто теги, которые использует этот атрибут, не должны быть пустыми.
Он может быть использован в следующих инпутах: url, email, text, password, date, month, week, tel, search, select, textarea, file, checkbox, time, number. Например, пользователь может забыть ввести значение в поле ввода. В этом случае сообщение об ошибке будет высвечивается до тех пор, пока это поле не будет заполнено правильно. Поэтому важно всегда визуально обозначать для пользователя поля, обязательные для заполнения.
2) maxlength
Этот атрибут позволяет установить максимальную длину вводимого текста для текстового поля ввода. Maxlength может быть использован в следующих инпутах: textarea, password, url, tel, text и search.
В этом textarea лимит символов будет до 350.
Maxlength не покажет ошибку, но браузер не позволит пользователю ввести больше указанного числа символов. Хорошим примером может быть тег tel — pole для телефонного номера, который не может иметь больше определенного количества символов, или формы обратной связи, где мы не хотим, чтобы пользователи писали сообщения больше определенной длины.
3) max, min
Атрибут min и max могут помочь указывать диапазон между минимальном и максимальном номером. Мы можем использовать эти атрибуты в следующих инпутах: date, time, week, range, number и month. В следующем примере мы можем видеть минимальную и максимальную разницу в возрасте от 18 до 65 лет.
Если пользователь введет возраст до 17 лет или после 66 лет, то он получит сообщение об ошибке, при том что этот запрос не будет отправлен на сервер.
4) step
Атрибут step можно использовать для числового интервала. В следующем примере есть input number где мы указываем минимальный и максимальный год, но мы добавляем step=”4”. Это означает, что при каждом изменении значение будет меняться с шагом 4 года.
Пользователь может также ввести значение вручную в поле ввода, но в этом случае, если оно не соответствует ограничениям, браузер выдаст сообщение об ошибке.
5) pattern
Атрибут паттерн использует регулярное выражение для валидаций этого поля. Регулярное выражение представляет собой заранее определенный набор символов, которые образуют определенный шаблон. Мы можем использовать его либо для поиска строк, которые следуют шаблону, либо для обеспечения определенного формата, определенного шаблона.
Приведенный ниже пример требует от пользователей ввести пароль, который содержит минимально 8 символов, и включает по крайней мере одну букву и одну цифру:
Валидация HTML5-форм
В этой статье, я собираюсь разобрать валидацию на примере простой формы заказа, используя Constraint API, сделав акцент на том, чтобы не снизить удобства использования.
Несмотря на то, что использование валидации форм на стороне клиента очень удобно и позволяет быстро оповестить пользователя об ошибках во введенных данных без необходимости обращения к серверу, это не отменяет необходимости проверять данные перед их отправкой.
Давайте разберем пример, чтобы понять, как можно проводить валидацию, используя лишь встроенные средства браузера. Ниже приведен код простой формы заказа:
Метки также помогают сделать интерфейс более наглядным. Для слабовидящих людей это незаменимо – программа, читающая с экрана, будет произносить текст метки, давая пользователю понять назначение поля. Также это полезно, чтобы указать на обязательные к заполнению поля, как это сделано в примере выше.
Это отображается, когда поле ввода получает фокус, предоставляя контекстно-зависимую справку:
Чтобы провести валидацию этой формы, нам необходимо:
Обязательные поля
Если мы попытаемся отправить данную форму, не заполнив всех обязательных полей, браузер оповестит о необходимости это сделать:
Наверное, вы заметили, что наличия атрибута ‘required’ в тегах меток для обязательных полей теперь не требуется. Это сделано потому, что программы, читающие с экрана, указывают наличие атрибута required также и для меток. В таком случае, сообщение о том, что поле обязательно к заполнению, прозвучит два раза, что, естественно, лишнее.
Предупреждение: не все браузеры имеют поддержку атрибута required, поэтому в некоторых комбинациях « браузер/программа чтения с экрана » могут возникать ошибки. Поэтому, на данный момент лучшей практикой будет указание атрибута aria-required=”true” :
Валидация данных
Теперь, после того как пользователь ввел данные в обязательные поля, нам необходимо убедиться, что они заполнены в соответствии с требуемым форматом.
Нам нужно, чтобы содержимое поля ‘Name’ имело формат ‘ Firstname Lastname ‘ и включало в себя только буквы и пробелы (в реальных сценариях, возможно, нужно будет принять во внимание и другие символы).
Этого можно достичь, добавив атрибут pattern к полю ‘Name’, установив его значение в виде регулярного выражения, которое описывает правило, которому должны соответствовать вводимые данные:
Вы можете помочь пользователю, использовав атрибут title, который подсказывает требуемый формат ввода:
Текст в атрибуте title затем присоединяется к встроенному валидационному сообщению:
Стоит заметить, что некоторые сочетания « программа чтения с экрана/браузер » могут привести к ситуации, когда значение атрибута title будет прочитано несколько раз, в дополнение к тексту атрибута aria-describedby, поэтому обратите на это внимание.
К примеру, я обнаружил, что использование программы NVDA с IE10 ведет к двойному прочтению: как атрибута title, так и aria-describedby. Однако NVDA с Chrome и Firefox ведет себя совершенно нормально – читается только текст атрибута aria-describedby.
Далее, мы рассмотрим этот вопрос и покажем решение с использованием CSS3.
Валидация email, URL и номеров
Чтобы убедиться, что пользователь ввел верные данные в поля email, website и number of tickets, мы можем использовать новые элементы ввода, появившиеся в HTML5:
Выбрав соответствующий тип поля, мы можем поручить браузеру проверку на наличие и правильность введенных данных.
Также заметим, что атрибут type больше не является обязательным. Если вы явно не укажете тип элемента ввода, то по умолчанию он будет равен type=»text».
Предположим, что мы хотим ограничить число билетов, которое может купить один человек. Это можно реализовать, используя атрибуты max и min :
Если пользователь введет число меньшее 1 или большее 4, то выведется сообщение о том, что диапазон ввода ограничен.
Использование CSS для подсветки обязательных полей и неверно введенных данных
Вкупе с новыми типами элементов ввода и атрибутами, появившимися в HTML5, CSS3 также предлагает новые псевдоклассы, которые можно использовать для визуальных подсказок пользователю о том, какие поля являются обязательными, какие опциональными, а какие содержат ошибки валидации.
Селекторы обязательных полей могут использовать псевдокласс :required :
А дополнительные – псевдокласс :optional :
Успешное или неудачное прохождение процедуры валидации может показываться пользователю с помощью псевдоклассов :valid, :invalid, :in-range и :out-of-range :
Ранее, я заметил, что определенные сочетания « программа чтения с экрана/браузер » ведут к двойному прочтению атрибутов title и aria-describedby.
Что ж, одним из способов обойти это препятствие является удаление атрибута title из тега элемента ввода и использование CSS3-псеводкласса :invalid, чтобы показать текст атрибута aria-describedby:
Далее, в дополнение к отображению текстовой справки при получении полем ввода фокуса, мы будем отображать эту подсказку, когда в поле ввода внесены неверные данные.
После всех манипуляций HTML-код должен выглядеть так:
Отключение встроенной в браузер валидации
Вы можете отключить встроенную в браузер валидацию, добавив атрибут novalidate к тегу
Кроссбраузерность
Хорошая новость состоит в том, что валидация HTML-форм поддерживается всеми новыми браузеры для настольных компьютеров и большинством мобильных браузеров.
Плохая же новость заключается в частичной поддержке в настольной версии Safari и её отсутствии во всех браузерах iOS Safari и в стандартных браузерах для Android. Если вам нужна поддержка старых версий IE (ниже версии 10), то там вы ее также не обнаружите.
Что же можно сделать, если требуется поддержка браузеров, которые не имеют встроенных средств валидации?
Первый вариант это положиться на валидацию на стороне сервера. Это не потребует от вас дополнительной работы и, в то же время, позволит пользоваться предлагаемыми возможностями тем, чьи браузеры не поддерживают клиентскую валидацию.
Второй способ это продолжить использовать исключительно JavaScript для валидации на стороне клиента, не добавляя возможности, которые были обсуждены выше.
Третий подход подразумевает использование JavaScript для обнаружения поддержки валидации форм в браузере, и, если таковая имеется, то использовать её; в противном же случае обратиться к JavaScript-валидации.
Библиотеки наподобие Modernizr могут помочь обнаружить поддержку HTML5, но вы всегда можете написать собственный код, если не хотите подключать стороннюю JavaScript-библиотеку:
Заключение
В этой статье мы обзорно изучили использование HTML5-валидации форм на стороне клиента, приведя пример её применения в форме заказа, и при этом мы не пользовались средствами JavaScript.
Также мы указали на некоторые вопросы, связанные с реализацией поддержки для людей с ограниченными возможностями, которые стоит иметь ввиду.
Также, было рассмотрено использование новых CSS3-псеводклассов для отображения визуальных подсказок о том, какие поля обязательны к заполнению, а какие нет, какие поля заполнены правильно, а какие — нет.
Наконец мы поговорили об отключении HTML-валидации форм и обнаружении поддержки этой возможности в различных браузерах.
Валидация форм
Поля в форме предназначены для сбора информации от посетителей страницы. Но несмотря на все усилия и объяснения, получение правильной информации может оказаться трудным делом. Нетерпеливые или невнимательные посетители могут пропускать важные поля, заполнять поле или несколько полей не полностью, да и попросту нажимать неправильные клавиши. Заполнив таким образом форму, они нажимают кнопку «Отправить», и серверная программа получает набор данных, с которыми она не знает что делать (если не реализована валидация данных на серверной стороне).
Серьезной веб-странице требуется проверка данных, т.е. какой-либо способ обнаружения ошибок во введенных данных, а еще лучше — способ, не допускающий ошибок вообще. На протяжении многих лет веб-разработчики делали это с помощью процедур JavaScript собственной разработки или посредством профессиональных библиотек JavaScript. И говоря по правде, эти подходы давали отличные результаты.
Но, видя, что проверка выполняется повсеместно (практически всем нужно проверять вводимые данные на ошибки) и применяется лишь к нескольким основным типам данных (например, адресам электронной почты или датам), а также, что ее реализация — такая неинтересная и скучная задача (никому, по сути, не хочется писать один и тот же код для каждой формы, не говоря уже о тестировании его), определенно должен быть лучший способ для ее реализации.
Как работает проверка 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>означает, что нужны три прописные буквы. Следующее тире не имеет никакого специального значения и означает самое себя, т.е. указывает, что после трех прописных букв должно быть тире. Наконец, 1 обозначает цифры в диапазоне от 0 до 9, а <3>требует три таких цифры.
Регулярные выражения полезны для поиска в тексте строк, отвечающих условиям, заданных в выражении, и проверки, что определенная строка отвечает заданному регулярным выражением шаблону. В формах 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. Она реализует поддержку возможностей форм, которые мы рассмотрим далее, таких как ползунок и средства выбора даты и цвета. Обе эти библиотеки предоставляют хорошую общую поддержку для веб-форм, но содержат в своем коде неизбежные пробелы и незначительные ошибки. Качество сопровождения и усовершенствования этих библиотек покажет только время.