Html form email required

Validating email addresses

One of the new values to the type attribute is email. Using this type of field instead of the regular text field the browser uses a regular expression to check that the user has in fact typed in an email address. Does this means that the user cannot type in a fake email address? No. But you do not have to worry that the user types in a comma instead of a period or that she accidentally types a space. No matter what the user is going to submit, it is going to look like an email address. Here is how it looks:

Some browsers only look for the @ and other browsers look for at pattern consisting of a @ followed by at least one letter and a dot.

As of right now, this is not supported by e.g. Internet Explorer 9.0 and previous version or by the Android browser. This means that in order to have valid email validation for these browsers you will have to make a work-around to have this feature working in all browsers. This does not mean that you should not implement the attribute email, because if the browser does not regocnize type=»email» it will just treat is as type=»text» and render it as plain text.

Using patterns to validate email addresses

Another way to validate email addresses is to use the pattern attribute. As mentioned in the chapter about patterns, the pattern can be anything you specify and it is based on regular expressions. I will not go further into the subject of regular expressions as this is a very comprehensive subject.

All you need to know to use patterns to validate email addresses is which pattern to use. The following HTML5 email address regular expression is close to a complete example of what your pattern could look like. (Thanks to Gervase Markham). Here is what the pattern looks like:

As you can see the pattern is pretty intricate, but basically it checks whether or not the user input looks like a normal email address such as janedoe@unknown.com

Type=»email» or pattern?

As both ways of validating email addresses has their pros and cons it is up to you to decide which one to use. You should not try to use them both at the same time as this might induce a clash in browsers that support both features. Using type=»email» has the advantage that it is semantically correct both using the pattern attribute has the advantage that there are several easy-to-use polyfills on the web which ensures support for a greater range of audience.

What you have learned

• Using HTML5 the semantically correct way of validating email addresses is to set the type attribute to email, type=»email»
• Not all browsers look for the same pattern when validating email addresses
• You can also use the pattern attribute to validate email addresses
• The type=»email» ensures semantically correct HTML5 where as the pattern attribute might ensure a valid email address more frequently
• The pattern attribute can be supported using a polyfill

Is your preferred language not on the list? Click here to help us translate this article into your language!

Источник

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

Несколько месяцев назад, Sandeep представил на всеобщее обозрение HTML Constraint API , показав, как можно использовать новые HTML5-элементы ввода и их атрибуты для валидации форм с минимальным использованием JavaScript.

В этой статье, я собираюсь разобрать валидацию на примере простой формы заказа, используя Constraint API, сделав акцент на том, чтобы не снизить удобства использования.

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

Строго говоря, вам следует использовать HTML5 DOCTYPE, иначе HTML-валидатор выдаст ошибки на странице. Но хорошая новость состоит в том, что новые функции имеют обратную совместимость. Если, к примеру, какой-нибудь старый браузер их не поддерживает, то это не « сломает » всю HTML-страницу – неподдерживаемые элементы будут отображены как .

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

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

 
 
Booking Details
 
Name (required):  
 
Email (required): 
Website: 
No. of Tickets (required): 
 

В данном примере каждый тег ассоциирован с тегом . Атрибут for тега сравнивается со значением атрибута id соответствующего тега . Это позволяет однозначно присвоить значения меток (тегов ) нужным элементам ввода. Также, это означает, что если вы кликните на метке, то соответствующий элемент ввода получит фокус.

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

Я также использовал WAI ARIA атрибут aria-describedby , который помогает пользователям с ограниченными возможностями ввести свое имя в правильном формате.

Это отображается, когда поле ввода получает фокус, предоставляя контекстно-зависимую справку:

Чтобы провести валидацию этой формы, нам необходимо:

• Проверить заполнены ли обязательные поля;
• Убедиться, что значение поля с именем является именно именем;
• Проверить формат введенного email-адреса;
• Проверить, чтобы введенный URL-адрес соответствовал формату;
• Убедиться, что было указано количество билетов.

Обязательные поля

Валидация обязательных полей на предмет их правильного заполнения, не сложнее добавления для поля ввода атрибута required . В нашем случае, это поля Name, Email и Number of Tickets. Например, поле Name с изменениями будет выглядеть так:

Если мы попытаемся отправить данную форму, не заполнив всех обязательных полей, браузер оповестит о необходимости это сделать:

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

Предупреждение: не все браузеры имеют поддержку атрибута required, поэтому в некоторых комбинациях « браузер/программа чтения с экрана » могут возникать ошибки. Поэтому, на данный момент лучшей практикой будет указание атрибута aria-required=”true” :

Валидация данных

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

Нам нужно, чтобы содержимое поля ‘Name’ имело формат ‘ Firstname Lastname ‘ и включало в себя только буквы и пробелы (в реальных сценариях, возможно, нужно будет принять во внимание и другие символы).

Этого можно достичь, добавив атрибут pattern к полю ‘Name’, установив его значение в виде регулярного выражения, которое описывает правило, которому должны соответствовать вводимые данные:

При использовании атрибута pattern, символы ^ и $ зарезервированы для начала и конца регулярного выражения и не должны в него включаться.

Вы можете помочь пользователю, использовав атрибут 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 :

input:valid, input:in-range < background:hsl(120, 50%, 90%); border-color:hsl(120, 50%, 50%); >input:invalid, input:out-of-range

Ранее, я заметил, что определенные сочетания « программа чтения с экрана/браузер » ведут к двойному прочтению атрибутов title и aria-describedby.

Что ж, одним из способов обойти это препятствие является удаление атрибута title из тега элемента ввода и использование CSS3-псеводкласса :invalid, чтобы показать текст атрибута aria-describedby:

input:focus + .help, input:invalid + .help

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

После всех манипуляций HTML-код должен выглядеть так:

 
 
Booking Details
 
Name:  
 
Email: 
Website: 
No. of Tickets: 
 

Отключение встроенной в браузер валидации

Вы можете отключить встроенную в браузер валидацию, добавив атрибут novalidate к тегу :

Кроссбраузерность

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

Плохая же новость заключается в частичной поддержке в настольной версии Safari и её отсутствии во всех браузерах iOS Safari и в стандартных браузерах для Android. Если вам нужна поддержка старых версий IE (ниже версии 10), то там вы ее также не обнаружите.

Что же можно сделать, если требуется поддержка браузеров, которые не имеют встроенных средств валидации?

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

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

Третий подход подразумевает использование JavaScript для обнаружения поддержки валидации форм в браузере, и, если таковая имеется, то использовать её; в противном же случае обратиться к JavaScript-валидации.

Библиотеки наподобие Modernizr могут помочь обнаружить поддержку HTML5, но вы всегда можете написать собственный код, если не хотите подключать стороннюю JavaScript-библиотеку:

// Без Moderizr var inputElem = document.createElement('input'); if (!('required' in inputElem)) < // JavaScript-валидация формы >. // С Modernizr if (!Modernizr.input.required) < // JavaScript-валидация формы >

Заключение

В этой статье мы обзорно изучили использование HTML5-валидации форм на стороне клиента, приведя пример её применения в форме заказа, и при этом мы не пользовались средствами JavaScript.

Также мы указали на некоторые вопросы, связанные с реализацией поддержки для людей с ограниченными возможностями, которые стоит иметь ввиду.

Также, было рассмотрено использование новых CSS3-псеводклассов для отображения визуальных подсказок о том, какие поля обязательны к заполнению, а какие нет, какие поля заполнены правильно, а какие — нет.

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

Источник