10 популярных мифов о валидности и валидации
Миф 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, потому что он — его подмножество) есть дополнительное (помимо валидности!) ограничение синтаксиса — веллформность («правильная сформированность», синтаксическая корректность). Именно она требует обязательного закрытия всех тегов (в т.ч. «самозакрытия» одиночных), «закавыченности» всех атрибутов, непременного экранирования амперсанда в виде & и т.п. Эти требования общие для всех языков на базе 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?Нет. Это надежная и полезная утилита, но это всего лишь программа, и, как у любого программного обеспечения, у нее есть ошибки и проблемы. Актуальный справочник по таблицам каскадных стилей есть в их спецификации.
Миф 9. Все валидаторы одинаково полезны
Пример употребления: «В пустые span-ы нужно вставлять хотя бы , иначе будет невалидно»
Реальность: не всё валидатор, что валидирует:). Например, популярный некогда аддон для Firefox с говорящим, казалось бы, названием «HTML validator» по умолчанию проверял совсем не тем алгоритмом, что официальный валидатор W3C. И считал многие вещи, вполне разрешенные стандартом (напр. те же пустые span-ы) ошибками! Хорошего в пустых span-ах, конечно, мало, но это не повод обвинять в несуществующих грехах сам стандарт. Поэтому, если пользуетесь «валидатором», отличным от официального валидатора W3C, обязательно поинтересуйтесь, что и как он проверяет на самом деле. Остерегайтесь подделок!
Миф 10. Все валидаторы, кроме официального валидатора W3C — ничто
Употребляется не так часто, но разоблачение предыдущего мифа иногда приводит к противоположной крайности
Реальность: во-первых, валидатор W3C проверяет только те стандарты, которые разработаны самим W3C. Так что сторонние валидаторы для сторонних стандартов — это логично. Например, валидаторы микроразметки Яндекса, Гугла и т.д. — вполне правильная и полезная вещь. Во-вторых, валидаторы (даже официальные!) — программы, гм… туповатые. Они проверяют «сферический код в вакууме» (например, для многострадального XHTML валидатор предполагает, что разбираться он будет XML-парсером, а скрипты в HTML-комментариях действительно закомментарены, т.е. «временно убраны», а не всего-навсего скрыты таким способом от архаичных браузеров).