Валидатор css


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

Проверка валидности htmlСчитается, что валидность кода — это единая, универсальная характеристика любого кода.
На самом деле, валидность это соответствие html кода документа определенному своду правил, указанному в доктайпе или подразумеваемому в HTML5.
То есть, валидность — понятие относительное, поскольку правила бывают разные, и требования у них тоже.
Чтобы было понятнее, приведу пример, который я нашла на сайте css-live.ru:

К строительству жилых домов и атомных электростанций применяются разные СНиПы (строительные нормы и правила), поэтому документ, валидный по одному своду правил, может быть не валидным по другому (хороша была бы АЭС, построенная по нормативам жилого дома!).

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

Валидация — что это?


Простыми словами, валидация — это процесс проверки кода и приведения его в соответствие с выбранным доктайпом (DTD).

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

Валидность HTML кода проверяется инструментом, который называется валидатором.
Самый известный валидатор w3c — https://www.w3.org.
Валидатор w3c производит несколько проверок кода.
Главные из них:

  1. Проверка на наличие синтаксических ошибок:
    Пример c habrahabr.ru/post/101985:
    <foo bar=»baz»> является корректным синтаксисом, несмотря на то, что <foo> является недопустимым HTML-тэгом
    Так что проверка синтаксиса является минимально полезной для написания хорошего HTML-кода.
  2. Проверка вложенности тэгов:
    В HTML документе тэги должны быть закрыты в обратном порядке относительно их открытия. Эта проверка выявляет незакрытые или неправильно закрытые теги.
  3. Валидация html согласно DTD:
    Проверка того, насколько код соответствует указанному DTD — Document Type Definition (доктайпу). Она включает проверку названий тэгов, атрибутов, и «встраивания» тэгов (тэги одного типа внутри тэгов другого типа).
  4. Проверка на наличие посторонних элементов:
    Она обнаружит все, что есть в коде, но отсутствует в доктайпе.
    Например, пользовательские тэги и атрибуты.

Для проверки валидности 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, как к истине в последней инстанции ошибочно. В обязательном порядке нужно исправлять только те ОВ, которые:
— мешают браузеру корректно отобразить страницу (незакрытые и неправильно вложенные теги).
— замедляют загрузку страницы (неправильно подключенные скрипты).
— можно исправить, не нарушая работоспособность темы.
Надеюсь, я ответила на все вопросы о валидации.

prodengiblog.ru

Проверить URI


Эта вкладка позволяет указывать адрес страницы размещенной в Интернете. Протокол http:// можно не писать, он будет добавлен автоматически (рис. 20.1).

Проверка документа по адресу

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

После ввода адреса нажмите на кнопку «Проверить» и появится одна из двух надписей: «Поздравляем! Ошибок не обнаружено» в случае успеха или «К сожалению, мы обнаружили следующие ошибки» при невалидном коде. Сообщения об ошибках или предупреждениях содержат номер строки, селектор и описание ошибки.

Проверить загруженный файл

Эта вкладка позволяет загрузить HTML или CSS-файл и проверить его на наличие ошибок (рис. 20.2).

Проверка файла при его загрузке

Рис. 20.2. Проверка файла при его загрузке

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

Проверить набранный текст


Последняя вкладка предназначена для непосредственного ввода HTML или CSS-кода, при этом проверке будет подвергнут только стиль (рис. 20.3).

Проверка введённого кода

Рис. 20.3. Проверка введённого кода

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

Выбор версии CSS

В CSS3 добавлено много новых стилевых свойств по сравнению с предыдущей версией, поэтому проводить проверку кода следует с учётом версии. По умолчанию в сервисе указан CSS3, так что если вы хотите проверить код на соответствие CSS2.1, это следует указать явно. Для этого щелкните по тексту «Дополнительные возможности» и в открывшемся блоке из списка «Профиль» выберите CSS2.1 (рис. 20.4).

Валидатор css

Рис. 20.4. Указание версии CSS для проверки

htmlbook.ru

Миф 1. Валидность — некая единая, универсальная характеристика для любого кода

Примеры употребления: «Поменяй доктайп с X на Y, а то невалидно».


Реальность: валидность — понятие конкретное и относительное. Валидность документа на языке разметки означает соответствие определенной схеме. Указанной (напр. DTD в доктайпе) или подразумеваемой (в HTML5). Схемы бывают разные, и требования у них тоже (аналог из жизни: к строительству жилых домов и атомных электростанций применяются разные СНиПы), поэтому документ, валидный по одной схеме, наверняка будет невалидным по другой (хороша была бы АЭС, построенная по нормативам жилого дома!).

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

Миф 2. Валидность — это соответствие стандарту

Пример употребления: так и употребляется

Реальность: валидность — результат механической проверки на отсутствие формальных грамматических ошибок заявленного в схеме языка. О логике, тем более о смысле документа валидация не знает и не задумывается. Например, по формальным правилам русского языка знаменитая фраза «волны… падали стремительным домкратом» абсолютно «валидна», любой «валидатор» (напр., проверка орфографии в Ворде) найдет в ней ровно ноль ошибок. Но грамотна ли эта фраза? Конечно, нет — ведь слова в ней использованы не по назначению! (Не подумайте, что я считаю валидацию или проверку орфографии ненужной — напротив, это нужные и очень полезные инструменты! Но, увы, не всесильные.)


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

В аналогии со строительством дома, валидатор укажет на неоштукатуренную вовремя стену или косо вставленное окно без шпингалетов (и будет прав, такое нужно исправлять!), но вполне может пропустить, например, то, что туалет оказался замурован наглухо (без единого дверного проема), а на кухню можно попасть только через балкон соседней квартиры (ведь валидатор не телепатор, замысел архитектора ему неизвестен — вдруг так и задумано? А монтаж перекрытий вполне соответствует ГОСТам и СНиПам…).

Миф 3. Валидность — это гарантия кроссбраузерности

Пример употребления: «— Почему у меня в IE8 (IE7, Fx2…) не так отображается меню, валидатор ведь ошибок не показывает?»

Реальность: валидность — это соответствие схеме. Ни больше ни меньше. Так что если какой-то браузер какую-то схему просто не знает — ждать от него правильного отображения в соответствии с этой схемой как минимум наивно. Кроме того, отображение сейчас главным образом зависит от поддержки браузерами CSS, а не разметки. И вообще браузеры умеют лишь то, что умеют. А еще у всех браузеров есть баги разной степени неочевидности.


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

Миф 4. Лучший валидатор — это браузер

Пример употребления: «Главное, чтобы страница везде одинаково отображалась, а валидностью пусть заморачиваются фанатики»

Реальность: браузер — не валидатор, никогда не был валидатором и не претендовал на то, чтобы быть валидатором. И не замена валидатору. У них разные задачи. У валидатора — тупо проверить страницу на соответствие заявленной схеме (и указать на все найденные несоответствия). У браузера — отобразить страницу хоть как-то, несмотря на эти несоответствия (и более того — даже на саму схему, иногда, особенно если она указана явно «от балды» и не имеет связи с реальностью).

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

Миф 5. Фраза «браузер — лучший валидатор» устарела, это пережиток эпохи IE6


Пример употребления: «Лебедев (или еще кто-то) сказал эту фразу в 90-е, а сейчас нет браузера с долей > 80%»

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

Причиной этого оказался главный секрет HTML5. Вкратце — впервые за историю веба браузеры и валидатор нашли общий язык. По крайней мере, стали понимать страничку по одним и тем же правилам. Более того — такие браузеры, как Fx4+ и Хром 7+, подстроили свои стили по умолчанию под эти правила (например, размер заголовка в них по умолчанию зависит не от его «номера», а от уровня вложенности в структуре плана документа). Так что если структура заголовков вашей страницы в этих браузерах при отключенных стилях выглядит логично — скорее всего, вы использовали элементы более-менее по назначению. А если при этом еще и таблицы не рвутся, подписи полей форм не улетают прочь от самих полей и т.п. — скорее всего, и грубых ошибок в синтаксисе у вас нет.

Миф 6. XHTML валиднее, чем HTML

Пример употребления: «Все одиночные теги по стандарту должны быть закрыты — <br />, <img /> и т.п., иначе невалидно»

Реальность: во-первых, см. п. 1. Даже код а-ля <FONT COLOR=RED>UNDER<BR>CONSTRUCTION</FONT> может быть валидным — если в доктайпе заявлена схема HTML 3.2:). Потому что валидность — это соответствие схеме, ни больше ни меньше!

Во-вторых, в XML (а следовательно, в XHTML, потому что он — его подмножество) есть дополнительное (помимо валидности!) ограничение синтаксиса — веллформность («правильная сформированность», синтаксическая корректность). Именно она требует обязательного закрытия всех тегов (в т.ч. «самозакрытия» одиночных), «закавыченности» всех атрибутов, непременного экранирования амперсанда в виде &amp; и т.п. Эти требования общие для всех языков на базе XML (будь то SVG, MathML и т.п.). Может показаться, что у XHTML валидация «двойная» (соответствие DTD плюс XML-веллформность), а у HTML — «одинарная» (только DTD), но на деле валидность и там, и там определяется именно схемой. По определению. А XML-веллформность — это требование базового синтаксиса. Вроде того, как HTML требует, чтобы теги начинались и заканчивались угловыми скобками.

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

Запомнить все правила HTML (напр., в каких случаях, кроме явного закрывающего тега, автоматически заканчивается элемент P) сложнее, чем правила XML. Но это не делает разметку, соответствующую этим правилам, менее валидной. А ведь кое-кто до сих пор уверяет, что правила HTML проще:)

Ну а если кто-то скажет вам, что «тег <br> невалиден в HTML, потому что не закрыт слешем» (увы, даже сейчас, в 2012-м, можно услышать подобное!) — отправляйте его в школу, учиться читать. Потому что, умея читать, вычитать такую чушь ни в одной спецификации нельзя:)

Миф 7. Вреда от XHTML-валидности уж точно не бывает

Пример употребления: так и употребляется.

Реальность: XHTML и HTML — разные языки. XHTML пишется и валидируется по правилам XML А вот читается, т.е. парсится браузерами, чаще всего как HTML(5).

HTML- и XML-парсеры работают по разному алгоритму. То, что XML-парсер в общем случае не поймет HTML-разметку, всем понятно. Но почему-то большинство авторов, ставящих на страницу XHTML-доктайп, считают это само собой разумеющимся, что для HTML-парсера она проблемы не составит. Хотя на самом деле это далеко не очевидно! Разметка, одинаково понятная для разных парсеров, по-научному называется «разметкой-полиглотом» и для нее был и есть отдельный стандарт, со своими особыми правилами. Или, как минимум, приложение C спецификации XHTML 1.0.

Валидатор же об этом «не задумывается» и проверяет только… правильно, соответствие схеме! А той всё равно, <div></div> или <div/>. Последний вариант иногда случайно копируется из окошка «показать код выделенного фрагмента» некоторых браузеров. И HTML-парсер, привыкший игнорировать концевые слеши, воспримет его как незакрытый тег!

Мораль: всегда валидируйте разметку по той схеме, по которой ее будут разбирать браузеры. И не злоупотребляйте доктайпами, которые могут сбить валидатор с толку. Чем плох лаконичный, ясный и однозначный <!DOCTYPE html>?:)

Миф 8. Валидация CSS3 — не фикция

Пример употребления: «Как сделать CSS3 валидным, если я использую filter и zoom?»

Реальность: валидность — это соответствие схеме. Есть ли схема у CSS? У CSS даже версий-то нет!

Формальное определение «валидного CSS» вроде бы есть. Всё та же спецификация CSS 2.1 говорит:

Валидность таблицы стилей зависит от уровня CSS, использованного для таблицы стилей. Все валидные таблицы стилей CSS1 являются валидными таблицами стилей CSS 2.1, но некоторые изменения по сравнению с CSS1 означают, что некоторые таблицы стилей CSS1 будут иметь слегка другой смысл в CSS 2.1. Некоторые «фичи» CSS2 не входят в CSS 2.1, поэтому не все таблицы стилей CSS2 являются валидными таблицами стилей CSS 2.1.

Валидная таблица стилей CSS 2.1 должна быть написана в соответствии с грамматикой CSS 2.1. Более того, она должна содержать исключительно @-правила, имена свойств и их значения, определенные в этой спецификации. Запрещенное (невалидное) @-правило, имя или значение свойства — то, которое не является валидным. (К последней фразе так и напрашивается подпись «К. О.» — прим. перев.:)

Ну а как быть с валидностью CSS3 (которого нет, как известно:)? По логике определения выше, «валидный CSS3» должен содержать свойства и значения, описанные в модулях 3-го уровня. Но ведь эти модули постоянно меняют синтаксис, то и дело признаются устаревшими и переписываются практически заново, а за некоторые модули (напр. таблицы 3-го уровня) вообще еще даже не брались?

В описании к сервису проверки CSS есть пояснение на эту тему (правда, в русской версии описания именно этот пункт почему-то потерялся!):

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

Но легко сказать «последняя спецификация», а каково на практике? Ладно, список свойств и значений можно взять, например, здесь. Или собрать по модулям статуса LC и выше (обычно в них есть специальный раздел со списком добавленных свойств, как здесь). А как быть с грамматикой? Бывает же и такое:

Этот модуль заменяет и расширяет правило ‘@media’, определенное в разделе 7.2.1 [CSS21], и включает изменения, ранее сделанные неофициальными в разделе 1 [MEDIAQ] (в частности, правила ‘@media’ могут быть вложенными, что не допускалось предыдущими редакциями — прим. перев.).

Его текущее определение зависит от @-правил, определенных в [CSS3-FONTS] и [CSS3-ANIMATIONS], но эта зависимость — только в допущении, что те модули будут обновляться раньше, чем этот. Если этот модуль будет развиваться быстрее, зависимость станет обратной.

Ну как, уже достаточно запутались или добавить шокирующих подробностей?

Неудивительно, что с определением «валидности CSS3» не всегда могут договориться сами авторы спецификаций. А тем более разработчики CSS-валидатора, которым один модуль твердит одно, а другой — противоположное. Поэтому они включили в описание сервиса следующий пункт:

Это официальная проверка на корректность CSS?

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

Так что, увидев сообщение об ошибке валидации CSS3 — не впадайте в панику и не бегите на форумы с вопросом Чернышевского, а спокойно прочитайте, в чем именно эти ошибки состоят. Если, например, в пропущенной точке с запятой между свойствами (отчего свойство не распознается) — такое надо исправлять. А если валидатор просто не знает парочки свойств (особенно в стилях, предназначенных только для старых IE) — смело считайте это проблемой валидатора. Ведь понятие «валидности CSS» такое расплывчатое! Хотя это не означает, что экспериментальными (с префиксами) и нестандартными браузерными «довесками» к CSS стоит злоупотреблять;)

Миф 9. Все валидаторы одинаково полезны

Пример употребления: «В пустые span-ы нужно вставлять хотя бы &nbsp;, иначе будет невалидно»

Реальность: не всё валидатор, что валидирует:). Например, популярный некогда аддон для Firefox с говорящим, казалось бы, названием «HTML validator» по умолчанию проверял совсем не тем алгоритмом, что официальный валидатор W3C. И считал многие вещи, вполне разрешенные стандартом (напр. те же пустые span-ы) ошибками! Хорошего в пустых span-ах, конечно, мало, но это не повод обвинять в несуществующих грехах сам стандарт. Поэтому, если пользуетесь «валидатором», отличным от официального валидатора W3C, обязательно поинтересуйтесь, что и как он проверяет на самом деле. Остерегайтесь подделок!

Миф 10. Все валидаторы, кроме официального валидатора W3C — ничто

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

Реальность: во-первых, валидатор W3C проверяет только те стандарты, которые разработаны самим W3C. Так что сторонние валидаторы для сторонних стандартов — это логично. Например, валидаторы микроразметки Яндекса, Гугла и т.д. — вполне правильная и полезная вещь. Во-вторых, валидаторы (даже официальные!) — программы, гм… туповатые. Они проверяют «сферический код в вакууме» (например, для многострадального XHTML валидатор предполагает, что разбираться он будет XML-парсером, а скрипты в HTML-комментариях действительно закомментарены, т.е. «временно убраны», а не всего-навсего скрыты таким способом от архаичных браузеров).

В этом плане html5.validator.nu («живой» валидатор, в каком-то смысле «официальный» валидатор WHATWG), хоть и не является официальным валидатором W3C, но во многом даже лучше его. Потому что анализирует страницу так же, как это делают браузеры (более того — в его основе такой же самый стандартный HTML5-парсер, что и в Gecko!). См. тж. разоблачение мифа 5 выше.

css-live.ru

проверка валидности htmlВ этой статье я познакомлю с понятием «валидность» кода сайта ( html & css ). Надеюсь все помнят, html — это структура сайта. Css — правила и стили для тегов, которые описаны в html.

Будем разбираться с самых низов: теория, а далее перейдем к практике. Так же вы найдете ответы на следующие вопросы: что такое валидность html и css кода, зачем она нужна, почему поисковые системы любят чистый / валидный код. А самое то главное покажу на примерах как проводить проверку валидности кода сайта.

Зачем нужна проверка валидности html и css кода

Валидность — по-другому чистый код ( без ошибок )

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

Константа № 2. Чистый код ( html и css ) поощряют поисковые машины ( Yandex, Google ). Говоря по-русски, когда робот поисковой машины приходит на ваш ресурс и видит что валидность соблюдена, то соответственно поисковой робот будет знать, что этот ресурс без ошибок, а значит к отношение к сайту в лучшую сторону.

Из личного опыта: В моей практике была ситуация, когда новые статьи на блоге ни в какую не хотели залетать в поисковую выдачу. Вроде делаешь то все правильно, ускоряешь индексацию а в выдаче Яндекса нет и все! Вот что делать, куда копать? Кто-то подумает фильтры — фильтры, но ничего такого нет.

Проверил сайт на валидность html кода, и как я был удивлен и понял где была собака зарыта. Оказалось что в коде отсутствовал закрывающий тег </noindex> , а это тег специальный который закрывает участки кода или ссылки от поисковой машины Яндекса. И что же получается у меня было? Вся статья закрыта от индексации. Вот и ответ на вопрос: «Почему в поисковой выдаче нет». Потом естественно я эту ошибку устранил.

Перейдем от голого текста с теорией к практике, и научимся проводить проверку валидации онлайн

Проверка html кода

Идем на ресурс validator.w3.org и вводим адрес вашего сайта вида: http://vashsait.ru и нажимаем кнопку «Check»

Если нужно например загрузить с компьютера файл на проверку, то используйте вкладку «Validate by File Upload». Если, вы хотите проверить отдельный участок кода, то кликаем на «Validate by Direct Input». Ниже привожу подсказки, и как выглядит само окно для работы ( можно увеличить )

валидатор w3c

В качестве примера, чтобы показать сам процесс выдачи ошибок возьму любой сторонний сайт, адрес которого останется за кадром =) на данном блоге ошибки убраны, а так бы показал на нем, смотрим что получаем при проверке html кода, заметьте что валидатор поддерживает и расширенные языки html такие как ( XHTML, HTML5 ).

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

результат валидации html

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

Проверка CSS кода

Сперва Вам понадобится определить абсолютное нахождение основного файла стилей css, который отвечает за внешний вид и расположение блоков вашей темы для блога или отдельной html страницы. Быстрый и простой способ: на главной странице своего сайта нажимаете комбинацию ( Ctrl + U ) — откроется исходный код страницы, либо правая кнопка мыши ( Посмотреть исходный код страницы )

Опишу частые случаи, чтобы вам было легче найти основной файл стилей css. Для быстрого поиска в исходном поиске нажмите комбинацию клавиш ( Ctrl + F ) а в поисковом поле введите ( style.css или index.css) — это частые случаи, но для каждого сайта индивидуально и этот способ может не подойди, остается через инспективание какого-либо элемента на сайте, чтобы определить основной файл css

Либо используйте загрузку файла с компьютера или вставкой кода в соответствующее окно.

Для блогов WordPress:

На эту часть ?ver=3.9.2 можете не обращать внимание

Для одностраничных сайтов:

Далее идем в Валидатор CSS и видим следующее окно, почти такое же как и выше, только здесь мы проверяем css файл. Объяснять что куда тыкать не вижу смысла, все на русском и все понятно. Помимо проверки с сервера, можете так же воспользоваться загрузкой файла с компьютера или вставить код

валидатор css

После проверки, видим какие ошибки присутствуют в файле css

В моем примере ошибки не встретились, а есть только предупреждения, вот так все это выглядит на деле

валидация css ошибки

Вот так проверка валидности html и css работает, теперь вы знаете как убрать те или иные ошибки на своем сайте.

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

Подведем некоторые итоги и выводы:

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

С уважением, Александр Лукьянов

vpluce.ru

Сервис для проверки валидности CSS

Валидацию CSS мы будем делать при помощи сервиса jigsaw.w3.org.
Оформление и принцип работы данного сервиса очень похож на валидатор HTML, но в отличии от него, данный сервис русифицирован.

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


«Профиль»
— позволяет задать стандарт css по правилам которого будет осуществляться проверка валидности. По умолчанию стоит CSS3, если по каким-то причинам вам нужно будет проверять CSS2 или CSS1, либо какие-то другие стандарты, то задать это можно здесь. Так как большинство сайтов сейчас делаются с использованием СSS3, то проверять лучше всего именно по правилам этого стандарта.

В раскрывающемся списке «Предупреждение» вы можете выбрать тип вывода отчёта. Я думаю здесь понятно, какой пункт за что отвечает.

В поле «Среда» вы можете выбрать, под какой способ отображения вы будете проверять набор CSS-правил.

Здесь лучше всего оставить значение по умолчанию.

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

Параметры мы рассмотрели, теперь можно вводить адрес сайта в соответствующее поле и нажимать кнопку «Проверить»

Анализ и исправление ошибок валидации CSS

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

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

В правом столбце указывается текст самой ошибки и рекомендации по ее устранению.

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

Если вам проще осуществлять проверку валидности CSS на английском и потом самостоятельно это переводить, вы можете воспользоваться сервисом css-validator.org

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

Конечно же, чтобы исправить ошибки валидности CSS вам нужно иметь определённые знания в данной области. Очень часто валидаторы ругаются на кроссбраузерные префиксы и CSS хаки для браузеров Internet Explorer. Однако эти префиксы и хаки добавлены как раз для того чтобы добиться одинакового отображения во всех браузерах. И их удаление или исправление может негативно отразиться на кроссбраузерности сайта.

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

Нужна ли проверка валидности CSS?

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

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

Что же касается проверки сайта на валидность и исправления ошибок с целью SЕО-оптимизации, то этот вопрос достаточно неоднозначный. Потому, что весной этого года Google объявил, что они вообще не будут учитывать валидность кода при ранжировании сайта. Яндекс пока что такого заявления не делал. Они в своих рекомендациях советуют стараться, что бы верстка соответствовала стандартам. Однако, как показывает практика, большинство сайтов находящихся в топе по высокочастотным запросам содержат в себе кучу ошибок HTML и CSS. Вы можете сами в этом убедиться, протестировав их через эти сервисы.

Видеоинструкция

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

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

С уважением Юлия Гусарь

impuls-web.ru

Валидация HTML

Произвести проверку можно по адресу: http://validator.w3.org/

Валидатор css

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

А вот как выглядит отчёт после проверки сайта:

Валидатор css

Как мы видим сервис нашёл у меня 20 ошибок и 3 опасных. Раньше было около 150 ошибок ). Исправить все ошибки многим не удаётся из-за шаблонов. Как я прочитал на одном сайте: «Сделай сайт валидный и потеряй всю красоту сайта.» Но всё равно нужно стремится к максимально возможному уменьшению ошибок на сайте!

seoprodvig.ru

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

CSS

CSS (от англ. Cascading Style Sheets) — это формальный стандарт, предназначенный для описания внешнего вида документа языком разметки.

Для проверки существует очень полезный сервис, который представляет Консорциум W3C. Перейдем на страницу сервиса CSS Validation Service и проверим валидность CSS. По сложившейся традиции для примера я проверю главную страницу Яндекса. Пройдя по ссылке откроется новое окно, которое будет выглядеть следующим образом:

Главное окно валидатора CSS

И здесь нас ждет приятное удивление! Все на русском языке! Кроме того, есть возможность выбора любого языка из 18 доступных. В окне присутствуют вкладки, предлагающие выбрать вариант проверки:

  • URI — по ссылке на страницу
  • Загруженный файл
  • Набранный текст

Думаю, здесь пояснения не требуются. Продолжаем экспериментировать с Яндексом и проверим его на соответствие стандартам CSS. Для этого в текстовую строку ввожу адрес главной страницы и нажимаю на кнопку «Проверить». В ответ получаю следующее:

Результаты проверки CSS

И снова Яндексу необходимо поработать над ошибками ? Кстати, из первых строк таблицы видно, что ошибки в основном связаны с параметром border-radius, отвечающим за скругление углов, что не поддерживает стандарт CSS2.1. На самом деле это не критично, просто браузеры, не поддерживающие такие свойства, не будут их учитывать и покажут углы без скруглений.

Настроек проверки как таковых нет, НО сервис предлагает нам сгенерированный валидный код таблицы стилей, который будет отображен после списка всех ошибок и предупреждений:

Информация о корректном CSS

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

Чтобы подтвердить, что ничего невозможного нет, привожу результат проверки валидности CSS Блога Свободного Вебмастера на момент написания поста:

Я прошел проверку CSS!

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

webliberty.ru

Валидатор HTML

Валидатор W3C HTML W3C HTML Validator — HTML-валидатор W3C, который проверяет синтаксис HTML и XHTML-кода. Проверку можно осуществлять тремя способами: указать адрес страницы в интернете (Validate by URI), загрузить проверяемый файл с компьютера (Validate by File Upload) или вставит HTML-код непосредственно в проверочное окно (Validate by Direct Input).

Нажав кнопку «More Options» можно установить дополнительные настройки проверки, такие как кодировка документа, тип документа (используемый <!DOCTYPE>) и т.д.

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

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

Валидатор CSS

Валидатор W3C CSS W3C CSS Validator — CSS-валидатор W3C на русском языке, предназначен для проверки CSS (Каскадные таблицы стилей). Как и в предыдущем случае, существует три способа проверки: указать адрес проверяемой страницы, загрузить файл с компьютера или вставить код CSS в окно валидатора.

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

Данный валидатор проверяет правильности написания селекторов CSS, свойств CSS и их значений, наличие фигурных скобок {  } и точек с запятой (;), но он не отслеживает наличие дубликатов свойств для одного и того же элемента, так как синтаксис CSS это позволяет. Поэтому, если ошибок в вашей таблице стилей не обнаружено, но при этом какие-то из параметров не работают, то скорее всего тут дело в приоритетах стилей.

Совмещенный валидатор HTML и CSS

Валидатор W3C Unicorn W3C Unicorn Validator — совмещенный валидатор W3C на русском языке, который может проводить не только проверку синтаксиса HTML и CSS, но и RSS, Atom и некоторых других кодов. Здесь вы также можете указать URL проверяемого файла, загрузить его с локальной машины или ввести код непосредственно в окно валидатора.

В меню «Задача» вы можете выбрать тип проверки или сделать ее общей (установлено по умолчанию).

seodon.ru


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.