Валидацией будем называть проверку документа на соответствие веб-стандартам и выявление существующих ошибок. Соответственно, валидным является такой веб-документ, который прошел подобную процедуру и не имеет замечаний по коду. Код веб-страницы должен подчиняться определенным правилам, которые называются спецификацией, ее разрабатывает W3 Консорциум (www.w3c.org) при поддержке разработчиков браузеров. На первый взгляд, кажется, что валидация необходима, ведь речь идет о сокращении количества ляпов разработчиков и написании «правильного» кода. На деле все обстоит гораздо сложнее и вокруг валидации до сих пор ведутся горячие споры об ее актуальности. Чтобы объективно раскрыть этот вопрос далее рассмотрим плюсы и минусы такой проверки.
Плюсы валидации
Хотя HTML-код имеет достаточно простую иерархическую структуру, при разрастании объема документа в коде легко запутаться, следовательно, просто и совершить ошибку. Браузеры, несмотря на явно неверный код, в любом случае постараются отобразить веб-страницу. Но поскольку не существует единого регламента о том, как же должен быть показан «кривой» документ, каждый браузер пытается сделать это по-своему. А это в свою очередь приводит к тому, что один и тот же документ может выглядеть по-разному в популярных браузерах. Исправление явных промахов и систематизация кода приводит, как правило, к стабильному результату.
Тенденции
Времена, когда производители браузеров добавляли уникальные возможности в свой продукт вопреки всем стандартам, начинают уходить в прошлое. Каждая новая версия браузера все больше поддерживает спецификации и отображает документы с минимальными ошибками или вообще без них. Разработчики сайтов, также придерживающихся канонов веб-стандартов, таким образом соответствуют современным тенденциям развития веб-технологий. Не стоит забывать и об XML (eXtensible Markup Language, расширяемый язык разметки). Этот язык становится стандартом де-факто для хранения данных и обмена информацией между разными приложениями. Синтаксис XML более жесткий, чем HTML и не прощает малейших ошибок. В каком-то смысле XML похож на языки программирования, в которых программа не будет скомпилирована, пока код не отлажен. HTML является первой ступенькой к изучению XML, поэтому приучая себя писать код по всем правилам, будет легче перейти к следующему этапу развития HTML.
Мода на валидацию
Как это не удивительно, но среди веб-разработчиков тоже существует своя мода. Текущая мода — создавать валидные документы и вывешивать специальный значок в виде картинки, что сайт соответствует спецификации HTML. Подобная тенденция затронула даже заказчиков сайтов и при написании технического задания на разработку сайта некоторые из них специально оговаривают, чтобы сайт был выполнен по веб-стандартам.
Косвенные преимущества
Следование стандартам во многом дает множество выгод, которые проявляются в мелочах и становятся заметными при достижении определенной критической массы. В частности, объем кода становится меньше, компактнее и читабельнее. Соответственно, для пользователей повышается скорость загрузки сайта в целом.
Минусы валидации
Сайты, конечно же, делают для того, чтобы их посещали люди. Именно посетители выступают мерилом работы сайта, а их интересует информация и способ ее получения. Пользователь желает, чтобы сайт корректно отображался в его любимом браузере, быстро загружался и содержал те материалы, которые ему нужны. Заметьте, в этом списке нет ничего про код документа и его валидность, посетителей это просто не интересует. Поэтому совершенно невалидный сайт, но выполненный с душой, наполненный интересными материалами привлечет к себе больше посетителей, чем пустой ресурс, но сделанный по всем «правилам».
Браузеры
Разработчики браузеров не всегда следуют спецификации и в некоторых случаях трактуют код не по заданным правилам, а по-своему. В конечном итоге это приводит к тому, что веб-страница, которая правильно (т.е. так, как и задумывали разработчики) отображается в одном браузере, выводится с ошибками в другом. Следование спецификации в подобных случаях, скорее всего, отпугнет пользователей некоторых браузеров. К примеру, Internet Explorer (IE) в настоящее время занимает лидирующее положение среди браузеров, но при этом поддерживает спецификация и CSS хуже, чем Firefox и Opera. Очевидно, что пользователи IE при посещении сайта выполненного по всем стандартам, но не учитывающего специфику этого браузера, увидят неприглядную картину. Заказчикам сайта, а также их разработчикам подобная ситуация не по нраву, поэтому стоя перед выбором: стандарты или браузер, они в большинстве своем выбирают браузер. Получается неутешительная картина — тратить время на отладку кода для соответствия спецификации нет особой нужды. Это время лучше посвятить тому, чтобы документ без проблем работал в разных браузерах — так в основном размышляют веб-разработчики.
Резюме
Так стоит ли проводить валидацию документов и заниматься этим этапом при написании веб-страниц? Безусловно, да. Кому-то она поможет выявить существующие недочеты, другому поможет писать корректный код. Исправлять же ошибки, добиваясь полного соответствия стандартам, или оставить их ради совместимости с разными браузерами — здесь уже каждый решает сам, какие цели он преследует и что для него важнее.
Валидацией будем называть проверку документа на соответствие веб-стандартам и выявление существующих ошибок. Соответственно, валидным является такой веб-документ, который прошел подобную процедуру и не имеет замечаний по коду. Код веб-страницы должен подчиняться определенным правилам, которые называются спецификацией, ее разрабатывает W3 Консорциум (www.w3c.org) при поддержке разработчиков браузеров. На первый взгляд, кажется, что валидация необходима, ведь речь идет о сокращении количества ляпов разработчиков и написании «правильного» кода. На деле все обстоит гораздо сложнее и вокруг валидации до сих пор ведутся горячие споры об ее актуальности. Чтобы объективно раскрыть этот вопрос далее рассмотрим плюсы и минусы такой проверки.
Плюсы валидации
Хотя HTML-код имеет достаточно простую иерархическую структуру, при разрастании объема документа в коде легко запутаться, следовательно, просто и совершить ошибку. Браузеры, несмотря на явно неверный код, в любом случае постараются отобразить веб-страницу. Но поскольку не существует единого регламента о том, как же должен быть показан «кривой» документ, каждый браузер пытается сделать это по-своему. А это в свою очередь приводит к тому, что один и тот же документ может выглядеть по-разному в популярных браузерах. Исправление явных промахов и систематизация кода приводит, как правило, к стабильному результату.
Тенденции
Времена, когда производители браузеров добавляли уникальные возможности в свой продукт вопреки всем стандартам, начинают уходить в прошлое. Каждая новая версия браузера все больше поддерживает спецификации и отображает документы с минимальными ошибками или вообще без них. Разработчики сайтов, также придерживающихся канонов веб-стандартов, таким образом соответствуют современным тенденциям развития веб-технологий. Не стоит забывать и об XML (eXtensible Markup Language, расширяемый язык разметки). Этот язык становится стандартом де-факто для хранения данных и обмена информацией между разными приложениями. Синтаксис XML более жесткий, чем HTML и не прощает малейших ошибок. В каком-то смысле XML похож на языки программирования, в которых программа не будет скомпилирована, пока код не отлажен. HTML является первой ступенькой к изучению XML, поэтому приучая себя писать код по всем правилам, будет легче перейти к следующему этапу развития HTML.
Мода на валидацию
Как это не удивительно, но среди веб-разработчиков тоже существует своя мода. Текущая мода — создавать валидные документы и вывешивать специальный значок в виде картинки, что сайт соответствует спецификации HTML. Подобная тенденция затронула даже заказчиков сайтов и при написании технического задания на разработку сайта некоторые из них специально оговаривают, чтобы сайт был выполнен по веб-стандартам.
Косвенные преимущества
Следование стандартам во многом дает множество выгод, которые проявляются в мелочах и становятся заметными при достижении определенной критической массы. В частности, объем кода становится меньше, компактнее и читабельнее. Соответственно, для пользователей повышается скорость загрузки сайта в целом.
Минусы валидации
Сайты, конечно же, делают для того, чтобы их посещали люди. Именно посетители выступают мерилом работы сайта, а их интересует информация и способ ее получения. Пользователь желает, чтобы сайт корректно отображался в его любимом браузере, быстро загружался и содержал те материалы, которые ему нужны. Заметьте, в этом списке нет ничего про код документа и его валидность, посетителей это просто не интересует. Поэтому совершенно невалидный сайт, но выполненный с душой, наполненный интересными материалами привлечет к себе больше посетителей, чем пустой ресурс, но сделанный по всем «правилам».
Браузеры
Разработчики браузеров не всегда следуют спецификации и в некоторых случаях трактуют код не по заданным правилам, а по-своему. В конечном итоге это приводит к тому, что веб-страница, которая правильно (т.е. так, как и задумывали разработчики) отображается в одном браузере, выводится с ошибками в другом. Следование спецификации в подобных случаях, скорее всего, отпугнет пользователей некоторых браузеров. К примеру, Internet Explorer (IE) в настоящее время занимает лидирующее положение среди браузеров, но при этом поддерживает спецификация и CSS хуже, чем Firefox и Opera. Очевидно, что пользователи IE при посещении сайта выполненного по всем стандартам, но не учитывающего специфику этого браузера, увидят неприглядную картину. Заказчикам сайта, а также их разработчикам подобная ситуация не по нраву, поэтому стоя перед выбором: стандарты или браузер, они в большинстве своем выбирают браузер. Получается неутешительная картина — тратить время на отладку кода для соответствия спецификации нет особой нужды. Это время лучше посвятить тому, чтобы документ без проблем работал в разных браузерах — так в основном размышляют веб-разработчики.
Резюме
Так стоит ли проводить валидацию документов и заниматься этим этапом при написании веб-страниц? Безусловно, да. Кому-то она поможет выявить существующие недочеты, другому поможет писать корректный код. Исправлять же ошибки, добиваясь полного соответствия стандартам, или оставить их ради совместимости с разными браузерами — здесь уже каждый решает сам, какие цели он преследует и что для него важнее.
Для проверки веб-страниц на наличие ошибок и замечаний существует множество путей и способов. Условно они делятся на онлайновые и локальные. Онлайновые предназначены для проверки страниц с помощью браузера через Интернет, а локальные используются для проверки документов на текущем компьютере. Далее рассмотрим популярные методы валидации документов.
validator.w3.org По адресу http://validator.w3.org располагается, пожалуй, самый распространенный инструмент для проверки отдельных страниц на валидность. Этот сайт предлагает три способа проверки: по адресу, локального файла и введенного в форму кода.
Проверка по адресу Если ваш сайт уже опубликован в Интернете, то любую страницу можно проверить, вводя в текстовое поле ее адрес . Форма для ввода адреса документа
Так, вводя http://www.faqpk.ru/ в форме «Validate by URI» (валидация по адресу) и нажав кнопку Check (проверить) получим сообщение о том, валидный документ или нет.
Хотя в текстовом поле вводится адрес сайта, проверяется не сайт целиком, а только одна главная страница. Валидатор проверяет HTML-код страницы и в случае отсутствия ошибок докладывает о валидности документа Отчет о проверке и валидности веб-страницы
При обнаружении ошибок выводится уведомление о том, что страница не валидна и список ошибок с указанием строк, где встречаются ошибки Отчет о проверке и вывод ошибок
Проверка локальных файлов[/color] Документы, еще не выставленные в Интернете, можно проверить с помощью формы, озаглавленной «Validate by File Upload» (валидация загруженных файлов) [color=#999999]Форма ввода пути к локальному файлу для его проверки
Вначале следует указать путь к HTML-файлу, после чего нажать кнопку Check. Файл будет загружен на сервер и проверен на ошибки.
Использование формы для ввода кода[/color] В некоторых случаях требуется проверить код без сохранения его в отдельный файл. В этом случае пригодится форма для прямого набора текста и отправки его на сервер для валидации [color=#999999]Форма для ввода HTML-кода
Расширение HTML Validator для браузера Firefox[/color] Популярность браузера Firefox обусловлена наличием для него большого количества разнообразных расширений — программ, которые добавляют новые возможности в браузер. Расширения построены по открытой технологии и написать их может любой разработчик. Не оставлены без внимания и веб-разрабочики — для их удобства создано множество расширений, в том числе и для валидации документа прямо в браузере. В данном случае нас интересует HTML Validator. Эта программа построена по той же технологии, что и валидатор W3C, но не требует подключения к Интернету и работает прямо «на лету».
Где скачать http://users.skynet.be/mgueury/mozilla/
Использование формы для ввода кода[color=#999999] В некоторых случаях требуется проверить код без сохранения его в отдельный файл. В этом случае пригодится форма для прямого набора текста и отправки его на сервер для валидации
Использование формы для ввода кода[/color] В некоторых случаях требуется проверить код без сохранения его в отдельный файл. В этом случае пригодится форма для прямого набора текста и отправки его на сервер для валидации
Установка расширения[color=#999999] После скачивания файла установить расширение можно несколькими способами.
1. Через менеджер расширений Запустите Firefox и откройте меню Инструменты > Расширения. Перетащите мышью загруженный файл (он имеет расширение xpi) в открывшееся окно. Далее расширение будет установлено автоматически.
2. С помощью открытия файла Выберите в меню Firefox пункт Файл > Открыть файл... и укажите путь к файлу с расширением, дальнейшие действия браузер выполнит сам.
3. Копирование файла в папку extension Откройте папку на диске, где установлен Firefox (к примеру c:\Program Files\Mozilla Firefox) и найдите в ней подпапку extension, в которую скопируйте расширение. После запуска браузера дальнейшая установка пройдет самостоятельно.
Все приведенные методы установки требуют перезагрузки браузера после установки расширения. Работа HTML Validator начинается сразу же после повторного запуска Firefox.
Если указанные способы по каким-либо причинам не помогли, вы можете обратиться на сайт поддержки браузера Mozilla Firefox и прочитать обо всех возможных методах установки расширений по адресу http://forum.mozilla-russia.org/doku.ph....talling
Использование HTML Validator При открытии веб-страницы HTML Validator начинает сразу же свою работу, и результат проверки отображается в строке состояния, в ее правом нижнем углу в виде небольшой картинки. Изображение зависит от статуса проверки Виды картинок, отображаемых при проверке документа
Кружок с галочкой показывает, что документ валидный, желтый треугольник с восклицательным знаком — по коду имеются замечания, которые могут быть исправлены автоматически. А красный кружок с крестиком предупреждает, что есть серьезные ошибки.
Просмотреть все ошибки можно двояко. Во-первых, заглянуть в HTML-код документа через меню Вид > Исходный код страницы или щелкнуть правой кнопкой и в контекстном меню выбрать Просмотр исходного кода страницы Контекстное меню с пунктом выбора исходного кода
Окно исходного кода веб-страницы разделено на три части (рис. 14.8), где верхний блок содержит собственно HTML-код. В левом нижнем блоке отображается список ошибок и замечаний или информационные сообщения в случае валидного документа. Правый нижний блок предназначен для подробных подсказок о текущих замечаниях. Результат работы расширения HTML Validator
Для проверки веб-страниц на наличие ошибок и замечаний существует множество путей и способов. Условно они делятся на онлайновые и локальные. Онлайновые предназначены для проверки страниц с помощью браузера через Интернет, а локальные используются для проверки документов на текущем компьютере. Далее рассмотрим популярные методы валидации документов.
validator.w3.org По адресу http://validator.w3.org располагается, пожалуй, самый распространенный инструмент для проверки отдельных страниц на валидность. Этот сайт предлагает три способа проверки: по адресу, локального файла и введенного в форму кода.
Проверка по адресу Если ваш сайт уже опубликован в Интернете, то любую страницу можно проверить, вводя в текстовое поле ее адрес . Форма для ввода адреса документа
Так, вводя http://www.faqpk.ru/ в форме «Validate by URI» (валидация по адресу) и нажав кнопку Check (проверить) получим сообщение о том, валидный документ или нет.
Хотя в текстовом поле вводится адрес сайта, проверяется не сайт целиком, а только одна главная страница. Валидатор проверяет HTML-код страницы и в случае отсутствия ошибок докладывает о валидности документа Отчет о проверке и валидности веб-страницы
При обнаружении ошибок выводится уведомление о том, что страница не валидна и список ошибок с указанием строк, где встречаются ошибки Отчет о проверке и вывод ошибок
Проверка локальных файлов[/color] Документы, еще не выставленные в Интернете, можно проверить с помощью формы, озаглавленной «Validate by File Upload» (валидация загруженных файлов) [color=#999999]Форма ввода пути к локальному файлу для его проверки
Вначале следует указать путь к HTML-файлу, после чего нажать кнопку Check. Файл будет загружен на сервер и проверен на ошибки.
Использование формы для ввода кода[/color] В некоторых случаях требуется проверить код без сохранения его в отдельный файл. В этом случае пригодится форма для прямого набора текста и отправки его на сервер для валидации [color=#999999]Форма для ввода HTML-кода
Расширение HTML Validator для браузера Firefox[/color] Популярность браузера Firefox обусловлена наличием для него большого количества разнообразных расширений — программ, которые добавляют новые возможности в браузер. Расширения построены по открытой технологии и написать их может любой разработчик. Не оставлены без внимания и веб-разрабочики — для их удобства создано множество расширений, в том числе и для валидации документа прямо в браузере. В данном случае нас интересует HTML Validator. Эта программа построена по той же технологии, что и валидатор W3C, но не требует подключения к Интернету и работает прямо «на лету».
Где скачать http://users.skynet.be/mgueury/mozilla/
Использование формы для ввода кода[color=#999999] В некоторых случаях требуется проверить код без сохранения его в отдельный файл. В этом случае пригодится форма для прямого набора текста и отправки его на сервер для валидации
Использование формы для ввода кода[/color] В некоторых случаях требуется проверить код без сохранения его в отдельный файл. В этом случае пригодится форма для прямого набора текста и отправки его на сервер для валидации
Установка расширения[color=#999999] После скачивания файла установить расширение можно несколькими способами.
1. Через менеджер расширений Запустите Firefox и откройте меню Инструменты > Расширения. Перетащите мышью загруженный файл (он имеет расширение xpi) в открывшееся окно. Далее расширение будет установлено автоматически.
2. С помощью открытия файла Выберите в меню Firefox пункт Файл > Открыть файл... и укажите путь к файлу с расширением, дальнейшие действия браузер выполнит сам.
3. Копирование файла в папку extension Откройте папку на диске, где установлен Firefox (к примеру c:\Program Files\Mozilla Firefox) и найдите в ней подпапку extension, в которую скопируйте расширение. После запуска браузера дальнейшая установка пройдет самостоятельно.
Все приведенные методы установки требуют перезагрузки браузера после установки расширения. Работа HTML Validator начинается сразу же после повторного запуска Firefox.
Если указанные способы по каким-либо причинам не помогли, вы можете обратиться на сайт поддержки браузера Mozilla Firefox и прочитать обо всех возможных методах установки расширений по адресу http://forum.mozilla-russia.org/doku.ph....talling
Использование HTML Validator При открытии веб-страницы HTML Validator начинает сразу же свою работу, и результат проверки отображается в строке состояния, в ее правом нижнем углу в виде небольшой картинки. Изображение зависит от статуса проверки Виды картинок, отображаемых при проверке документа
Кружок с галочкой показывает, что документ валидный, желтый треугольник с восклицательным знаком — по коду имеются замечания, которые могут быть исправлены автоматически. А красный кружок с крестиком предупреждает, что есть серьезные ошибки.
Просмотреть все ошибки можно двояко. Во-первых, заглянуть в HTML-код документа через меню Вид > Исходный код страницы или щелкнуть правой кнопкой и в контекстном меню выбрать Просмотр исходного кода страницы Контекстное меню с пунктом выбора исходного кода
Окно исходного кода веб-страницы разделено на три части (рис. 14.8), где верхний блок содержит собственно HTML-код. В левом нижнем блоке отображается список ошибок и замечаний или информационные сообщения в случае валидного документа. Правый нижний блок предназначен для подробных подсказок о текущих замечаниях. Результат работы расширения HTML Validator
Валидация документов предназначена не только для того чтобы удостовериться, что код соответствует спецификации HTML, но и с целью устранения имеющихся ошибок и замечаний в документе. Между тем, формирование определенной культуры написания кода позволяет существенно снизить или даже вообще избавиться от возможных ошибок. Такая культура складывается из знания спецификаций и типовых ляпов разработчиков, которых надо избегать.
По адресу http://www.w3.org/TR/html401/ ознакомиться с правилами HTML версии 4.01 может каждый, здесь же мы рассмотрим рядовые ошибки и научимся, как же их обходить.
Ошибки в коде обычно возникают по следующим причинам:
на странице не задан <!DOCTYPE>;
опечатка (неверно написан тег или его атрибут);
не указан обязательный атрибут тега;
используется тег или его атрибут, который не входит в спецификацию;
неверное вложение тегов.
Далее разберем эти ошибки подробнее.
Не указан <!DOCTYPE>
Элемент <!DOCTYPE> располагается в первой строке кода документа и сообщает браузеру, как интерпретировать код и отображать данную веб-страницу. Разница между страницей с <!DOCTYPE> и без него может быть очень существенной, к тому же валидатор в первую очередь проверяет наличие этого элемента в коде.
Опечатки
Очевидно, что самая простая для исправления ошибка возникает из-за опечатки, когда допущено неверное написание требуемого тега. После валидации выдается тип ошибки и номер строки в коде, где она имеется, так что остается только поменять значение на корректное.
Не указан обязательный атрибут тега
У некоторых тегов имеются атрибуты, которые обязательно должны присутствовать. Например, нельзя просто указать тег <style>, необходимо писать <style type="text/css">.
Атрибут или значение не входит в спецификацию
В порыве завоевать рынок пользователей разработчики браузеров добавляли в них специальные теги, не входящие в спецификацию HTML, но расширяющие возможности веб-страниц. Со временем часть таких тегов была включена в спецификацию, но многие так и остались «за бортом». При этом поддержка браузером осталась, так что результат работы тега наблюдать можно, но валидацию документ не пройдет. Типичным примером подобного тега является <marquee> придуманный компанией Microsoft и понимаемый всеми современными браузерами. Вот только в спецификацию этот тег не включен.
Неверное вложение тегов
Ошибка с вложением одного контейнера внутрь другого может быть вызвана следующими причинами:
блочный элемент располагается внутри строчного, когда должно быть наоборот — строчные элементы допустимо помещать внутрь блочных;
пересечение тегов, например, как это показано в следующем примере:<strong><em>текст</strong></em>. Здесь закрывающий тег </strong>помещается в контейнер <em>, тогда как он должен следовать только после тега</em>;
не соблюдается порядок вложения тегов. В определенных элементах вроде списка и таблицы принципиальное значение имеет порядок следования тегов. Перестановка тегов местами может привести к неверному отображению объекта и появлению ошибок при валидации документа.
Напоследок отметим еще раз простые правила написания кода, соблюдение которых поможет существенно сократить количество ошибок или обойтись без них.
Закрывайте все теги
Хотя HTML и не требует присутствия некоторых закрывающих тегов, их наличие поможет сохранить строгость кода и четко определить порядок следования тегов.
Указывайте значения атрибутов тегов в кавычках
Валидатор во многих случаях пропустит значения атрибутов указанных без всяких кавычек, тем не менее, кавычки лучше писать всегда. Во-первых, подобный навык поможет для устранения возможных ошибок связанных с атрибутами тегов. А во-вторых, поможет легче перейти на XHTML (Extensible Hypertext Markup Language, расширяемый язык разметки гипертекста), синтаксически более строгую версию HTML. В XHTML кавычки выступают обязательным элементом синтаксиса.
Коллекционируйте заготовки
Большинство элементов веб-страницы достаточно шаблонно, поэтому имея в своем запасе набор проверенных заготовок на разные случаи, можно сократить затраты времени и быть уверенным, что код корректный.
Используйте блочные элементы
Нельзя так просто вставить текст в код документа, он должен располагаться внутри абзаца (тег <p>) или другого блочного элемента. В тех случаях, когда вы не знаете, какой блочный тег использовать, добавляйте универсальный элемент <div>.
Переключайте <!DOCTYPE>
В HTML-коде обычно применяется строгий <!DOCTYPE>, который наиболее полно соответствует спецификации. Однако он же и требует соблюдения всех, самых жестких правил написания кода. В тех случаях, когда это сложно или затратно по времени, переключайтесь на переходный <!DOCTYPE>.
Валидация документов предназначена не только для того чтобы удостовериться, что код соответствует спецификации HTML, но и с целью устранения имеющихся ошибок и замечаний в документе. Между тем, формирование определенной культуры написания кода позволяет существенно снизить или даже вообще избавиться от возможных ошибок. Такая культура складывается из знания спецификаций и типовых ляпов разработчиков, которых надо избегать.
По адресу http://www.w3.org/TR/html401/ ознакомиться с правилами HTML версии 4.01 может каждый, здесь же мы рассмотрим рядовые ошибки и научимся, как же их обходить.
Ошибки в коде обычно возникают по следующим причинам:
на странице не задан <!DOCTYPE>;
опечатка (неверно написан тег или его атрибут);
не указан обязательный атрибут тега;
используется тег или его атрибут, который не входит в спецификацию;
неверное вложение тегов.
Далее разберем эти ошибки подробнее.
Не указан <!DOCTYPE>
Элемент <!DOCTYPE> располагается в первой строке кода документа и сообщает браузеру, как интерпретировать код и отображать данную веб-страницу. Разница между страницей с <!DOCTYPE> и без него может быть очень существенной, к тому же валидатор в первую очередь проверяет наличие этого элемента в коде.
Опечатки
Очевидно, что самая простая для исправления ошибка возникает из-за опечатки, когда допущено неверное написание требуемого тега. После валидации выдается тип ошибки и номер строки в коде, где она имеется, так что остается только поменять значение на корректное.
Не указан обязательный атрибут тега
У некоторых тегов имеются атрибуты, которые обязательно должны присутствовать. Например, нельзя просто указать тег <style>, необходимо писать <style type="text/css">.
Атрибут или значение не входит в спецификацию
В порыве завоевать рынок пользователей разработчики браузеров добавляли в них специальные теги, не входящие в спецификацию HTML, но расширяющие возможности веб-страниц. Со временем часть таких тегов была включена в спецификацию, но многие так и остались «за бортом». При этом поддержка браузером осталась, так что результат работы тега наблюдать можно, но валидацию документ не пройдет. Типичным примером подобного тега является <marquee> придуманный компанией Microsoft и понимаемый всеми современными браузерами. Вот только в спецификацию этот тег не включен.
Неверное вложение тегов
Ошибка с вложением одного контейнера внутрь другого может быть вызвана следующими причинами:
блочный элемент располагается внутри строчного, когда должно быть наоборот — строчные элементы допустимо помещать внутрь блочных;
пересечение тегов, например, как это показано в следующем примере:<strong><em>текст</strong></em>. Здесь закрывающий тег </strong>помещается в контейнер <em>, тогда как он должен следовать только после тега</em>;
не соблюдается порядок вложения тегов. В определенных элементах вроде списка и таблицы принципиальное значение имеет порядок следования тегов. Перестановка тегов местами может привести к неверному отображению объекта и появлению ошибок при валидации документа.
Напоследок отметим еще раз простые правила написания кода, соблюдение которых поможет существенно сократить количество ошибок или обойтись без них.
Закрывайте все теги
Хотя HTML и не требует присутствия некоторых закрывающих тегов, их наличие поможет сохранить строгость кода и четко определить порядок следования тегов.
Указывайте значения атрибутов тегов в кавычках
Валидатор во многих случаях пропустит значения атрибутов указанных без всяких кавычек, тем не менее, кавычки лучше писать всегда. Во-первых, подобный навык поможет для устранения возможных ошибок связанных с атрибутами тегов. А во-вторых, поможет легче перейти на XHTML (Extensible Hypertext Markup Language, расширяемый язык разметки гипертекста), синтаксически более строгую версию HTML. В XHTML кавычки выступают обязательным элементом синтаксиса.
Коллекционируйте заготовки
Большинство элементов веб-страницы достаточно шаблонно, поэтому имея в своем запасе набор проверенных заготовок на разные случаи, можно сократить затраты времени и быть уверенным, что код корректный.
Используйте блочные элементы
Нельзя так просто вставить текст в код документа, он должен располагаться внутри абзаца (тег <p>) или другого блочного элемента. В тех случаях, когда вы не знаете, какой блочный тег использовать, добавляйте универсальный элемент <div>.
Переключайте <!DOCTYPE>
В HTML-коде обычно применяется строгий <!DOCTYPE>, который наиболее полно соответствует спецификации. Однако он же и требует соблюдения всех, самых жестких правил написания кода. В тех случаях, когда это сложно или затратно по времени, переключайтесь на переходный <!DOCTYPE>.
FAQpk.ru
