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

Что за страшное слово?

Основные правила составления веб-документа содержатся в спецификациях, разрабатываемых Консорциумом Всемирной Паутины (w3c), в сотрудничестве с создателями web-браузеров.

При проведении процесса валидации выполняются следующие задачи:

1. Проверка на наличие синтаксических ошибок
2. Отслеживание вложенности тегов. Например, валидатор проверит не забыли ли вы закрыть все свои теги.
3. Проверка соответствия вашего кода объявленому Document Type Definition (названия тегов, атрибутов, встраивания тегов и т.д.).
4. Валидация посторонних элементов (тех, которые не входят в Document Type Definition). Например, пользовательские атрибуты и т.д.

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

Чтобы объективно оценить роль валидации в современном web-программировании, рассмотрим ее преимущества и недостатки.

Быть!.. или преимущества

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

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

2. Размер имеет значение. Ошибки и исправления, при обработке кода валидатором могут быть малозаметными на простых, но очень весомыми на объемных и сложных проектах. Количество кода редуцируется, повышается его «readability». Страницы сайта грузятся быстрее.
3. «Мы в тренде». С каждым новым обновлением разработчики веб-браузеров максимизируют поддержку спецификаций, что приводит к уменьшению общего количества ошибок отображения документов. Веб-мастера, в свою очередь, придерживаются стандартов, дабы соответствовать тенденциям современного веб-дизайна.
4. «Мы модные». Валидация кода в среде веб-разработчиков стала аналогом «хорошего тона», и некоторые из них размещают на созданных сайтах иконки, свидетельствующие о соответствии спецификациям HTML. Более того, эта мода распространилась и на заказчиков — сегодня в техническом задании на разработку нередко можно увидеть пункт «выполнение по веб-стандартам».
5. Ну и напоследок… Если вы планируете использовать в своих проектах XML, то приучив себя придерживаться спецификаций, в дальнейшем сэкономите ящик времени и два ящика нервов. Синтаксис XML является более строгим и напоминает некоторые языки программирования, в которых компиляция проекта не возможна до полной отладки кода.

Куда же без них, или минусы

1. Кросс-браузерность. Не смотря на то, что разработчики браузеров стараются придерживаться web-development канонов, валидный код не гарантирует 100%-ю правильность отображения документа.
2. Удобность.Заходя на сайт, пользователь хочет видеть нужный ему контент в его любимом браузере, странички чтоб там быстро загружались… И, заметьте, ни слова о w3c. Валидный код не гарантирует удобность.
3. Эмоции. Валидный код не гарантирует хороший Опыт взаимодействия

(англ. User eXperience, UX) — определяет личное восприятие пользователем функциональных и эмоциональных параметров продукта (услуги) в процессе взаимодействия.

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

Подытожим?

Так стоит ли включать такой инструмент как валидация в свой «джентельменский набор»? Конечно же стоит.

Так, например, проверки №1 и №2 (см. начало статьи) являются обязательными в любом случае и при любом профессиональном уровне разработчика. Они помогут обнаружить серьезные недочеты, или просто «почистят» ваш код.

Проверка №3 так же важна, хотя и в меньшей степени. Проверка №4 ситуационная, в некоторых конкретных задачах она незаменима, но могут и возникнуть проблемы (например при вставке контента с отличающейся разметкой — SVG или MathML.).

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