Заказать вёрстку
  • verstka.pro

О валидности и невалидности

Когда речь заходит о вёрстке, практически всем, даже самым неосведомлённым людям, на ум приходит слово «валидность». Кто-то подробно знает что это такое, кто-то читал мельком в паре статей и усвоил для себя лишь то, что валидность нужна, но не усвоил зачем. В любом случае, большинство сходятся на том, что сайт должен быть валиден. Но часто они заблуждаются.

Начнём с того, что валидность бывает разная. В русскоговорящей части вселенной чаще всего проверяют валидность HTML и CSS. При этом существуют и другие стандарты, например WCAG. Я встречал мало сайтов (и не только российских), соблюдающих все эти стандарты в точности, а уж если и соблюдают первые два, то о последнем речи и не едёт. Так почему же заказчики требуют валидно, а получается как всегда?

Зайдите на любые 10 сайтов с установленными баннерами W3С и нажмите на них. Вы никогда не увидите безошибочный код даже и на половине этих сайтов. В чём же дело?

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

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

О валидности HTML

Валидность HTML — святое. В ней и лежит залог правильного отображения сайта во всех браузерах. Будем считать, что валидный HTML это абсолютно правильный HTML. За примером здесь далеко ходить не надо: попробуйте вставить div внутрь label и попробовать кастомизировать всё это в FireFox.

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

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

О валидности CSS

«Лучший валидатор — это браузер».
Артемий Лебедев

С валидностью CSS, в отличие от HTML, всё обстоит немного иначе. Все мы знаем, что браузеры — существа своеобразные (в особенности Internet Explorer), и иногда одинаковый код понимают по-разному, даже когда HTML написан правильно. Возникает проблема: как же свести к минимуму отличия в рендеринге? Тут есть как минимум три пути: переназначение стилей через JavaScript, использование CSS-хаков или использование условных комментариев (для IE).

Остановимся на самом распространённом способе — на хаках. Хаки (hacks) — это CSS-свойства, позволяющие изменить отображение отдельного элемента в отдельном браузере. Они не всегда являются валидными и основаны на особенностях движков различных браузеров. Это первая причина невалидности большинства сайтов. Многие сейчас зададут резонный вопрос: «А почему бы не отказаться от невалидных хаков и сделать как-то иначе?». Отвечаю.

  • Используя хаки, мы часто уменьшаем количество кода на странице по сравнению с валидной версией стиля
  • Мы используем хак прямо в том селекторе, в котором он нужен, наравне с обычными стилями. Чтобы сделать валидно, нужно вынести определённый код в отдельный CSS-файл. В свою очередь это затрудняет поддержку сайта (незнакомому человеку придётся дольше искать место, в котором вы перекрыли какое-либо свойство), увеличивает количество запросов к серверу и делает CSS в целом менее удобным
  • Исходя из первых двух пунктов, использование хака будет более правильным решением, нежели погоня за валидностью

Такой вариант является правильной невалидностью. Она не наносит вреда и заметна лишь при проверке валидатором. Но я не думаю, что пользователи часто проверяют ваш сайт.

При этом я не говорю, что в CSS вы можете писать всё как вам хочется. Вы должны соблюдать стандарты установленные W3C, но вы можете использовать нестандартизированные методы для наилучшего достижения цели. И если используете такие методы, вы должны чётко понимать зачем это делаете.

Всегда помните Грамотный и опытный верстальщик сделает одновременно невалидно и хорошо, а начинающий — валидно и плохо.

О программистах

Конечно, вполне существуют хорошие верстальщики, которые предоставляют своим заказчикам на 100% валидный код. Заказчик получает вёрстку, радуется, отдаёт её программисту. В итоге получается сайт. Заказчик гордо вводит его адрес в валидатор и настроение сразу портится. И самое главное, что верстальшик тут уже ни при чём.

Например: приходит заказчик и говорит, что ему нужна вёрстка под какую-то CMS и сразу же интересуется, валиден ли будет код. Ответить на этот вопрос точно практически невозможно. Я не спорю, что есть очень хорошие системы управления сайтом, которые не вторгаются в новый шаблон, или вторгаются «мягко» — без распространения всяких невалидных и неправильных вещей.

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

О пользователях

«Ничего не доверяйте пользователям. Они всегда всё ломают».

Допустим, вы заказчик и вам повезло — всё вышеописанное не имело отношения к вам в процессе разработки сайта. Вы стали наполнять сайт информацией. И однажды замечаете, что одна или несколько страниц сайта расползлись. Вы не знаете в чём причина, а самое главное — не знаете что делать. А причина совсем рядом. Причина — вы сами.

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

Итоги

Итак, мы рассмотрели два вида невалидности: правильную и неправильную. На конкретных примерах я попытался рассказать о возможных причинах невалидности и о их последствиях.

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

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

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

Не гонитесь за валидностью. Верстайте правильно.

Нет времени разбираться? Закажите вёрстку сайта у меня =)