Привет. Сразу отвечу на ваш вопрос: стоит ли читать Вам этот урок? Перейдите на весьма полезный и бесплатный сервис validator.w3.org, вбейте туда адрес своего сайта и, если вы видите, что на Вашем сайте есть ошибки, то урок прочитать стоит. Примеры отображения ошибок с помощью данного онлайн валидатора:
На моем же блоге сейчас нет подобных ошибок, я от них избавился (всего было более 70 ошибок и более 80-ти предупреждений). Чтобы внести ясность, расскажу, что такое валидный код и зачем он нам необходим.
Валидный код — это код, который соответствует стандартам.
На валидность можно проверить HTML, CSS, всяческие микроразметки и другое. Сегодня я расскажу про валидность в HTML.
- Валидный код необязателен, но количество ошибок должно быть минимальным, иначе ваш сайт не будет кроссбраузерным. Валидность кода нужна в прежде всего для того, чтобы ваш сайт отображался правильно во всех браузерах.
- Поисковые роботы «разговаривают» с вашим сайтом на языке HTML, поэтому важно отдавать четко и ясно контент на сайте со всеми «закрытыми тегами» и прочее.
- Валидность HTML влияет на SEO, но довольно незначительно (если, конечно, у вас не сотни, а то и тысячи ошибок). Рекомендую почитать интересные наблюдения Деваки «Влияние качества HTML на их ранжирование».
- Когда я делал на своем сайте код валидным, я нашел и исправил свои глупые ошибки (повторение тегов, пропущенная буква и т.п.).
- Не стоит «рвать себе *опу», если какую-то ошибку сложно исправить, либо ее исправление принесет вред функциональности сайта. Главное, чтобы было удобно пользователю.
Ниже я разберу основные ошибки, на которые указывал валидатор. Если вдруг в списке ниже не окажется вашей ошибки, впишите ее в комментариях, попробуем вместе разобраться и я добавлю решение данной проблемы в данный урок. Кстати, да, ошибки, на которые указывает валидатор w3c смотрим тут:
В каждой ошибке есть подсказка — это номер строки в исходном коде странице, а из нее уже можно определить примерно в каком файле темы расположена данная строка. Исходный код страницы смотрим с помощью CTRL+U (в основных браузерах).
Перед тем, как приступить к работе, сделайте резервную копию шаблона вашего сайта.
Также для упрощения нахождения ошибок в исходном коде, можете использовать HTML валидатор для Mozilla Firefox. Установив его, перейдя в исходный код страницы, вы увидите те же самые ошибки, что указывает сервис validator.w3.org. Кликнув по названию ошибки (в левом нижнем углу), вас автоматически перебросит на ту строчку, где находится данный невалидный код.
Нахождение ошибок в HTML с помощью валидатора w3c и их исправление
Ищите в списке ниже свою ошибку и кликнуть по ней, вас автоматически «прокрутит» куда надо.
- No space between attributes.
- The width attribute on the td element is obsolete. Use CSS instead.
- An img element must have an alt attribute, except under certain conditions. For details, consult guidance on providing text alternatives for images.
- Section lacks heading. Consider using h2-h6 elements to add identifying headings to all sections.
- The hgroup element is obsolete. To mark up subheadings, consider either just putting the subheading into a p element after the h1-h6 element containing the main heading, or…
- Element «noindex» undefined.
- End tag for element «div» which is not open
- Document type does not allow element «li» here; missing one of «ul», «ol», «menu», «dir» start-tag.
- End tag for «div» omitted, but OMITTAG NO was specified.
- There is no attribute «border».
- Character «<» is the first character of a delimiter but occurred as data.
- Saw » when expecting an attribute name. Probable cause: = missing immediately before.
- The align attribute on the img element is obsolete. Use CSS instead.
- Bad value Блог Алексея Смирнова for attribute href on element link: Illegal character in path segment: not a URL code point.
1. No space between attributes.
…rel=»shortcut icon» href=»http://arbero.ru/favicon.ico» ; type=»image/x-icon» Просто убираем «точку с запятой».
2. The width attribute on the td element is obsolete. Use CSS instead.
td valign=»center» width=»80″ height=»80″ >
Подобное преобразуем к виду
td style=»align:center; width:80; height: 80;»>
3. An img element must have an alt attribute, except under certain conditions. For details, consult guidance on providing text alternatives for images.
Одна из самых частых ошибок. Просто не хватает альтернативного текста для картинки. Прописываем тег alt.
4. Section lacks heading. Consider using h2-h6 elements to add identifying headings to all sections.
section id=»comments» >
Внутри блока section должны содержаться что-то из тегов h2-h6, если их нет, просто переименовываем слово section на div
5. The hgroup element is obsolete. To mark up subheadings, consider either just putting the subheading into a p element after the h1-h6 element containing the main heading,
or else putting the subheading directly within the h1-h6 element containing the main heading, but separated from the main heading by punctuation and/or within, for example, a span class=»subheading» element with differentiated styling. To group headings and subheadings, alternative titles, or taglines, consider using the header or div elements.
Аналогично предыдущему пункту. Просто меняем фразу hgroup на div. Вы можете использовать инструмент «Найти/заменить все» в текстовом редакторе, чтобы ускорить подобные процессы.
6. Element «noindex» undefined
Чтобы тег noindex стал валидным, пишем его в виде комментирования, то есть так:
<!--noindex-->Неиндексируем<!--/noindex-->
7. End tag for element «div» which is not open
Закрывающий тег div лишний. Убираем его.
8. Document type does not allow element «li» here; missing one of «ul», «ol», «menu», «dir» start-tag
Неправильное использование тега «li»: отсутствует тег «ul», «ol» и др. Проверьте.
9. End tag for «div» omitted, but OMITTAG NO was specified
Не хватает закрывающего тега div.
10. There is no attribute «border»
alt=»» width=»1″ height=»1″ border=«0″/>
Просто удаляем фразу border=»0″.
11. Character «<» is the first character of a delimiter but occurred as data
Не используйте тег «<» перед обычными словами, используйте лучше разные кавычки.
12. Saw » when expecting an attribute name. Probable cause: = missing immediately before.
Лишняя кавычка, удалите ее.
13. The align attribute on the img element is obsolete. Use CSS instead.
Не используйте значение align внутри тега img. Пропишите ее отдельно, в таком виде:
<div align='center'>тут картинка (img src)</div>
14. Bad value for attribute href on element link: Illegal character in path segment: not a URL code point.
То, что идет в href должно быть ссылкой, начинаться с http, но никак не слово.
Заключение
Если у вас на сайте есть какая-то ошибка, которой нет в этом списке — пишите в комментариях. Разберемся, а я дополню статью. Повторюсь, если какую-то ошибку не получается исправить, не стоит заморачиваться.
У меня на блоге осталась ошибка (хотя еще вчера почему-то код был без ошибок):
The text content of element script was not in the required format: Expected space, tab, newline, or slash but found < instead.
Если в курсе, как исправить ее, буду признателен. Я немножко перфекционист. 🙂
Будете ли вы делать HTML код сайта валидным?
Пожелаю вам получить валидный HTML код на вашем сайте, уведомление которого выглядит так:
P.s. Вы часто перегружаете свой организм? Тогда вам нужна программа детоксикации. Восстановите силы и энергетический баланс.
Для начала немного теории. Валидность HTML – это соответствие кодов html и каскадных таблиц стилей CSS неким стандартам, которые задает нам Консорциум Всемирной Паутины (W3C – World Wide Web Consortium). На производстве – ГОСТ, в русском языке – грамматика, а в интернете – валидность. Страницы сайта, прошедшего проверку на соответствие стандартам W3C будут правильно отображаться в современных браузерах, вырастет скорость загрузки и как следствие — маленький плюсик при ранжировании в поисковой выдаче.
Проверить валидность HTML кода сайта можно официальным валидатором стандарта W3C.
Здесь мы видим три вкладки проверки:
- Validate by URL – по URL адресу;
- Validate by File Upload – загруженного файла;
- Validate by Direct Input — непосредственно HTML кода страницы сайта.
Начните проверку по URL с главной страницы своего сайта (блога), а затем проверьте отдельные страницы, на которых вставлены какие-либо скрипты или блоки (голосование, различные сервисы, фотогалереи и т. д.).
Перед проверкой нажмите на кнопку «More Options» и выберите параметры отображения ошибок.
- Show Source – с выводом исходного (с ошибками) кода;
- Validate error pages – проверка страниц вывода ошибок (404 страница);
- Show Outline – вывод строки с ошибкой;
- Verbose Output — отображение заголовков, передаваемых сайтом браузеру: дата изменения документа, его размер и тип, параметры сервера;
- Clean up Markup with HTML Tidy – вывод правильного кода (по версии html Tidy), которым можно заменить неправильный. Полезная функция, должна здорово помочь при исправлении ошибок. По моим наблюдениям, работает только с мелкими ошибками – пропущена кавычка, не закрыт тег, и т. д.
- List messages Sequentially – вывод ошибок и предупреждений по порядку;
- Group Error Messages bu Type – вывод ошибок и предупреждений в группах по типу.
Рассмотрим на конкретном примере как найти на блоге и исправить найденные валидатором ошибки и предупреждения.
После проверки этой моей страницы валидатор выдал предупреждение на линии 252 и ошибку на линии 263.
После перевода этой абракадабры можно понять, что для устранения предупреждения на линии 252 рекомендуется заменить символ «<» (в куске кода выделен красным цветом) на амперсанд «&«. Опустимся на линию 252 приведенного HTML кода нашей страницы ниже.
Сразу становится понятным то, что это код поиска вирусов онлайн от Dr.Web, включенный мной в пост в HTML редакторе.
1. Как и было рекомендовано символ «<» заменяем на амперсанд «&«. 2. Проделываем аналогичную операцию с закрывающим символом «>» на линии 263. Проводим перепроверку страницы валидатором.
Как видим, предупреждение и ошибка исчезли, наш документ проверку на валидность прошел. Наслаждаемся чувством умиротворения от качественно проделанной работы.
Довольно часто, почти всегда, ошибки кроются в плагинах. В этих случаях ошибку найти не так просто, и я рекомендую воспользоваться инструментом «поиск» файл менеджера Total Commander. Как использовать этот инструмент файл менеджера я уже писал в статье «Внешние ссылки» и повторяться здесь не буду.
Многим блогерам, особенно тем, кто плотно не знаком с HTML, будет трудно понять чего нам говорит валидатор. Для облегчения понимания сути ошибки и ее исправления скачайте шпаргалку — подсказку по ссылке — на скачивание шпаргалки, где описаны самые распространенные ошибки HTML кода и способы их исправления. Если, несмотря на все усилия, ошибку в коде плагина, скрипта, и т.п., устранить не удается, откажитесь от него и замените подобным с валидным кодом.
Sorry! This document can not be checked.
Такой грозной надписью вас известит сервис, если он не сможет проверить сайт на валидность HTML сода. Причиной этому может быть конфликт плагинов. В моем случае помогло простое обновление WordPress. Можете использовать проверку валидности непосредственно HTML кода страницы блога на вкладке Validate by Direct Input.
В следующей статье «Валидность CSS» мы рассмотрим, как выполнить проверку и исправление ошибок CSS каскадных таблиц стилей. P.S. По многочисленным просьбам читателей публикую здесь валидный код блока кнопок поделиться в социальных сетях от Яндекса:
<script type="text/javascript" src="http://yandex.st/share/share.js" charset="utf-8"></script> <script type="text/javascript"><!-- document.write('</p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <div class="yashare-auto-init" data-yashareL10n="ru" data-yashareType="button" data-yashareQuickServices="yaru,vkontakte,facebook,twitter,odnoklassniki,moimir,lj,friendfeed,moikrug,gplus,blogger"></div> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p>'); --></script>
Именно этот блок вы видите в конце каждой моей статьи. Нажмите на кнопки, чтобы проверить, работают ли :-).
Здравствуйте, дорогие читатели. Сожалею, что так долго не писал, решил немного заняться новым проектом и на 2 месяца забросил этот сайт 
. Исправляюсь, по вашим многочисленным просьбам пишу статью про валидность сайта валидность HTML кода и как проверить сайт на валидность и исправить ошибки.
Проверить сайт на валидность важно по нескольким причинам:
- выявить ошибки и устранить их
- для каждого пользователя ( зависит от его браузера и версии ) страница может отображаться по-разному. Браузеры смогут отобразить страницу с небольшими огрехами, но каждый отобразит по-своему.
- если браузеры могут автоматически исправить маленькие недочеты, то поисковые системы замечают любую погрешность. К примеру на западе поисковики серьезно относятся к валидности сайтов, у нас уже тоже не исключение.
Всему этому необходимо следовать. А задает эти нормы W3C Консорциум Всемирной паутины ( World Wide Web Consortium ).
Проверка HTML кода на валидность
W3C предоставляет для всех вебмастеров валидатор html кода, чтобы проверить валидность сайта.
Validate by URI — проверка по URL
Validate by File Upload — проверить загружаемый файл
Validate by Direct Input — вставка и проверка участка кода
Нажимаем кнопку Check и появятся результаты. По умолчанию настройки определяются автоматически, но если вы подгоняете под другой тип, то используйте свои.
Подмечу, что часто достаточно исправить 1 или пару ошибок, чтобы сайт полностью соответствовал правилам. ( Например, в этом случае достаточно было сделать 1 исправление в 1 файле, чтобы пропало 5 ошибок ).
Далее будет выведен список ошибок и их решение.
Все на английском, правда в валидаторе есть полезная опция «Clean up Markup with HTML-Tidy», ниже расскажу о ней.
Также можно будет выбрать дополнительные опции при проверке на валидность:
- Show Source – отобразить исходный код вашей страницы
- Show Outline – показать строку, где есть ошибки
- Validate error pages – проверить страницы ошибок, например 404 — страницы не существует
- List Messages Sequentially – показать ошибки и предупреждения списком, последовательно
- Group Error Messages by Type – группировать ошибки с общими признаками
- Clean up Markup with HTML Tidy — программа HTML Tidy выводит исправленный код, не входит в состав W3C validator, поэтому не гарантируется полная корректность
Исправление ошибок валидности
Теперь попытаемся разобраться как исправлять ошибки.
1. Копируем строчку с ошибкой ( … не копируем, это продолжение кода )
2. Определяем в каком файле она находится. Открываем сайт, CTRL + U просматриваем исходный код страницы и ищем ошибку CTRL + F. Часто ошибка не связана с файлами шаблона, она может находиться в файлах плагинов, либо в подпапках вашего шаблона, поэтому нужны некоторые знания
3. Далее открываем файл и при помощи записи под ошибкой, либо при помощи программы HTML Tidy ( включаем опцию вверху страницы валидатора), в таком случае ищем уже исправленный код ( просто копируйте код на 2-3 символа до красного выделения ). И исправляем.
Часто встречаемые ошибки валидации
Тег noindex
Пример:
<noindex> <a rel=»nofollow» href=»…» >…</a></noindex>
Ошибка валидатора: You have used the element named above in your document, but the document type you are using does not define an element of that name
Пояснение: noindex — не входит официальную спецификацию тега языка гипертекстовой разметки веб-страниц HTML. Также полезно знать, что ЯНДЕКС учитывает, как и Google, Yahoo и Bing, rel=»nofollow»
Правильно:
<a rel=»nofollow» href=»…» >…</a>
Пример:
<a href="index.php?pid=1&id=2">...</a>
Ошибка валидатора: Unknown entity…
Пояснение: использовать & вместо &
Правильно:
<a href="index.php?pid=1&id=2">...</a>
Неверная вложенность
Пример:
<strong><li>...</strong></li>
Ошибка валидатора: Missing </ tagli>
Пояснение: элементы должны быть закрыты в обратном порядке их открытию
Правильно:
<strong><lili
Чувствительность DOCTYPE к регистру
Пример:
<!doctype html public "-//w3c//dtd xhtml 1.0 transitional//en" "http://www.w3.org/tr/xhtml1/dtd/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
Ошибка валидатора: Missing DOCTYPE
Пояснение: DOCTYPE зависим к регистру
Правильно:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="<a>http://www.w3.org/1999/xhtml</a>" >
Не прописан закрывающий «/»
Пример:
…style.css" type="text/css" media="screen">
Пояснение: «пустые элементы», как img или br, должны заканчиваться»/» c пробелом перед этим
Правильно:
…style.css» type=»text/css» media=»screen» />
Тэги прописаны в верхнем регистре
Пример:
<STRONG><LI>...</LI></STRONG>
Ошибка валидатора: There is no such element…
Пояснение: в XHTML документах все элементы и атрибуты должны быть в нижнем регистре, т.к. этот язык регистрозависим и для него <li> и < разные тэгиLI>
Правильно:
<strong><li>...</li></strong>
Значения атрибутов прописаны без кавычек
Пример:
<style type=text/css>...</style>
Ошибка валидатора: Missing » »
Пояснение: значения атрибутов пишутся вместе с кавычками
Правильно:
<style type="text/css">...</style>
У img отсутствует атрибут alt
Пример:
<img src="/image/1.png" height="10" width="10" alt="" title="">
Ошибка валидатора: required attribute «alt» not specified
Пояснение: у тега img атрибут alt должен быть всегда, значение можно оставить пустым, если картинка используется для оформления
Правильно:
<img src="/image/1.png" height="10" width="10" alt="" title="">
В итоге вы сможете исправить ошибки сайта и сделать сайт валидным.
Наличие ошибок в коде страницы сайта всегда влечет за собой негативные последствия – от ухудшения позиций в ранжировании до жалоб со стороны пользователей. Ошибки валидации могут наблюдаться как на главной, так и на иных веб-страницах, их наличие свидетельствует о том, что ресурс является невалидным. Некоторые проблемы замечают даже неподготовленные пользователи, другие невозможно обнаружить без предварительного аудита, анализа. О том, что такое ошибки валидации и как их обнаружить, мы сейчас расскажем.
Ошибка валидации, что это такое?
Для написания страниц используется HTML – стандартизированный язык разметки, применяемый в веб-разработке. HTML, как любой другой язык, имеет специфические особенности синтаксиса, грамматики и т. д. Если во время написания кода правила не учитываются, то после запуска сайта будут появляться различные виды проблем. Если HTML-код ресурса не соответствует стандарту W3C, то он является невалидным, о чем мы писали выше.
Почему ошибки валидации сайта оказывают влияние на ранжирование, восприятие?
Наличие погрешностей в коде – проблема, с которой необходимо бороться сразу после обнаружения. Поисковые системы «читают» HTML-код, если он некорректный, то процесс индексации и ранжирования может быть затруднен. Поисковые роботы должны понимать, каким является ресурс, что он предлагает, какие запросы использует. Особо критичны такие ситуации для ресурсов, имеющих большое количество веб-страниц.
Как проверить ошибки валидации?
Для этой работы используется либо технический аудит сайта, либо валидаторы, которые ищут проблемы автоматически. Одним из самых популярных является сервис The W3C Markup Validation Service, выполняющий сканирование с оглядкой на World Wide Web Consortium (W3C). Рассматриваемый валидатор предлагает три способа, с помощью которых можно осуществить проверку сайта:
- ввод URL-адреса страниц, которые необходимо просканировать;
- загрузка файла страницы;
- ввод части HTML-кода, нуждающегося в проверке.
После завершения проверки вы получите развернутый список выявленных проблем, дополненных описанием, ссылками на стандарты W3C. По ходу анализа вы увидите слабые места со ссылками на правила, что позволит самостоятельно исправить проблему.
Существуют другие сервисы, позволяющие выполнить проверку валидности кода:
- Dr. Watson. Проверяет скорость загрузки страниц, орфографию, ссылки, а также исходный код;
- InternetSupervision.com. Отслеживает производительность сайта, проверяет доступность HTML.
Плагины для браузеров, которые помогут найти ошибки в коде
Решить рассматриваемую задачу можно с помощью плагинов, адаптированных под конкретный браузер. Можно использовать следующие инструменты (бесплатные):
- HTML Validator для браузера Firefox;
- HTML Validator for Chrome;
- Validate HTML для Firefox.
После проверки нужно решить, будете ли вы устранять выявленные ошибки. Многие эксперты акцентируют внимание на том, что поисковые системы сегодня уделяют больше внимания качеству внешней/внутренней оптимизации, контенту, другим характеристикам. Однако валидность нельзя оставлять без внимания, ведь если даже обнаруженные проблемы не будут мешать поисковым ботам, то они точно начнут раздражать посетителей сайта.
Как исправить ошибку валидации?
Для этой работы используется либо технический аудит сайта, либо валидаторы, которые ищут проблемы автоматически. Одним из самых популярных является сервис The W3C Markup Validation Service, выполняющий сканирование с оглядкой на World Wide Web Consortium (W3C). Рассматриваемый валидатор предлагает три способа, с помощью которых можно осуществить проверку сайта:
- ввод URL-адреса страниц, которые необходимо просканировать;
- загрузка файла страницы;
- ввод части HTML-кода, нуждающегося в проверке.
После завершения проверки вы получите развернутый список выявленных проблем, дополненных описанием, ссылками на стандарты W3C. По ходу анализа вы увидите слабые места со ссылками на правила, что позволит самостоятельно исправить проблему.
Существуют другие сервисы, позволяющие выполнить проверку валидности кода:
- Dr. Watson. Проверяет скорость загрузки страниц, орфографию, ссылки, а также исходный код;
- InternetSupervision.com. Отслеживает производительность сайта, проверяет доступность HTML.
Плагины для браузеров, которые помогут найти ошибки в коде
Решить рассматриваемую задачу можно с помощью плагинов, адаптированных под конкретный браузер. Можно использовать следующие инструменты (бесплатные):
- HTML Validator для браузера Firefox;
- HTML Validator for Chrome;
- Validate HTML для Firefox.
После проверки нужно решить, будете ли вы устранять выявленные ошибки. Многие эксперты акцентируют внимание на том, что поисковые системы сегодня уделяют больше внимания качеству внешней/внутренней оптимизации, контенту, другим характеристикам. Однако валидность нельзя оставлять без внимания, ведь если даже обнаруженные проблемы не будут мешать поисковым ботам, то они точно начнут раздражать посетителей сайта.
Как исправить ошибку валидации?
В первую очередь нужно сосредоточить внимание на слабых местах, связанных с контентом – это то, что важно для поисковых систем. Если во время сканирования было выявлено более 25 проблем, то их нельзя игнорировать из-за ряда причин:
- частичная индексация;
- медленная загрузка;
- баги, возникающие во время непосредственной коммуникации пользователя с ресурсом.
Например, игнорирование ошибок может привести к тому, что некоторые страницы не будут проиндексированы. Для решения рассматриваемой проблемы можно привлечь опытного фрилансера, однако лучшее решение – заказ услуги в веб-агентстве, что позволит исправить, а не усугубить ситуацию.
Технический и SEO-аудит
Выявление ошибок – первый шаг, ведь их еще нужно будет устранить. При наличии большого пула проблем целесообразно заказать профессиональный аудит сайта. Он поможет найти разные виды ошибок, повысит привлекательность ресурса для поисковых ботов, обычных пользователей: скорость загрузки страниц, верстка, переспам, другое.
В заключение
На всех сайтах наблюдаются ошибки валидации – их невозможно искоренить полностью, но и оставлять без внимания не стоит. Например, если провести проверку сайтов Google или «Яндекс», то можно увидеть ошибки, однако это не означает, что стоит вздохнуть спокойно и закрыть глаза на происходящее. Владелец сайта должен ставить во главу угла комплексное развитие, при таком подходе ресурс будет наполняться, обновляться и «лечиться» своевременно. Если проблем мало, то можно попробовать устранить их своими силами или с помощью привлечения стороннего частного специалиста. В остальных случаях лучше заказать услугу у проверенного подрядчика.
Приветствую вас на моем сайте!
В этой статье я расскажу вам как проверить сайт на валидность и нужно ли делать это вообще, а так же более подробно остановлюсь на проверке валидности HTML, покажу как использовать w3c валидатор и исправлять возникающие ошибки.
Приветствую вас на моем сайте!
В этой статье я расскажу вам как проверить сайт на валидность и нужно ли делать это вообще, а так же более подробно остановлюсь на проверке валидности HTML, покажу как использовать w3c валидатор и исправлять возникающие ошибки.
Что такое валидатор?
Валидаторы HTML и CSS представляют собой онлайн-сервисы, которые проверяют ваш сайт на соответствие его определенным стандартам и правилам.
Данные правила устанавливает консорциум W3С в который входят крупнейшие компании, такие как: Google, Microsoft, Opera, Mozilla, Apple, IBM и многие другие.
Зачем нужна валидация?
Необходимость валидации кода возникла тогда, когда веб-технологии начали развиваться очень быстрыми темпами. В CSS и HTML стало появляться множество возможностей и веб-разработчики, конечно же, их использовали для своих проектов, причем делали это кто как хотел.
Так же, стало появляться множество различных браузеров, которые могли по-разному отображать одни и те же элементы веб-страницы.
Консорциум W3C был создан для того, что бы как-то стандартизировать и прописать определенный свод правил и требований, прежде всего, к HTML и CSS коду.
То есть основная идея всех этих правил заключается в том, что если на вашем сайте нет никаких ошибок валидации, то он должен одинаково отображаться во всех браузерах, то есть быть кроссбраузерным. Но на самом деле это далеко не всегда так!
В большинстве случаев, даже если сайт не имеет никаких ошибок при проверке на валидность это не дает вообще ни каких гарантий того, что он будет одинаково и корректно отображаться во всех браузерах.
Так же, есть множество примеров, когда кроссбраузерные сайты, которые одинаково отображаются в разных браузерах, содержат в себе множество ошибок и предупреждений при проверке сайта на валидность.
В любом случае проверять сайт на валидность нужно, потому что это позволяет вам выявить некоторые очень грубые ошибки, которые, впоследствии, могут негативным образом сказаться на работе вашего сайта, на отображении его в различных браузерах и на разных устройствах.
Как проверить сайт на валидность?
Давайте посмотрим как выглядит проверка валидности HTML на практике.
Для проверки сайта на валидность кода нам понадобится сервис W3C Markup Validator.
Выглядит он следующим образом:
Здесь есть три вкладки:
На первой вкладке «Validate by URI» вы можете сразу же вставить адрес вашего сайта или какой-то его страницы.
На вкладке «Validate by file Upload» вы можете загрузить сюда файл HTML-страницы, который находится на вашем компьютере.
На вкладке Validate by Direct Input вы можете вставить готовый фрагмент кода который вы хотите проверить на ошибки.
Так как мы валидность сайта, то нам нужна будет вкладка «Validate by URI». В поле «Address» вставляем адрес проверяемого сайта и далее мы можем сразу же нажать на кнопку «Check», либо можем нажать на ссылку «More Options» и посмотреть, какие есть еще настройки у W3C валидатора.
Если у вас, в теле документа, не задана кодировка, что бывает очень редко, и, в принципе, этого быть не должно, то вы можете, в поле Character Encoding, выбрать кодировку вашего сайта вручную.
Так же если в теле вашего html-документа не задан атрибут DOCTYPE, то вы можете выбрать его из раскрывающегося списка Document Type. Здесь есть множество различных стандартов и вам нужно выбрать по правилам какого стандарта вы хотите проверять сайт на валидность.
Если вы ничего не понимаете в кодировках и доктайпах лучше здесь вообще ничего не трогать и оставить все по умолчанию.
В следующей строке вы можете настроить вывод результатов проверки валидатора W3C:
List Messages Sequentially – выводит все ошибки и предупреждения, возникающие при валидации последовательно.
Group Error Messages by Type – позволяет сгруппировать все ошибки валидации по типу.
Show Source – отображает исходный код страницы
Show Outline – отображение строки в которой валидатор нашёл ошибку.
Clean up Markup with HTML-Tidy – позволяет вывести строку с уже исправленной ошибкой, то есть правильным html-кодом. Это осуществляется при помощи программы HTML-Tidy, и консорциум W3C не дает никаких гарантий, что данный код будет на 100% правильный.
Validate error pages – позволяет проверить на валидность страницу 404, которая выдается в случае если человек вводит не правильный адрес страницы на сайте.
Verbose Output – позволяет вывести подробную информацию.
Я обычно здесь ничего не ставлю. Просто ввожу адрес сайта и нажимаю на кнопку «Check», а дальше смотрю на список ошибок и предупреждений, который возникают на проверяемом сайте.
После нажатия на кнопку «Check», отображается список ошибок и предупреждений, возникших в процессе проверки валидности HTML.
На данном сайте есть два предупреждения — они выделяются желтым цветом, и две ошибки – они выделяются красным цветом.
Давайте посмотрим на саму структуру вывода предупреждений и ошибок.
В первой строке выводится текст самой ошибки, где указывается название определенных атрибутов, которые не понравились валидатору W3C и названия тегов, в которых они встречаются.
В данном предупреждении написано, что атрибут role со значением banner не является обязательным для элемента header.
Во второй строке указывается, с какой строки, и с какого столбца по какую строку, и какой столбец был найден фрагмент кода с ошибкой.
То есть, наш код начинается со строки 52 столбец 2, и заканчивается в строке 52 столбец 57.
В третей строке отображается, текст самого кода. Он выделенный желтым цветом.
В данном случае, для того чтобы исправить это предупреждение, нам нужно убрать атрибут role у тега header, потому что он здесь, в принципе, не нужен и вызывает предупреждение при проверке валидности.
Для этого мы можем открыть нашу страницу и найти строку 52 столбец 2. Но это далеко не всегда эффективно, потому что если ваш сайт на каком-то движке, то вся файловая часть сайта разбита на множество различных файлов шаблона и там все выводится при помощи php и найти там данную строку будет очень сложно.
Поэтому, мы берем и копируем строчку с данным кодом и затем находим ее в файлах шаблона темы и уже там исправляем.
Тоже самое касается всех остальных ошибок и предупреждений, найденных валидатором W3C.
Конечно же универсального рецепта по исправлению всех ошибок нет. Здесь нужно смотреть на то, какой у вас сайт, какие у вас используются элементы, в каких фрагментах кода выдаются те или иные ошибки.
Очень часто бывает так, что для организации, к примеру, галереи приходится для изображений этой галереи присваивать атрибуты rel, и потом, когда страница проверяется валидатором, он начинает на них ругаться. Но если эти атрибуты удалить, то галерея перестанет работать. При этом, данная ошибка вообще ни как не повлияет на отображение сайта в браузерах, но тем не менее она у вас будет, и здесь вам нужно будет просто выбирать, чего вы хотите больше: чистого валидного кода, либо красивую галерею на вашем сайте.
Нужно ли проверять сайт на валидность вообще?
Я для себя сделала следующий вывод:
Проверку валидности HTML проводить нужно, но доводить ее до совершенства, что бы на сайте не было ни единой ошибочки, нужно далеко не всегда. То есть в первую очередь, нужно исправить все грубые ошибки валидации, которые могут повлиять на работоспособность сайта в будущем и на его отображение в разных браузерах.
Если же ошибки не значительные и их устранение повлечет за собой какие-то негативные последствия, то их можно спокойно оставить и ничего страшного здесь не произойдет, на кроссбраузерность сайта это не повлияет и на поисковой выдаче, с вероятностью 99%, это тоже не отобразится.
Google уже отказался от учета валидности сайта при ранжировании страниц. Яндекс пока еще не отказался, но судя по тому, какие страницы находятся у него в топе, он этот фактор либо учитывает в незначительной степени, либо не учитывает вообще.
Видеоинструкция
Если у вас мало опыта в верстке и разработке сайтов, то, скорее всего, самостоятельно вы не сможете определить, какая ошибка валидации является грубой, а какая нет. Здесь лучше всего будет обратиться к специалисту либо за консультацией, либо с просьбой проверить ваш сайт на валидность с последующим исправлением ошибок.
Надеюсь, что у вас не возникнет проблем с валидатором и проверкой вашего сайта. Если у вас будут возникать какие-то вопросы – вы всегда их можете задать через форму комментариев.
На этом у меня все. Подписывайтесь на мою рассылку и на мой канал на YouTube и до встречи в следующих статьях.
С уважением Юлия Гусарь
В этой статье мы рассмотрим, как с помощью сервиса Labrika обнаружить и исправить на сайте HTML-ошибки. Информация о таких ошибках будет полезна как для владельца веб-ресурса, который контролирует работу своего SEO-специалиста и хочет знать, какие нерешенные проблемы есть на сайте, так и для оптимизаторов, поскольку им нужно оперативно обнаружить и исправить все изъяны, мешающие продвижению ресурса.
HTML (от англ. HyperText Markup Language) — это язык гипертекстовой разметки, который применяется на каждой веб-странице в интернете и состоит из множества элементов (тегов). Как правило, ошибками в коде HTML являются незакрытые или дублированные элементы, неправильный порядок их расположения, неверные атрибуты или их отсутствие.
На примере ниже в коде страницы присутствует закрывающий тег ссылки </a> без открывающего тега <a>:
Для проверки валидности кода (то есть соответствия стандартам HTML) используются специальные инструменты. Они проверяют:
- Синтаксические ошибки: пропущенные символы, ошибки в написании тегов.
- Нарушения вложенности тэгов: незакрытые и неправильно закрытые теги. По правилам теги закрываются так же, как их открыли, только в обратном порядке.
- Соответствие кода указанному DTD (Document Type Definition): правильность названий тегов, вложенности, атрибутов. Наличие пользовательских тегов и атрибутов.
Как HTML-ошибки влияют на продвижение сайта?
Как отмечал представитель Google Джон Мюллер, валидность кода HTML не является прямым фактором ранжирования, однако критические ошибки в HTML мешают:
- сканированию сайта поисковыми ботами;
- определению структурированной разметки на странице;
- отображению на мобильных устройствах и кроссбраузерности.
В первую очередь наличие ошибок в коде HTML может привести к тому, что часть контента страницы не будет проиндексирована.
О том, что следует использовать действительный HTML, сказано в Рекомендациях Google для веб-мастеров. Среди авторитетных SEO-источников бытует мнение, что фильтр Google Panda может быть наложен на сайт за большое количество таких ошибок (отдельную статью об алгоритме Google Panda вы можете прочитать на нашем сайте).
Официальные источники Яндекса также сообщают, что подобного рода ошибки на сайте нежелательны, а верстка страниц должна соответствовать принятым стандартам.
Почему важно проверять наличие HTML-ошибок?
Ошибки в коде HTML могут быть критическими и несущественными, которые не ведут к серьезным потерям. Что касается критических, то одни из них отрицательно сказываются на функционировании сайта, а другие — на работе поисковых систем.
Современные браузеры автоматически исправляют 99% критических ошибок при загрузке сайта. Однако некоторые из них браузер исправить не может. Например, если тег <а> для создания ссылки не содержит адреса, то браузер не сможет определить, куда её направить. Или в теге <img> для размещения картинки не указан путь к ней, тогда браузер не сможет её подгрузить. Наличие таких ошибок в коде может привести к серьезным последствиям — например, не загрузятся фото товара или не будет работать корзина.
Поисковые системы также автоматически исправляют часть HTML-ошибок, но у них возникает следующая проблема: если браузеры в состоянии потратить несколько секунд на исправление ошибок, то у поисковых роботов нет такой возможности. Им приходится сканировать сотни миллиардов страниц ежемесячно, поэтому боты не могут тратить время на устранение всех ошибок. Некоторые из них поисковые системы игнорируют, а также могут не включать в индекс содержащие их страницы или проиндексировать только часть контента таких страниц.
Веб-мастера и пользователи просматривают сайты в браузере, где большая часть HTML-ошибок исправляется автоматически, и поэтому не придают им большого значения. Зачастую даже разработчики не исправляют элементарных грубых ошибок в разметке. Это приводит к тому, что критические для поисковых систем ошибки остаются на сайтах и могут стать причиной неправильной индексации страниц. В результате бюджеты на продвижение будут потрачены неэффективно, а источник проблемы так и остается неустановленным.
Как обнаружить HTML-ошибки с помощью сервиса Labrika
Labrika проверяет данные ошибки двумя способами:
- С помощью валидатора W3C, который проверяет наличие всех HTML-ошибок.
- С использованием валидатора Labrika «Критические ошибки HTML». Он устанавливает только те ошибки, которые могут повлиять на сбор данных поисковыми системами или привести к некорректному отображению сайта и нарушениям в его работе. определяет порядка 15 видов таких ошибок.
Отчет » Критические ошибки HTML» вы сможете найти в левом боковом меню в разделе «Технический аудит».
Актуальные данные в отчете вы сможете увидеть после запуска проверки сайта.
Отчет показывает:
- Страницы, которые содержат критические ошибки HTML.
- Количество и описание критических HTML-ошибок на данной странице.
При клике по их числу осуществляется переадресация на валидатор W3C, в котором вы сможете найти подробную информацию обо всех имеющихся в коде страницы ошибках.
Как исправлять HTML-ошибки?
Критические HTML-ошибки необходимо исправлять в первую очередь, так как поисковые системы могут отреагировать на них отрицательно. Влияние прочих ошибок на продвижение в поиске не доказано.
Если для исправления ошибок требуется передать их список специалисту по верстке, с помощью кнопок в правой части страницы отчета вы можете скачать его данные в формате таблицы Excel или поделиться ссылкой на отчет по HTML-ошибкам с другими пользователями.
После нажатия на значок ссылки появится следующее всплывающее окно:
Кнопка, которая расположена справа от ссылки, позволяет скопировать её в буфер обмена. Отчет по ссылке будет доступен даже тем, кто не имеет аккаунта в Labrika.
Для ускорения работы по исправлению HTML-ошибок можно воспользоваться редакторами, которые автоматически создают закрывающие теги для документов HTML (например, Bluefish, Notepad++).
Как проверить CSS и HTML-код на валидность и зачем это нужно.
В статье:
-
Что такое валидность кода
-
Чем ошибки в HTML грозят сайту
-
Как проверить код на валидность
-
HTML и CSS валидаторы — онлайн-сервисы для проверки кода
Разберем, насколько критическими для работы сайта и его продвижения могут быть ошибки в HTML-коде, и зачем нужны общие стандарты верстки.
Что такое валидность кода
После разработки дизайна программисты верстают страницы сайта — приводят их к единой структуре в формате HTML. Задача верстальщика — сделать так, чтобы страницы отображались корректно у всех пользователей на любых устройствах и браузерах. Такая верстка называется кроссплатформенной и кроссбраузерной — это обязательное требование при разработке любых сайтов.
Для этого есть специальные стандарты: если им следовать, страницу будут корректно распознавать все браузеры и гаджеты. Такой стандарт разработал Консорциумом всемирной паутины — W3C (The World Wide Web Consortium). HTML-код, который ему соответствует, называют валидным.
Валидность также касается файлов стилей — CSS. Если в CSS есть ошибки, визуальное отображение элементов может нарушиться.
Разработчикам рекомендуется следовать критериям этих стандартов при верстке — это поможет избежать ошибок в коде, которые могут навредить сайту.
Чем ошибки в HTML грозят сайту
Типичные ошибки кода — незакрытые или дублированные элементы, неправильные атрибуты или их отсутствие, отсутствие кодировки UTF-8 или указания типа документа.
Какие проблемы могут возникнуть из-за ошибок в HTML-коде
- страницы загружаются медленно;
- сайт некорректно отображается на разных устройствах или в браузерах;
- посетители видят не весь контент;
- программист не замечает скрытую рекламу и вредоносный код.
Как валидность кода влияет на SEO
Валидность не является фактором ранжирования в Яндекс или Google, так что напрямую она не влияет на позиции сайта в выдаче поисковых систем. Но она влияет на мобилопригодность сайта и на то, как поисковые боты воспринимают разметку, а от этого косвенно могут пострадать позиции или трафик.
Почитать по теме:
Главное о микроразметке: подборка знаний для веб-мастеров
Представитель Google Джон Мюллер говорил о валидности кода:
«Мы упомянули использование правильного HTML. Является ли фактором ранжирования валидность HTML стандарту W3C?
Это не прямой фактор ранжирования. Если ваш сайт использует HTML с ошибками, это не значит, что мы удалим его из индекса — я думаю, что тогда у нас будут пустые результаты поиска.
Но есть несколько важных аспектов:— Если у сайта действительно битый HTML, тогда нам будет очень сложно его отсканировать и проиндексировать.
— Иногда действительно трудно подобрать структурированную разметку, если HTML полностью нарушен, поэтому используйте валидатор разметки.
— Другой аспект касается мобильных устройств и поддержки кроссбраузерности: если вы сломали HTML, то сайт иногда очень трудно рендерить на новых устройствах».
Итак, критические ошибки в HTML мешают
- сканированию сайта поисковыми ботами;
- определению структурированной разметки на странице;
- рендерингу на мобильных устройствах и кроссбраузерности.
Даже если вы уверены в своем коде, лучше его проверить — ошибки могут возникать из-за установки тем, сторонних плагинов и других элементов, и быть незаметными. Не все программисты ориентируются на стандарт W3C, так что среди готовых решений могут быть продукты с ошибками, особенно среди бесплатных.
Как проверить код на валидность
Не нужно вычитывать код и считать символы — для этого есть сервисы и инструменты проверки валидности HTML онлайн.
Что они проверяют:
- Синтаксис
Синтаксические ошибки: пропущенные символы, ошибки в написании тегов. - Вложенность тэгов
Незакрытые и неправильно закрытые теги. По правилам теги закрываются также, как их открыли, но в обратном порядке. Частая ошибка — нарушенная вложенность.
- DTD (Document Type Definition)
Соответствие кода указанному DTD, правильность названий тегов, вложенности, атрибутов. Наличие пользовательских тегов и атрибутов — то, чего нет в DTD, но есть в коде.
Обычно сервисы делят результаты на ошибки и предупреждения. Ошибки — опечатки в коде, пропущенные или лишние символы, которые скорее всего создадут проблемы. Предупреждения — бессмысленная разметка, лишние символы, какие-то другие ошибки, которые скорее всего не навредят сайту, но идут вразрез с принятым стандартом.
Валидаторы не всегда правы — некоторые ошибки не мешают браузерам воспринимать код корректно, зато, к примеру, минификация сокращает длину кода, удаляя лишние пробелы, которые не влияют на его отображение.
Почитать по теме:
Уменьшить вес сайта с помощью gzip, brotli, минификации и других способов
Поэтому анализируйте предложения сервисов по исправлениям и ориентируйтесь на здравый смысл.
Перед исправлением ошибок не забудьте сделать резервное копирование. Если вы исправите код, но что-то пойдет не так и он перестанет отображаться, как должен, вы сможете откатить все назад.
HTML и CSS валидаторы — онлайн-сервисы для проверки кода
Есть довольно много валидаторов, выберите тот, в котором вам удобнее работать. Мы рекомендуем использовать известные сервисы от создателей стандартов. Если пояснения на английском воспринимать сложно, можно использовать автоматический перевод страницы.
Валидатор от W3C
Англоязычный сервис, онлайн проверяет соответствие HTML стандартам: можно проверить код по URL, залить файл или вставить код в окошко.
Инструмент покажет список ошибок и предупреждений с пояснениями — описанием ошибки и ее типом, а также укажет номер строки, в которой нужно что-то исправить. Цветом отмечены типы предупреждений и строчки с кодом.
Валидатор CSS от W3C
Инструмент от W3C для проверки CSS, есть русский язык. Работает по такому же принципу, анализирует стили на предмет ошибок и предупреждений. Первым идет блок ошибок, предупреждения собраны ниже отдельно.
Исправления ошибок и валидации HTML и CSS может быть недостаточно: всегда есть другие возможности испортить отображение сайта. Если что-то не работает, как надо, проведите полноценный аудит, чтобы найти ошибки.
С другой стороны, не зацикливайтесь на поиске недочетов в HTML — если код работает, а контент отображается корректно, лучше направить ресурсы на что-то другое — оптимизацию и ускорение загрузки, например.
В этой статье мы рассмотрим, как с помощью сервиса Labrika обнаружить и исправить на сайте HTML-ошибки. Информация о таких ошибках будет полезна как для владельца веб-ресурса, который контролирует работу своего SEO-специалиста и хочет знать, какие нерешенные проблемы есть на сайте, так и для оптимизаторов, поскольку им нужно оперативно обнаружить и исправить все изъяны, мешающие продвижению ресурса.
HTML (от англ. HyperText Markup Language) — это язык гипертекстовой разметки, который применяется на каждой веб-странице в интернете и состоит из множества элементов (тегов). Как правило, ошибками в коде HTML являются незакрытые или дублированные элементы, неправильный порядок их расположения, неверные атрибуты или их отсутствие.
На примере ниже в коде страницы присутствует закрывающий тег ссылки </a> без открывающего тега <a>:
Для проверки валидности кода (то есть соответствия стандартам HTML) используются специальные инструменты. Они проверяют:
- Синтаксические ошибки: пропущенные символы, ошибки в написании тегов.
- Нарушения вложенности тэгов: незакрытые и неправильно закрытые теги. По правилам теги закрываются так же, как их открыли, только в обратном порядке.
- Соответствие кода указанному DTD (Document Type Definition): правильность названий тегов, вложенности, атрибутов. Наличие пользовательских тегов и атрибутов.
Как HTML-ошибки влияют на продвижение сайта?
Как отмечал представитель Google Джон Мюллер, валидность кода HTML не является прямым фактором ранжирования, однако критические ошибки в HTML мешают:
- сканированию сайта поисковыми ботами;
- определению структурированной разметки на странице;
- отображению на мобильных устройствах и кроссбраузерности.
В первую очередь наличие ошибок в коде HTML может привести к тому, что часть контента страницы не будет проиндексирована.
О том, что следует использовать действительный HTML, сказано в Рекомендациях Google для веб-мастеров. Среди авторитетных SEO-источников бытует мнение, что фильтр Google Panda может быть наложен на сайт за большое количество таких ошибок (отдельную статью об алгоритме Google Panda вы можете прочитать на нашем сайте).
Официальные источники Яндекса также сообщают, что подобного рода ошибки на сайте нежелательны, а верстка страниц должна соответствовать принятым стандартам.
Почему важно проверять наличие HTML-ошибок?
Ошибки в коде HTML могут быть критическими и несущественными, которые не ведут к серьезным потерям. Что касается критических, то одни из них отрицательно сказываются на функционировании сайта, а другие — на работе поисковых систем.
Современные браузеры автоматически исправляют 99% критических ошибок при загрузке сайта. Однако некоторые из них браузер исправить не может. Например, если тег <а> для создания ссылки не содержит адреса, то браузер не сможет определить, куда её направить. Или в теге <img> для размещения картинки не указан путь к ней, тогда браузер не сможет её подгрузить. Наличие таких ошибок в коде может привести к серьезным последствиям — например, не загрузятся фото товара или не будет работать корзина.
Поисковые системы также автоматически исправляют часть HTML-ошибок, но у них возникает следующая проблема: если браузеры в состоянии потратить несколько секунд на исправление ошибок, то у поисковых роботов нет такой возможности. Им приходится сканировать сотни миллиардов страниц ежемесячно, поэтому боты не могут тратить время на устранение всех ошибок. Некоторые из них поисковые системы игнорируют, а также могут не включать в индекс содержащие их страницы или проиндексировать только часть контента таких страниц.
Веб-мастера и пользователи просматривают сайты в браузере, где большая часть HTML-ошибок исправляется автоматически, и поэтому не придают им большого значения. Зачастую даже разработчики не исправляют элементарных грубых ошибок в разметке. Это приводит к тому, что критические для поисковых систем ошибки остаются на сайтах и могут стать причиной неправильной индексации страниц. В результате бюджеты на продвижение будут потрачены неэффективно, а источник проблемы так и остается неустановленным.
Как обнаружить HTML-ошибки с помощью сервиса Labrika
Labrika проверяет данные ошибки двумя способами:
- С помощью валидатора W3C, который проверяет наличие всех HTML-ошибок.
- С использованием валидатора Labrika «Критические ошибки HTML». Он устанавливает только те ошибки, которые могут повлиять на сбор данных поисковыми системами или привести к некорректному отображению сайта и нарушениям в его работе. определяет порядка 15 видов таких ошибок.
Отчет » Критические ошибки HTML» вы сможете найти в левом боковом меню в разделе «Технический аудит».
Актуальные данные в отчете вы сможете увидеть после запуска проверки сайта.
Отчет показывает:
- Страницы, которые содержат критические ошибки HTML.
- Количество и описание критических HTML-ошибок на данной странице.
При клике по их числу осуществляется переадресация на валидатор W3C, в котором вы сможете найти подробную информацию обо всех имеющихся в коде страницы ошибках.
Как исправлять HTML-ошибки?
Критические HTML-ошибки необходимо исправлять в первую очередь, так как поисковые системы могут отреагировать на них отрицательно. Влияние прочих ошибок на продвижение в поиске не доказано.
Если для исправления ошибок требуется передать их список специалисту по верстке, с помощью кнопок в правой части страницы отчета вы можете скачать его данные в формате таблицы Excel или поделиться ссылкой на отчет по HTML-ошибкам с другими пользователями.
После нажатия на значок ссылки появится следующее всплывающее окно:
Кнопка, которая расположена справа от ссылки, позволяет скопировать её в буфер обмена. Отчет по ссылке будет доступен даже тем, кто не имеет аккаунта в Labrika.
Для ускорения работы по исправлению HTML-ошибок можно воспользоваться редакторами, которые автоматически создают закрывающие теги для документов HTML (например, Bluefish, Notepad++).
Как строить и построить
Время на прочтение
11 мин
Количество просмотров 3.3K
Предыстория
Встретившись в многочисленных местах разработки на Javascript с ситуациями, где необходимо было проводить валидацию значений, стало понятно, что необходимо как-то решить этот вопрос. С этой целью была поставлена следующая задача:
Разработать библиотеку, которая будет давать возможность:
- валидировать типы данных;
- задавать дефолтные значения вместо невалидных полей или элементов;
- удалять невалидные части объекта или массива;
- получать сообщение об ошибке;
В основе которой будет:
- Легкость в освоении
- Читабельность получаемого кода.
- Легкость модификации кода
Для достижения этих целей была разработана библиотека валидации quartet.
Основные кирпичи валидации
В основе большинства систем, которые расчитываются быть применимыми в широком кругу задач, лежат простейшие элементы: действия, данные и алгоритмы. А также методы их композиции — с целью из простейших элементов собрать что-то более сложное для решения более сложных задач.
Валидатор
В основе библиотеки quartet — лежит понятие валидатора. Валидаторами в данной библиотеке являются функциями следующего вида
function validator(
value: any,
{ key: string|int, parent: any },
{ key: string|int, parent: any },
...
): booleanВ данном определении есть несколько вещей, которые стоит описать подробнее:
function(...): boolean — говорит о том, что валидатор — вычисляет результат валидации, и результатом валидации является булевое значение — истинно или ложно, соответственно валидно или не валидно
value: any — говорит о том, что валидатор — вычисляет результат валидации значения, которое может быть любым значением javascript’a. Валидатор либо относит данное валидируемое значение к валидным или либо к невалидным.
{ key: string|int, parent: any }, ... — говорит о том, валидируемое значение может быть в разных контекстах в зависимости от того, на каком уровне вложенности находится значение. Покажем это на примерах
Пример значения без какого-либо контекста
const value = 4;
// Это значение не находится в контексте другой структуры данных.
// Чтобы валидатор его провалидировал он вызывается на самом значении:
const isValueValid = validator(4)Пример значения в контексте массива
// ключи 0 1 2 3 4
const arr = [1, 2, 3, value, 5]
// В массиве данное значение находится под индексом(kеу): 3
// Родителем в данном контексте является массив: [1, 2, 3, value, 5]
// Поэтому при валидации value - валидатор вызывается с такими параметрами
const isValueValid = validator(4, { key: 3, parent: [1,2,3,4,5] })Пример значения в контексте объекта
const obj = {
a: 1,
b: 2,
c: value,
d: 8
}
// В данном обьекте значение имеет ключ равный 'c'
// Родителем в данном контексте является весь объект: { a: 1, b: 2, c: 4, d: 8 }
// Поэтому при валидации value - валидатор вызывается
// с такими параметрами:
const isValueValid = validator(4, { key: 'c', parent: { a: 1, b: 2, c: 4, d: 8 } })Так как структуры в объекте могут иметь бо́льшую вложенность, то имеет смысл говорить и о множестве контекстов
const arrOfObj = [{
a: 1,
b: 2,
c: value,
d: 8
},
// ...
]
// В данном cлуче значение имеет ключ равный 'c'
// Первым родителем является объект: { a: 1, b: 2, c: 4, d: 8 }
// В свою очередь родителем родителя является массив arrOfObj,
// в котором объект находится под индексом 0.
// Поэтому при валидации value - валидатор вызывается с такими параметрами
const isValueValid = validator(
4,
{ key: 'c', parent: { a: 1, b: 2, c: 4, d: 8 } }
{ key: 0, parent: [{ a: 1, b: 2, c: 4, d: 8 }] }
)И так далее.
О сходстве с методами массивов
Данное определение валидатора должно вам напомнить определение функций, которые передаются в качестве аргумента в методы массивов, такие как: map, filter, some, every и тд.
- Первым аргументом этих функций является элемент массива
- Вторым аргументом — индекс элемента
- Третьим аргументом — сам массив
Валидатор в данном случае является более обобщённой функцией — он принимает не только индекс элемента в массиве и массив, но и индекс массива — в его родителе и его родителя и так далее.
Что нам стоит дом построить?
Кирпичи, описанные выше, ничем не выделяются в среде других «решений-камней», которые валяются на костыльном «пляже» javascript. Поэтому давайте построим из них, что-нибудь более стройное и интересное. Для этого у нас есть композиция.
Как построить небоскрёб валидации объектов?
Согласитесь, было бы удобно валидировать объекты таким образом, чтобы само описание валидации совпадало с описанием объекта. Для этого мы будем использовать объектную композицию валидаторов. Она выглядит следующим образом:
// Подключаем библиотеку валидации quartet
const quartet = require('quartet')
// Создаём композитор валидаторов (v - значит validator)
const v = quartet()
// Опишем схему объекта в контексте валидаторов,
// используемых для конкретных полей
const objectSchema = {
a: a => typeof a ==='string', // Валидатор типа 'string'
b: b => typeof b === 'number', // Валидатор типа 'number'
// ...
}
const compositeObjValidator = v(objectSchema)
const obj = {
a: 'some text',
b: 2
}
const isObjValid = compositeObjValidator(obj)
console.log(isObjValid) // => trueКак видим, из разных кирпичей-валидаторов, определённых для конкретных полей, мы можем собрать валидатор объекта — некоторое «маленькое здание», в котором ещё довольно тесно — но уже лучше чем без него. Для этого мы используем композитор валидаторов v. Всякий раз, встречая объектный литерал v на месте валидатора, он будет рассматривать его как объектную композицию, превращая его в валидатор объекта по его полям.
Иногда мы не можем описать все поля. Например, когда объект является словарём данных:
const quartet = require('quartet')
const v = quartet()
const isStringValidator = name => typeof name === 'string'
const keyValueValidator = (value, { key }) =>
value.length === 1 && key.length === 1
const dictionarySchema= {
dictionaryName: isStringValidator,
...v.rest(keyValueValidator)
}
const compositeObjValidator = v(dictionarySchema)
const obj = {
dictionaryName: 'next letter',
b: 'c',
c: 'd'
}
const isObjValid = compositeObjValidator(obj)
console.log(isObjValid) // => true
const obj2 = {
dictionaryName: 'next letter',
b: 'a',
a: 'invalid value',
notValidKey: 'a'
}
const isObj2Valid = compositeObjValidator(obj2)
console.log(isObj2Valid) // => falseКак переиспользовать строительные решения?
Как мы увидели выше, существует необходимость переиспользования простых валидаторов. В данных примерах нам уже пришлось использовать «валидатор типа строки» уже два раза.
Для того, чтобы укоротить запись и повысить её читаемость в библиотеке quartet используются строковые синонимы валидаторов. Всякий раз, когда композитор валидаторов встречает строку на месте, где должен быть валидатор, он ищет в словаре соответствующий ей валидатор и использует его.
По умолчанию в библиотеке уже определены самые распространённые валидаторы.
Рассмотрим примеры:
v('number')(1) // => true
v('number')('1') // => false
v('string')('1') // => true
v('string')(null) // => false
v('null')(null) // => true
v('object')(null) // => true
v('object!')(null) // => false
// ...и множество других описаных в документации.
Каждой арке — свой вид кирпичей?
Композитор валидаторов(функция v) также является фабрикой валидаторов. В том смысле, что содержит множество полезных методов, которые возвращают
- валидаторы-функции
- значения, которые композитором будут восприниматься как схемы для создания валидаторов
Например, посмотрим на валидацию массива: чаще всего она состоит из проверки типа массива и проверки всех его элементов. Воспользуемся для этого методом v.arrayOf(elementValidator). Для примера возьмём массив точек с именами.
const a = [
{x: 1, y: 1, name: 'A'},
{x: 2, y: 1, name: 'B'},
{x: -1, y: 2, name: 'C'},
{x: 1, y: 3, name: 'D'},
]Так как массив точек — это массив объектов, то имеет смысл использовать объектную композицию для валидации элементов массива.
const namedPointSchema = {
x: 'number', // number - один из именованных по умолчанию валидаторов
y: 'number',
name: 'string' // string - один из именованных по умолчанию валидаторов
}Теперь, с помощью фабричного метода v.arrayOf, создадим валидатор всего массива.
const isArrayValid = v.arrayOf({
x: 'number',
y: 'number',
name: 'string'
})Посмотрим как работает данный валидатор:
isArrayValid(0) // => false
isArrayValid(null) // => false
isArrayValid([]) // => true
isArrayValid([1, 2, 3]) // => false
isArrayValid([
{x: 1, y: 1, name: 'A'},
{x: 2, y: 1, name: 'B'},
{x: -1, y: 2, name: 'C'},
{x: 1, y: 3, name: 'D'},
]) // => trueЭто только один из фабричных методов, каждый из которых описан в документации
Как вы видели выше, v.rest также является фабричным методом, который возвращает объектную композицию, которая проверяет все поля не указанные в объектной композиции. А значит, может быть встроен в другую объектную композицию с помощью spread-operator.
Приведём в качестве примера использования нескольких из них:
// Подключаем библиотеку валидации quartet
const quartet = require('quartet')
// Создаём композитор валидаторов (v - значит validator)
const v = quartet()
// Рассмотрим такой объект, который описывает персонажа
const max = {
name: 'Maxim',
sex: 'male',
age: 34,
status: 'grandpa',
friends: [
{ name: 'Dima', friendDuration: '1 year'},
{ name: 'Semen', friendDuration: '3 months'}
],
workExperience: 2
}
// имя валидно, когда является "и" строкой,
// "и" не пустой, "и" первая буква - большая
const nameSchema = v.and(
'not-empty', 'string', // именованные валидаторы
name => name[0].toUpperCase() === name[0] // валидатор-функция
)
const maxSchema = {
name: nameSchema,
// Валидатор принадлежности к задданному множеству значений
sex: v.enum('male', 'female'),
// Возраст - положительное целое число.
// Используем именнованые валидаторы и фабричный метод "и"
age: v.and('non-negative', 'safe-integer'),
status: v.enum('grandpa', 'non-grandpa'),
friends: v.arrayOf({
name: nameSchema,
// валидируем строку по регулярному выражению
friendDuration: v.regex(/^[1-9]d? (years?|months?)$/)
}),
workExperience: v.and('non-negative', 'safe-integer')
}
console.log(v(maxSchema)(max)) // => trueБыть, или не быть?
Часто бывает так, что валидные данные принимают различные формы, например:
idможет быть числом, а может быть строкой.- Объект
pointможет содержать, а может не содержать некоторые координаты, в зависимости от размерности. - И множество других случаев.
Для организации валидации вариантов предусмотрен отдельный вид композиции — вариантная композиция. Она представляется массивом валидаторов возможных вариантов. Валидным считается объект, когда хоть один из валидаторов сообщил о его валидности.
Рассмотрим пример c валидацией идентификаторов:
const isValidId = v([
v.and('not-empty', 'string'), // Идентификатор может быть либо непустой строкой
v.and('positive', 'safe-integer') // Либо положительным числом
])
isValidId('') // => false
isValidId('asdba32bas321ab321adb321abds546ba98s7') // => true
isValidId(0) // => false
isValidId(1) // => true
isValidId(1123124) // => trueПример с валидацией точек:
const isPointValid = v([
{
// для первой размерности - должна быть только x координата
dimension: v.enum(1),
x: 'number',
// v.rest с функцией возвращающей false
// Означает, что дополнительные поля - невалидны
...v.rest(() => false)
},
// для второй - х и у
{
dimension: v.enum(2),
x: 'number',
y: 'number',
...v.rest(() => false)
},
// Для третьей - x, y и z
{
dimension: v.enum(3),
x: 'number',
y: 'number',
z: 'number',
...v.rest(() => false)
},
])
// Итого, валидной точкой считается та, у которой размерность не выше третьей, и для каждой размерности - соответствующее кол-во полей для координат
isPointValid(1) // => false
isPointValid(null) // => false
isPointValid({
dimension: 1,
x: 2
}) // => true
isPointValid({
dimension: 1,
x: 2,
y: 3 // лишнее поле
}) // => false
isPointValid({
dimension: 2,
x: 2,
y: 3
}) // => true
isPointValid({
dimension: 3,
x: 2,
y: 3,
z: 4
}) // => true
// ...Таким образом всякий раз, когда композитор видит массив, он будет считать его композицией валидаторов-элементов этого массива таким образом, что когда один из них посчитает значение валидным — расчёт валидации остановится — и значение будет признано валидным.
Как видим композитор считает валидатором не только функцию валидатор, но и всё, что может привести к функции валидатору.
| Тип валидатора | Пример | Как воспринимается композитором |
|---|---|---|
| функция валидации | x => typeof x === 'bigint' |
просто вызывается на необходимых значениях |
| объектная композиция | { a: 'number' } |
создает функцию валидатор для объекта на основании заданных валидаторов полей |
| Вариантная композиция | ['number', 'string'] |
Создаёт функцию валидатор для валидации значения минимум одним из вариантов |
| Результаты вызова фабричных методов | v.enum('male', 'female') |
Большинство фабричных методов возвращают функции валидации (за исключением v.rest, который возвращает объектную композицию), поэтому они трактуются как обычные функции валидации |
Все данные варианты валидаторов валидны и могут использоваться в любом месте внутри схемы, в котором должен стоять валидатор.
В итоге схема работы всегда такая: v(schema) возвращает функцию валидации. Далее эта функция валидации вызывается на конкретных значениях:
v(schema)(value[, ...parents])
У вас аварии на стройке были?
— Нет пока ещё не одной
— Будут!
Бывает так, что данные невалидны и нам нужно уметь определить причину невалидности.
Для этого в библиотеке quartet предусмотрен механизм объяснений. Он состоит в том, что в случае, когда валидатор, будь-то внутренний или внешний, обнаружит невалидность проверяемых данных — он должен отправить пояснительную записку.
Для этих целей используется второй аргумент композитора валидаторов v. Он добавляет сайд-еффект отправки пояснительной записки в массив v.explanation в случае невалидности данных.
Пример, пусть мы валидируем массив, и хотим узнать номера всех элементов, которые невалидны и их значение:
// Данная функция - будет вызвана при невалидности
// элемента массива
const getExplanation = (value, { key: index }) => ({
invalidValue: value,
index
})
// Видим, что её параметры совпадают с параметрами валидаторов.
// Результат же этой функции будет помещён в массив v.explanation
// Зададим валидатор массива
const arrValidator = v.arrayOf(
v(
'number', // валидатор числа
getExplanation // функция возвращающая "записку", или сама "записка"
)
)
// видим, что валидатором элемента является "объясняющий" валидатор
// Вторым параметром композитора является функция, которая возвращает объяснение ошибки
// Вторым параметром композитора может быть не только функция
// Но и значение, которое должно быть помещено как объяснение
const explainableArrValidator = v(arrValidator, 'this array is not valid')
const arr = [1, 2, 3, 4, '5', '6', 7, '8']
explainableArrValidator(arr) // => false
v.explanation
// [
// { invalidValue: '5', index: 4 },
// { invalidValue: '6', index: 5 },
// { invalidValue: '8', index: 7 },
// 'this array is not valid'
// ]Как видим, выбор объяснения зависит от задачи. Иногда оно даже не нужно.
Иногда нам необходимо что-то сделать с невалидными полями. В таких случаях имеет смысл использовать имя невалидного поля как объяснение:
const objSchema = {
a: v('number', 'a'),
b: v('number', 'b'),
c: v('string', 'c')
}
const isObjValid = v(objSchema)
let invalidObj = {
a: 1,
b: '1',
c: 3
}
isObjValid(invalidObj) // => false
v.explanation // ['b', 'c']
// Сообщаем о невалидных полях
console.error(`${v.explanation.join(', ')} is not valid`) // => b, c is not valid
// Удаляем невалидные и не проверенные поля (см. документацию)
invalidObj = v.omitInvalidProps(objSchema)(invalidObj)
console.log(invalidObj) // => { a: 1 }Имея данный механизм объяснений, можно реализовать любое поведение, связанное с результатами валидации.
Пояснением может быть всё что угодно:
- объект содержащий необходимую информацию;
- функция, которая исправляет ошибку. (
getExplanation => function(invalid): valid); - имя невалидного поля, или индекс невалидного элемента;
- код ошибки;
- и всё на что хватит вашей фантазии.
Что делать, когда дело не строится?
Исправлять ошибки валидации — не редкая задача. Для этих целей в библиотеке используются валидаторы с побочным эффектом, который запоминает место ошибки и как её исправить.
v.default(validator, value)— возвращает валидатор, который запоминает невалидное значение, и в момент вызоваv.fix— устанавливает дефолтное значениеv.filter(validator)— возвращает валидатор, который запоминает невалидное значение, и в момент вызоваv.fix— удаляет это значение из родителяv.addFix(validator, fixFunc)— возвращает валидатор, который запоминает невалидное значение, и в момент вызоваv.fix— вызывает fixFunc c параметрами (value, { key, parent }, …).fixFunc— должна муттировать одного из парентов — для изменения значения
const toPositive = (negativeValue, { key, parent }) => {
parent[key] = -negativeValue
}
const objSchema = {
a: v.default('number', 1),
b: v.filter('string', ''),
c: v.default('array', []),
d: v.default('number', invalidValue => Number(invalidValue)), // привести к числу
pos: v.and(
v.default('number', 0), // Если значение не число - установить 0
v.addFix('non-negative', toPositive) // если значение не положительно - поменять знак
)
}
const invalidObj = {
a: 1,
b: 2,
c: 3,
d: '4',
pos: -3
}
v.resetExplanation() // или синоним v()
v(objSchema)(invalidObj) // => false
// v.hasFixes() => true
const validObj = v.fix(invalidObj)
console.log(validObj) // => { a: 1, b: '', c: [], d: 4 }По хозяйству ещё пригодиться
В данной библиотеке также существуют утилитные методы для действий связанных с валидацией:
| Метод | Результат |
|---|---|
v.throwError |
В случае невалидности бросает TypeError с заданным сообщением. |
v.omitInvalidItems |
Возвращает новый массив(или объект-словарь) без невалидных элементов(полей). |
v.omitInvalidProps |
Возвращает новый объект без невалидных полей, по заданному объектному валидатору. |
v.validOr |
Возвращает значение, если оно валидно, иначе заменяет его на заданное дефолтное значение. |
v.example |
Проверяет, подходят ли к схеме данные значения. Если не подходят, бросается ошибка. Служит документацией и тестированием схемы |
Результаты
Заданные задачи были решены следующими способами:
| Задача | Решение |
|---|---|
| Валидация типов данных | Дефолтные именованные валидаторы. |
| Дефолтные значения | v.default |
| Удаление невалидных частей | v.filter, v.omitInvalidItems и v.omitInvalidProps. |
| Легкость в освоении | Простые валидаторы, простые способы композиции их в сложные валидаторы. |
| Читабельность кода | Одной из целей библиотеки была уподобить схемы валидаций самим |
| валидируемым объектам. | |
| Легкость модификации | Освоив элементы композиций и используя собственные функции валидации — менять код довольно просто. |
| Сообщение об ошибке | Пояснение, в виде сообщения об ошибки. Или расчёт кода ошибки на основе пояснений. |
Послесловие
Данное решение было разработано для быстрого и удобного создания функций валидаторов с возможностью встраивания пользовательских функций валидации. Поэтому, если таковые будут, любые правки, критика, варианты улучшения от прочитавших данную статью приветствуются. Спасибо за внимание.