Проверка ограничений

Проверка ввода данных

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

Пример: для программ типа калькулятора нужно вводить числа, чтобы производить с ними различные вычисления и нужна проверка (валидация) на то, что пользователь ввёл числа, а не буквы или символы.

Для ввода данных служит элемент input, у него и будем проверять валидацию.

Валидация input через HTML происходит с помощью атрибута pattern.

Время на прочтение

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

Давайте попробуем собрать стандартную форму, которая будет включать в себя: Имя, E-Mail, Телефон, Ссылку на сайт и допустим Ваш рост, чтобы поэксперементировать с числовым полем.

jQuery Validate требует знаний javascript и jQuery. Хотя понятно, что тут можно запрограммировать HTML-форму как угодно.

Но нам нужен был простой инструмент для веб-мастера, где можно было просто задавать дополнительные атрибуты тегов input, select, а вся функциональнасть подключалсь автоматически. Вот мы и написали библиотеку ITForms.class.js. Библиотека бесплатная и активно развивается. Вот что уже сейчас поддерживается:

Посмотреть как все это работает в действии и загрузить библиотеку можно на сайте itforms.ru

Будем рады замечаниям и предложениям.

— Важное дополнение!

1. Всем еще раз большое спасибо за замечания, многие я уже реализовал. На очереди введение базовых типов.

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

В планах есть добавление языков. Но сначала хочется алгоритм отладить, чтобы код не загромождать.

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

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

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

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

Хотя мобильные браузеры Safari для iOS и Android не поддерживают проверку, предоставление этими браузерами специализированных клавиатур является значительным удобством, поэтому в приложениях для этих веб-обозревателей стоит использовать специальные типы данных.

Интерактивные веб-сайты и приложения невозможно представить без форм, которые позволяют нам общаться с нашими пользователями и получать данные, необходимые для обеспечения гладких сделок с ними. В то время как мы можем улучшить удобство и простоту использования наших форм с удачно выбранным шаблоном проектирования UX. H TML5 также имеет собственный механизм для ограничения проверки, который позволяет нам поймать ошибки ввода прямо на фронт энде.

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

Валидация в HTML5

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

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

Кроме тех типов входных данных, которые уже существовали до HTML5 (text, password, submit, reset, radio, checkbox, button, hidden), мы можем также использовать следующие смысловые HTML5 типы: email, tel, url, number, time, date, datetime, datetime-local, month, week, range, search, color.

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

Пара примеров атрибутов для валидации

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

1) required
Required является самым известным атрибутом в валидации HTML. У него не может быть значения. Просто теги, которые использует этот атрибут, не должны быть пустыми.

Он может быть использован в следующих инпутах: url, email, text, password, date, month, week, tel, search, select, textarea, file, checkbox, time, number. Например, пользователь может забыть ввести значение в поле ввода. В этом случае сообщение об ошибке будет высвечивается до тех пор, пока это поле не будет заполнено правильно. Поэтому важно всегда визуально обозначать для пользователя поля, обязательные для заполнения.

2) maxlength
Этот атрибут позволяет установить максимальную длину вводимого текста для текстового поля ввода. Maxlength может быть использован в следующих инпутах: textarea, password, url, tel, text и search.

В этом textarea лимит символов будет до 350.

Maxlength не покажет ошибку, но браузер не позволит пользователю ввести больше указанного числа символов. Хорошим примером может быть тег tel — pole для телефонного номера, который не может иметь больше определенного количества символов, или формы обратной связи, где мы не хотим, чтобы пользователи писали сообщения больше определенной длины.

3) max, min
Атрибут min и max могут помочь указывать диапазон между минимальном и максимальном номером. Мы можем использовать эти атрибуты в следующих инпутах: date, time, week, range, number и month. В следующем примере мы можем видеть минимальную и максимальную разницу в возрасте от 18 до 65 лет.

Если пользователь введет возраст до 17 лет или после 66 лет, то он получит сообщение об ошибке, при том что этот запрос не будет отправлен на сервер.

4) step
Атрибут step можно использовать для числового интервала. В следующем примере есть input number где мы указываем минимальный и максимальный год, но мы добавляем step=”4”. Это означает, что при каждом изменении значение будет меняться с шагом 4 года.

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

5) pattern
Атрибут паттерн использует регулярное выражение для валидаций этого поля. Регулярное выражение представляет собой заранее определенный набор символов, которые образуют определенный шаблон. Мы можем использовать его либо для поиска строк, которые следуют шаблону, либо для обеспечения определенного формата, определенного шаблона.

Приведенный ниже пример требует от пользователей ввести пароль, который содержит минимально 8 символов, и включает по крайней мере одну букву и одну цифру:

Заключение

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

For a basic introduction to these concepts, with examples, see the Form validation tutorial.

Note: HTML Constraint validation doesn’t remove the need for validation on the server side. Even though far fewer invalid form requests are to be expected, invalid ones can still be sent such as by bad people trying to trick your web application. Therefore, you need to always also validate input constraints on the server side, in a way that is consistent with what is done on the client side.

Внутренние и базовые ограничения

В HTML основные ограничения объявляются двумя способами:

Типы семантического ввода

Внутренние ограничения для атрибута типа:

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

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

Процесс проверки ограничений

Вызов checkValidity() называется статической проверкой ограничений, а вызов reportValidity() или отправка формы называется интерактивной проверкой ограничений.

Сложные ограничения с использованием API проверки ограничений

Используя JavaScript и Constraint API, можно реализовать более сложные ограничения, например, ограничения, объединяющие несколько полей, или ограничения, включающие сложные вычисления.

Ограничение объединения нескольких полей

Формат почтового индекса варьируется от страны к стране. Мало того, что в большинстве стран разрешен дополнительный префикс с кодом страны (например, D- в Германии, F- во Франции или Швейцарии), но в некоторых странах есть почтовые индексы, состоящие только из фиксированного количества цифр; другие, например Великобритания, имеют более сложную структуру, позволяющую размещать буквы в определенных позициях.

Примечание. Это не комплексная библиотека проверки почтовых индексов, а скорее демонстрация ключевых концепций.

В качестве примера мы добавим скрипт, проверяющий проверку ограничения для этой простой формы:

Почтовый индекс:

Страна :

Швейцария
Франция
Германия
Нидерланды

Сначала напишем функцию, проверяющую само ограничение:

ограничения

«Почтовые индексы Швейцарии должны состоять ровно из 4 цифр: например, CH-1950 или 1950».

«Почтовые индексы Франции должны состоять ровно из 5 цифр: например, F-75012 или 75012»

«Почтовые индексы Германии должны состоять ровно из 5 цифр: например, D-12345 или 12345»

// Читаем идентификатор страны
стоимость документа страны

// Получаем поле NPA
Документ ZIPField

// Создаем средство проверки ограничений
ограничения ограничениястрана
консольное ограничение

// Проверь это!
ограничениеZIPFieldvalue

ZIPField

// выдаем сообщение о формате, необходимом для этой страны
ZIPFieldconstraintscountry

окно
проверка документа на изменениеZIP
проверка ввода документаZIP

Ограничение размера файла перед его загрузкой

Еще одним распространенным ограничением является ограничение размера загружаемого файла. Проверка этого на стороне клиента перед передачей файла на сервер требует объединения API проверки ограничений, и особенно метода field.setCustomValidity(), с другим API JavaScript, в данном случае API файлов.

Вот HTML-часть:

Выберите файл размером менее 75 КБ:

JavaScript считывает выбранный файл, использует метод File.size() для получения его размера, сравнивает его с (жестко запрограммированным) пределом и вызывает Constraint API, чтобы сообщить браузеру о нарушении:

документ
файлы файлы

// Если выбран (хотя бы) один файл
длина файла
размер файла
// Проверяем ограничение
«Выбранный файл не должен быть больше 75 КБ»

// Никаких нарушений пользовательских ограничений

Наконец, мы подключаем метод к правильному событию:

окно
documentonchange checkFileSize

Визуальное оформление проверки ограничений

Внешний вид элементов можно контролировать с помощью псевдоклассов CSS.

Дополнительные псевдоклассы CSS

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

Псевдокласс CSS, отображаемый заполнителем

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

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

CSS3

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

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

Мы можем пойти на небольшую хитрость и использовать псевдокласс :placeholder-shown. С помощью этого псевдокласса мы можем определить отображается ли сейчас значение placeholder в нашем поле ввода. Атрибут placeholder отображается только тогда, когда в наше поле ничего не введено. Соответственно, чтобы применить этот псевдокласс нам просто нужно обратить его свойство с помощью :not. В итоге получаем вот такую конструкцию:

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

У данного метода есть только один минус: поддержка. Псевдоэлемент :placeholder-shown поддерживается во всех браузерах кроме IE и EDGE. К счастью :not не обладает таким недостатком.

Для примера я набросал все вышесказанное в CodePen и добавил еще немного возможностей:

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

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

Специализированная JavaScript-проверка

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

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

Осуществляется это следующим образом. Прежде всего, значение соответствующего поля проверяется на правильность. Это делается с помощью обычного события oninput:

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

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

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

Ползунки

Другим числовым типом HTML5 является range. Подобно типу number, этот тип может представлять целые и дробные значения. Также поддерживает атрибуты min и max для установки диапазона значений. Далее показан пример кода для создания поля этого типа:

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

Чтобы установить значение типа range, нужно просто перетянуть ползунок в требуемую позицию между минимальным и максимальным значениями. Но браузеры, поддерживающие этот тип поля, не предоставляют никакой обратной информации об установленном значении. Чтобы получить эти сведения, в разметку нужно добавить процедуру JavaScript, которая реагирует на изменения положения ползунка (возможно, посредством обработки события onChange), а потом отображает эту формацию рядом с полем.

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

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

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

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

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

А вот эти нет:

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

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

Примеры атрибута «pattern»

Атрибут required делает заполнение поля обязательным.

Атрибуты minlength, maxlength задаёт минимальное и (или) максимальное допустимое количество символов. Например minlength=»6″.

Использование CSS при валидации

Введите число ОТ 10 ДО 999

Введите что нибудь и щёлкните вне элемента INPUT.

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

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

Атрибуты minlength=»2″ maxlength=»3″ следят за тем, чтобы было введено от двух до трёх символов. Один символ, подсветка останется красной. Больше трёх символов ввести не удаться.

При правильном вводе, красная подсветка исчезнет, а введённые числа станут зелёными.

Цвет

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

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

Самый простой путь валидации — это определить тип input поля и расставить атрибуты required которые отвечают за обязательность заполнения.

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

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

Однако, нам на помощь приходит атрибут pattern. Этот атрибут принимает в себя значение регулярного выражения. В нашем случае рассмотрим вариант паттерна для ввода мобильного телефона в РФ: +7 (123) 456-78-91. Для этого добавим простое регулярное выражение в наше поле с телефоном, а также ограничим минимальное и максимальное количество символов:

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

Поддержка браузерами атрибута pattern на данный момент очень хорошая. i OS начиная с версии 10.3 полностью поддерживает данное свойство, до этого наблюдалось отсутствие подсказок о неправильном вводе данных.

Стоит также учитывать, что атрибут minlength до сих пор не поддерживается в браузерах IE, EDGE и только с версии 10.3 появился в iOS. Однако maxlength поддерживается везде и очень давно. Нам в целом хватит и этого.

Давайте также поставим ограничение для поля с ростом. Допустим мы предполагаем, что пользователь нашего сайта определенно не может быть ниже 100 см и выше 250 см. Так и напишем:

С поддержкой этих атрибутов в браузерах, все хорошо.

Перейдем к стилизации!

Поля поиска

Тип search применяется для полей поиска. Они обычно предназначены для ввода ключевых слов, по которым потом выполняется какой-либо вид поиска. Это может быть поиск по всему Интернету (как в Google), поиск по одной странице или же специальная поисковая процедура, которая исследует каталог информации. В любом случае поле поиска выглядит и ведет себя почти точно так же, как и обычное текстовое поле.

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

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

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

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

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

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

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

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

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

Числа

В HTML5 определяются два числовых типа данных. Тип number предназначен для обычных чисел.

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

Конечно же, есть много чисел, которые не подходят для каждого типа числовых данных. Например, в приведенной выше разметке разрешается возраст наподобие 43 000 или -6 лет, что несколько не соответствует реальности. Эта проблема решается с помощью атрибутов min и max. В следующем коде представлен пример ограничения возраста разумным диапазоном:

Обычно поля типа number принимают только целые числа, а дроби, например 30.5 не разрешаются. ( Более того, некоторые браузеры даже не позволят ввести десятичный знак.) Но это поведение также можно изменить с помощью атрибута step, который указывает шаг изменения числа (в большую или меньшую сторону). Например, установив значение step в 0.1, можно вводить такие значения, как 0.1, 0.2 0.3 и т. д. Но попробуйте отправить форму со значением 0.15 и вы получите знакомое всплывающее сообщение об ошибке. По умолчанию значение шага равно 1.

Атрибут step также влияет на работу кнопок поля со счетчиком:

Адреса электронной почты

Тип email поддерживает атрибут multiple, который позволяет вводить несколько адресов в поле. Но эти несколько адресов все равно выглядят, как одна строка текста, только разделены запятыми.

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

Пример валидации на JavaScript

x = document.getElementById(«numb»).value;

Введите число от 1 до 10

Необычный способ проверки валидности email.

Тип url применяется для полей ввода URL-адресов. Вопрос, что является допустимым URL, продолжает горячо обсуждаться. Но большинство браузеров применяет сравнительно нестрогий алгоритм проверки. Адрес должен содержать префикс (который может быть как настоящим, типа http://, так и выдуманным, типа bonk//) и позволяет вводить пробелы и большинство специальных символов, за исключением двоеточия.

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

Дата и время

В HTML5 определяется несколько типов данных, связанных со временем. Браузеры, которые поддерживают типы дат, могут выводить удобный выпадающий календарь, в котором пользователь может выбрать требуемую дату и/или время. Это не только устраняет неопределенность относительно правильного формата даты, но также запрещает случайно (или нарочно) установить несуществующую дату. Интеллектуальные браузеры могут делать еще больше, например поддерживать интеграцию с персональным календарем.

Ниже показан пример использования дат:

В таблице ниже перечислены шесть новых форматов HTML5 для дат и времени, дано их краткое описание:

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

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

Веб-программирование — HTML5 — Валидация форм

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

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

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

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

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

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

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

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

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

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

Несколько необычных атрибутов элемента

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

Некоторые браузеры пытаются заполнить пробелы в знаниях правописания пользователя, проверяя орфографию вводимого текста. Очевидная проблема с этой услугой заключается в том, что не весь текст состоит из настоящих слов, и роспись волнистых красных подчеркиваний может очень быстро начать действовать пользователю на нервы. Чтобы браузер не проверял орфографию текста в поле, присвойте атрибуту spellcheck значение false, а для проверки — значение true.

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

Некоторые браузеры пытаются сэкономить время пользователя, предлагая при вводе информации в поле значения, которые вводились в это поле ранее. Такое поведение не всегда желательно — как указывается в спецификации HTML5, некоторая информация может быть конфиденциальной (например, коды для запуска ядерных ракет 😉 или оставаться актуальной только непродолжительное время (например, одноразовый пароль входа в банковскую систему самообслуживания). Для таких полей установите значение атрибута autocomplete в off, чтобы браузер не предлагал возможных вариантов завершения вводимого в поле текста. А чтобы выполнять автозаполнение для определенного поля, установите значение его атрибута autocomplete в on.

Атрибуты autocorrect и autocapitalize

Эти атрибуты применяются для управления возможностями автоматического исправления и капитализации на некоторых мобильных браузерах, а именно в версиях Safari для iPad и iPhone

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

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

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

required и optional

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

valid и invalid

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

in-range и out-of-range

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

Итог

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