Как проверить правильность (валидность) готового html-кода

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

Для проверки безукоризненности кода чаще всего используют очень полезный сайт валидатор «Markup Validation Service», расположенный по адресу: http://validator.w3.org, созданный компанией W3C.

HTML

Здесь перед Вами три варианта валидации:

• ввести URL-адрес страницы;
• загрузить файл с кодом со своего компьютера;
• вставить готовый код в форму.

Сервис указывает не только на ошибки html кода и их расположение, но и даёт советы по исправлению. Если код уже имеется в Сети, то можно произвести валидацию путём введения её URL-адреса в форму «Validate by URL» и нажатия кнопки Check. Валидатор HTML включит считывание кода и сообщит об итогах.

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

В этом видео наглядно объяснён процесс проверки с помощью валидатора:

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

По этому же адресу http://validator.w3.org можно проверить код, выбрав вкладку «Validate by File Upload» и загрузив документ с прописанным код.

Выбираем путь к необходимому файлу и жмём Check. Далее всё происходит аналогично.

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

Иногда удобней вставить сразу код страницы и проверить его онлайн: выбираем вкладку «Validate by Direct Input» и отправляем весь код на сервер.

CSS

Проверка валидности кода CSS может быть пройдена также онлайн валидатором: https://jigsaw.w3.org/css-validator/

Здесь все на русском языке, для многих это действительно приятный сюрприз.

Снова можно выбрать — указать URL, загрузить свой файл или вставить код.

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

Пример:

Изучаем полученный код и приводим исходный к нужному виду.

Расширения для браузеров

Для браузеров существуют всевозможные расширения для проверки валидации. Для Google Chrome есть проверяющий валидность кода плагин HTML Tidy Browser Extension, для Opera — расширение Validator, для Safari — Zappatic, для Firefor — HTML Validator.

Остановимся на последнем более детально. Он осуществляет ту же проверку, что и validator, только оффлайн. Взять его можно здесь http://users.skynet.be/mgueury/mozilla/

Устанавливаем расширение, перезагружаем браузер — и можно сразу работать. В случае возникновения заморочек с установкой, можно написать в саппорт Mozilla Firefox или полистать форум http://forum.mozilla-russia.org/doku.php?id=general:extensions_installing

Подробное видео об установке HTML Validator и его использовании:

При загрузке любого URL расширение автоматически включается и считывает код. Результат виден в правом верхнем углу.

Выглядит результат как небольшая картинка с итогом валидации:

Щёлкнув по результату, можно открыть:
— исходный код;
— ошибки — в левом нижнем блоке (или сообщение о валидности);
— подсказки по исправлению ошибок — в правом нижнем.

Как исправить наиболее частые ошибки

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

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

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

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

1. No space between attributes.
…rel=»shortcut icon» href=»http://arbero.ru/favicon.ico» type=»image/x-icon»

Здесь исправления убираем «точку с запятой».

2. End tag for element «div» which is not open

Закрывающий тег div лишний. Убираем его.

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

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

Пользование сервисом проверки W3C Validator Suite

Сервис очень прост в использовании — достаточно ввести URL, задать необходимые параметры и подтвердить начало проверки:

В настоящий момент Validator Suite объединяет в себе следующие инструменты и возможности:

• HTML валидатор. Используются те же средства, что и в MarKup Validation Service, но результаты представлены в альтернативном, более интуитивно понятном интерфейсе. Включает в себя проверку HTML5.
• CSS валидатор. Также используются стандартные широко известные средства с новым представлением результатов. Включает в себя проверку CSS3.
• Поисковый робот. Он автоматически находит все страницы на сайте, подлежащие проверке, в том числе карты сайта в XML формате. Не нужно вручную добавлять каждую страницу — достаточно указать главную и запустить проверку, а робот самостоятельно найдет все внутренние страницы.
• Суммарный отчет. Когда все страницы будут проверены Вы увидите суммарный отчет для сайта, в котором предупреждения и ошибки будут сгруппированы.
• Отчет по URL. Отчет об ошибках для каждой страницы. Вы увидите количество ошибок HTML и CSS, а также предупреждений со ссылкой на детализированное описание проблемы.
• Повторные проверки. Вероятно сразу после получения отчета Вы приступите к работе по устранению ошибок. Используя валидатор можно отправлять на проверку отдельные страницы или запросить повторно полную проверку сайта.
• Неограниченное хранение отчетов. Вы можете хранить свои отчеты столько времени, сколько понадобиться до тех пор пока учетная запись активна. В это же время аналогичные сервисы удаляют их через несколько дней.
• Загружаемые отчеты. Есть возможность скачать результаты проверки в формате CSV (формат, совместимый с таблицами MS Excel, OpenOffice и другим программным обеспечением).

Чем ошибки в HTML грозят сайту

Типичные ошибки кода — незакрытые или дублированные элементы, неправильные атрибуты или их отсутствие, отсутствие кодировки UTF-8 или указания типа документа.

Какие проблемы могут возникнуть из-за ошибок в HTML-коде

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

Как валидность кода влияет на SEO

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

Представитель Google Джон Мюллер говорил о валидности кода:

Итак, критические ошибки в HTML мешают

• сканированию сайта поисковыми ботами;
• определению структурированной разметки на странице;
• рендерингу на мобильных устройствах и кроссбраузерности.

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

Оптимизация кода страниц для SEO

Ниже приведены базовые рекомендации по HTML-верстке страниц, которые оценят поисковые роботы:

Теги Title, Description и Keywords следует располагать сразу после открывающегося тега head,
CSS-стили и Java-скрипты необходимо выносить в отдельные файлы с расширением .css и .js

В противном случае технический код будет увеличивать объем страницы и негативно влиять на скорость ее загрузки.
Весь ненужный код – счетчики статистики (liveinternet, rambler top100, bigmir и т.п.), формы голосований и опросов, отправки заявки или поиска товара, логин-панель — следует закрыть от индексации.
Важно удалять из исходного кода комментарии верстальщиков к разным элементам, т.к. это увеличивает объем страницы и увеличивает скорость ее загрузки.
Из кода необходимо удалять все скрытые от поисковых систем средствами CSS-форматирования элементы

К наиболее часто встречающимся элементам этой категории относятся «display:none» и «visibility:hidden».
Прописывать атрибут alt для всех изображений
Правильно формировать парные теги – если тег был открыт, его обязательно нужно закрыть.
Устаревшие теги, которые уже не поддерживаются, следует исключить из кода, заменив на универсальный тег div. Примеры таких тегов: applet, acronym, bgsound, dir, frame, frameset, noframe, isindex, listing, xmp, nextid, noembed, plaintext, rb, strike, basefont, big, blink, center, font, marquee, multicol, nobr, spacer, tt, u.
Для атрибутов ширины и высоты в элементе img нужно указывать только цифры без «px»
Корректный конструкция тега noindex выглядит следующим образом: Текст или код, который нужно исключить из индексации. Не следует использовать конструкцию Текст или код, который нужно исключить из индексации.

Why validate?

There is a common feeling amongst some web developers that if a web page looks fine in browsers, it doesn’t matter if it doesn’t validate. They describe validation as an ideal goal, but not something that is a black-and-white issue.

Learn the rules so you know how to break them properly.

There are two very powerful reasons to validate your HTML as you author it:

• You are not always perfect, and neither is your code — we all make mistakes, and your web pages will be higher quality (ie, work more consistently) if you weed out all the mistakes.
• Browsers change. In the future, it is likely that browsers will be less forgiving when parsing invalid code, not more forgiving.

Validation is your early-warning system about introducing bugs into your markup that can manifest in interesting and hard-to-determine ways. When a browser encounters invalid HTML, it has to take an educated guess as to what you meant to do—and different browsers can come up with different answers.

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

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

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

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

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

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

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

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

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

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

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

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

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

Как проверить валидность HTML-кода

Проверка HTML-кода сайта на валидность осуществляется с помощью специального инструмента от W3C https://validator.w3.org/ Проверить код можно, указав URL сайта, загрузив часть кода или файл с ним.

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

• Валидация синтаксиса — проверка на наличие синтаксических ошибок.
• Проверка вложенности тегов
• Валидация DTD — проверка соответствия кода указанному Document Type Definition. Она включает проверку названий тегов, атрибутов, и встраивания тегов.
• Проверка на посторонние элементы — проверка выявляет все, что есть в коде, но отсутствует в DTD. Например, пользовательские теги и атрибуты.

Сервис поддерживает IDN-домены и для их проверки не требуется переводить имя домена в Punycode.

Отчет, который предоставляет валидатор от W3C, содержит:

• Список ошибок и предупреждений, с указанием критичности,
• Строка тега с ошибкой,
• Рекомендации по исправлению.

Для исправления ошибок можно обратиться к специалистам либо исправить их самостоятельно

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

Download and Install the CSS Validator

Download the CSS Validator

The CSS validator is available in three different packaging: from Git for developers who want the very latest version,
as a jar archive to build applications and for use as a command line tool, and (since 2009) as a war archive for server-side
applications.

Download the source code

The source of the CSS Validator can be retrieved with Git.
Please note that the online service for the CSS validator is a stable release,
generally a little older than the version under Git, and their results and behaviour may differ.

Download the Java archive (jar)

Installation Guide

The CSS Validation service is based on a servlet written in the cross-platform Java language, and can
be installed on any servlet platform. While the official service from W3C runs under the Jigsaw server
(which is the recommended setup), we will for the sake of convenience describe in this guide the setup
under Apache’s servlet engine, Tomcat, as well as some quick instructions for Jigsaw and commandline usage.

Prerequisites

This guide assumes that you have already downloaded and installed successfully the following:

• a working java environment ;
• the Ant java build tool ;
• a Java servlet container such as Jigsaw,
  Tomcat or Jetty, if you plan to provide the validator as a web service.

As a prerequisite to the installation, you will need to know the complete path to the java library called servlet.jar.
It is generally available within /common/lib/, with being the path under which Tomcat is installed. It may also be found under the name servlet-api.jar. If you can not
find it, java.sun.com will have it.

Installation of the CSS validator under Tomcat

1. Download the Git source as explained  ;
2. Edit the file called build.xml and replace the value of
   property servlet.lib with the full path to servlet.jar

3. You can now build the source : from [VALIDATOR_DIRrun the command ant war.
   Running ant should download a number of necessary libraries, and build the archive called css-validator.war.

4. Copy or move css-validator.war to /webapps.
5. Finally, restart the Tomcat engine :"cd ; ./bin/shutdown.sh; ./bin/startup.sh;"

Installation of the CSS validator under Jigsaw

1. Download the Git source as explained previously, save it under /WWW
   and build source with ant jigsaw ;
2. Next, configure the root folder for the validator (in most cases it will be called css-validator) to make it a servlet container.
   Within your Jigsaw installation, launch the Jigsaw Admin utility, browse to and change it from HTTPFrame to ServletDirectoryFrame ;
3. The next step will be to create a «validator» resource as ‘ServletWrapper’ class. A ‘ServletWrapperFrame’ frame will automagically
   be created for it. You will need to provide the name of the servlet class, which for the CSS Validator os org.w3c.css.servlet.CssValidator.
   Note that a file called “validator” may already be present – you MUST rename it, as the validator absolutely needs to enforce this name for the servlet wrapper ;
4. Make sure that all the .jar libraries within the /WWW/css-validator/lib folder
   are properly added to Jigsaw’s CLASSPATH setup.
5. Finally, restart Jigsaw and point your browser to the validator. The URI should be something like :
   http://localhost:8001/css-validator/validator.html

Any computer with Java installed can also run the validator from the terminal/console as a commandline tool.
Download the css-validator.jar jar archive (or build it with ant jar) and run it as :java -jar css-validator.jar http://www.w3.org/.

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

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

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

Браузер	IE	Firefox	Chrome	Safari	Opera	Safari iOS	Android
Минимальная версия	10	4	10	5	10	—	—

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

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

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

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

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

Плагины Firefox

Firebug

Firebug – это полнофункциональный отладчик и редактор, который позволяет вам работать с HTML, JavaScript, CSS, DOM и многими другими страницами. Вы также можете использовать расширение для мониторинга JavaScript, CSS и XML в режиме реального времени, искать ошибки, которые могут быть в них, и узнавать, что вам нужно сделать, чтобы их исправить. Являясь важным инструментом практически в каждом арсенале инструментов дизайнера, Firebug стал настолько обычным явлением, что даже начал получать свои собственные расширения (например, собственныйсправочный инструментCodeBurner SitePoint).

HTML Validator

Создан на основе Tidy и OpenSP, HTML Validator дает вам простой значок уведомления о достоверности любой страницы, которую вы посещаете. Вы можете запросить дополнительную информацию из инструмента, и при просмотре источника страницы ошибки, приводящие к тому, что страница становится недействительной, подсвечиваются. Если вы не можете самостоятельно понять, что не так, расширение предложит вам рекомендации.

Total Validator

Total Validator дает вам массу инструментов в одном удобном дополнении. Перейдите на нужную страницу, щелкните значок «TV» и проверьте контент на соответствие нескольким версиям HTML, сделайте снимки экрана и многое другое.

Validaty

Validaty позволяет добавить кнопку на панель инструментов, которая позволит вам просто щелкнуть ее при посещении страницы и просмотреть простое визуальное представление о достоверности страницы.

User support

How to handle communication/feedback/questions from the community and what to to use (mailing list, issues, forum, stackoverflow…)
forum & mailing list are not competitors, just look at different goals.

Mailing lists, which we are using right now, are helpful for bug reporting, suggestions & technical questions. But now, when a young developer have some questions on results or don’t understand validators issues he go to ask on others platforms like stackoverflow etc etc….

I suggest to identify 3 categories:

• Bugs reports & suggestions
• Local installation
• Understanding of validator reports

Bugs reports & suggestions

• Centralize and make all current issues publicly available on GitHub alongside the project source code and documentation

Local installation

Some users or companies need to install the validators locally. In the current state, it is difficult to install these tools because documentation is missing or outdated and often their installation involves many manual steps that could be improved (requirement to install lots of dependencies).

• Update installation documentation
• Simplify install process (improve build and deployment tools)
• Use GitHub issues to report bug while installing
• Use mailing list for help in installation

Understanding of validator reports

Users need to understand validators reports. In the current state, some developers don’t understand these reports (too technical, not enough explanation).

• Help on validators report using social forum (community help):
• Link each report issue to its technical documentation page (web platform, W3C spec, …)
• Example of Google Cloud Platform using Stack Overflow for their community support:

W3C’s Validators dissemination

• Lot of developers don’t know that W3C develops and maintains several validators. They need a single place to find all validator projects, a place that will showcase and promote their utilization.
• Each validator needs its own page describing its features and goals to its audience.

Technical improvements

• In some validators reports are not very clear. Maybe rephrase technical issues reported by the validators
• Link each report issue to its technical documentation page (web platform, W3C spec, …)
• Link report issues to tags on stackoverflow
• Export report as PDF
• Send report by email (with report attached as PDF)
• Develop some modular functionalities which can be used by all validators. (like UI templates, page fetch, parser, formatting of report messages)
• Provide a framework for translating validators’ messages

Source code and package availabilityfor the W3C Markup Validator

The W3C Markup Validator provides Perl/CGI/SGML/XML/DTD-based
validation of a variety of document types.
SGML and DTDs are older technologies that never found wide use on
the Web, so for checking of HTML documents using modern
technologies, you probably want to instead use the
W3C HTML Checker.
To do that,

• Download the
  latest release version.
• Read the
  usage guide.

If for some reason you’d rather run a service based on the same source as
the W3C Markup Validator, this page provides the following information:

Installing from packages

Rather than trying to install and run an instance of the W3C from
the sources, it’s much easier to install one of a variety of
pre-built packages. The sections below provide information about
packages available for various systems.

Fedora/Red Hat RPM package

Fedora RPM packages of the validator are included in Fedora.
The name of the validator package is w3c-markup-validator,
use the standard automated package management tools of the
distribution (such as yum) to install it along with its
dependencies.

For Red Hat Enterprise Linux and derivative distributions, the
w3c-markup-validator package is available in
EPEL.

openSUSE/SUSE Linux RPM package

openSUSE/SUSE Linux RPM packages of the validator are available,
courtesy of Sierk Bornemann, at software.openSUSE.org,
<http://software.opensuse.org/>.
Starting with openSUSE 10.3, the latest stable validator package and all its
dependencies are included in the official stable openSUSE distribution.
The name of the validator package is w3c-markup-validator,
use the standard automated package management tools of the
distribution (such as YaST, zypper, smart,
apt4rpm or yum) to install it along with its
dependencies.

Additionally, you can also get these and other needed packages
from the openSUSE Software Repository at
<http://software.opensuse.org/package/w3c-markup-validator>

Debian GNU/Linux package

A Debian package is available, courtesy of Frédéric
Schütz.

Starting with Debian 3.1 («Sarge»), the package and all its
dependencies are included in the official Debian distribution, and
can be installed by running the command apt-get install
w3c-markup-validator as root.

Mac OS X Application

The Validator is also packaged as a standalone Mac OS X Application,
called Validator S.A.C., courtesy of Chuck Houpt.

Getting the source

The source code for the W3C
Markup Validation Service is available under the terms of the
W3C
Software License.

If you just want to glance at the code, or see its revision
history, you can
browse it
directly in Github.

The most interesting files are currently
a
CGI script called «check» that does pretty much everything,
and possibly also the
httpd.conf configuration file snippet for Apache.
Select the topmost revision numbers on these
pages to see the most recent revision of each file.

To actually install and run an instance of the W3C Markup Validator from
the sources, see the
installation manual.