Валидность сайта и её проверка

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

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

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

{3}-{3}

Квадратные скобки в начале строки определяют диапазон допустимых символов. Иными словами, группа разрешает любые прописные буквы от А до Z. Следующая за ней часть в фигурных скобках указывает множитель, т.е. {3} означает, что нужны три прописные буквы. Следующее тире не имеет никакого специального значения и означает самое себя, т.е. указывает, что после трех прописных букв должно быть тире. Наконец, обозначает цифры в диапазоне от 0 до 9, а {3} требует три таких цифры.

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

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

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

QDR-001
WES-205
LOG-104

А вот эти нет:

qdr-001
TTT-0259
5SD-000

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

Чтобы применить полученное тем или иным путем регулярное выражение для проверки значения поля <input> или <textarea>, его следует добавить в этот элемент в качестве значения атрибута pattern:

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

Cколько спецификаций существует.

Начиная с HTML5, разработчики и производители браузеров могут выбирать между двумя разновидностями одного и того же языка разметки: спецификациями, разработанными консорциумом W3C, и тех, что разработаны WHATWG.

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

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

Если HTML-спецификации W3C и WHATWG различаются, то мы стараемся следовать спецификации WHATWG.

The «Philosophy» of the LogValidator

Step-by-step quality

Log Validator is a web server log analysis tool with focus on the quality of Web documents.
Thanks to a modular, extensible design, the Log Validator can help Web authors find the most
popular content on their web site that matches particular criteria.

The Log Validator was first written with Validation (HTML, etc.) in
mind : it can thus help web content managers find and fix the most
frequently accessed invalid documents on their Web site, acting as a
comprehensive, step-by-step
validation tool.

What this tool does (and does not)

This tool takes a web server’s last logs and processes it through validation
modules. Those validation modules check the most popular documents’
validity for a certain technology . The default module is HTML validation, but there
are others available (see the for
supported technologies).

The (X)HTML validation module, for example, helps you
find, among the most popular pages on your site, which are invalid, and thus tell you
which (invalid) pages you should fix first. This is a step-by-step process, you can
set up this tool to run every week, and painlessly fix only a few documents at the
time. Eventually, you will have fixed your whole site, or at least the most important
parts of it. (see also for the HTML module)

Способы проверки валидации

О каждом из способов я написал подробные инструкции в виде текста, а также, если кому-то лень читать и вникать, снял видео ? .

1 способ. Сервис validator.w3.org

Суть первого способа состоит в использовании сервиса для проверки валидности сайта. Как проверить валидность сайта с помощью сервиса validator.w3.org:

1. Переходим по адресу: validator.w3.org. Перед нами откроется страница, на которой есть 3 вкладки. На первой вкладке «Validate by URI» вы можете проверить валидность сайта размещенного в интернет, на второй «Validate by File Upload» — загрузить файл с компьютера, и на третьей «Validate by Direct Input» — вставить содержимое файла непосредственно в форму для ввода. Я буду рассказывать о первом варианте, то есть когда сайт размещен в интернет (думаю и с другими способами у вас проблем не возникнет). Поэтому выбираем первую вкладку как на изображении ниже:

2. Далее нажимаем на кнопку «More options» и здесь необходимо выставить следующие значения:

• Character Encoding — кодировку вашего сайта. НО! Если она уже есть между тегами <head> (у себя на сайте в браузере нажимаете на сочетание клавиш CTRL+U, и ищете в начале документа примерно такую строку

  ), то здесь оставляем выбранным (detect automatically).

• Document Type — тип текущего документа. Он указывается первой строкой в HTML (когда находитесь на своем сайте, в браузере нажимаете сочетание клавиш CTRL+U, и смотрите самую первую строчку

  ). Если же в первой строчке присутствует что-то похожее, тогда и здесь оставляйте значение (detect automatically).

Если у вас что-то из того, что я описал выше нету, тогда вам самостоятельно необходимо будет выставить эти значения. Я здесь ничего не менял и оставил всё как есть.

3. Затем в поле «Address» вводим адрес вашего сайта как сделал я:

После чего нажимаем на кнопку «Check», которая расположена по середине серого блока:

4. Далее идет валидация вашего сайта и через некоторое время появится результат валидации. Будет похожая страница с сообщением «This document was successfully checked as HTML5!» (что значит что ваш сайт успешно прошел проверку на валидность определенному типу документа, то есть в моем случае HTML5):

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

Для тех, кто не понял или поленился почитать — смотрите видео ниже ?

2 способ. Плагины для браузеров

1. Плагин для браузера Mozilla Firefox — Перейти

2. Плагин для браузера Google Chrome — Перейти

Здесь вам необходимо нажать на кнопку «Бесплатно» и затем во всплывающем окошке нажать «Добавить».

3. Плагин для браузера Opera — Перейти

Здесь также происходит обычная установка дополнения.

4. Плагин для браузера Safari — Перейти

Установка:

1. Распакуйте архив с плагином.
2. Скопируйте файл «Safari Validator.webplugin» в папку, где установлен браузер, затем /Library/Internet Plug-Ins (создайте папку, если она отсутствует)
3. Сделайте двойной клик на файле Safari Validator.safariextz.
4. Перезапустить браузер Safari.

Как установить плагин в Firefox и как пользоваться им я рассказываю во втором видео:

A bit of History

Since 1994 and the
first HTML validator service, there has been a way to check the validity of one’s
webpage with regards to web standards (HTML, CSS, …). Other services, like
HTML Tidy allow you to
(semi-)automatically fix invalid documents…

This tool is here to make your life as a webmaster, web designer, web developer even
easier, by telling you which documents you should fix in priority.

It has first been developed by Gerald Oskoboiny as
an internal W3C tool (yes, even at W3C we create invalid HTML sometimes) to check the
HTML validity of the webpages on the W3C website, then
released its code
in september 2001.

In 2002, the Quality Assurance team at W3C decided to re-write
it as a modular, portable, and easy-to-use tool for webmasters. Its development continues, mostly
with the addition of new processing modules making the Log Validator a very useful and versatile
Web Quality analysis tool.

Стоимость проверки с помощью W3C Validator Suite

Да, к сожалению, проверка сайта этим инструментом не бесплатна. На данный момент представлены два тарифных плана:

1. Первый тарифный план называется «One Time, One Job», суть которого заключается в оплате услуг за одну проверку. Стоимость зависит от числа страниц в проекте.
2. Месячная подписка. Оплачивая месячную подписку клиент получает неограниченное количество проверок. Стоимость на момент бета-релиза не указывается, ее необходимо уточнять индивидуально у специалистов технической поддержки. Кстати, сейчас многие онлайн сервисы переходят именно на оплату по подписке.

Внимание! Начиная с 6 августа 2015 года Validator Suite стал бесплатным

Проверка сайта на валидность

Валидаторы кода это онлайн-сервисы, способные выполнить проверку сайта на валидность, то есть соответствие всех элементов его установленным правилам и стандартам.

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

1. На первой вкладке – Проверить URL, можно сразу же ввести адрес сайта или отдельной страницы для проверки.

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

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

Все настройки сначала можно оставить по умолчанию и нажимаем Проверить. Получаем список ошибок и предупреждений.

Предупреждения выделены желтым цветом, а ошибки — красным. Рассмотрим, как выводятся предупреждения и ошибки при проверке на валидность:

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

В данном случае можно открыть страницу и найти там строку 70, колонка 93.

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

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

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

W3C Markup Validator Roadmap

This page holds the development roadmap for the W3C Markup
Validation Service.

• For a list open bugs and detailed feature, we now use
  Bugzilla, which can be searched
  by specific milestone version numbers.
• This roadmap only gives a high-level overview of what each generation of the
  validator changed from the others.
  For a detailed list of features and changes in past releases, see the
  News page.
• If you would like to discuss this roadmap, or request new features, please join the
  www-validator
  mailing list.

High-Level Objectives

• Provide the web with a one-stop service for Web Quality check
• Help raise quality for (m)any kind(s) of Web content
• Build a positive culture of Web Quality
• Future-proof our services (new formats, new usage)
• Leverage Communities energy
• Remain the trusted source by professionals
• Find the right balance between accuracy and user-friendliness

Roadmap

Multi-engine validator

The current validator is mostly based on an DTD parser, with an XML parser used only for some checks.
It also plugs into an html5 parser for the validation of HTML5 content. In the future, other engines
should be used to check compound XML documents (with NVDL+relax, XML Schema, Schematron — using e.g the relaxed engine)

The following flowchart describes the validation engine architecture, as it is now, and as we envision it in the near future.

(follow link to enlarge, or download the vector-based
graffle,
PDF or
SVG version)

Milestones

@@ TODO @@ add these as Bugzilla entries

1. Interface with an NVDL+RelaxNG engine for validation of compound XML documents (coding the interface will be similar to the one
   done for hTML5 engine)

2. Choose the right NVDL+RelaxNG engine. relaxed and validator.nu provide such capability, and of course there is the option to roll our own (jing, etc).

3. Change check code to send multiple-namespace XML documents to NVDL+RelaxNG engine

4. Interface with the feed validator, RDF validator and CSS validator programatically (instead of redirecting, as done today)

Mulitilingual tool

The Markup Validator receives 1M requests per day, and is only in English. Making it multiligual
would make the tool easier to use for web developers and designers worldwide. Although this may be technically tricky
(given the number of message/engine sources), the community would be very excited in participating in the translation effort.

Site-wide services

The markup validator currently checks a single page. Some companion software (such as the log validator)
could be made into a web service to provide crawling, batch validation, scheduled checks etc.

Check beyond markup

This may be in the roadmap for Unicorn rather than the markup validator, but it fits in the «long-term»
vision of developing the W3C Web Quality services. Checking of RDDL, RDFa, microformats and other rich markup are in scope.
Many other checks could be added to the validators, such as:

• document cacheability
• spell checking
• semantic extraction
• accessibility evaluation

Less finger pointing, more problem solving

Most of our tools, and especially the «star» HTML validator,
have a binary «valid/invalid» way of presenting their results. While this is useful for some, it tends to make people look away
from the «big picture» of web quality. A new one-stop quality checker could help bring a paradigm shift by showing diverse
aspects of web quality, while systematically suggesting solutions for every problem. This would involve working with designers
to find ways to present aggregated quality information in a clear and positive manner.

0.8.x

The 0.8.0 release sees the validator code reorganized around a more modular architecture, adding better XML checking capabilities. In 0.8.5, HTML5 checking capabilities were added by interfacing with the validator.nu engine.

0.7.x

The 0.7.0 release reorganized the validator to use templates, making it easier to produce different outputs (hence the development of an API). 0.7.0 through 0.7.4 included mostly bug fixes and documentation updates.

0.6.x

The 0.6.0 release, in 2002, kicked in a new phase of open source development for the validator,
including a number of bug fixes. 0.6.0 through 0.6.7 included mostly bug fixes and documentation updates.

Versions Prior to 0.6.0

Versioning up to version 0.5.x was only done as a development mechanism, and
the validator was not following a strict release cycle.

Валидность и другие показатели качества сайта

Еще многое предстоит сделать по расширению возможностей сервиса, в планах по реализации три дополнительных направления:

1. Доступность. Соответствие стандарту WCAG (Web Content Accessibility Guidelines), обеспечивающему доступность содержимого сайта для людей с ограниченными возможностями.
2. Совместимость. Мультиплатформенная совместимость снижает затраты на разработку и позволяет пользователям просматривать сайт в любом браузере.
3. Оптимизация. Упрощение и минимизация кода, оптимизация графики и контента делает сайт более открытым для поисковых систем и удобным для пользователей.

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

Рекомендую ознакомиться с другими моими обзорами средств анализирования сайта из рубрики Аудит и тестирование. И конечно же жду Ваших отзывов! Как думаете, сервис найдет свое место в нише и будет пользоваться спросом?

Инструменты для валидации веб-сайта

W3C markup validation service (он же validator w3 org)

Этот сервис поможет проверить валидность разметки веб-документов в форматах HTML, XHTML, SMIL, MathML и т. д. И позволит исключить необходимость использования дополнительных инструментов.

Какие проверки осуществляются:

• Анализ синтаксиса и стилей;
• Проверка сайта на ошибки онлайн.

CSS validator

Позволяет проверить код CSS и (X)HTML-документы с таблицами. Если нужно валидировать CSS, встроенный в (X)HTML-код, то сначала нужно будет проверить разметку.

Checklink

Проверяет ссылки и анкоры на отдельных веб-страницах или на целом сайте. Этот инструмент позволяет выявить проблемы, связанные со ссылками, анкорами и объектами в веб-странице, CSS-таблицами и т. д. Сначала убедитесь, что в проверяемых документах используется валидная (X)HTML-разметка и CSS-код.

Feed

Бесплатный сервис для W3C-валидации ленты рассылок (Feed), который позволяет проверить синтаксис Atom или RSS. Вы можете проверить сайт на ошибки по URL или с помощью прямого ввода кода.

Mobile checker

Инструмент позволяет проводить различные тесты веб-страниц для определения того, насколько они адаптированы под мобильные устройства. Тесты описаны в спецификации mobileOK Basic Tests 1.0. Веб-страница считается адаптированной, если проходит сразу все тесты.

HTML Validator

HTML Validator от WDG по функционалу напоминает сервис валидации от W3C. Основные отличия были исключены с выходом обновленной версии W3C-валидатора.

Watson’s site validation check

Валидатор HTML онлайн Dr. Watson – бесплатный сервис, который позволяет проверить сайт на ошибки онлайн. Укажите URL-адрес страницы, которую необходимо проверить, и Watson сразу же сделает ее копию. Он также умеет исследовать множество других аспектов сайта: валидность ссылок, скорость скачивания, оптимизация под поисковые системы и т. д. Многие функции совмещены в одну. Если требуется решение «все в одном», то этот инструмент вам точно пригодится.

Какие проводятся проверки:

1. Скорость загрузки страницы;
2. Анализ синтаксиса и стилей;
3. Подсчет количества слов;
4. Проверка орфографии;
5. Проверка ссылок;
6. Уровень оптимизации под поисковые системы;
7. Проверка входящих ссылок;
8. Проверка исходного кода.

XML well checker and validator

Эту форму можно использовать для проверки XML-документов на валидность. Инструмент проверяет и все подкрепленные внешние файлы на наличие синтаксических ошибок и находит лишние пробелы.

Robots checker

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

Как работает проверка HTML5?

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

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

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

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

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

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

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

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

Проверка CSS кода на валидность

В валидаторе W3c также можно проверить CSS-код на валидность. Сделать это можно по этой ссылке. Принцип работы все тот же: указываете URL-сайта, либо выбираете файл на компьютере и нажимаете на кнопку «Проверить».

В отличии от того же валидатора HTML, валидатор CSS на русском.

Ошибки и предупреждения CSS

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

В моем случае, большинство предупреждений из 281 — это CSS-свойства для нормального отображения в различных браузерах:

Сервис позиционирует подобные теги, как «неизвестное расширение поставщика». Поэтому если при проверке своих CSS-файлов, Вы видите большое количество таких ошибок, то не пугайтесь. Все нормально.

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

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

Ну а сейчас, до свидания!

Предыдущая статья Урок 112. Оптимизация заголовков H1, H2, H3 и т.д. Следующая статья Урок 114. Составление технического задания

Get involved! Contribute to W3C Open-Source Software

W3C software is free and open source: the software is made primarily by
people of the Web community, for the Web community.

There are many ways to get involved:

Help Others

A lot of W3C software have a specific user discussion mailing-list (see each
projects for details), some also have IRC (chat) channels, such as the
#validator channel on the irc.freenode.net for
discussions on W3C validation services.

Write code

As explained , all of W3C software source is freely available, developers are
encouraged to get the source for the projects they care about and start hacking
right away.

Read the if you intend to contribute code. Note that as
this license is GPL compatible, it is possible to redistribute software based
on W3C sources under a GPL license.

Send Feedback

Code is not the only way to get involved in making W3C software better.
Testing, bug reports, suggestions, or help in creating good documentation are
equally important! Most project will have a Feedback page, and you can
report bugs, test cases and patches on our Bugzilla.

Donate

All the tools listed on this page are free and open source, but hosting,
maintaining and developing them often costs a lot. With your support through
the Validator Donation Program
or the W3C Supporters Program,
we can build even better tools.

Custom validators¶

We will step through the evolution of writing a length-checking validator
similar to the built-in validator, starting from a
case-specific one to a generic reusable validator.

Let’s start with a simple form with a name field and its validation:

class MyForm(Form):
    name = StringField('Name', InputRequired()])

    def validate_name(form, field):
        if len(field.data) > 50
            raise ValidationError('Name must be less than 50 characters')

Above, we show the use of an to do
validation of a single field. In-line validators are good for validating
special cases, but are not easily reusable. If, in the example above, the
name field were to be split into two fields for first name and surname, you
would have to duplicate your work to check two lengths.

So let’s start on the process of splitting the validator out for re-use:

def my_length_check(form, field):
    if len(field.data) > 50
        raise ValidationError('Field must be less than 50 characters')

class MyForm(Form):
    name = StringField('Name', InputRequired(), my_length_check])

All we’ve done here is move the exact same code out of the class and as a
function. Since a validator can be any callable which accepts the two
positional arguments form and field, this is perfectly fine, but the validator
is very special-cased.

Instead, we can turn our validator into a more powerful one by making it a
factory which returns a callable:

def length(min=-1, max=-1):
    message = 'Must be between %d and %d characters long.' % (min, max)

    def _length(form, field):
        l = field.data and len(field.data) or 
        if l < min or max != -1 and l > max
            raise ValidationError(message)

    return _length

class MyForm(Form):
    name = StringField('Name', InputRequired(), length(max=50)])

Now we have a configurable length-checking validator that handles both minimum
and maximum lengths. When is passed in your validators list,
it returns the enclosed _length function as a closure, which is used in the
field’s validation chain.

This is now an acceptable validator, but we recommend that for reusability, you
use the pattern of allowing the error message to be customized via passing a
parameter:

class Length(object):
    def __init__(self, min=-1, max=-1, message=None):
        self.min = min
        self.max = max
        if not message
            message = u'Field must be between %i and %i characters long.' % (min, max)
        self.message = message

    def __call__(self, form, field):
        l = field.data and len(field.data) or 
        if l < self.min or self.max != -1 and l > self.max
            raise ValidationError(self.message)

length = Length

In addition to allowing the error message to be customized, we’ve now converted
the length validator to a class. This wasn’t necessary, but we did this to
illustrate how one would do so. Because fields will accept any callable as a
validator, callable classes are just as applicable. For complex validators, or
using inheritance, you may prefer this.

We aliased the class back to the original name in the
above example. This allows you to keep API compatibility as you move your
validators from factories to classes, and thus we recommend this for those
writing validators they will share.

Setting flags on the field with validators

Sometimes, it’s useful to know if a validator is present on a given field, like
for use in template code. To do this, validators are allowed to specify flags
which will then be available on the . Some of the built-in validators such as
already do this.

To specify flags on your validator, set the attribute on your
validator. When the Field is constructed, the flags with the same name will be
set to True on your field. For example, let’s imagine a validator that
validates that input is valid BBCode. We can set a flag on the field then to
signify that the field accepts BBCode:

# class implementation
class ValidBBCode(object):
    field_flags = ('accepts_bbcode', )

    pass # validator implementation here

# factory implementation
def valid_bbcode():
    def _valid_bbcode(form, field):
        pass # validator implementation here

    _valid_bbcode.field_flags = ('accepts_bbcode', )
    return _valid_bbcode

Then we can check it in our template, so we can then place a note to the user:

{{ field(rows=7, cols=70) }}
{% if field.flags.accepts_bbcode %}
    <div class="note">This field accepts BBCode formatting as input.</div>
{% endif %}

Some considerations on using flags:

• Flags can only set boolean values, and another validator cannot unset them.

• If multiple fields set the same flag, its value is still True.

• Flags are set from validators only in , so inline
  validators and extra passed-in validators cannot set them.

HTML и CSS валидаторы — онлайн-сервисы для проверки кода

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

Валидатор от W3C

Англоязычный сервис, онлайн проверяет соответствие HTML стандартам: можно проверить код по URL, залить файл или вставить код в окошко.

Инструмент покажет список ошибок и предупреждений с пояснениями — описанием ошибки и ее типом, а также укажет номер строки, в которой нужно что-то исправить. Цветом отмечены типы предупреждений и строчки с кодом.

Фрагмент примера проверки

Инструмент от W3C для проверки CSS, есть русский язык. Работает по такому же принципу, анализирует стили на предмет ошибок и предупреждений. Первым идет блок ошибок, предупреждения собраны ниже отдельно.

Проверка CSS

Проверить HTML можно с помощью браузерных плагинов, к примеру, Web-developer или HTML Validation Bookmarklet для Google Chrome, HTML Validator для Firefox и Google Chrome, Validator или W3C Markup Validation Service для Opera, или другого решения из списка инструментов.

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

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

Что такое валидность кода

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

Для этого есть специальные стандарты: если им следовать, страницу будут корректно распознавать все браузеры и гаджеты. Такой стандарт разработал Консорциумом всемирной паутины — W3C (The World Wide Web Consortium). HTML-код, который ему соответствует, называют валидным.

Валидность также касается файлов стилей — CSS. Если в CSS есть ошибки, визуальное отображение элементов может нарушиться.

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