Валидация HTML5 документов


Содержание материала:

Валидация html-документов

Валидация html-документа – это проверка html-документа на соответствие существующим веб-стандартам.

Проверить html-документ на наличие ошибок можно на сайте http://validator.w3.org/. Открываем вкладку Validate by File Upload, нажимаем кнопку Выбрать файл, выбираем html-документ, затем нажимаем кнопку Check:

При написании html кода соблюдайте ряд правил:

  1. Обязательно указывайте тип документа .
  2. Не используйте атрибуты тегов для оформления элементов веб-страницы, они уже давно устарели, и вместо них нужно использовать каскадные таблицы стилей.
  3. Соблюдайте правила вложенности тегов, например, такая запись будет считаться неправильной: Нужно сначала закрыть вложенный тег , затем его родитель :
  4. Не забывайте об обязательных атрибутах.
  5. Строчные элементы не могут содержать в себе блочные. Такая запись будет считаться ошибочной: Правильной будет такая запись:
  6. Не используйте устаревшие теги. Со всеми тегами, входящими в спецификацию пятой версии HTML можно ознакомиться на сайте htmlbook.ru или www.w3schools.com

Видео к уроку

Каскадные таблицы стилей. CSS.

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

Валидация форм через HTML

Для проверки полей формы на валидность средствами HTML используют атрибут pattern. В нем можно указать любое регулярное выражение согласно которому будут проверятся данные в поле.

Синтаксис использования атрибута таков:

Регулярные выражения для распространенных видов данных

Выражение Значение
[A-Za-zА-Яа-яЁё] любая буква
^[a-zA-Z]+$ только латиница
^[a-zA-Z0-9]+$ только цыфры и латинские буквы
^[а-яА-ЯёЁa-zA-Z0-9]+$ цифры+латиница+кириллица
^[ 0-9]+$ только цифры
^\(\d<3>\)\d<3>-\d<2>-\d<2>$ телефон в формате (ХХХ)XXX-XX-XX
/^([a-z0-9_\.-]+)@([a-z0-9_\.-]+)\.([a-z\.]<2,6>)$ email
[0-9]<4>-(0[1-9]|1[012])-(0[1-9]|1[0-9]|2[0-9]|3[01]) дата в формате YYYY-MM-DD
(0[1-9]|[12][0-9]|3[01])[- /.](0[1-9]|1[012])[- /.](19|20)\d\d дата в формате DD/MM/YYYY
^([0-1]\d|2[0-3])(:[0-5]\d)<2>$ время в формате HH:MM:SS
\-?\d+(\.\d<0,>)? целые числа и числа с плавающей точкой с разделителем точкой
^[a-zA-Z][a-zA-Z0-9-_\.]<1,20>$ имя пользователя (с ограничением 2-20 символов, которыми могут быть буквами и цифрами, первый символ обязательно буква)
^(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(. *\s).*$ пароль (Строчные и прописные латинские буквы, цифры)
(?=^.<8,>$)((?=.*\d)|(?=.*\W+))(?![.\n])(?=.*[A-Z])(?=.*[a-z]).*$ пароль (Строчные и прописные латинские буквы, цифры, спецсимволы. Минимум 8 символов)

Ограничение количества вводимых символов

Атрибут maxlength устанавливает ограничение на максимальное количество символов, которые можно ввести в поле:

Markup Validation Service

Check the markup (HTML, XHTML, …) of Web documents

Note: file upload may not work with Internet Explorer on some versions of Windows XP Service Pack 2, see our information page on the W3C QA Website.

Validate by direct input

This validator checks the markup validity of Web documents in HTML, XHTML, SMIL, MathML, etc. If you wish to validate specific content such as RSS/Atom feeds or CSS stylesheets, MobileOK content, or to find broken links, there are other validators and tools available. As an alternative you can also try our non-DTD-based validator.

This service runs the W3C Markup Validator, v 1.3+hg.

Copyright © 1994-2013 W3C ® (MIT , ERCIM , Keio, Beihang), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.

Валидация форм в html5.

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

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

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

Но для начала создадим простую форму содержащую в себе несколько полей: Имя, Телефон, E-mail и кнопку отправить.

Вот она самая простая и не красивая форма, поля которой подразумевают что поле имя — будет введен текст, в поле телефон — телефон(т.е. только цифры) и поле e-mail в которое можно ввести как буквы так и цифры, но с одним условием, там должен присутствовать символ @. Теперь посмотрим как html5 позволит нам справиться с задачей и провалидировать данную форму.

Атрибут required.

Данный атрибут у тега input устанавливает обязательное заполнение поля.

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

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

Атрибут type.

Данный атрибут добавляет стандартные способы валидации для полей. Для поля почты изменим значение на type=»email» а для телефона type=»tel»

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

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

Атрибут pattern.

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

Например для имени —

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

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

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

Использование валидации входных данных

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

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

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

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

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

Проверка входных данных осуществляется при помощи атрибутов. В таблице 14-7 показано, какие элементы (и типы input ) поддерживают атрибуты валидации.

Таблица 14-7: Поддержка валидации входных данных


Атрибут валидации Элементы
required textarea , select , input (типы text , password , checkbox , radio , file , datetime , datetime-local , date , month , time , week , number , email , url , search и tel )
min , max input (типы datetime , datetime-local , date , month , time , week , number и range )
pattern input (типы text , password , email , url , search и tel )

Давайте убедимся, что пользователь ввел значение

Простейшим видом проверки входных данных является получение гарантии в том, что пользователь вообще предоставил значение. Это можно сделать при помощи атрибута required . Пользователь не может отправить форму, пока не введены данные, хотя для этих данных и не установлены никакие ограничения. В листинге 14-6 показано, как используется атрибут required .

Листинг 14-6: Использование атрибута required

В листинге 14-6 я применил атрибут required для трех типов элемента input . Пользователь не сможет отправить форму, пока не предоставит для всех них значения. Для типов text и password это обозначает, что пользователь должен ввести текст в текстовое поле, а для типа checkbox – должен выбрать хотя бы одно значение.

Начальное значение, установленное с помощью атрибута value , удовлетворяет атрибут валидации required . Если вы хотите обязать пользователя самого ввести значение, лучше используйте атрибут placeholder . Информацию об атрибутах value и placeholder можно найти в главе 12.

Разные браузеры, которые поддерживают валидацию входных данных, делают это немного по-разному, но результат во многом схож: когда пользователь нажимает на кнопку, чтобы отправить форму, первый элемент, который имеет атрибут required и куда не было введено значение, выделяется для пользователя. Затем пользователь может исправить данное упущение и снова отправить форму. Если есть другие ошибки, тогда выделяется следующий элемент. Этот процесс продолжается, пока пользователь не предоставит значения для всех элементов с атрибутом required . На рисунке 14-6 показано, как Google Chrome привлекает внимание пользователя к элементу, с которым возникла проблема.

Рисунок 14-6: Google Chrome привлекает внимание пользователя к полю с обязательным заполнением

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

Давайте убедимся, что значение находится в заданных рамках

Мы можем использовать атрибуты min и max , чтобы убедиться, что числовые значения и даты находятся в пределах определенного диапазона. В листинге 14-7 показаны эти атрибуты, применяемые к типу number элемента input .

Листинг 14-7: Использование атрибутов min и max

Оба атрибута применять не обязательно. Для создания верхнего предела для значения применяется только атрибут max , а нижнего предела – только атрибут min . При применении обоих атрибутов мы создаем диапазон значений с верхним и нижним ограничениями. Значения min и max являются «включительными», то есть если вы укажете максимальное значение 100, то допускается любое значение до и включая 100.

Вы можете увидеть, как браузер сообщает об ошибке валидации заданного диапазона значений, на рисунке 14-7.

Рисунок 14-7: Ошибка валидации диапазона значений

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

Давайте убедимся, что значение соответствует шаблону

Атрибут pattern гарантирует, что значение соответствует регулярному выражению. В листинге 14-8 показано, как используется атрибут pattern .

Листинг 14-8: Использование атрибута pattern

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

Рисунок 14-8: Ошибка валидации регулярных выражений

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

Давайте убедимся, что значением является имейл адрес или URL

Типы элемента input email и url , которые я описал в главе 13, гарантируют то, что пользователь ввел действительный адрес электронной почты или полный url , соответственно (ну, почти: браузерная поддержка типа email является довольно приличный, а типа url несколько поверхностной).

Мы можем объединить атрибут pattern с этими типами элемента input , чтобы еще больше ограничить значения, которые может ввести пользователь, например, ограничить адрес электронной почты определенным доменом. В листинге 14-9 представлен пример.

Листинг 14-9: Использование атрибута pattern с элементом input типа email

Валидация HTML5

Чтобы убедиться в том, что код набран правильно и не содержит неуклюжие опечатки, его следует проверить с помощью валидатора — так называется программа или сервис для проверки документа на соответствие веб-стандартам и выявления существующих ошибок. Соответственно, валидным является такой веб-документ, который прошел подобную процедуру и не имеет замечаний по коду. Хотя HTML5 ещё находится в процессе развития, возможность валидации предоставляет сервис validator.w3.org и validator.nu .

По адресу http://validator.w3.org располагается, пожалуй, самый распространенный инструмент для проверки отдельных страниц на валидность. Этот сайт предлагает три способа проверки: по адресу, локального файла и введенного в форму кода.

Проверка по адресу

Если ваш сайт уже опубликован в Интернете, то любую страницу можно проверить, вводя в текстовое поле её адрес (рис. 9.3).

Рис. 9.3. Форма для ввода адреса документа

Так, вводя http://lionindesert.ru в форме «Validate by URI» (валидация по адресу) и нажав кнопку Check (проверить) получим сообщение о том, валидный документ или нет.

Хотя в текстовом поле вводится адрес сайта, проверяется не сайт целиком, а только одна главная страница. Учтите, что, к примеру, адрес http://lionindesert.ru равнозначен вводу http://lionindesert.ru/index.html.

Валидатор проверяет HTML-код страницы и в случае отсутствия ошибок докладывает о валидности документа (рис. 9.4).

Рис. 9.4. Отчёт о проверке и валидности веб-страницы

Определение HTML5 происходит автоматически на основе доктайпа, при этом выводится предупреждение, что проверка на соответствие HTML5 находится в экспериментальной стадии.

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

Рис. 9.5. Отчет о проверке и вывод ошибок

Проверка локальных файлов

Документы, еще не выставленные в Интернете, можно проверить с помощью формы, озаглавленной «Validate by File Upload» (валидация загруженных файлов), как показано на рис. 9.6.

Рис. 9.6. Форма ввода пути к локальному файлу для его проверки

Вначале следует указать путь к HTML-файлу, после чего нажать кнопку Check. Файл будет загружен на сервер и проверен на ошибки.

Использование формы для ввода кода

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

Рис. 9.7. Форма для ввода HTML-кода

Разработанный Анри Сивоненом этот простой со спартанским интерфейсом валидатор позволяет проверять страницы на HTML5, а также на XHTML5, XHTML, HTML и некоторые экспериментальные функции. Валидатор работает в трёх режимах: проверка по адресу документа (Address), загрузка его на сервер (File Upload) и ввод кода непосредственно в текстовое поле (Text Field). Переключение между режимами происходит с помощью списка (рис. 9.8).

Рис. 9.8. Проверка по адресу документа

После нажатия на кнопку Validate выводится результат проверки. Если ошибок нет, демонстрируется зелёная рамка с надписью, что документ соответствует стандартам (рис. 9.9).

Рис. 9.9. Результат проверки


В противном случае отображается красная рамка, а также список ошибок.

На странице расположено две ссылки: About this Service (об этом сервисе), где подробно расписаны разные возможности сайта и More options (дополнительные опции). При нажатии на эту ссылку интерфейс меняется и дополнительно можно указать разные настройки валидации (рис. 9.10). Они преимущественно применяются для проверки других языков разметки чем HTML5.

Валидация форм средствами HTML5

Введение

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

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

1. Специализированные типы входных данных

В HTML5 введены несколько новых типов ввода. Они используются для создания поля ввода, принимающего только определенные типы данных.

Новые типы входных данных выглядят следующим образом:

input type =»email»/>

Если браузер не поддерживает данный тип ввода, поле будет вести себя, как обычное поле ввода текста.

2. Обязательные поля для заполнения

Просто добавив атрибут » required » к input > , select > или textarea >. , Вы говорите браузеру, что значение должно быть заполнено.

input type =»checkbox» name =»terms» required >

3. Лимиты

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

input type =»text» name =»name» required maxlength =»15″>

Поле input type =»number» /> использует атрибуты » max «и » min «, чтобы создать диапазон возможно-допустимых значений (в примере минимально допустимый возраст 18)

input type =»number» name =»age» min =»18″ required >

4. Стилизирование

CSS3 псевдо-классы позволяют украсить форму в не зависимости от ее состояния. Это:

В примере мы объединили селекторы » valid » и » invalid » с псевдо-классом » focus » для закрашивания поля формы в красный или зеленый, в зависимости от того, что делает пользователь: выбирает или печатает.

border : solid 2px #F5192F ;

border : solid 2px #18E109 ;

5. Подсказки

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

Обратите внимание, что разные браузеры отображают всплывающие подсказки по-разному. В браузере Chrome значение названия атрибута будет отображаться мелким шрифтом, под основным сообщением об ошибке. В Firefox другая проблема: использовав атрибут “pattern” после того как он берется в качестве шаблона, Вы не получите всплывающую подсказку.

input type =»text» name =»name» title =»Пожалуйста введите имя пользователя.»>

6. Шаблоны

Атрибут » pattern «, разрешает разработчикам задавать регулярное выражение, которое браузер сравнивает с данными ввода, прежде чем отправить форму заявки.

Вот как это можно использовать:

input type =»email» name =»email» required pattern =»^\[email protected]\S+\.\S+$» title =»[email protected]»>

С функцией фильтрования входных данных мы можем принимать только полный e-mail адрес.

Валидация HTML-документа.

Верстка любой сложности из PSD макетов

Доброго времени суток. Меня зовут Михаил.

Специализируюсь на создании сайтов и их настройке. Разрабатываю современные сайты, учитывая каждое пожелание заказчика уже более 7 лет. Завершены сотни проектов.

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

21 октября 2014

В прошлом видео ролике мы поговорили о событиях HTML, рассмотрели на живых примерах, как они работаю и для чего нужны события HTML.

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

Нужна ли валидация?

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

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

Как пройти валидацию HTML-документа?

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

Существует вариант с указанием адреса сайта, если сайт уже в сети интернет. Также можно загрузить документ для проверки. И третий вариант, добавить весь код HTML-документа в текстовое поле сервиса и одним нажатием на кнопку проверить его на ошибки.

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

Сервис для проверки HTML-документа на валидацию: http://validator.w3.org/


Подробнее об использовании сервиса и его возможностях я рассказал в видео уроке.

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

Видео Урок: Валидация HTML-документа.

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

HTML-справочник и другие материалы можно и нужно скачать здесь!

Не проверив HTML5-кода, не суйся в воду — с Майком™ Смитом

Майк™ Смит (известный как @sideshowbarker) из W3C — человек, с головой увязший в исходном коде инструмента W3C для проверки валидности разметки; эта магия работает именно благодаря ему. Вопросы были заданы на радость и в назидание читателю сайта.

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

Майк™ Смит — заместитель директора @W3C: вариант либерального подхода к работе

Я не работаю. Я — старосветский бонвиван. Я пью чай, изящно отставив мизинец, и трачу силы только на то, что меня забавляет. Последние несколько лет меня забавляло тратить время на работу над программой, помогающей людям проверить, соответствуют ли их документы определённым требованиям в спецификации HTML.

Какая разница между DTD и проверкой, основанной на схеме?

DTD-шки высечены на каменных плитах. И поэтому для обработки они требуют целой кучи камнерезных инструментов. Однако, увы, веб не был построен на обработке каменных плит, поэтому нам пришлось искать другие решения. Для проверки документа на соответствие мы решили использовать такие вещи, как схемы RelaxNG, которые, хоть и не дотягивают до DTD-шной утонченности, представляют собой гораздо более мощные средства для выражения определённых требований соответствия документа. Так что это компромисс.

В чём разница между проверкой на соответствие и валидацией?

Валидация — это что-то из старого мышления. Используйте это слово, когда хотите заставить людей думать, что вы — ископаемое или пережиток прошлого. Это что-то вроде слов «ништяк» или «XHTML».

Многие люди не знают этого, но этимология слова «валидация» тянется еще с тех времен, когда наши предки были, в основном, свинокрадами, и их награждали значком за правильное написание своих имён, да ещё похлопывали по спине: «Молодец»!

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

Впрочем, словосочетание проверка соответствия документа имеет и противную уродскую часть: соответствие — действительно оскорбительное слово. Но вы не должны обращать на него внимания! Уделяйте внимание только слову «проверка» — веселому и полезному.

Именно поэтому я называю инструмент по адресу validator.w3.org/nu «Новая проверка разметки», а не «Бла-бла-валидатор» — я хочу делиться радостью слова «проверка». Проверка — это что-то, реально приносящее людям пользу, а не просто похлопывающее их по спине. Это штука, которая проверяет ваши документы автоматически и избавляет вас от нудной необходимости делать это вручную. Она помогает вам. Возможно, ее следовало бы назвать «Новая проверка-и-помощь».

Что касается самой проверки, она ищет случайные ошибки, которые вы могли допустить: неправильно написанные названия элементов или значения атрибутов, в которые случайно влез какой-то «левый» символ. В общем, такого рода вещи. И она сообщает вам о таких штуках, чтобы вы могли исправить их.

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

Другие названия для того, что умеет этот инструмент, пока еще не одобрены сообществом — это «линтинг» или «статический анализ». Но отличие той штуковины, над которой я работаю, в том, что правила линтинга для нее на самом деле определены в спецификации, а не являются чем-то таким, что, скажем, Дуг Крокфорд (пример навскидку) как-то утром взял и вытащил из шляпы.

Какая разница между ошибками и предупреждениями?

Ошибка — это какой-то явный ляп, например, опечатка в названии элемента, или какие-то дикие нечитаемые символы в значении атрибута, или непонятно что, непонятно откуда взявшееся и явно ненужное.

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

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

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

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

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

Есть ли смысл в использовании доктайпов HTML4 или XHTML?

Нет абсолютно никакой причины для использования доктайпа HTML4. Просто вставьте доктайп в ваши HTML-документы, убедитесь, что они отдаются как text/html , и всё. Живите вашей обычной жизнью. Но если по какой-то причине вы непременно хотите отдавать документы в application/xhtml+xml , то вам не придётся использовать для них доктайп XHTML, т.к. и в этом случае вы можете спокойно использовать . (Но, вероятно, вы не захотите использовать application/xhtml+xml и XHTML в любом случае. Смените же наконец прическу! Сколько можно жить в прошлом, целый огромный мир ждет вас.)

Какие подводные камни поджидают пользователей HTML-проверки и инструментов валидации?

Я полагаю, те же подводные камни, на которые вы наткнетесь, если обратитесь к какому-нибудь разумному человеку, по-настоящему готовому вам помочь: он действительно попытается это сделать, а не просто отмахнётся или даст вам значок «этот свинокрад может написать своё имя». Его помощь может не всегда оказаться тем, что вы хотели услышать, или это могут быть уже известные вам советы, которые вы спокойно можете игнорировать. Такова жизнь.

Какие плюсы?

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

Как так получилось, что между правилами соответствия W3C HTML и WHATWG HTML есть различия?

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

А что, если я найду ошибку в валидаторе или проверке W3C HTML?

Могу ли я запустить локальную копию проверки соответствия W3C HTML?

Да. Лучший способ сделать это — скачать релиз и следовать инструкциям. А если вы используете grunt, попробуйте плагин grunt-html для проверки HTML, основанный на коде валидатора.

Какие-либо советы или подсказки по разумному использованию инструментов проверки соответствия HTML?

Это какой-то вопрос с подвохом? Пожалуй, единственное, что я мог бы посоветовать — не стоит забывать, что инструменты — это машины, а вы — не машина (предполагаю, что этот вопрос задан не машиной). Поэтому, оценивая любые сообщения об ошибках и предупреждениях от любого средства проверки HTML, полагайтесь на собственный здравый смысл. И если здравый смысл подсказывает вам, что какое-то сообщение на самом деле не помогает вам, просто игнорируйте его. Это не конкурс популярности, вы не заденете ничьи чувства.

А ещё лучше, если у вас найдется время, — воспользуйтесь функцией «Фильтрация сообщений» на validator.w3.org/nu, которая позволит вам постоянно игнорировать любые сообщения, которые вы сочтёте бесполезными, надоедливыми или которые вы просто больше не желаете видеть.

Сейчас инструмент проверки W3C HTML не проверяет и не показывает ошибки для SVG1.1 и некоторых атрибутов веб-компонентов, планируете ли добавить поддержку этого?

Да. Эти вещи добавлены в мой список задач. В конечном итоге я доберусь до них.

В чём история с ошибками из-за неизвестных атрибутов? Их используют многие JS-библиотеки, что делать разработчикам?

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

Временное решение — если вы намеренно используете какое-то неизвестное имя атрибута, задействуйте галочку в «Фильтрации сообщений» на validator.w3.org/nu. Это укажет проверке, что вы не желаете видеть сообщения об этом конкретном атрибуте, и они больше не будут вас беспокоить.

Есть ли в валидаторе функция для проверки использования ARIA? Если да, то что это за проверка?

Да, он проверяет ошибки в использовании разметки ARIA в HTML-документах, а теперь еще и находит некоторые ошибки ARIA как в элементах SVG внутри HTML-документов, так и в отдельных SVG-документах.

Для HTML-элементов это проверка на соответствие требованиям не только спецификации HTML, но и появившемуся сейчас самостоятельному документу ARIA в HTML. Планируется, что спецификация HTML вскоре будет обновлена, чтобы просто ссылаться на требования ARIA в этом документе.


Что касается SVG-элементов, у меня в планах вскоре обновить проверку, чтобы она следовала аналогичным самостоятельным документам в «Web developer rules for use of ARIA attributes on SVG1.1 elements»

А что насчёт проверки ARIA в документах по спецификациям до HTML5? Будет ли это сделано?

Ни один человек не должен пользоваться чем-то, кроме HTML5, и не нужно пытаться помогать ему в этом. HTML5 — это просто HTML. Мы уже давно переросли всё связанное с версиями. скоро исполнится 10 лет. Здравый смысл победил. В нашем XXI веке нам нечем толком помочь человеку, который прописывает в новом документе HTML4 или какой-то другой древний доктайп. Это гиблое дело. Мы никоим образом не помогли бы, если бы дали какую-то возможность сделать это и вписать разметку ARIA в такие документы, а потом сказали бы, что всё в порядке. Это называется попустительство.

При использовании HTML-валидатора W3C для проверки моего HTML5 я вижу следующее: «Валидатор проверил ваш документ с помощью экспериментальной функции: проверка соответствия HTML5…» — значит ли это, что есть более стабильный инструмент валидации, который мне следовало бы использовать?

Понятие «стабильный» здесь не очень применимо. Но да, существует другой инструмент, которым вам следовало бы пользоваться. Это validator.w3.org/nu. У него больше возможностей и он лучше по всем статьям.

Это — инструмент экспериментальный, но в хорошем смысле. Планируется, что он всегда останется таким. Страница validator.w3.org/nu/about.html пытается задать правильные ожидания насчет того, в чем цель и что означает экспериментальный:

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

Не нужно пытаться применить Новую проверку разметки как средство, чтобы заставить людей сверять документы с какой-либо спецификацией на «соответствует или не соответствует»; инструмент задуман исключительно как средство проверки, а не как механизм для выдачи сертификатов соответствия.

Что насчёт проверки веб-компонентов?

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

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

В чём разница между валидатором W3C и Новой проверкой разметки?

Старый W3C-валидатор находится на validator.w3.org, и его ядро основано на таких древних вещах, как Perl, DTD-шки, SGML и старые спецификации из XX века, типа HTML4. Никто в данный момент активно не поддерживает его код. Единственная хорошая новость на этот счёт — для проверки любых документов с современным доктайпом он фактически использует движок Новой проверки разметки, а затем просто возвращает все сообщения оттуда.

Новая проверка разметки находится по адресу validator.w3.org/nu. Она основана на чуть более новых вещах типа Java и RelaxNG и на спецификациях из нынешнего века, таких как HTML5, а также имеет большое преимущество в виде фактической активной поддержки. К тому же у нее больше возможностей, напр., функция «Фильтрация сообщений», позволяющая отфильтровать сообщения, которые вы не хотите видеть.

Что лучше — проверка исходного кода или реального вывода HTML DOM? Известные проблемы?

Я полагаю, что для обоих случаев есть хорошие варианты. Ограничение проверки DOM заключается в невозможности сделать так, чтобы validator.w3.org/nu сам забрал DOM какого-то произвольного документа в сети, а потом проверил. Где-то между должен быть браузерный движок, который реально распарсит документ в DOM-представление в памяти, выполнит ваши скрипты, а затем преобразует итоговую DOM обратно в текстовое представление, которое вы можете «скормить» проверке. Но если у вас есть HTML-документ, который вы хотите проверить, и вы уже открыли его в браузере, вы можете использовать что-то типа букмарклета, чтобы отправить строковое представление DOM этого документа в validator.w3.org/nu для проверки.

Дополнительные вопросы

Стоит ли помечать предупреждениями в W3C-валидаторе доктайпы, которые были до HTML5, ведь HTML5 теперь рекомендация?

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

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

Критерий обработки для WCAG 2.0

Консультант по доступности нашего клиента говорит ему, что для совместимости с WCAG 2.0 у них должен быть валидный HTML. Это правда?

Без понятия. Я не эксперт в WCAG и никогда даже не читал спецификацию WCAG 2.0. И HTML-проверка — не WCAG-проверка. Или, по меньшей мере, она не претендует на это.

У WCAG 2.0 есть критерий успеха, который требует, чтобы в разметке документов не было ошибок парсинга. Новая проверка разметки отмечает ошибки парсинга наряду с другими машинно проверяемыми критериями соответствия HTML. Мы создали букмарклет ошибок парсинга для WCAG 2.0, который фильтрует результаты, полученные из Новой проверки разметки, чтобы отобразить только ошибки или предупреждения парсинга.

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

Спасибо, Майк!

Полезный совет — всегда проверяй свой HTML под рок-н-ролл, играющий… ГРОМКО!

Перевод оригинального интервью «HTML5 — Check it Before you Wreck it with Mike™ Smith» Стива Фолкнера, опубликованного на сайте HTML5 Doctor. Переведено и опубликовано с разрешения автора.

Комментарии +

В оригинале статьи Майк, говоря о разнице между валидацией по «высеченным на камне» схемам и новой проверкой на соответствие, использует словечки из оруэлловского «новояза»: валидацию относит к «старомыслию», а новую проверку называет «благомысленной» и «одобряемой партией». Насколько я понимаю, этой аллюзией он подчеркивал безальтернативность HTML5 в современных браузерах, по построению парсера разбирающих любую разметку с типом text/html , независимо от указанного доктайпа, по алгоритму из нового стандарта (что практически лишает смысла валидацию по любой из старых схем). К сожалению, при редактуре мы не нашли способ адекватно передать эту игру слов в переводе, поэтому от нее пришлось отказаться, но, на мой взгляд, совсем не упомянуть этот момент было бы неверно.

И вообще этот Майк действительно озорной, остроумный и бескомплексный дядька (судя по этому и другим интервью с его участием:)

Labdes

Думаю многие знают, что такое форма: это совокупность элементов, которые могут представлять собой текстовое поле (text), текстовое пространство (textarea), чек боксы (checkbox), радио кнопки/переключатели (radio), выпадающие списки (option), кнопки (button, submit). Эти поля посылают данные – имя/значение. Данные соответственно обрабатываются на сервере и результат возвращается пользователю. Валидация – это проверка данных заполненных полей на соответствие какому-то шаблону.

Проверка может осуществляться с помощью html5, javascript/jQuery на клиенте и также на сервере. Любое поле должно иметь атрибут ‘name’ Также input поля могут иметь атрибут ‘value’ . Если значение value заполнено, то оно будет отображаться на страничке по умолчанию. Input поля могут обрамляться тегами . Применение данного тега – является хорошим стилем программирования. Когда он используется то у input поля появляется заголовок при клике на который становится активным данный input или переключатель, а также можно назначать горячие клавиши. Есть два варианта использования: первый вариант связка for ссылающаяся на >Имя либо Имя: Текстовое поле это или У полей с типом password вводимые символы отображаются звездочками для безопасности. Чтобы загрузить файл, используется поле Input с type=”file” Поле с галочкой – Input type=”checkbox”. Если поставить галочку, то такое поле получит атрибут “checked” Радио кнопка – Input type=”radio”, в отличии от чекбокса можно выбрать только одно значение. Для передачи значений, которые не нужно видеть юзеру, используются скрытые поля- Input type=”h >click me . Поле для большого куска текста – Поле выбора значения из выпадающего списка: Задать выбранное поле по умолчанию поможет атрибут selected. Если задать атрибут multiple то можно выбрать несколько значений: …

HTML 5 Input

Input type=”date” выводит календарь для выбора даты. Input type=”color” выводит палитру для выбора цвета. Input type=”range” выведет слайдер для выбора значения от 0 до 100%. Также появились новые атрибуты: autocomplete, placeholder, required, pattern и так далее… Контейнер для всех полей, это тег form. Его возможные параметры: Action – куда послать данные, Enctype – как браузеру воспринимать передаваемые данные, Method – метод передачи данных GET (через url) или POST (фоновая передача).

HTML 5 Валидация

HTML5 Валидация будет осуществляться самим браузером основываясь на типе поля. Например глянем на форму и увидим типы e-mail, url, number, datetime:

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

Если добавить атрибут required: то данное поле должно быть обязательно заполнено, иначе появится предупреждение.

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

Проверить поддержку какого-то параметра браузером, можно на сайте caniuse.com

Ограничить количество вводимых символов можно свойством maxlength, например:

Параметры min/max ограничивают цифровые значения: . Также это ограничение можно присваивать датам:

Параметр multiple позволяет выбирать несколько файлов с помощью Input=”file” или делает возможным ввод нескольких емэйлов в поле Input=”email”.

Разрешить загрузку только определенных типов файлов можно указав mime-type, например только для PNG:

Или только для любых изображений:

Для mp3 и видео:

Можно также использовать регулярные выражения. Например паттерны:

Поле для ввода только слова Привет: . Если надо сделать возможность ввода Привет и привет, то меняем паттерн так: pattern=”[Пп]ривет”. И так далее. Еще примеры. Прописные буквы: [a-z]+ Плюс означает один или больше. Строчные и прописные [A-Za-z]+

Топ-пост этого месяца:  Что такое RSS, где скачать иконки и какая читалка самая лучшая
Добавить комментарий