Ошибка валидации формата поля что это такое
Валидация форм — Принципы — Контур.Гайды
Валидация — это проверка значений, указанных пользователем, и отображение найденных ошибок.
Описанное здесь поведение валидаций и отображение ошибок реализовано в библиотеке «React UI Validations», по возможности используйте эту библиотеку в продукте.
Принципы
Задача дизайнера — сделать так, чтобы пользователь не совершил ошибку и валидация не понадобилась, для этого:
- Ограничьте выбор заведомо неверных значений в списке: блокируйте эти значения или не показывайте в списке.
- Ограничьте ввод неподходящих символов. Если в поле нужно вводить только цифры, и это очевидно пользователю, игнорируйте ввод букв вместо того, чтобы показать ошибку. Используйте маски в полях, где у значений известен формат.
- Пишите подсказки для заполнения формы. Например, плейсхолдер в полях ввода.
Валидация на только что открытой пустой форме запрещена. Исключение — черновики, когда пользователь уже заполнял эту форму, через какое-то время вернулся к ней, а она заполнена с ошибками.
Виды валидации
Существует три вида валидаций: мгновенная, по потере фокуса и по отправке формы.
Чем раньше интерфейс сообщает об ошибке, тем лучше — пользователю проще вернуться и исправить ошибку.
Самый быстрый способ сообщить об ошибке — мгновенная валидация. Но она возможна только в тех случаях, когда в процессе ввода понятно, что значение некорректное. Обычно такие ошибки связаны с неправильной раскладкой клавиатуры (кириллица вместо латиницы) или вводом букв в цифровое поле (ИНН, КПП и др.) Для этих случаев мы используем поля с масками: ввод неподходящих символов в них заблокирован. Поэтому в наших интерфейсах есть только два вида валидации:
- по потере фокуса — основной вид валидации
- по отправке формы — для тех случаев, когда валидация по потере фокуса невозможна.
Валидация по потере фокуса
Когда использовать
Этот вид валидации подходит для большинства случаев.
Как работает
Не валидируйте поля на пустоту по потере фокуса — не показывайте ошибку если поле не заполнено, возможно пользователь вернется и заполнит поле чуть позже. Показывать ошибку в таких случаях можно только после отправки формы.
Валидация срабатывает сразу после потери фокуса, если значение в поле заполнено. Если найдена ошибка, поле подсвечивается красным. Фокус в это поле автоматически не возвращается:
Текст ошибки появляется в тултипе, когда поле получает наведение или фокус:
Поле с ошибкой должно остаться подсвеченным, если оно получило фокус, его значение не исправляли, а затем оно потеряло фокус.
Красная подсветка снимается с поля, как только пользователь начал исправлять ошибочное значение.
Валидация при отправке формы
Когда использовать
Используйте этот вид валидации, когда нельзя проверить поля по потере фокуса. Например, для проверки заполнения обязательных полей.
Как работает
Проверка происходит после того, как пользователь нажал кнопку отправки данных: все поля с ошибками на форме подсвечиваются, страница прокручивается к первому полю с ошибкой, фокус перемещается в это поле, курсор встает в конец строки, рядом с полем появляется тултип с подсказкой.
При прокрутке к первому полю от верхней границы окна до ошибочного поля остается отступ 48px — шесть модулей.
Блокирование кнопки отправки
В небольших формах вместо проверки заполнения обязательных полей можно блокировать кнопку отправки формы. Используйте это поведение, когда очевидно, почему кнопка отправки формы неактивна. Например, на форме входа:
Как только заполнены все обязательные поля — кнопка становится активной. Если после этого пользователь стер значение в одном из полей — кнопка снова должна стать не активной.
Сообщения об ошибках
Об ошибках можно сообщать двумя способами:
- Красным текстом около поля, обычно под полем или справа от него:
- Текстом в тултипе:
Из этих двух способов мы рекомендуем использовать тултипы. Они идут отдельным слоем, поэтому не раздвигают форму и легко размещаются, даже если поля на форме расположены плотно.
Тултипы
Как работают
Тултип с подсказкой появляется в двух случаях:
- При наведении на поле с ошибкой.
- Когда поле с ошибкой получает фокус.
Если значение в поле с ошибкой было изменено, потеряло фокус, а потом заново оказалось в фокусе — тултип с текстом старой ошибки уже не возникает. Это правило одинаково работает для всех типов валидаций: и по потере фокуса, и при отправке формы.
Тултип исчезает, когда:
- Курсор вышел из области поля с ошибкой.
- Поле с ошибкой потеряло фокус.
Тултип по наведению перекрывает тултип по фокусу.
Тултип может появляться сверху или справа от контрола с ошибкой, так чтобы он не перекрывал полезную информацию:
Единообразие поведения и внешнего вида
Показывайте тултипы справа от полей. Eсли в этом случае они перекрывают важное содержимое на странице, выводите тултипы сверху. Придерживайтесь единообразия, но помните, что контент важнее него.
Красные тексты на странице
Как работают
Красный текст ошибки появляется сразу, как только произошла валидация и ошибочное поле подсветилось.
Как только пользователь начал исправлять значение, красная подсветка поля исчезает, и цвет текста ошибки меняется на черный — #333.
Текст ошибки пропадает по потере фокуса и больше не появляется, если поле заново получает фокус. Это правило одинаково работает для всех типов валидаций: и по потере фокуса, и при отправке формы.
Выводите текст ошибки справа, если на форме есть место, а само сообщение короткое. Так форму не придется раздвигать, чтобы показать ошибку.
Если справа от поля нет места для текста, раздвигайте форму и выводите сообщение под полем.
На более сложных формах выводите сообщение об ошибке в тултипе.
Валидация зависимых полей
Зависимые поля — это поля, значение которых зависит друг от друга.
Ошибки, которые связаны с нарушением зависимости полей, мы показываем после сабмита формы. Например, ИНН и КПП. Если пользователь указал ИНН из 10 цифр, а поле с КПП оставил пустым, после отправки формы пустое поле с КПП будет подсвечено.
ИНН может быть двух видов:
- 10-значный у юридических лиц
- 12-значный у ИП.
Если пользователь указал ИНН из 12 цифр, значит организация — индивидуальный предприниматель, и у нее нет КПП, значит поле КПП заполнять не нужно. И наоборот, если заполнено КПП, а ИНН указан 12-значный, возможно неверно указан ИНН.
Подсветка зависимых полей пропадает, как только пользователь начал исправлять значение в одном из этих полей.
Если при заполнении зависимого поля нарушен формат значения, сообщайте о такой ошибке при потере фокуса. Например, пользователь ввел 3 цифры в поле ИНН и убрал фокус. Такое поле должно подсветиться сразу же.
Пример
Есть форма из 5 полей:
- Название организации — простое текстовое, обязательное
- ИНН — 10 или 12 цифр, проверка контрольной суммы по потере фокуса, обязательное
- КПП — 9 цифр с проверкой контрольной суммы по потере фокуса, обязательное, если ИНН состоит из 10 цифр
- Электронная почта — адрес почты, проверка по потере фокуса по маске [email protected], необязательное
- Телефон — международный формат, проверка по потере фокуса по маске +00000000000, обязательное
Пользователь пропустил поле с названием организации, заполнил ИНН значением из 10 цифр, перешел в поле почты, указал некорректный адрес, перешел в поле с телефоном и указал некорректный номер, но из поля пока не ушел:
Пользователь навел курсор на поле с почтой, появился тултип. Но исправлять значение пользователь не стал:
Пользователь нажал кнопку «Отправить» — фокус перешел в поле «Название организации», так как оно обязательное и незаполненное:
Поле с телефоном также подсветилось красным, так как заполнено некорректно. ИНН и КПП подсветились, так как ИНН состоит из 10 цифр, значит должен быть заполнен и КПП — валидация зависимых полей произошла только после отправки формы.
Пользователь начинает вводить название организации, подсветка поля гаснет, а текст подсказки остается:
Заполнил название организации, перешел в поле ИНН:
Понял, что ИНН правильный, и нужно заполнить КПП:
Начал заполнять поле КПП. Красная рамка у ИНН и КПП исчезла — пользователь изменил значение в одном из зависимых полей:
Заполнил КПП, перешел в следующее поле:
Исправил почту, перешел в следующее поле:
Исправил телефон, кликнул за пределами поля:
Теперь по нажатию кнопки «Отправить» все будет хорошо.
Техники валидации форм — Блог HTML Academy
Ни для кого не секрет, что онлайн-формы могут стать серьёзным испытанием для пользователей. Особенно когда они выглядят как список полей для ввода без каких-либо подсказок. Однако мы, как разработчики, можем значительно облегчить жизнь посетителям наших сайтов.
Используем 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, мы можем просто-напросто добавить туда ещё несколько проверок.
Валидация в реальном времени
Хотя текущий способ выглядит намного лучше, он тоже не без изъянов. Наихудший из недочётов заключается в том, что пользователь не сможет увидеть никаких сообщений, пока не нажмёт на кнопку отправки формы. Было бы гораздо лучше, если бы валидация поля происходила сразу же при его заполнении. Можно выделить три правила для того, чтобы с формой было удобно работать:
- Требования для каждого поля чётко видны до того, как пользователь начал печатать.
- Как только пользователь начинает вводить данные, соблюдая требования, он сразу видит индикатор успешного заполнения поля или подсказки, если есть ошибки.
- Нужно отображать сообщения об ошибках таким образом, чтобы пользователь не мог отправить некорректно заполненную форму.
В статье на следующей неделе (оригинал, перевод готовится) я покажу, как реализовать валидацию в реальном времени, переделав вот такую простую форму регистрации:
Пример валидации в реальном времениЕсли вы хотите попробовать свои силы (и даже сделать получше), вы можете воспользоваться вот этим шаблоном.
Простая валидация формы без JS / Habr
В данной статье я бы хотел поделиться методом быстрой валидации полей с помощью разметки и стилей. Данный метод не является кроссбраузерным и рекомендуется к использованию только как дополнительная фича. По ходу статьи мы будем уменьшать наши шансы на кроссбраузерность, но повышать функциональность.Давайте попробуем собрать стандартную форму, которая будет включать в себя: Имя, E-Mail, Телефон, Ссылку на сайт и допустим Ваш рост, чтобы поэксперементировать с числовым полем.
<form action="#"> <input type="text" name="name" placeholder="Имя" /> <input type="text" name="email" placeholder="E-Mail" /> <input type="text" name="phone" placeholder="Телефон" /> <input type="text" name="url" placeholder="Ваш сайт" /> <input type="text" name="growth" placeholder="Ваш рост" /> <button type="submit">Отправить</button> </form> HTML5
Сейчас уже никого не удивить атрибутами валидации input полей, которое принес нам стандарт HTML5. Однако, обходить стороной мы его не станем — этот метод валидации является наиболее поддерживаемым в современных браузерах.
Самый простой путь валидации — это определить тип input поля и расставить атрибуты required которые отвечают за обязательность заполнения.
<form action="#"> <input type="text" name="name" placeholder="Имя" required /> <input type="email" name="email" placeholder="E-Mail" /> <input type="tel" name="phone" placeholder="Телефон" /> <input type="url" name="url" placeholder="Ваш сайт" /> <input type="number" name="growth" placeholder="Ваш рост" /> <button type="submit">Отправить</button> </form> Применение этих двух атрибутов позволит гораздо эффективнее валидировать вводимую информацию нативными методами. Ну и конечно же поддержка этих свойств браузерами наиболее широка.
Отдельно хотелось бы сказать про тип поля tel. Ожидается что браузер будет валидировать телефонные номера, но нет, поле с типом tel используется сейчас только для автозаполнения. Дело в том, что валидация телефонных номеров очень неоднозначная задача из-за слишком большого количества различных форматов телефонных номеров в разных странах, которые просто никак не получится унифицировать и записать в одно правило.
Однако, нам на помощь приходит атрибут pattern. Этот атрибут принимает в себя значение регулярного выражения. В нашем случае рассмотрим вариант паттерна для ввода мобильного телефона в РФ: +7 (123) 456-78-91. Для этого добавим простое регулярное выражение в наше поле с телефоном, а также ограничим минимальное и максимальное количество символов:
<input type="tel" name="phone" placeholder="Телефон" pattern="[\+]\d{1}\s[\(]\d{3}[\)]\s\d{3}[\-]\d{2}[\-]\d{2}" minlength="18" maxlength="18" /> Обычно я использую данный паттерн в связке с маской для ввода номера, но тут к сожалению без JS пока что не обойтись. Если вы не используете маску, то я бы не стал использовать паттерны на вводе телефона, поскольку это в большинстве случаев вызовет больше неудобств для пользователя.
Поддержка браузерами атрибута pattern на данный момент очень хорошая. iOS начиная с версии 10.3 полностью поддерживает данное свойство, до этого наблюдалось отсутствие подсказок о неправильном вводе данных.
Стоит также учитывать, что атрибут minlength до сих пор не поддерживается в браузерах IE, EDGE и только с версии 10.3 появился в iOS. Однако maxlength поддерживается везде и очень давно. Нам в целом хватит и этого.
Давайте также поставим ограничение для поля с ростом. Допустим мы предполагаем, что пользователь нашего сайта определенно не может быть ниже 100 см и выше 250 см. Так и напишем:
<input type="number" name="growth" placeholder="Ваш рост" min="100" max="250" /> С поддержкой этих атрибутов в браузерах, все хорошо.
Перейдем к стилизации!
CSS3
Для того чтобы кастомно стилизовать нашу валидацию, воспользуемся псевдоклассами :invalid и :valid. Поддержка этих псевдоклассов в браузерах позволяет использовать их максимально широко на данный момент.
input:invalid {border-color: red;} input:valid {border-color: green;}Казалось бы, берем полученные знания и применяем! Но не все так просто как кажется, давайте проверим как это работает. В результате мы получим, что все наши поля изначально пустые и обязательные будут считаться не валидными, а все остальные валидными. Совсем не красиво и непонятно для пользователя, что от него хотят.
Мы можем пойти на небольшую хитрость и использовать псевдокласс :placeholder-shown. С помощью этого псевдокласса мы можем определить отображается ли сейчас значение placeholder в нашем поле ввода. Атрибут placeholder отображается только тогда, когда в наше поле ничего не введено. Соответственно, чтобы применить этот псевдокласс нам просто нужно обратить его свойство с помощью :not. В итоге получаем вот такую конструкцию:
input:invalid:not(:placeholder-shown) {border-color: red;} input:valid:not(:placeholder-shown) {border-color: green;}Если прочитать дословно: окрасить красным цветом границу инпута, когда наше поле не валидно и когда в нем не отображается значение атрибута placeholder. Если ваше поле не имеет атрибута placeholder, можно просто поставить внутри пробел:
<input type="text" placeholder=" " />У данного метода есть только один минус: поддержка. Псевдоэлемент :placeholder-shown поддерживается во всех браузерах кроме IE и EDGE. К счастью :not не обладает таким недостатком.
Для примера я набросал все вышесказанное в CodePen и добавил еще немного возможностей:
Итог
Таким образом, не прибегая к JS мы с помощью двух строк в CSS смогли стилизовать и валидировать форму. На текущий момент такая конструкция будет хорошо работать в большинстве браузеров, к сожалению, как всегда, веб-разработку подводят детища Microsoft.
| backend_error (503) | Ошибка сервера. |
| invalid_parameter (400) | Неверно задан параметр. |
| not_found (404) | Указанный объект не найден. |
| missing_parameter (400) | Не указан необходимый параметр. |
| access_denied (403) | Доступ запрещен. |
| unauthorized (401) | Неавторизованный пользователь. |
| quota (429) | Превышен лимит количества запросов к API. |
| query_error (400) | Запрос слишком сложный. |
| conflict (409) | Нарушение целостности данных. |
| not_acceptable (406) | Неподдерживаемый формат. |
| timeout (504) | Запрос выполняется дольше отведенного времени. |
| invalid_uploading (400) | Некорректная загрузка файла. |
| no_changes (400) | Повторная загрузка одинакового файла. |
| header_validation_error (400) | Ошибка валидации заголовка в файле CRM сегмента |
| too_large_polygon (400) | Слишком большой полигон. |
| self_crossing_polygon (400) | Задан полигон с самопересечениями. |
| crossing_polygons (400) | Заданы пересекающиеся полигоны. |
| reprocess_quota (429) | Превышен лимит пересчета сегментов. |
| reprocess_wrong_type (400) | Сегмент не может быть пересчитан. |
| reprocess_wrong_status (400) | Сегмент не может быть пересчитан. |
| targeted_quota (400) | Недостаточно сегментов используются для нацеливания. |
| Код ошибки | Текст сообщения | Комментарий, возможные причины |
| 52 | Сервер авторизации временно недоступен | Сервер API Директа временно не может получить информацию от сервиса Яндекс.OAuth. Попробуйте вызвать метод через некоторое время. |
| 1000 | Сервер временно недоступен | Внутренняя ошибка сервера API Директа. Попробуйте вызвать метод через некоторое время. При повторении ошибки обратитесь в службу поддержки. |
| 1001 | Ошибка инициализации сервиса | |
| 1002 | Ошибка операции | |
| 1003 | Не удалось создать учетную запись пользователя на Яндексе | При создании учетной записи произошла ошибка. Попробуйте вызвать метод через некоторое время. |
| 1004 | Не удалось создать клиента | При создании клиента в Директе произошла ошибка. Попробуйте вызвать метод через некоторое время. При повторном вызове используйте другой логин. |
| 1020 | Внутренняя ошибка сервера | Список доступных валют не определен. Обратитесь в службу поддержки. |
| 53 | Ошибка авторизации | Указан недействительный OAuth-токен. Причины, по которым токен становится недействительным, перечислены в разделе Отзыв токенов документации Яндекс.OAuth. |
| 58 | Незавершенная регистрация | Необходимо создать заявку на доступ к API и дождаться ее подтверждения. |
| 54 | Нет прав |
|
| 513 | Ваш логин не подключен к Яндекс.Директу | Пользователь, от имени которого выполняется запрос, не имеет аккаунта в Директе. Для регистрации аккаунта необходимо создать от имени пользователя рекламную кампанию в веб-интерфейсе. См. также раздел Доступ и авторизация. |
| 3000 | Нет доступа к API |
|
| 3001 | Нет доступа к методу | Метод AgencyClients.add недоступен агентству. |
| 152 | Недостаточно баллов | |
| 506 | Превышено ограничение на количество соединений | Превышено ограничение на количество одновременных соединений с сервером. |
| 3500 | Не поддерживается | |
| 4000 | Параметры запроса указаны неверно |
|
| 4001 | Неверно заданы параметры фильтрации SelectionCriteria |
|
| 4002 | Неверно указаны параметры страницы | Неверное значение параметра Limit или Offset. |
| 4003 | Не передано ни одного из необходимых параметров | В запросе должен присутствовать хотя бы один параметр из совокупности, однако не указано ни одного. |
| 4004 | Передан больше чем один параметр | Указаны взаимоисключающие параметры, только один из которых может присутствовать в запросе. |
| 4005 | В одном запросе необходимо использовать Id одного типа | При назначении ставок указаны идентификаторы разнородных объектов (например, в одной структуре Bids — CampaignId , а в другой — AdGroupId). |
| 4006 | В одном запросе заданы несовместимые операции | Редактировать уточнения к объявлению можно либо с помощью операций ADD и REMOVE, либо с помощью операции SET. |
| 5000 | Поле обязательно для заполнения | Значение обязательного поля пустое или состоит из пробелов. |
| 5001 | Превышена допустимая длина | |
| 5002 | Используются недопустимые символы |
|
| 5003 | Указано пустое значение | Пустая строка, например, в параметре Href в объявлении. |
| 5004 | Неверный формат | Некорректное значение поля объекта, например:
|
| 5005 | Поле задано неверно | Некорректное значение поля объекта, например:
|
Эссе о валидации данных / Habr
В заметке «Можно ли делить на 0,01 ?» на сайте тестировщиков я написал, что при тестировании нужно проверять согласованность валидаторов входных данных с логикой обработки этих данных приложением. Но из комментариев к этой заметке я понял, что для понимания того, как надо тестировать валидацию данных, надо понимать, как она должна работать, что можно считать правильным, а что нет. Поэтому я написал об этом отдельную статью. В ней рассматривается три вопроса: 1) зачем вообще нужна валидация данных, и 2) где и когда может выполняться валидация данных, 3) какие бывают разновидности проверок. Ну и конечно продемонстрировано, как всё это выглядит на живых примерах. А может быть мои рассуждения окажутся интересны не только тестировщикам, но и разработчикам.Зачем нужна валидация данных?
Казалось бы, «невалидные» данные, не удовлетворяющие определённым ограничениям, могут вызвать сбой в работе программы. Но что это означает? Предположим, в каком-то месте программы возникает исключение при попытке преобразовать строку в число, если строка имеет некорректный формат. Разумеется, если исключение не будет нигде перехвачено, это может привести к аварийному завершению программы. Но это маловероятный сценарий развития событий. Скорее всего в каком-то месте сработает перехватчик, который либо выдаст пользователю какое-то сообщение об ошибке в программе, либо сделает запись в журнал ошибок, после чего программа постарается восстановиться от сбоя и продолжить работу. То есть даже если валидацию не выполнять, вполне вероятно, что ничего страшного не случится.
Но определённые негативные последствия у отсутствия валидации всё таки могут быть, давайте чуть подробнее рассмотрим, какие проблемы при этом могут возникнуть.
- Невозможность восстановиться после сбоя. Не всегда программа способна «вернуть всё назад». Возможно, в процессе работы программа выполнила какие-то необратимые действия — удалила файл, отправила данные по сети, напечатала что-то на принтер, запустила резец станка и он частично произвёл обработку заготовки детали. Но даже если восстановление в принципе возможно, алгоритм восстановления может тоже содержать ошибки, и это иногда приводит к совсем печальным последствиям.
- Дополнительная нагрузка на систему. Восстановление после сбоя — это лишняя работа. Вся работа, которая была выполнена до момента сбоя — тоже лишняя. А это означает дополнительную нагрузку на систему, которой можно избежать, если заранее проверить данные. С другой стороны, валидация — это тоже дополнительная нагрузка, причём восстановление приходится делать лишь изредка, а проверку надо выполнять каждый раз, так что ещё неизвестно, что выгоднее.
- Инъекции не вызывают сбоев. Один из основных способов эксплуатации уязвимостей в программах заключается в том, чтобы «обмануть» валидаторы, то есть передать данные, которые валидатор признаёт корректными, но при этом они интерпретируются непредусмотренным образом, так что злоумышленник может получить несанкционированный доступ к данным или некоторым возможностям программы, либо способен разрушить данные или программу. Если валидации нет вообще, задача злоумышленника максимально упрощается.
- Сложность идентификации причины проблемы. Если исключение вылетело откуда-то из глубины программы, определить причины его возникновения не так-то просто. И даже если это возможно, может оказаться нелегко объяснить пользователю, что сбой вызван данными, которые он ввёл некоторое время назад в каком-то совершенно другом месте программы. А если проверка выполнена немедленно после ввода данных, никаких сложностей с идентификацией источника проблемы не возникает.
Короче говоря, отсутствие валидации может приводить к вышеописанным (а может быть и ещё каким-то другим) проблемам. Соответственно, наличие валидации позволяет предотвратить серьёзные сбои, упрощает идентификацию проблем, но за это приходится расплачиваться производительностью, поскольку дополнительные проверки увеличивают нагрузку на систему. И тут мы переходим ко второму вопросу — как уменьшить эту дополнительную нагрузку.
Где и когда выполнять валидацию данных?
Как уже было сказано выше, с точки зрения уменьшения нагрузки лучше всего вообще не выполнять валидацию данных.
Но если всё-таки проверка нужна, логика подсказывает, что удобно проверять данные в том месте, где они попадают в программу из внешнего мира. После такой проверки можно быть уверенным, что в программу попадают правильные данные и в дальнейшем они могут использоваться без дополнительных проверок.Это может быть пользовательский интерфейс, через который человек вводит данные. Это может быть файл, содержащий настройки программы или данные, которые программа должна обработать. Это может быть база данных, в которую информация может попадать из других программ. Это может быть сетевой протокол обмена данными с другими программами. Наконец, это может быть программный интерфейс, который использует другая программа, вызывая некоторые функции/процедуры и передавая в них параметры.
Увы, здравый смысл иногда вынужден отступить перед натиском действительности. «Фейс-контроль» данных на входе иногда не просто нецелесообразен, но вообще невозможен. Ниже приведены некоторые причины этого.
- Для валидации требуется доступ к недоступной части состояния системы. Это особенно характерно для проверки данных, вводимых человеком через графический интерфейс пользователя. Современные приложения часто построены с использованием многоуровневой архитектуры, которая предполагает, что реализация пользовательского интерфейса выделена в презентационный слой, а для проверки требуется доступ к другим слоям, вплоть до слоя базы данных.
Особенно хорошо это заметно для веб-приложений, где пользовательский интерфейс реализуется в браузере и выполняется на стороне клиента, а для проверки ввода требуется сравнение с тем, что хранится в базе данных. В этой ситуации проверку приходится выполнять уже после отправки данных на сервер. (Впрочем, сейчас с появлением AJAX-технологии эта проблема частично решена).
- Валидация требует полностью повторить логику обработки. Как уже отмечено двумя абзацами выше, при многослойной архитектуре приложения пользовательский интерфейс обычно выделяется в специальный презентационный слой, а логика обработки данных находится на другом слое. И бывают такие ситуации, когда для валидации нужно практически полностью выполнить эту обработку, потому не существует более короткого способа понять, завершится она успехом или нет.
Как выполнять валидацию данных?
Впрочем, где бы ни выполнялась валидация, можно это делать несколькими различными способами, в зависимости от того, какие ограничения накладываются на данные.
- Посимвольная проверка. Как правило такие проверки выполняются в пользовательском интерфейсе, по мере ввода данных. Но не только. Например, лексический анализатор компилятора тоже выявляет недопустимые символы непосредственно в процессе чтения компилируемого файла. Поэтому такие проверки можно условно назвать «лексическими».
- Проверка отдельных значений. Для пользовательского интерфейса это проверка значения в отдельном поле, причём выполняться она может как по мере ввода (проверяется то неполное значение, которое введено к настоящему моменту), так и после завершения ввода, когда поле теряет фокус. Для программного интерфейса (API) это проверка одного из параметров, переданных в вызываемую процедуру. Для данных, получаемых из файла, это проверка какого-то прочитанного фрагмента файла. Такие проверки, опять-таки по аналогии с компиляторной терминологией, можно назвать «синтаксическими».
- Совокупность входных значений. Можно предположить, что в программу сначала передаются какие-то данные, после чего подаётся некоторый сигнал, который инициирует их обработку. Например, пользователь ввёл данные в форму или в несколько форм (в так называемом «визарде») и наконец нажал кнопку «OK». В этот момент можно выполнить так называемые «семантические» проверки, нацеленные на валидацию не только отдельных значений, но и взаимосвязей между ними, взаимных ограничений.
Вполне возможна ситуация, когда каждое отдельное значение «синтаксически» корректно, но вместе они образуют несогласованный набор. Для программного интерфейса эта разновидность валидации предполагает проверку набора входных параметров вызываемой процедуры, для случая получения данных из файла это проверка всех прочитанных данных.
- Проверка состояния системы после обработки данных. Наконец, есть последний способ, к которому можно прибегнуть, если валидацию непосредственно входных данных выполнить не удаётся — можно попытаться их обработать, но оставить возможность вернуть всё к исходному состоянию. Такой механизм часто называется транзакционным.
Транзакция — это последовательность действий, которые либо все завершаются успешно, либо происходит какой-то сбой при выполнении отдельного действия, и тогда отменяются результаты всех предыдущих действий этой цепочки. Так вот, валидацию можно выполнять в процессе выполнения транзакции, а последняя проверка может быть выполнена в самом конце транзакции по обработке данных. При этом мы валидируем уже не сами данные, а то состояние, которое получилось после их полной обработки, и если это состояние не удовлетворяет каким-то ограничениям, тогда мы признаём входные данные невалидными и возвращаем всё к исходному состоянию.
Какой способ валидации следует применять на практике в том или ином случае? Чаще всего одним способом ограничиться не удаётся, да и не нужно. Валидацию данных можно и нужно выполнять в несколько этапов, усложняя проверки.
Сначала, по мере ввода, следим за тем, чтобы данные не содержали недопустимых символов. Например, для числового поля пользователю может быть запрещён ввод нецифровых символов.
После того, как ввод завершён, можно проверить всё значение целиком. Для введённого числа могут быть какие-то ограничения, например, оно не должно превышать определённого максимального допустимого значения. Если наше числовое поле представляет собой возраст, оно должно находиться в пределах от 0 до, скажем, 120.
Когда заполнены все поля, можно проверить, согласованы ли введённые значения друг с другом. Например, если в форме кроме поля для указания возраста есть поле для ввода номера паспорта, приложение может проверить, что при заполнении номера паспорта возраст должен быть не менее 14 лет.
Наконец, если всё введено корректно, можно попытаться начать обработку, выполняя проверки по ходу дела, а также в самом конце, и если что-то пошло не так, выполнить откат к исходному состоянию.
Ну и, конечно же, проверки на следующем уровне могут подстраховывать проверки предыдущих уровней. Скажем, для веб-приложений обязательной является проверка данных, пришедших на сервер в HTTP-запросе, независимо от того, выполнялась ли перед этим предварительная валидация в браузере или нет. Причина этого в том, что проверку на клиентской стороне можно обойти. Для других видов приложений обойти проверки не так просто, но иногда тоже вполне возможно, как показано в примере чуть ниже.
Тестирование валидаторов
Завершим статью демонстрацией различных видов валидаторов, а также некоторыми рекомендациями относительно того, как при тестировании проверять правильность их работы.
Начнём с посимвольной проверки. Графический редактор Paint, диалог изменения размеров рисунка, ширина рисунка. В это поле допускается вводить только цифры, при попытке ввести другие символы выдаётся сообщение об ошибке:
Однако, проявив смекалку, можно обойти эту валидацию вводимых символов: через буфер обмена удаётся вставить в это поле отрицательное число, несмотря на то, что минус является недопустимым символом:
Впрочем, это не приводит к негативным последствиям, потому что на следующем уровне стоит ещё одна проверка, которая срабатывает при нажатии кнопки OK:
Есть и другие ограничения для этого поля, которые тоже проверяются после нажатия кнопки OK:
А вот находящееся совсем рядом в том же диалоге поле для ввода наклона рисунка не содержит валидации символов, несмотря на то, что это тоже числовое поле. Более того, при вводе недопустимых символов после нажатия OK можно увидеть вот такое странное сообщение, практически не поддающееся расшифровке:
Все вышеописанные примеры связаны с проверкой отдельно взятого поля. Пример валидации комбинации полей можно найти в том же приложении, но в другом месте — в диалоге настройки параметров страницы для печати. Если указать размеры полей страницы так, чтобы в сумме они превосходили ширину страницы, получим вот такое сообщение:
Ну и, наконец, в заметке «Почему не хватает памяти, чтобы уменьшить размеры рисунка?» описана ошибка, связанная с тем, что в этом графическом редакторе отсутствует корректная обработка сбоев и откат транзакции при слишком сильном увеличении размера рисунка.
Тестировщику необходимо все эти ситуации отрабатывать. Во-первых, нужно проверять валидацию на всех уровнях. Во-вторых, нужно проверять согласованность валидаторов на разных уровнях. В-третьих, надо искать пути обхода валидаторов, пытаясь добраться до следующего уровня без предварительных проверок.
Заключение
Большая часть этой статьи посвящена не способам тестирования валидаторов, а описанию их устройства. Почему? Потому что врага надо знать в лицо. Чтобы найти дефект валидации данных, надо понимать, где искать и на что обращать внимание.
P.S. Кросспост
Отображение ошибок валидации
Отображение ошибок валидации
Последнее обновление: 31.10.2015
Для отображения сообщений об ошибках при валидации модели мы можем использовать хелпер Html.ValidationSummary:
@using (Html.BeginForm()) {
@Html.ValidationSummary(true)
<div>
@Html.LabelFor(model => model.Name)
</div>
<div>
@Html.EditorFor(model => model.Name)
@Html.ValidationMessageFor(model => model.Name)
</div>
<div>
@Html.LabelFor(model => model.Author)
</div>
<div>
@Html.EditorFor(model => model.Author)
@Html.ValidationMessageFor(model => model.Author)
</div>
<div>
@Html.LabelFor(model => model.Year)
</div>
<div>
@Html.EditorFor(model => model.Year)
@Html.ValidationMessageFor(model => model.Year)
</div>
<p>
<input type="submit" value="Create" />
</p>
}
В данном случае сообщения об ошибках выводятся над полями для ввода значений свойств:
Но данный хелпер имеет перегруженные версии, которые помогают настроить более точное отображение сообщений об ошибках:
Перегруженная версия | Описание |
| Отображает общий список ошибок сверху |
| Если параметр равен |
| Данная перегруженная версия хелпера отображает перед списком ошибок сообщение, которое передается в параметр string |
| Сочетает две предыдущие перегруженные версии |
Также мы можем использовать хелпер Html.ValidationMessageFor для вывода сообщения об ошибке для отдельного свойства, причем рядом с полем для ввода свойства, а не в сводке ошибок сверху:
@Html.ValidationSummary(true) <div> @Html.LabelFor(model => model.Name) </div> <div> @Html.EditorFor(model => model.Name) @Html.ValidationMessageFor(model => model.Name) </div> <div> @Html.LabelFor(model => model.Author) </div> <div> @Html.EditorFor(model => model.Author) @Html.ValidationMessageFor(model => model.Author) </div>
Стилизация ошибок
Еще один важный момент отображения ошибок - это их стилизация. То, что мы видим ошибки в красном цвете и границы полей ввода также в красном цвете, не жестко установлено, и мы все это можем изменить. В файле стилей Site.css в проектах, созданных по шаблону Basic и Internet Application, мы можем найти секцию стилей, которая как раз и отвечает за стилизацию (при использования проекта по типу Empty нам самим придется добавить стили):
/* Styles for validation helpers
-----------------------------------------------------------*/
.field-validation-error {
color: #f00;
}
.field-validation-valid {
display: none;
}
.input-validation-error {
border: 1px solid #f00;
background-color: #fee;
}
.validation-summary-errors {
font-weight: bold;
color: #f00;
}
.validation-summary-valid {
display: none;
}
Это классы используются полями, генерируемыми хелперами валидации. И изменяя данные стили, мы можем управлять отображением ошибок.
Итак, изменим два стиля - стиль класса .field-validation-error (он управляет отображением ошибок рядом с текстовыми полями) и
стиль класса стиль класса .input-validation-error, который управляет отображением поля ввода в режиме ошибки:
.field-validation-error {
color: #6699CC;
font-weight:bold;
text-decoration:underline;
}
.input-validation-error {
border: 1px solid #006699;
background-color: silver;
}
В итоге при возникновении ошибок валидации мы увидим следующую картину:
Развитие валидации форм / Habr
Валидация форм была педантичным занятием с момента появления web. Первой пришла серверная валидация. Затем она развилась в валидацию на стороне клиента для проверки результатов в браузере. Теперь у нас есть такие гиганты как HTML5 и CSS3: глава о формах HTML5 предлагает нам новые типы для input полей и атрибуты, которые делают возможным проверку ограничений поля. Базовый UI модуль CSS3 предоставляет несколько псевдо-классов, которые помогают нам стилизовать состояние валидности и менять внешний вид поля в зависимости от действий пользователя. Давайте взглянем на комбинацию обоих для создания валидатора форм основанного на CSS, который имеет достаточно широкую поддержку браузеров.
Чем больше мы можем дать подсказок пользователю, как правильно заполнять форму, в процессе заполнения, тем меньше шансов, что он сделает ошибку. Взгляните на пример CSS3 валидации форм в браузере поддерживающем CSS3 UI псевдо-классы, например Chrome 4+, Safari 5+ или Opera 9.6+. Я использовал CSS3 UI псевдо-классы и HTML5 атрибуты форм для создания валидации основанной на CSS. Давайте посмотрим как это работает.
CSS3 UI псевдо-классы
UI модуль содержит несколько псевдо-классов, которые помогают стилизовать поля формы в зависимости от их состояния.
- valid
- invalid
- required
- optional
- in-range
- out-of-range
- read-only
- read-write
В демо, показанном выше, я использовал псевдо-классы
required, invalid и valid для выполнения проверки.input:focus:required:invalid {
background: pink url(ico_validation.png) 379px 3px no-repeat;
}
input:required:valid {
background-color: #fff;
background-position: 379px -61px;
}
* This source code was highlighted with Source Code Highlighter.Так как мы хотим обозначить, что поле является не валидным только когда активно, мы используем псевдо-класс
focus, чтобы вызвать стиль invalid для поля (Естественно, обозначать все обязательные поля как не валидные с самого начала будет плохим дизайнерским решением).Для привлечение внимания к обязательным полям, не прошедшим проверку, вызывается стиль показывающий иконку с восклицательным знаком, который предупреждает пользователя о том, что что-то должно быть введено. После проверки поля, если оно проходит ограничения, вызывается псевдо-класс valid. Теперь мы удаляем псевдо-класс focus, чтобы зеленая галочка, обозначающая валидность поля, осталась.
Все значения псевдо-классов, перечисленных выше, говорят сами за себя. Псевдо-классы in-range и out-of-range должны использоваться в сочетании с атрибутами min и max, будь то поле input[type=range] или любое другое поле принимающее эти атрибуты. Например, если пользователь вводит значение, выходящее за ограничения, мы можем использовать псевдо-класс для изменения стиля, учитывающий это состояние. Кроме того, мы можем сделать то же самое в случае попадания значения в диапазон ограничений.
В данный момент псевдо-классы range поддерживает только Opera. В ближайшее время поддержка появится и у других браузеров.
Дополнительные типы и атрибуты помогающие нам
В HTML5 формы, также внедрены новые типы
input, такие как email, url и number. К примеру email вызывает псевдо-класс valid когда пользователь вводит корректный e-mail адрес, тоже самое происходит и для полей numer и url. Проверка поля url отличается в разных браузерах. В Opera набрав "http://" поле обозначается валидным, в Crome "http://w", а в Safari, просто набрав "http:".Есть еще несколько атрибутов помогающих в проверке поля, такие как placeholder, required, maxlength, pattern, min, max и step.
<input name="postcode" type="number" min="1001" max="8000" maxlength="4" required />
* This source code was highlighted with Source Code Highlighter.Поле postcode использует новый тип
number и несколько новых атрибутов. В Австралии почтовый индекс может состоять, только из 4 цифр, поэтому мы устанавливаем атрибут maxlength, чтобы ограничить его. Мы так же хотим ограничить максимальное и минимальное значение индекса, для этого используются атрибуты min и max. Атрибут required говорит сам за себя(обязательное поле). Мы можем использовать атрибут step, для большего ограничания совместно с min и max. По умолчанию step установлен в единицу. Поэтому любое число установленное в диапазоне между min и max является валидным. Если изменить значение step на 100, то будет проверяться значение в границах от min до max с шагом 100. Например атрибут step будет валиден при значениях поля 1001, 1101, 1201, 1301 и тд.
Поиск образца
Чтобы вызывать псевдо-класс
invalid у поля с более специфичными ограничениями, например у поля номер телефона, мы можем использовать атрибут pattern, который позволяет применять регулярные выражения для проверки значения поля.<input type="tel" name="tel" pattern="\d{10}" placeholder="Please enter a ten digit phone number" required />
* This source code was highlighted with Source Code Highlighter.В данном примере, регулярное выражение очень простое, «Я принимаю только 10 цифр и ничего больше». Таким образом, поле будет невалидным, пока не выполнится регулярное выражение. Обратите внимание, что я использовал атрибут placeholder, чтобы дать подсказку пользователю.
В реальности мы можем задать более мощные условия в значение атрибута pattern, путем добавления, более сложных регулярных выражений, например для поля пароль:
<input name="password" type="password" title="Minimum 8 characters, one number, one uppercase and one lowercase letter" required pattern="(?=^.{8,}$)((?=.*\d)|(?=.*\W+))(?![.\n])(?=.*[A-Z])(?=.*[a-z]).*" />
* This source code was highlighted with Source Code Highlighter.Теперь мы имеем более строгие ограничения, что позволяет заставить пользователя ввести более безопасный пароль. Пароль должен быть не менее 8 символов, содержать одно число, одну строчную и одну заглавную букву.
Чтобы помочь пользователю, мы используем атрибут title. Мы не используем атрибут placeholder в данном случае, так как он предназначен только для коротких сообщений.
Добавление полезных советов
Если пользователь не наведет курсор на поле, он никогда не увидит дополнительных инструкций в атрибуте
title. Вы можете заметить, что для полей phone, postcode и password появляются полезные подсказки, это помогает, когда пользователь нуждается в дополнительных инструкциях.<input type="password" />
<p>
<span>Minimum 8 characters, one number, one uppercase letter and one lowercase letter</span>
<span>Your password meets our requirements, thank you.</span>
</p>
* This source code was highlighted with Source Code Highlighter.Разметка выше, содержит дополнительные контейнеры для обоих состояний — поле валидно и не валидно. Таким образом, когда поле не валидно, оно будет содержать информацию, которая поможет пользователю ввести корректные данные. Когда все верно, наше сообщение и зеленая галочка убеждают его в том, что поле заполнено верно.
.validation01 {
background: red;
color: #fff;
display: none;
font-size: 12px;
padding: 3px;
position: absolute;
right: -110px;
text-align: center;
top: 0;
width: 100px;
}
input:focus + .validation01 {
display: block;
}
input:focus:required:valid + .validation01 {
background: green;
}
input:focus:required:valid + .validation01 .invalid {
display: none;
}
input:focus:required:invalid + .validation01 .valid {
display: none;
}
* This source code was highlighted with Source Code Highlighter.Чтобы показать или скрыть подсказку, в зависимости от состояния поля, мы можем указать полю цепочку псевдо-классов с добавлением соседнего элемента, содержащего нужную подсказку. После того, как поле было заполнено верно цвет фона изменяется на зеленый и показывается соответствующее сообщение.
UX проблемы этого подхода
Существует одна главная проблема в использовании псевдо-класса invalid, когда поле является обязательным и существуют дополнительные условия, которые должны быть выполнены. Например когда поле обязательное и его тип email, оно будет не валидно, пока все его условия не выполнены и будут использоваться стили для
invalid с самого начала, еще до того, как пользователь ввел что либо. Вот почему мы использовали псевдо-класс focus, что бы показать стили invalid, только когда это поле в фокусе. Это не оптимальное решение: если пользователь уходит из этого поля, не выполнив требования валидатора, не будет показано, что данные введены не корректно, до тех пор, пока он не вернется к редактированию этого поля.Решением этого былобы добавление неопределенного псевдо-класса, доступного для radio и checkbox input. Технически, поля имеющие больше условий, чем просто required, пока пусты не являются ни валидными, ни не валидными, а скорее неопределенными. Эта идея может исправить состояние invalid и позволит применять оптимальные стили для полей в зависимости от состояния валидации.
Кроме того, мы можем сделать некоторую довольно большую функционатьность без JavaScript. Мы можем сказать какое состояние у поля если оно в фокусе, если требуется, сказать ему соответствовать определенному шаблону, заданному в регулярном выражении, указать минимальные и максимальные значения и многое другое. Но что если этого не достаточно? Что если мы хотим большего? К счастью глава о формах HTML5 так же определяет API проверки ограничений валидации.
API проверки ограничений валидации
Наряду со всеми новыми атрибутами, типами input и CSS3 псевдо-классами, глава о HTML5 формах, так же определяет простой JavaScript API, что позволяет расширять возможности валидации форм несколькими полезными встроенными методами, атрибутами и событиями. Давайте взглянем на обновленное демо, которое подключает API для проверки ограничений валидации.
Каждое поле формы имеет новый атрибут validity. Атрибут validity возвращает объект ValidityState, который предоставляет текущее состояние валидности. Объект ValidityState содержит несколько булевых переменных, которые определяют какое состояние у определенного элемента. В основном их ответы это true/false которые дают возможность разработчику понять что не так с полем:
- valueMissing
Этот атрибут возвращает true, если обязательное поле пустое. - typeMismatch
Распространяется на новые типы input. Например, если значение email не корректно, этот атрибут возвратит true. - patternMismatch
Если элемент содержит атрибут pattern и его значение не соответствует условиям регулярного выражения, атрибут вернет true. - tooLong
Если значение какого либо элемента превышает его maxlength, этот атрибут вернет true. - rangeUnderflow и rangeOverflow
Если значение элемента выходит за пределы атрибутов min или max, то этот атрибут вернет true. - stepMismatch
Когда элемент с атрибутом step не соответствует требуемому значению, этот атрибут вернет true. - valid
Если любое из вышеперечисленных значений возвращает true, то этот атрибут вернет false. В противном случае, если все условия выполнятся, то вернет true.
Это еще не все
Событие
invalid несет еще одну полезную функцию. Он будет вызываться полем, пока его значение будет оставаться невалидным. Так что, с его помощью, мы можем изменять стили полей в соответствии с их текущим состоянием.Кроме того, метод checkValidity() может быть выполнен на любом отдельном поле или формы в целом, вернув true или false.
Применим к демо
Давайте возьмем наше предыдущее демо и улучшим его при помощи API проверки ограничений валидации. Принимая то, что мы узнали от Luke Wroblewski в статье Inline Validation in Web Forms и наши собственные данные, мы можем применить эти идеи в нашей демо форме, чтобы создать оптимальный валидатор.
Первое, что мы можем исправить — это мгновенная стилизация для не валидного поля. Вместо того, чтобы сразу изменить стиль поля, показывая, что пользователь вводит некорректные данные, мы ждем пока пользователь уйдет из поля.
Если данные отвечают требованиям, даже в то время когда поле в фокусе, мы позволим пользователю узнать, что поле валидно. Мы делаем это путем добавления для input события для проверки валидности поля. Если все верно, то мы обновляем стили и показываем результат сразу.
Если поле имеет некорректное значение, а пользователь переходит к следующему полю, событие blur проверит валидность поля, а потом применит invalid стили. Для того, чтобы пользователь мог знать об ошибке. Это сохранит отображение стилей ошибок, до их исправления.
Что насчет старых браузеров?
Во всех топиках обсуждаются новинки и поддержка современных браузеров, все это хорошо, но двайте не будем забывать о реальном мире, где мы должны поддерживать и устаревшие браузеры. Для этого я написал скрипт помогающий это делать.
Для браузеров не поддерживающих HTML5 формы и API проверки ограничений валидации скрипт эмулирует эту функциональность. Для браузеров поддерживающих эту функциональность, скрипт определит наличие поддержки и выполнится функциональность средствами браузера. Давайте взглянем на очередное обновление демо с добавленным скриптом. Проверьте в IE или Firefox, чтобы увидеть функциональность скрипта, такую же как у браузеров поддерживающих нужную функциональность.
Поддержка браузерами
Скрипт протестирован и работает в следующих браузерах:
- IE6+
- Firefox 1+ — FF4 будет иметь встроенную поддержку;
- Chrome 4+ — Встроенная поддержка;
- Safari 3.2+ — Safari 5 имеет встроенную поддержку;
- Opera 9.6+ — Встроенная поддержка.
Функции эмулируемые скриптом:
- Каждое поле имеет объект
validity, который дает возможность узнать текущее состояние; - Доступен метод
checkValidity()указывающий что форма или какой то отдельный элемент не валиден; - Поддержка атрибутов
placeholder,required,min,maxиstep; - Поддержка атрибутов
placeholderиrequiredдляtextarea; - Поддержка атрибура
requiredдля элементаselect; - Типы email и
urlдляinputбудут проверяться с помощью встроенного регулярного выражения.
Изобилие проверок
Поддержка браузерами HTML5 форм и моделя CSS3 UI начинает улучшаться. Opera9 продолжит поддержку Web Forms 2.0 пока они не будут объединены с HTML5 формами. В Chrome появилась поддержка с версии 4, Safari получил ее недавно с выходом версии 5, Firefox должен добавить поддержку в предстоящей бета-версии 4 и IE9, если они продолжат свое развитие в таком темпе, тоже должен получить поддержку.
Мы можем сделать удивительные вещи при помощи соответствующих разделов CSS3 и HTML5. Все браузеры улучшают поддержку и такой способ проверки форм становится жизнеспособным, способным проверять любые простые или сложные формы.
