Защита от дурака
«Защитой от дурака» называется комплекс мер по пресечению ввода неправильной информации в форме. Например, если в поле требуется ввести положительное число от 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-адрес. |
| 1 | Почтовый индекс. |
| \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 тега
HTML5: атрибут формы required
Логический атрибут required HTML сообщает браузеру о возможности отправки данных формы только при заполнении обязательных полей. Это значит, что поле нельзя оставить пустым, и что в зависимости от других атрибутов или типов полей приниматься могут только конкретные типы значений. Чуть позже мы поговорим о том, как сообщать браузерам о необходимости отправки определенные типы данных.
В терминологии Javascript событие focus запускает элемент формы, когда на нее переключается фокус, когда фокус переходит на другой элемент или она теряет фокус.
В CSS можно использовать псевдокласс :focus для стилизации элементов, которые выделены в данный момент.
Добавим атрибут HTML input required к форме регистрации. Сделаем поля имени, адреса электронной почты, пароля и даты подписки обязательными:
На скриншотах, приведенных ниже, можно видеть, что делает атрибут required HTML при попытке подтвердить форму:
Сообщение об обязательных полях в Firefox
Та же ситуация в Opera…
Стилизация обязательных полей в форме
В данном случае мы добавляем фоновое изображение ( звёздочку ) к обязательным полям формы. В input-элементы нельзя включать генерируемый контент. Поэтому лучше будет использовать фоновое изображение. Кроме этого валидные и не валидные поля можно выделить разными фоновыми картинками. Изменения будут заметны, только если пользователь выделил соответствующий элемент формы.
Предупреждение : Firefox стилизует не валидные элементы
Подсказка : таргетированная стилизация для устаревших браузеров
Дайте знать, что вы думаете по этой теме в комментариях. За комментарии, отклики, подписки, лайки, дизлайки огромное вам спасибо!
Валидация форм на стороне клиента
Перед отправкой данных на сервер важно убедиться, что все обязательные поля формы заполнены данными в корректном формате. Это называется валидацией на стороне клиента и помогает убедиться, что данные, введённые в каждый элемент формы, соответствуют требованиям. Данная статья проведёт вас через основные концепци и примеры валидации на стороне клиента.
| Начальные требования: | Владение компьютером, достаточное понимание HTML, CSS, и JavaScript. |
|---|---|
| Цель: | Понять, что такое валидация на стороне клиента, почему это важно и как применять различные техники для её реализации. |
Валидация на стороне клиента — это первичная проверка введённых данных, которая существенно улучшает удобство взаимодействия с интерфейсом; обнаружение некорректных данных на стороне клиента позволяет пользователю немедленно их исправить. Если же проверка происходит только на сервере, процесс заполнения может быть более трудоёмким, так как требует повторения одних и тех же действий отправки данных на сервер для получения обратного ответа с сообщением о том, что нужно исправить.
Однако, не следует рассматривать валидацию на стороне клиента как достаточную меру безопасности! Любые данные, отправляемые через форму, необходимо дополнительно проверять на безопасность и на стороне сервера, поскольку валидацию на стороне клиента достаточно просто обойти и она может не остановить злоумышленников. Чтобы лучше понимать потенциальные угрозы, рекомендуем ознакомиться с разделом Безопасность вебсайтов; валидация на стороне сервера выходит за рамки этого модуля, но о ней следует помнить.
Что такое валидация формы?
Зайдите на любой популярный сайт, имеющий форму регистрации. Вы заметите, что при вводе данных в неправильном формате, пользователя сразу уведомляют о наличии проблемы. Вы получите примерно такое сообщение:
Это называется валидацией формы. По мере ввода, браузер и/или сервер проверяют данные, чтобы определить, соответствуют ли они требуемому формату. Валидация, выполняемая в браузере, называется валидацией на стороне клиента, а выполняемая на сервере — валидацией на стороне сервера. В этом разделе мы сосредоточимся на валидации, выполняемой на стороне клиента.
Если формат корректен, приложение позволяет отправить данные на сервер и (обычно) сохранить в базу данных; в противном случае выводится сообщение с описанием того, что нужно исправить, позволяя ввести данные снова.
Мы хотим максимально упростить заполнение веб-форм. Тогда почему мы настаиваем валидации данных? На это есть три основные причины:
Предупреждение:: Никогда не доверяйте данным, передаваемым на сервер клиентской программой. Даже если ваша форма правильно валидируется и не допустит введение потенциально вредоносных данных на стороне клиента, злоумышленники по-прежнему могут изменить сетевой запрос.
Типы валидации на стороне клиента
Существует два типа валидации на стороне клиента, с которыми вы столкнётесь в Интернете:
Использование встроенной валидации форм
Одной из самых важных функций элементов форм HTML5 является способность валидировать бóльшую часть пользовательских данных без использования JavaScript. Это выполняется с помощью атрибутов валидации у элементов формы. Многие из них мы уже рассмотрели в этом курсе:
Если данные, введённые в поле формы, соответствуют правилам перечисленных выше атрибутов, они считаются валидными, если нет — не валидными
Когда элемент валиден, справедливы следующие утверждения:
Когда элемент не валиден, справедливы следующие утверждения:
Примеры встроенной валидации форм
В этом разделе мы протестируем некоторые из атрибутов, которые обсуждали выше.
Простой начальный файл
Для начала скопируйте файл fruit-start.html в новую папку на вашем жёстком диске.
Атрибут required
Обратите внимание на CSS, который включён в файл примера:
Данный CSS задаёт полю красную пунктирную рамку, когда оно не валидно, а когда валидно — сплошную чёрную. Мы также добавили фоновый градиент для обязательных не валидных полей. Проверьте новое поведение в примере ниже:
Примечание: Рабочий пример можно найти на GitHub по адресу fruit-validation.html (отдельно можно найти исходный код.)
Попробуйте отправить форму без введения значения. Обратите внимание, что не валидное поле получает фокус, появляется сообщение об ошибке («Заполните это поле») и блокируется отправка формы.
Примечание: Для повышения удобства взаимодействия указывайте пользователям, какие поля являются обязательными. К тому же, этого требует руководство по обеспечению доступности WCAG. Требуйте обязательного ввода только тех данных, которые вам действительно нужны: например, так ли важно знать пол или должность пользователя?
Валидация с помощью регулярного выражения
Регулярные выражения достаточно сложны и мы не подем подробно рассматривать эту тему в данной статье. Ниже приведены несколько примеров, чтобы дать вам представление о том, как они работают.
Есть еще много возможностей, которые мы не упомянули. Полный список со множеством примеров можно найти в документации по Регулярным выражениям
Давайте рассмотрим пример. Добавьте в атрибут pattern следующий шаблон:
Это даёт нам следующее обновление — опробуйте его:
Примечание: Рабочий пример можно найти на GitHub по адресу fruit-pattern.html (исходный код.)
В этом примере элемент принимает одно из четырёх возможных значений: строку «banana», «Banana», «cherry», или «Cherry». Регулярные выражения чувствительны к регистру, но с помощью шаблона «Aa», вложенного в квадратные скобки, мы сделали поддержку написания слова как с большой, так и с маленькой буквы.
Подставьте в атрибут pattern приведённые выше примеры регулярных выражений, и посмотрите, как это повлияет на валидацию введённого в поле значения. Попробуйте написать свои шаблоны проверки и посмотрите, что получится. По возможности, делайте их связанными с фруктами, чтобы примеры имели смысл.
Примечание: Элемент
Ограничение длины вводимых значений
Можно ограничить максимально допустимое количество символов для текстовых полей или
Ограничение допустимых значений
Давайте рассмотрим другой пример. Создайте новую копию файла fruit-start.html.
Содержимое элемента замените на:
Примечание: Рабочий пример можно найти на GitHub по адресу fruit-length.html (исходный код.)
Полный пример
Ниже представлен полный пример, демонстрирующий использование встроенного функционала валидации. Сначала немного HTML:
И немного CSS для стилизации HTML:
Примечание: Рабочий пример можно найти на GitHub по адресу full-example.html (исходный код.)
Валидация форм с помощью JavaScript
Если нужно управлять внешним видом встроенных сообщений об ошибке или работать с устаревшими браузерами, которые не поддерживают встроенную валидацию форм HTML, вам следует использовать JavaScript. В данном разделе мы рассмотрим различные способы делать это.
Constraint Validation API
Большинство браузеров поддерживают Constraint Validation API, который состоит из набора свойств и методов, доступных на DOM-интерфейсах следующих элементов форм:
Для перечисленных выше элементов Constraint Validation API делает доступными следующие свойства.
Также для перечисленных выше элементов Constraint Validation API делает доступными следующие методы.
Реализация кастомного сообщения об ошибке
Как вы видели в примерах HTML5-валидации выше, каждый раз, когда пользователь пытается отправить не валидную форму, браузер отображает сообщение об ошибке. Способ отображения сообщения зависит от браузера.
У этих автоматических сообщений есть два недостатка:
Настройка таких сообщений об ошибках является одной из наиболее распространённых причин использования Constraint Validation API. Давайте рассмотрим простой пример, как это делается.
Начнём с простого HTML (Не стесняйтесь поместить это в пустой HTML-файл. Вы можете взять за основу свежую копию fruit-start.html, если хотите):
Добавьте на страницу следующий JavaScript:
Здесь мы сохраняем ссылку на поле email, а затем добавляем к нему слушатель события, который запускает код обработчика каждый раз, когда в поле меняется значение.
Попробовать пример можно ниже:
Примечание:: Данный пример можно найти на GitHub по адресу custom-error-message.html (отдельно можно найти исходный код.)
Более подробный пример
Теперь, когда мы разобрали простой пример, давайте посмотрим, как можно использовать данный API для создания более сложной валидацию.
Во-первых, HTML. Опять же, не стесняйтесь писать его вместе с нами:
Примечание: Ключевым моментом здесь является то, что добавление к форме атрибута novalidate отключает отображение встроенных сообщений об ошибке и позволяет вместо этого добавлять в DOM кастомные сообщения.
Перейдём к базовому CSS, чтобы немного улучшить внешний вид формы и обеспечить визуальную обратную связь при введении не валидных данных:
Теперь давайте рассмотрим JavaScript, который реализует кастомную валидацию.
Комментарии объясняют логику хорошо, но кратко:
Примечание: Рабочий пример можно найти на GitHub по адресу detailed-custom-validation.html (отдельно можно найти исходный код.)
Constraint Validation API явяется мощным инструментом валидации форм, позволяющим получить контроль над пользовательским интерфейсом, существенно превосходящий возможности HTML и CSS.
Примечание: Для получения дополнительной информации смотрите руководства Constraint validation guide и Constraint Validation API.
Проверка форм без встроенного API
В некоторых случаях, например, при необходимости поддержки устаревших браузеров или кастомных элементов формы, вы не сможете или не захотите использовать Constraint Validation API. Вы по-прежнему сможете использовать JavaScript для валидации форм, но для этого всё нужно будет писать самостоятельно.
Для создания своего валидатора формы, задайте себе несколько вопросов:
Пример без использования Constraint Validation API
Чтобы проиллюстрировать это дальше приводится упрощённая версия предыдущего примера, которая работает с устаревшими браузерами.
HTML почти тот такой же; мы только удалили функционал валидации HTML5.
CSS также не требует особых изменений; мы только заменили CSS-псевдокласс :invalid на реальный класс и не использовали селектор по атрибутам, так как он не работает в Internet Explorer 6.
Существенно изменился только JavaScript-код, который теперь должен выполнять гораздо больше работы.
Результат выглядит следующим образом:
Как вы можете видеть, сделать собственную валидацию не так уж и сложно. Сложность состоит лишь в том, чтобы сделать его кроссплатформенным и работающим с любой формой, которую можно создать. Для проверки формы доступно множество библиотек, например Validate.js.
Проверьте свои навыки!
Вы дошли до конца этой статьи, но можете ли вы вспомнить самую важную информацию? Вы можете найти дополнительные тесты, чтобы убедиться, что вы сохранили эту информацию, прежде чем двигаться дальше — Test your skills: Form validation.
Заключение
Для проверки формы на стороне клиента иногда требуется JavaScript, если вы хотите настроить стилизацию и сообщения об ошибках, но это всегда требует от вас внимательного отношения к пользователю. Всегда помните о необходимости помогать пользователям исправлять данные, которые они вводят. Для этого обязательно нужно:
После того, как вы убедились, что форма заполнена правильно, ее можно отправлять. Дальше мы рассмотрим отправку данных формы.
Формы в html5. Что появилось нового
Дата публикации: 2016-03-17
От автора: приветствую вас, дорогие читатели, на нашем блоге о сайтостроении. Продолжаю тему спецификации htm5, сегодня я предлагаю поговорить о формах и о том, какие новые возможности появились в этом отношении. К сожалению, на данный момент все еще не все браузеры поддерживают эти возможности, однако html5 формы все равно начинают использовать.
Нововведения
В html5 появилось так много возможностей для расширения функциональности форм, что им бы стоило посвятить отдельный раздел в книге, а не статью. Сегодня же мы рассмотрим лишь некоторые новые возможности.
Новые поля ввода
Появилось очень много новых типов полей. Все они задаются с помощью элемента input с различным type. Некоторые из них:
Type = “email” – с виду это обычное текстовое поле, но на самом деле в него встроена автоматическая валидация. Если браузер не находит знак @, который является основным атрибутом любого email-адреса, то он просто не пропускает такую форму на отправку. Давайте проверим это в последней версии Chrome, где все это отлично поддерживается.
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Создали простейшую форму. Откройте такой код в браузере и вы увидите два абсолютно одинаковых элемента для ввода и кнопку отправки. Что ж, а ну-ка попробуйте ввести во второе поле что-то наобум и отправить форму. Ничего не получится, браузер показывает, что в нем обязательно должен присутствовать значок @.
Вот так вот, и отныне никакой валидации с помощью javascript и не нужно. Это относится к тем браузерам, которые поддерживают html5 в должной мере.
Type = “tel” – для ввода номера телефона. В общем-то, в нем нет такой валидации, но интересно, что если заполнять такую форму с мобильных устройств, то при нажатии на нее может изменится раскладка клавиатуры (будут показываться цифры). То же самое происходит и в случае с type = email.
Type = “color” – сюда ничего вводить не нужно. Интересует нас по той причине, что тут можно выбрать цвет, причем сделать это в интуитивно понятной палитре, такой, как в paint. Вот так это выглядит:
Это, конечно, не является обязательным атрибутом любой формы, но уже сегодня есть много идей по использованию этого элемента.
Конечно, там, где оно не поддерживается, будет выведено обычное поле для текста. В таких браузерах нет смысла выводить его, не будет же пользователь вручную писать, какой он выбирает цвет (а может и будет).
Type = date. Поле для выбора календарной даты. Если оно поддерживается браузером, то появляются очень удобные инструменты, в которых вы можете определить дату, а при клике на треугольничек даже разворачивается календарь.
Собственно, есть такие же поля datetime и datetime-local. Они предназначены для того, чтобы определять в них время (и время с указанием явного часового пояса, соответственно).
Поддержка браузерами
На самом деле я бы мог перечислить здесь еще много таких полей, их действительно появилось много, но нужно сказать и о другом немаловажном факторе – поддержке всего этого добра в браузерах.
В этом плане Google Chrome и Opera подают всем пример, потому что поддерживают абсолютно все новые значения. К сожалению, от них серьезно отстают Mozilla и IE. В Explorer только с десятой версии поддерживаются пару новых полей.
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Выбор обязательных полей
Пожалуй, одна из главных возможностей для валидации формы еще на стороне пользователя. Чтобы пометить поле как обязательное к заполнению, ему нужно дописать пустой атрибут required.
В html5 обязательные поля формы достаточно отметить этим атрибутом, никаких скриптов применять не нужно. Если бы это поддерживалось во всех браузерах, то были бы вообще прекрасно.
Обязательно или нет? Как отмечать поля в формах
Привет, я Антон, UX-дизайнер в eLama — платформе для автоматизации интернет-рекламы. Мы довольно часто работаем с формами. Раньше мы выделяли обязательные поля, но увидели мнение, что этот подход не самый правильный. Мы решили разобраться, а как правильно, но быстро поняли, что единых правил нет: кто-то делает акцент на обязательных полях, кто-то, наоборот, говорит, что некоторые поля можно пропустить. Попробуем сравнить самые распространенные подходы.
Все делают по-разному
Самые распространенные способы
1. Отмечать обязательные поля звездочкой
➕ Занимает мало места.
➖ Обычно обязательных полей больше, чем необязательных, поэтому визуального шума тоже больше.
➖ Требуют расшифровки в коде для скринридера.
2. Подписывать необязательные поля
➕ Скорее всего, таких отметок будет немного, а значит, визуального шума будет меньше, чем от звездочек.
➕ Мы не давим на пользователя и не принуждаем его заполнять поля. Наоборот, мы экономим его время, показывая ему, что некоторые поля можно пропустить.
➖ Отметка может потеряться на фоне заголовка, и пользователь может ее не увидеть.
➖ Неочевидно, что поля в верхней части формы нужно заполнить обязательно. Пользователь может понять это, только когда увидит необязательные поля.
3. Вообще не отмечать поля, а показывать ошибки при отправке формы
➕ Отсутствие визуального шума. Особенно это важно в больших формах.
➖ Не всем понравится заполнять форму повторно после того, как она загорится красным.
➖ Не сразу понятно, какие поля можно пропустить, а какие нет.
4. Отмечать обязательные поля звездочкой, а необязательные —подписывать
➕ Согласно этому исследованию, такие формы самые удобные: пользователь сразу видит, какое поле пропустить можно, а какое нет.
➖ В больших формах такие отметки создают визуальный шум.
➖ Требуют расшифровки в коде для скринридера.
Важно: ставить обязательные поля выше необязательных
Если пользователь не заметит отметки, он скорее заполнит верхние поля. Если форма разбита на смысловые группы, в каждой из них обязательные поля должны быть выше, чем необязательные.
Как делаем в eLama
Мы решили использовать четвертый способ, потому что удобство пользователя важнее, и это преимущество перевешивает недостатки подхода.
Так обязательное поле не теряется даже в большой форме
Но в некоторых случаях мы используем и третий способ.
Когда не ставим отметки
1. Если поле одно
Чтобы разблокировать кнопку, можно сделать только одно: заполнить поле
2. Если можно заполнить любое поле
Кнопка разблокируется, если заполнить любое из полей
Вместо заключения
Кроме этих способов наверняка есть и другие. Важно выбрать один-два подхода, которые подходят вашему продукту.
Спасибо Сергею Токареву и Елене Отроковой за помощь в подготовке материала и редактуру.
