«Защитой от дурака» называется комплекс мер по пресечению ввода неправильной информации в форме. Например, если в поле требуется ввести положительное число от 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. Предупреждение о неправильных данных
Шаблон ввода
Табл. 1. Регулярные выражения
Шаблон
Описание
^[a-zA-Z]+$
Любые латинские буквы.
^[ 0-9]+$
Любое количество цифр.
\d<1,3>\.\d<1,3>\.\d<1,3>\.\d
IP-адрес.
5
Почтовый индекс.
\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 тега
От автора: приветствую вас, дорогие читатели, на нашем блоге о сайтостроении. Продолжаю тему спецификации 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 обязательные поля формы достаточно отметить этим атрибутом, никаких скриптов применять не нужно. Если бы это поддерживалось во всех браузерах, то были бы вообще прекрасно.
HTML-формы являются элементами управления, которые применяются для сбора информации от посетителей веб-сайта.
Веб-формы состоят из набора текстовых полей, кнопок, списков и других элементов управления, которые активизируются щелчком мыши. Технически формы передают данные от пользователя удаленному серверу.
Для получения и обработки данных форм используются языки веб-программирования, такие как PHP, Perl.
HTML5-формы решили большинство этих распространенных проблем благодаря наличию новых атрибутов, предоставив возможность изменять внешний вид элементов форм за счет CSS3.
Рис. 1. Улучшенные веб-формы с помощью HTML5
Создание HTML5-формы
2. Группировка элементов формы
3. Создание полей формы
Элемент создает большинство полей формы. Атрибуты элемента отличаются в зависимости от типа поля, для создания которого используется этот элемент.
4. Текстовые поля ввода
Таблица 4. Атрибуты элемента
7. Кнопки
Кнопки позволяют пользователям передавать данные в форму, очищать содержимое формы или предпринимать какие-либо другие действия. Можно создавать границы, изменять фон и выравнивать текст на кнопке.
В этой статье, я собираюсь разобрать валидацию на примере простой формы заказа, используя 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-валидации форм и обнаружении поддержки этой возможности в различных браузерах.
Привет, я Антон, UX-дизайнер в eLama — платформе для автоматизации интернет-рекламы. Мы довольно часто работаем с формами. Раньше мы выделяли обязательные поля, но увидели мнение, что этот подход не самый правильный. Мы решили разобраться, а как правильно, но быстро поняли, что единых правил нет: кто-то делает акцент на обязательных полях, кто-то, наоборот, говорит, что некоторые поля можно пропустить. Попробуем сравнить самые распространенные подходы.
Все делают по-разному
Самые распространенные способы
1. Отмечать обязательные поля звездочкой
➕ Занимает мало места.
➖ Обычно обязательных полей больше, чем необязательных, поэтому визуального шума тоже больше.
➖ Требуют расшифровки в коде для скринридера.
2. Подписывать необязательные поля
➕ Скорее всего, таких отметок будет немного, а значит, визуального шума будет меньше, чем от звездочек.
➕ Мы не давим на пользователя и не принуждаем его заполнять поля. Наоборот, мы экономим его время, показывая ему, что некоторые поля можно пропустить.
➖ Отметка может потеряться на фоне заголовка, и пользователь может ее не увидеть.
➖ Неочевидно, что поля в верхней части формы нужно заполнить обязательно. Пользователь может понять это, только когда увидит необязательные поля.
3. Вообще не отмечать поля, а показывать ошибки при отправке формы
➕ Отсутствие визуального шума. Особенно это важно в больших формах.
➖ Не всем понравится заполнять форму повторно после того, как она загорится красным.
➖ Не сразу понятно, какие поля можно пропустить, а какие нет.
4. Отмечать обязательные поля звездочкой, а необязательные —подписывать
➕ Согласно этому исследованию, такие формы самые удобные: пользователь сразу видит, какое поле пропустить можно, а какое нет.
➖ В больших формах такие отметки создают визуальный шум.
➖ Требуют расшифровки в коде для скринридера.
Важно: ставить обязательные поля выше необязательных
Если пользователь не заметит отметки, он скорее заполнит верхние поля. Если форма разбита на смысловые группы, в каждой из них обязательные поля должны быть выше, чем необязательные.
Как делаем в eLama
Мы решили использовать четвертый способ, потому что удобство пользователя важнее, и это преимущество перевешивает недостатки подхода.
Так обязательное поле не теряется даже в большой форме
Но в некоторых случаях мы используем и третий способ.
Когда не ставим отметки
1. Если поле одно
Чтобы разблокировать кнопку, можно сделать только одно: заполнить поле
2. Если можно заполнить любое поле
Кнопка разблокируется, если заполнить любое из полей
Вместо заключения
Кроме этих способов наверняка есть и другие. Важно выбрать один-два подхода, которые подходят вашему продукту.
Спасибо Сергею Токареву и Елене Отроковой за помощь в подготовке материала и редактуру.
Рис. 1. Улучшенные веб-формы с помощью HTML5
Все делают по-разному