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

Как со мной это часто бывает, статья, задуманная как несколько абзацев и сжатых списков, превратилась в немаленький экскурс с теорией и практикой :-)

Well-formed

"Well-formed" довольно трудно кратко перевести на русский. Пожалуй, наиболее точно передает смысл словосочетание "синтаксически корректный". Но поскольку распространенного термина нет, я буду продолжать писать английское название (которое, кстати, читается примерно как "вел-формд").

Сначала скажу, что вообще знакомые всем документы с тегами в угловых скобочках (< >) описываются стандартом SGML. Язык HTML как раз построен на его базе. Правила SGML довольно витиеваты и допускают много вольностей, которые очень облегчают написание кода вручную. Но наличие вольностей повышает вероятность ошибок, а также сильно усложняет машинный парсинг: очень много вариантов обрабатывать надо.

Для решения этих проблем придумали понятие well-formed: набор более четких и жестких правил составления документов с тегами. Эти правила и является сущностью того, что называется "XML". Другими словами, XML - это документ с тегами, оформленный по жестким правилам синтаксической корректности. Формально правил этих много - целая спецификация, но на практике для человека, знакомого, например, с HTML это сводится к таким простым вещам:

Жесткость этих правил такова, что если XML-парсер встречает хотя бы одну ошибку он обязан моментально бросить парсинг и сообщить об ошибке юзеру. Это правило известно как "драконовский контроль ошибок". В отличие от XML'а HTML, например, не определяет таких правил, и поэтому браузеры стараются как могут исправлять ошибки, допущенные авторами (или их софтом). Это поведение называют "прощающий" или "либеральный" парсинг.

Если внимательно посмотреть на правила well-formed'ности, то они ничего не говорят о наличии или отсутствии каких-то конкретных элементов. То есть well-formed'ность - это свойство любого XML-документа, и ее можно проверить вообще ничего не зная о том, что именно это за документ.

Валидность

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

Кстати, HTML и XHTML - это, по сути, два варианта одного и того же языка, но первый использует синтаксис SGML, а второй - более жесткого XML.

Так вот валидность - это синтаксические правила корректности конкретных XML и SGML языков.

На самом деле, не только XML и SGML. У любого языка есть понятие валидности - соответствия правилам синтаксиса.

В языках с тегами правила валидности определяют такие вещи:

Например, язык XHTML определяет, что его корневым элементом должен быть элемент <html> (именно в таком написании). А внутри него могут находится два других элемента: <head> и <body> (и только они). Ну и так далее...

Правила валидности можно записать формально. Для этого служит DTD - Document Type Definition. Это описание подключается к документу в виде длинной строчки-заклинания, которая обычно стоит в самом начале и начинается с <!DOCTYPE ... >. На сайте W3C есть список DTD для большинства теговых языков, которые используются на вебе.

Так вот по этим DTD как раз и производится автоматическая валидация (проверка валидности) документов. Валидатор смотрит на DOCTYPE в начале документа и проверяет его на соответствие правилам этого языка.

Conformance

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

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

Другими словами, документ может быть полностью валидным, но совершенно не соответствовать стандарту.

Чтобы не высасывать пример из пальца, сошлюсь на Hixie, который специально на эту тему предложил викторину, в которой дал валидный документ, в котором, тем не менее, было 4 четких ошибки несответствия спецификации HTML.

Если вам лень кликать по ссылкам, вот код документа:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html lang="english">
<title>Written by Ian Hickson</title>
<h1>Current weather in <cite>Berlin, Germany</cite></h1>
<p>There are thunderstorms in Berlin at the moment. The air is very
humid. The temperature is a warm 24&deg;C.
<img src="icons/low-wind" alt="low wind icon">

Кому интересно, потратьте пару минут, посмотрите, найдете ли вы эти 4 ошибки. Я привел ответы в конце статьи.

Самая большая засада с этой "конформностью" состоит в том, что ее, очевидно, совершенно нереально проверить машинным способом. Поэтому не ищите на W3C официальных кнопок "conformant XHTML". Это проверяется только самостоятельно.

Валидность в современном вебе

Сейчас заявлять валидность своих документов модно. Многие системы управления контентом самых разных направлений завяляют это в своих списках фич (например WordPress, DokuWiki). И многие авторы вешают себе на странички кнопочки "Валидный (X)HTML". Однако практически пользы от этой самой валидности - не много.

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

Например, если блог-движок получает комментарий с URL'ом, то он, по идее, должен заменить все & на &. Если он этого не делает, код перестает быть валидным. Или, например, веб-мастер запихивает в страницу код какой-нибудь кнопки или счетчика, скопировав его из исходника, а тот тоже может оказаться невалидным.

Другими словами, валидация - это не состояние, а процесс, который требует внимания. Справедливости ради надо сказать, что есть сайты, на которых софт доработан достаточно хорошо, и обрабатывает все такие ситуации (как например блог Саймона Виллисона - всегда валидный, well-formed XHTML). Но таких мало.

Однако такое состояние дел с валидацией, очевидно, не мешает нам с вами ходить по интернету. Дело в том, что все потребительские браузеры на валидацию попросту плюют :-). Причем, делают это совершенно "законно":

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

Некоторое время назад я хотел сделать extension для Firefox'а, который бы, находя на странице элемент <address>, выбирал бы из него информацию о контактной информации с автором или владельцем ресурса. Но в итоге забросил, потому что это не работало бы на подавляющем большинстве валидных сайтов. Никто не пишет контактную информацию в <address>, никто не пишет alt-текстов к картинкам "как доехать" и т.д.

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

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

Бонус: валидация CSS

Кроме кнопок про валидный (X)HTML, есть и кнопки про валидный CSS. И если валидация HTML, как я говорил выше, вещь хоть и не самая важная, но по крайней мере понятная, то валидация CSS - зверь странный...

Чтобы проверить валидность страницы автоматически, надо знать, с синтаксисом какого языка и какой его версии сверяться. Для (X)HTML ссылка на синтаксис, как я говорил, указывается через DOCTYPE в начале документа. А вот для CSS ничего такого нет. Автоматический валидатор CSS на W3C, насколько я понимаю, проверяет CSS на соответствие текущей официальной спецификации - CSS2.

Но у CSS другая идеология, в ней, в общем-то, и понятия "версий" языка нет. Идеология состоит в том, что язык постоянно дорабатывается, причем не обязательно целиком, а блоками. Например, CSS уровня 2 сейчас в процессе замены на CSS2.1, в котором отменены многие вещи, которые не были реализованы или были плохо реализованы. CSS уровня 3 представляет собой набор модулей, некоторые из которых уже почти являются официальными рекомендациями, а некоторые - глухие черновики.

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

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

Это означает, что если вы захотите использовать свойство opacity из CSS3, то валидатор ругнется, хотя ничего страшного вы не сделали, и ничего не сломали. Даже потенциально.

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


Ответы на викторину

  1. Слово "english" в атрибуте lang не является допустимым кодом языка. Там должен быть код из RFC 1766 - "en".
  2. В элементе <title> написан не заголовок страницы, а имя автора. Заголовок должен быть в духе "Погода в Берлине", а имя автора должно быть написано в элементе <address>.
  3. Элемент <cite> тоже использован не по назначению. Он нужен для обозначения источника цитаты, а название места тут ни при чем.
  4. Alt-текст для картинки неправильный. Он используется вместо картинки, если она по каким-то причинам не отобразилась. Чтобы текст не выглядел криво, alt должен был быть "Ветер слабый.", а не "иконка слабого ветра".

Комментарии: 13 (feed)

  1. chapai

    По поводу примера - а как насчет отсутствия и ?
    Title как раз не является ошибкой, это дела автора. а вот насчет формата image я не уверен. Цитата - тоже не ошибка, выглядит корректно, и сугубо авторское дело.

  2. chapai

    sorry
    <Body&qt;
    </HTML&qt;

  3. Иван Сагалаев

    Повторюсь, пример полностью валидный. Все, что там опущено - это как раз те вольности, который допускает SGML, про которые я писал в пункте про well-formed'ность.

    Смысл примера не в этом, а в том, чтобы показать, что полное соответствие стандарту нельзя проверить автоматически. Это, в общем-то, можно считать авторским делом, но человек, глядя на этот документ, определенно может сказать, что "written by ..." - это не название этого документа.

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

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

  4. 8AleX8

    Утверждение: XHTML определяет два режима для парсера: валидирующий и невалидирующий. Все браузеры работают, как невалидирующие парсеры, поэтому в XHTML валидность не проверяют вообще. не точно. Оно полностью верно только для IE. А вот остальные современные браузеры (Firefox, Opera и т.д.) выберают тип парсинга в соответствие с MIME типом документа, обьявляемым веб сервером (Content-Type).
    Любые документы (HTML и XHTML) served as text/html действительно в любом случае подвергаются только “либеральному” парсингу.
    Но все домкументы обьявленные сервером (http://www.rfc-editor.org/rfc/rfc2616.txt ) как application/xhtml+xml будут обрабатываться по всем правилам XML без каких либо скидок.
    Serving XHTML 1.0
    XHTML Media Types
    Checking HTTP Headers

  5. Иван Сагалаев

    Нет, это вы о другом немного. Здесь я говорю не о text/html, а именно о настоящем XHTML, именно о том случае, когда он со своим правильным MIME-типом пересылается. В этом случае он действительно является XML'ом и обрабатывается в новых браузерах XML-парсером. И вот уже в самом XML есть эти два режима парсинга - валидирующий и невалидирующий.

    http://www.w3.org/TR/2004/REC-xml-20040204/#proc-types

    И этот невалидирующий - вполне себе такой же официальный, а вовсе не либеральный, которым парсится text/html. В нем проверяется XML'ная well-formed'ность, но не проверяется соответствие DTD.

  6. 8AleX8

    Ничего не понял.

  7. Константин

    Замечательная статья.
    Ясному пониманию семантических ошибок в викторине хорошо способствует даже прочтение "сухой" в техническом смысле спецификации HTML.

  8. monokril
        <p>На дворе 2007 год, и плагин для FireFox по проверке валидности уже есть - TYDY. И он сейчас мне показывает что на странице автора блога</p>
    

    <ol> <li> <p>line 229 column 9 - Предупреждение: неизвестная ссылка на сущность "&amp;qt"</p> </li> <li> <p>line 230 column 10 - Предупреждение: неизвестная ссылка на сущность "&amp;qt"</p> </li> </ol> <p>зы.</p> <p>Спасибо за статьи, с удовольствие читаю!</p>

  9. Denis

    Отличные статьи! Лучшего пособия по правильной верстке не встречал.

    Иван, вы собираетесь выпускать свои статьи в печатном виде?

  10. Иван Сагалаев

    Вряд ли... Времени не найду. Да и тут они тоже неплохо читаются :-)

  11. Рон Марун

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

    Но работа солидная и правильная.
    Надеюсь, что специалисты оценят.
    Зато теперь более или менее понимаю, что такое валидность.

    Удачи и творческих успехов!

  12. Миркус

    действительно очень здорово всё тут написано,
    и по человечески понятно.

    спасибо.
    вроде на RSS подписан ,статей в этом блоге я.
    но ссылку с xpoint.ru на статью порекомендовали.

    Всё очень близко по духу.

  13. Александр

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

    DOCTYPE - зло. Вольные мысли сам-себе HTML-кодера. http://html-pedia.narod.ru/private/studdraw/doctype-is-evil.html

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

Format with markdown