До сих пор мы рассматривали отдельные фрагменты кода HTML. Но HTML-документ (или веб-страница, что означает то же самое) требует определённой структуры для того, чтобы стать валидным .
Почему мы заботимся о валидации HTML-документа?
- Правильность : валидный документ корректно отображается в браузере.
- Отладка : некорректный код HTML может вызвать ошибки, сложные для выявления.
- Поддержка : валидный документ легче обновлять позже, даже кому-то другому.
Доктайп
Первой информацией которую мы пишем, является тип HTML-документа - доктайп .
Подумайте о доктайпе как о версии автомобиля на протяжении многих лет: Ford Fiesta, купленный в 1986 году, был Fiesta 2. Если вы покупаете его сегодня, то это Fiesta 7.
Раньше сосуществовало несколько версий HTML (XHTML и HTML 4.01 были конкурирующими стандартами). В настоящее время нормой является HTML5 .
Чтобы сообщить браузеру, что HTML-документ представляет собой HTML5, просто начните свой документ со следующей строки:
Вот и всё. Просто установите и забудьте об этом.
Вы можете задаться вопросом, почему это доктайп HTML5 не упоминает цифру 5. В W3C подумали, что предыдущие определения доктайпа были слишком запутанными и воспользовались возможностью, чтобы упростить его, удалив упоминание о версии HTML.
Элемент
Помимо строки с доктайпом, весь ваш HTML-документ должен располагаться внутри элемента :
технически является предком всех элементов HTML.
Как атрибуты несут дополнительную информацию для элемента HTML, так и элемент
несёт дополнительную информацию для всей веб-страницы.Например, заголовок страницы (отображается на вкладке) находится в
:
Следующие элементы HTML могут появляться в
и только в :В то время как
содержит только метаданные, не предназначенные для отображения вообще (за исключениемПолностью валидный HTML-документ
Объединив все эти требования, мы можем написать простой и валидный HTML-документ:
Привет, мир!
Если вы просмотрите этот пример в браузере, то увидите, что:
- «MarkSheet» написано на вкладке браузера;
- «Привет, мир!» - это единственный текст, отображаемый в окне, потому что это единственное содержимое .
W3C предлагает Markup Validation Service для проверки любого HTML-документа на наличие ошибок и предупреждений.
Большинство начинающих вебмастеров рано или поздно сталкиваются с таким понятием как «Валидность кода », лично у меня этот процесс затянулся почти на 2 года. За этот срок я создал три собственных сайта и лишь, потом совершенно случайно узнал о такой необходимости как проверка кода на валидность .
Уже спустя несколько минут я был частично подкован в информационном плане, и успел проглотить несколько коротеньких статей на тему валидности кода. Не могу сказать, что я был доволен изученной информацией, лишь по той причине, что все мои сайты оказались, не достаточно хорошо оптимизированы, и как оказалось, были допущены ошибки на страницах.
Несколько грубых и серьёзных нарушений я устранил сразу, однако в процессе понял, на то что бы поправить все страницы, написанные за два года, понадобится очень много времени, которым в данный момент я не располагаю.
Мораль такова, что бы ни было проблем в дальнейшем, лучше немного подсуетиться и всё продумать заранее.
И так, давайте разберёмся, что же такое валидность кода и на что она влияет.
Валидность кода.
– это исходный код страницы, который должен быть написан по правилам веб-стандартов и правилам языка разметки. Именно этот код в первую очередь видят поисковые системы, во время посещения вашего ресурса и именно этот код отображается в браузере, формируя страницу в том виде, к которому мы привыкли.
Поисковики во время таких посещений и индексации извлекают из этого кода все элементы страницы, включая тексты, заголовки, изображения с прописанными атрибутами, html теги, имена файлов и так далее.
Не трудно представить, что ошибки, допущенные в коде, могут повлиять на оценку ресурса со стороны роботов, которые в свою очередь могут повлечь за собой некие санкции и оказать влияние на ранжирование в поисковых системах. Более того, я уверен, что и самому веб-мастеру будет куда комфортнее и уютнее среди валидных документов «зелёного цвета».
Таким образом, валидность можно отнести к внутренней оптимизации, которая зачастую является основной частью в продвижении ресурса. Грамотно составленный и полностью валидный код - это залог успеха и улучшение позиций в поисковой выдаче.
Пожалуй, начнём со статистики. Так уж сложилось, что большинство Web-дизайнеров пренебрегают валидностью публикуемых документов и не доводят их исходный код до определённых стандартов. По статистике, количество ресурсов, которые проходят проверку кода на валидность составляет чуть больше 6% - вы представляете как это мало?
Учитывая эти данные, получается, что писать валидный код в принципе необязательно, так как большинство этим не занимаются и при этом неплохо себя чувствуют. Многие считают, что проверка валидности это ни что иное как способ обнаружения каких-то мелких недочётов, которые в целом не могут нанести особого вреда.
Увы, в действительности это именно так. Я провёл немало времени, пока анализировал страницы с высокочастотными запросами, которые, несмотря на наличие огромного количества ошибок, находились на топовых позициях. Чего уж там говорить, если даже сам Я ндекс при проверке валидности в коде содержит 113 ошибок и 20 предупреждений.
Если раньше вы никогда не проверяли валидность, спешу вас огорчить – банально, если Вы установили на свой сайт счётчик посещений от liveinternet и ничего в нём не меняли, несколько ошибок вы уже получаете автоматом.
На самом деле, существует несколько способов, с помощью которых можно проверить валидность интересующей страницы. Подробнее остановлюсь лишь на некоторых.
- Способ первый и, наверное, самый примитивный. Пользуясь браузером «Opera», необходимо кликнуть правой кнопкой мыши в любом месте страницы и выбрав соответствующий пункт проверить, соблюдены ли стандарты .
Сразу после этого появится ещё одно диалоговое окно, в котором необходимо подтвердить проверку исходного кода страницы. Нажимаем «OK» и получаем результаты в новой вкладке.
- Второй способ – самый популярный. Для того что бы проверить валидность нужной страницы достаточно перейти на сайт W3.org и вписав её адрес в поле «Address» нажать кнопку «Check».
По-хорошему, именно таким образом должны выглядеть результаты проверки. Слово «Passed » означает, что загруженная страница прошла проверку валидности без ошибок . Так же, об этом не трудно догадаться по зелёному цвету, который преобладает в качестве подсветки результатов.
Создать валидный код отнюдь не так сложно как может показаться на первый взгляд, тем не менее, я считаю что, приведя исходный код сайта в надлежащее состояние, Вы обеспечите для него кроссбраузерность что в свою очередь увеличит скорость загрузки страницы (пусть и незначительно) и соответственно скорость индексации поисковыми системами, что немаловажно для огромных проектов.
Учтите, поисковые системы отдают своё предпочтение в первую очередь страницам с правильным кодом.
PS: Если статья понравилась, можете обратить своё внимание ещё на то - как я создавал свой сайт и на чём делал акцент.
В этой статье я познакомлю с понятием «валидность» кода сайта (html & css). Надеюсь все помнят, html — это структура сайта. Css — правила и стили для тегов, которые описаны в html.
Будем разбираться с самых низов: теория, а далее перейдем к практике. Так же вы найдете ответы на следующие вопросы: что такое валидность html и css кода, зачем она нужна, почему поисковые системы любят чистый / валидный код. А самое то главное покажу на примерах как проводить проверку валидности кода сайта.
Зачем нужна проверка валидности html и css кода
Валидность — по-другому чистый код (без ошибок)
Константа № 1 . Валидность кода сайта позволяет правильно отображать сайт в разных браузерах т.е. вся визуальная и функциональная составляющая сайта отображается и работает правильно. Чаще всего получается, что браузер обрабатывает и отображает корректно все элементы сайта, но это не говорит о том, что код чист и гладок как попка младенца.
Константа № 2. Чистый код (html и css) поощряют поисковые машины (Yandex, Google). Говоря по-русски, когда робот поисковой машины приходит на ваш ресурс и видит что валидность соблюдена, то соответственно поисковой робот будет знать, что этот ресурс без ошибок, а значит к отношение к сайту в лучшую сторону.
Из личного опыта: В моей практике была ситуация, когда новые статьи на блоге ни в какую не хотели залетать в поисковую выдачу. Вроде делаешь то все правильно, а в выдаче Яндекса нет и все! Вот что делать, куда копать? Кто-то подумает фильтры — фильтры, но ничего такого нет.
Проверил сайт на валидность html кода, и как я был удивлен и понял где была собака зарыта. Оказалось что в коде отсутствовал закрывающий тег , а это тег специальный который закрывает участки кода или ссылки от поисковой машины Яндекса. И что же получается у меня было? Вся статья закрыта от индексации. Вот и ответ на вопрос: «Почему в поисковой выдаче нет». Потом естественно я эту ошибку устранил.
Перейдем от голого текста с теорией к практике, и научимся проводить проверку валидации онлайн
Проверка валидности HTML кода сайта обязательно входит в мой . Но не нужно переоценивать значимость ошибок валидации на SEO продвижение — она очень мала. По любой тематике в ТОП будут сайты с большим количеством таких ошибок и прекрасно себе живут.
НО! Отсутствие технических ошибок на сайте является фактором ранжирования, и поэтому пренебрегать такой возможностью не стоит. Лучше исправить, хуже точно не будет. Поисковики увидят ваши старания и дадут маленький плюсик в карму.
Как проверить сайт на валидность HTML кода
Проверяется валидация кода сайта с помощью онлайн сервиса W3C HTML Validator . Если есть ошибки, то сервис выдает вам список. Сейчас я разберу самые распространенные типы ошибок, которые я встречал на сайтах.
- Error: Duplicate ID min_value_62222
И за этой ошибкой такое предупреждение.
- Warning: The first occurrence of ID min_value_62222 was here
Это значит, что дублируется стилевой идентификатор ID, который по правилам валидности html должен быть уникальным. Вместо ID для повторяющихся объектов можно использовать CLASS.
Исправлять это желательно, но не очень критично. Если очень много таких ошибок, то лучше исправить.
Аналогично могут быть еще такие варианты:
- Error: Duplicate ID placeWorkTimes
- Error: Duplicate ID callbackCss-css
- Error: Duplicate ID Capa_1
Следующее очень распространенное предупреждение.
- Warning: The type attribute is unnecessary for JavaScript resources
Это очень частая ошибка при проверке валидации сайта. По правилам HTML5 атрибут type для тега script не нужен, это устаревший элемент.
Аналогично такое предупреждение для стилей:
- Warning: The type attribute for the style element is not needed and should be omitted
Исправлять эти предупреждения желательно, но не критично. При большом количестве лучше исправить.
- Warning: Consider avoiding viewport values that prevent users from resizing documents
Это предупреждение показывает, что нельзя увеличить размер страницы на мобильном или планшете. То есть пользователь захотел посмотреть поближе картинки или очень маленький текст и не может этого сделать.
Я считаю это предупреждение очень нежелательным, для пользователя неудобно, это минус к поведенческим. Устраняется удалением этих элементов — maximum-scale=1.0 и user-scalable=no.
- Error: The itemprop attribute was specified, but the element is not a property of any item
Это микроразметка, атрибут itemprop должен находиться внутри элемента с itemscope. Я считаю эту ошибку не критичной и можно оставлять как есть.
- Warning: Documents should not use about:legacy-compat, except if generated by legacy systems that can’t output the standard doctype
Строка about:legacy-compat нужна только для html-генераторов. Здесь нужно просто сделать но ошибка совсем не критичная.
- Error: Stray end tag source
Если посмотреть в коде самого сайта и найти этот элемент, видно, что одиночный тег
Соответственно, нужно убрать из кода закрывающий тег . Аналогично этой ошибке могут встречаться теги
- Error: An img element must have an alt attribute, except under certain conditions. For details, consult guidance on providing text alternatives for images
Все картинки должны иметь атрибут alt, я считаю эту ошибку критичной, ее нужно исправлять.
- Error: Element ol not allowed as child of element ul in this context. (Suppressing further errors from this subtree.)
Здесь не верно прописана вложенность тегов. В
- должны быть только
- . В данном примере эти элементы вообще не нужны.
Аналогично могут быть еще такие ошибки:
- Element h2 not allowed as child of element ul in this context.
- Element a not allowed as child of element ul in this context.
- Element noindex not allowed as child of element li in this context.
- Element div not allowed as child of element ul in this context.
Это все нужно исправлять.
- Error: Attribute http-equiv not allowed on element meta at this point
Атрибут http-equiv не предназначен для элемента meta, нужно убрать его или заменить.
Аналогичные ошибки:
- Error: Attribute n2-lightbox not allowed on element a at this point.
- Error: Attribute asyncsrc not allowed on element script at this point.
- Error: Attribute price not allowed on element option at this point.
- Error: Attribute hashstring not allowed on element span at this point.
Здесь также нужно или убрать атрибуты n2-lightbox, asyncsrc, price, hashstring или заменить их на другие варианты.
- Error: Bad start tag in img in head
Или вот так:
- Error: Bad start tag in div in head
Тегов img и div не должно быть в
. Эту ошибку нужно исправлять.- Error: CSS: Parse Error
В данном случае здесь не должно быть точки с запятой после скобки в стилях.
Ну такая ошибка, мелочь, но не приятно) Смотрите сами, нужно убирать это или нет, на продвижение сайта никакой совершенно роли не окажет.
- Warning: The charset attribute on the script element is obsolete
В скриптах уже не нужно прописывать кодировку, это устаревший элемент. Предупреждение не критичное, на ваше усмотрение.
- Error: Element script must not have attribute charset unless attribute src is also specified
В этой ошибке нужно убрать из скрипта атрибут charset=»uft-8″, так как он показывает кодировку вне скрипта. Я считаю, эту ошибку нужно исправлять.
- Warning: Empty heading
Здесь пустой заголовок h1. Нужно удалить теги
или поместить между ними заголовок. Ошибка критичная.- Error: End tag br
Тег br одиночный, а сделан как будто закрывающий парный. Нужно убрать / из тега.
- Error: Named character reference was not terminated by a semicolon. (Or & should have been escaped as &.)
Это спецсимволы HTML, правильно нужно писать или ©. Лучше эту ошибку исправить.
- Fatal Error: Cannot recover after last error. Any further errors will be ignored
Это серьезная ошибка:
После ничего вообще не должно быть, так как это последний закрывающий тег страницы. Нужно удалять все, что после него или переносить выше.
- Error: CSS: right: only 0 can be a unit. You must put a unit after your number
Нужно значение в px написать:
Вот аналогичная ошибка:
- Error: CSS: margin-top: only 0 can be a unit. You must put a unit after your number
- Error: Unclosed element a
В последнее время я получила несколько вопросов от пользователей, касающихся валидности моих тем и валидации вообще. В этом посте хочу ответить на них.
Что такое валидность?
Считается, что валидность кода - это единая, универсальная характеристика любого кода.
На самом деле, валидность это соответствие html кода документа определенному своду правил, указанному в доктайпе или подразумеваемому в HTML5 .
То есть, валидность - понятие относительное, поскольку правила бывают разные, и требования у них тоже.
Чтобы было понятнее, приведу пример, который я нашла на сайте css-live.ru :К строительству жилых домов и атомных электростанций применяются разные СНиПы (строительные нормы и правила), поэтому документ, валидный по одному своду правил, может быть не валидным по другому (хороша была бы АЭС, построенная по нормативам жилого дома!).
Доктайп обычно указывает на документ, по которому планируется валидация html, но может быть выбран из прагматических соображений для выбора оптимального режима браузеров.
XHTML5 может вообще не иметь доктайпа, но быть валидным.Валидация - что это?
Простыми словами, валидация - это процесс проверки кода и приведения его в соответствие с выбранным доктайпом (DTD).
Как проверяется валидность?
Валидность HTML кода проверяется инструментом, который называется валидатором.
Самый известный валидатор w3c - https://www.w3.org .
Валидатор w3c производит несколько проверок кода.
Главные из них :- Проверка на наличие синтаксических ошибок:
Пример c habrahabr.ru/post/101985 :является корректным синтаксисом, несмотря на то, что является недопустимым HTML-тэгом
Так что проверка синтаксиса является минимально полезной для написания хорошего HTML-кода. - Проверка вложенности тэгов
:
В HTML документе тэги должны быть закрыты в обратном порядке относительно их открытия. Эта проверка выявляет незакрытые или неправильно закрытые теги. - Валидация html согласно DTD
:
Проверка того, насколько код соответствует указанному DTD - Document Type Definition (доктайпу). Она включает проверку названий тэгов, атрибутов, и «встраивания» тэгов (тэги одного типа внутри тэгов другого типа). - Проверка на наличие посторонних элементов
:
Она обнаружит все, что есть в коде, но отсутствует в доктайпе.
Например, пользовательские тэги и атрибуты.
Для проверки валидности CSS кода существует валидатор css - http://jigsaw.w3.org/css-validator .
Валидность кода - это результат механической проверки на отсутствие формальных ОВ, согласно указанного свода правил.
Нужно понимать, что валидация - инструмент, а не самоценность.
Верстальщики с опытом обычно знают, где можно нарушить правила валидации HTML или CSS, а где нет, и чем грозит (или не грозит) та или иная ошибка валидации.
Примеры того, когда не валидный код делает сайт:- более удобным и быстрым - пользовательские атрибуты для Javascrip/AJAX или
- SЕО оптимизированным - разметка ARIA.
Понятно, что в валидности ради валидности нет никакого смысла.
Как правило, опытные верстальщики придерживаются следующих правил:
- В коде не должно быть грубых ошибок.
- Незначительные можно допустить, но только по обоснованным причинам.
В отношении допустимости ошибок валидации html/CSS:Ошибки валидации (ОВ) можно разделить на группы:
- ОВ в файлах шаблона:
Их не сложно найти и исправить.
Если, какие то из мелких ошибок помогают сделать сайт более функциональным или быстрым, их можно оставить. - ОВ в сторонних скриптах, подключенных на сайте:
Например, виджет Вконтакте, скрипт Твиттера или видео-файлы с ютуб.
Исправить их никак не удастся, поскольку эти файлы и скрипты находятся на других сайтах и у нас нет к ним доступа. - CSS-правила, которые валидатор не понимает:
Валидатор проверяет соответствие кода сайта определенной версии HTML или CSS.
Если вы использовали в шаблоне правила CSS версии 3, а валидатор проверяет на соответствие версии 2.1, то все правила CSS3 он будет считать ошибками, хотя они таковыми не являются. - ОВ, которые поневоле приходится оставлять на сайте, чтобы получить нужный результат. Например:
- теги noindex. Они не валидны, но очень нужны и с этим приходится мириться.
- хаки. Чтобы получить корректное отображение сайта в некоторых браузерах, иногда, приходится использовать хаки - код, который понимает только определенный браузер.
- Ошибки самого валидатора.
Часто он не видит каких то тегов (например, закрывающих) и сообщает об ОВ там, где ее нет.
Получается, что на работающем сайте практически всегда будут какие-то ОВ.
Причем, их может быть очень много.
Например, главные страницы Google , Яндекса и mail.ru содержат по несколько десятков ошибок.
Но, они не ломают отображение сайтов в браузерах и не мешают им работать.
Все написанное выше относится и к моим темам.В сложных темах есть:
- WordPress функции (например the_category()) , которые дают невалидный код.
- Вывод видео с видеохостингов, например, с YouTube, а в коде YouTube очень много ОВ, на которые ни вы, ни я не можем влиять.
- Кнопки социальных сетей, которые подключаются при помощи скриптов этих сетей и содержат ОВ.
- Правила CSS3 и HTML5, которые валидаторы старых версий считают ошибками.
В то же время, валидаторы версий CSS3 и HTML5 считают ошибками старые правила:). - Иногда, чтобы добиться корректного отображения в браузере Internet Explorer или старых версиях других браузеров приходится использовать, так называемые хаки - код, который понимает только определенный браузер, чтобы написать правила отображения сайта именно для этого браузера.
В итоге получить полностью валидный код можно только при верстке очень простых тем, т.е. тем, которые содержат минимальное количество функционала.
После окончания верстки любой своей темы я всегда проверяю ее валидатором и исправляю все ОВ, которые можно исправить без потери работоспособности темы.
Т.е., если стоит выбор между работающим функционалом и валидностью - я выбираю функционал.
Если вы верстаете свои темы, советую поступать так же.
С моей точки зрения (а также, точки зрения большинства верстальщиков) отношение к валидации html/CSS, как к истине в последней инстанции ошибочно. В обязательном порядке нужно исправлять только те ОВ, которые:
- мешают браузеру корректно отобразить страницу (незакрытые и неправильно вложенные теги).
- замедляют загрузку страницы (неправильно подключенные скрипты).
- можно исправить, не нарушая работоспособность темы.
Надеюсь, я ответила на все вопросы о валидации.