Введение в стандарты Web

Валидация HTML

Показывать лекцию целиком

Введение

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

Ответом является валидация (проверка на соответствие правилам)! Существует много доступных средств на сайте W3C и в других местах, которые позволяют выполнить валидацию кода сайта.

Наиболее известными валидаторами являются следующие:

  • ): Этот валидатор находит используемый в проверяемом документе doctype (X)HTML, и просматривает затем весь документ, указывая места, где код HTML не соответствует используемому doctype (т.е., где имеются ошибки кода HTML ).
  • ): Этот валидатор просматривает документ, представленный для проверки, и проверяет все ссылки в документе, чтобы гарантировать отсутствие неработающих ссылок (у которых значения href указывают на несуществующие ресурсы).
  • ): Как можно догадаться, этот валидатор просматривает документ CSS (или HTML/CSS ) и проверяет, что CSS соответствует спецификациям CSS.
  • В этой статье будет рассмотрен первый из этих инструментов, чтобы показать, как его использовать, и как интерпретировать типичные результаты, которые возвращает валидатор. Проверка ссылок достаточно очевидна, а валидатор CSS также станет вполне понятен после прочтения этой статьи и статей по CSS, которые будут представлены дальше в курсе.

    Статья имеет следующую структуру:

  • Ошибки
  • Что такое валидация?
  • Зачем нужна валидация?
  • Различные браузеры интерпретируют неправильный код HTML по разному
  • Quirksmode
  • Как выполнить валидацию страниц
  • Валидатор W3C HTML
  • Заключение
  • Дополнительные инструменты
  • Контрольные вопросы
  • Ошибки

    В программировании компьютеров существует, вообще говоря, два вида проблем кода:

  • синтаксические ошибки - когда ошибки в записи кода не позволяют компьютеру правильно выполнить или скомпилировать программу.
  • ошибки программирования (или логики) — когда код не полностью отражает замысел программиста.
  • В большинстве языков программирования ошибки первого рода достаточно легко обнаружить - программа просто отказывается выполняться или компилироваться, пока ошибка не будет исправлена. Это делает поиск и исправление таких ошибок значительно проще в ситуациях "почему она не делает то, что я хочу".

    HTML не является языком программирования. Синтаксические ошибки на Web -странице обычно не ведут к тому, что Web-браузер отказывается открыть страницу (хотя XHTML является более строгим, чем HTML -- по крайней мере, когда обрабатывается как данные application/xhtml+xml или text/xml, как и должно быть - и некоторые doctype запрещают использование определенных типов элементов HTML ). Это является одной из основных причин быстрого принятия и распространения Web.

    Первый браузер ) написанный Тимом Бернерс-Ли, был также редактором, позволявшим людям создавать Web -страницы, не изучая сначала HTML. Этот редактор создавал неверный HTML. Это можно было бы исправить, но был создан важный прецедент, который существует во всех браузерах Web до сегодняшнего дня - суть которого в том, что предоставление людям доступа к контенту важнее, чем сообщение об ошибках людям, которые их не понимают или не могут их исправить.

    Что такое валидация?

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

    Программа валидации сравнивает код HTML на странице Web с правилами сопровождающего doctype и сообщает, какие правила и где были нарушены.

    Зачем нужна валидация?

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

    Существует некоторая доля истины в таком подходе, спецификация HTML не является совершенной, и сейчас существенно устарела. Некоторые вещи, которые, возможно, правильны (такие как начало упорядоченного списка в точке, отличной от 1) являются недействительными в HTML. Однако как говорит пословица:

    Учите правила, чтобы знать, как нарушать их правильно

    Существует две крайне важные причины для валидации кода HTML при его создании.

  • Человек не совершенен, как и создаваемый им код — все делают ошибки, и Web -страницы будут более высокого качества (т.е., работать более согласованно), если выполоть все ошибки.
  • Браузеры изменяются. В будущем браузеры, скорее всего, будут менее снисходительны при синтаксическом анализе недействительного кода.
  • Валидация является системой раннего предупреждения о существовании ошибок на страницах, которые могут проявлять себя разнообразным и трудно определяемым образом. Когда браузер встречает недействительный код HTML, он вынужден делать обоснованное предположение о том, что вы собирались делать - и различные браузеры могут приходить к различным ответам.

    Различные браузеры интерпретируют неправильный код HTML по разному

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

    Но что будет, если передать браузеру недействительный (невалидный) код? Что тогда произойдет? Ответ состоит в том, что в браузере начинает работать обработка ошибок, чтобы определить, что делать с кодом. Браузер, как правило, поступает следующим образом: "ладно, этот код недействителен, как можно представить эту страницу конечному пользователю? Давайте заполним недостающее следующим образом!"

    Звучит прекрасно, не правда ли? Если на странице имеется несколько ошибок, то браузер заполнит вместо вас недостающее? Не совсем так, так как каждый браузер делает это по-разному. Например:

    <p><strong>This text should be bold</p>
    <p>Should this text be bold? How does the HTML look when rendered?</p>
    <p><a href="#"></strong>This text should be a link</p>
    <p>Should this text be a link? How does the HTML look when rendered?</p>

    Ошибки состоят в том, что элемент strong неправильно вложен в несколько блочных элементов, а элемент анкера не закрыт.

    Когда вы попробуете вывести этот код в различных браузерах, они интерпретируют код совершенно по разному:

  • Opera сделает последующие элементы потомками элемента strong.
  • Firefox добавит дополнительные элементы strong между параграфами, которые не присутствуют в разметке.
  • Internet Explorer поместит текст "This text should be a link" ("Этот текст должен быть ссылкой") вне тега анкера, который создает ссылку.
  • Исходную версию этого примера можно найти в статье Халворда Стина "Одинаковые ошибки ) — прочтите ее, чтобы познакомиться с более глубокой обработкой ошибок HTML, и дополнительной информацией об инструментах отладки.

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

    Quirksmode

    Надо знать еще о так называемом режиме Quirksmode. Браузер переходит в этот режим, если встречает страницу, которая имеет неправильный doctype, или вообще не имеет doctype. В этом режиме браузер делает наилучшие предположения о множестве правил, согласно которым он должен интерпретировать код, и снова заполняет пробелы как можно лучшим образом. Этот режим существует в действительности для того, чтобы можно было все еще выводить старые страницы, и не должен никогда использоваться при создании новых страниц.

    Как выполнить валидацию страниц

    Теперь, когда мы исследовали теорию, лежащую в основе валидации HTML, поговорим о более простых вещах - реальной валидации! Впрочем, это не совсем точно. Поместить URL в валидатор и наблюдать, будет страница валидной или нет, действительно легко; понять, что неправильно и исправить ошибки иногда бывает трудно, так как сообщения об ошибках могут быть иногда слишком загадочными. Мы рассмотрим несколько примеров ниже.

    Пример, рассматриваемый в этом разделе, имеет следующий вид:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" lang="en">
      <head>
        <title>Validating your HTML</title>
      </head>
      <body>
        <h2>The tale of Herbet Gruel</h2>
        <pGT;Welcome to my story. I am a slight whisp of a man, slender and fragile, 
         features wrinkled and worn, eyes sunken into their sockets like rabbits cowering 
          in their burrows. The <em>years have not been kind to me</em>,
           but yet I hold no regrets, as I have overcome all that sought to ail me,
            and have been allowed to bide my time, 
              making mischief as I travel to and fro, 'cross the unyielding landscape of the
          <a href="http://outer-rim-rocks.co.uk" colspan="3">outer rim</a>.</p>
        <h3>Buster</h3>
        <p>Buster is my guardian angel. Before that, he was my dog. 
         Before that, who knows? I lost my dog many moons ago 
          while out hunting geese in the undergrowth. A shot rang out from my rifle, 
           and I called for Buster to collect the goose I had felled. He ran off towards 
            where the bird had landed, but never returned. I never found his body, 
             but I comfort myself with the thought that he did not die; 
              rather he transcended to a higher place, and now watches over me, to ensure my well-being.
        <h3>My possessions</h3>
        <p>A travelling man needs very little to accompany him on the road:</p>
        <ul>
          <li>My hat full of memories</li>
          <li>My trusty walking cane</li>
          <li>A purse that did contain gold at one time</li>
          <li>A diary, from the year 1874<li>
          <li>An empty glasses case</li>
          <li>A newspaper, for when I need to look busy</li>
        </ul>
      </body>

    Эта простая страница состоит из трех заголовков, трех параграфов, одной гиперссылки, и одного неупорядоченного списка. Она использует doctype XHTML 1.0 Strict в качестве своего множества правил для валидации. В документе имеется несколько ошибок, которые мы рассмотрим ниже, используя валидатор W3C HTML.

    Валидатор W3C HTML

    Как упоминалось выше, ) — откройте его в браузере в отдельной вкладке — будет полезно иметь возможность переключаться между вкладками браузера с валидатором и рассматриваемым примером из этой статьи.

    Отметим, что можно также выполнять валидацию страниц в валидаторе W3C прямо из браузера Opera, выполняя просто щелчок правой кнопкой мыши/при нажатой клавише Ctrl и выбирая пункт меню "Validate" ("Соблюдены ли Web -стандарты").

    Можно заметить, что валидатор имеет три вкладки вверху интерфейса:

  • Проверка URI: Позволяет ввести адрес страницы в Интернет для валидации.
  • Проверка загруженного файла: Позволяет загрузить для валидации файл HTML.
  • Проверка прямого ввода: Позволяет скопировать содержимое файла HTML в окно для валидации.
  • При использовании любого метода будет получен один и тот же результат; мне кажется, что проще всего протестировать пример страницы отсюда, копированием кода всего примеры выше, и вставкой его в окно третьей вкладки. В этом случае будет получен результат, показанный на рис. 24.1.

    (рис 24.1) Результаты валидации образца документа —17 ошибок!

    Это может звучать угрожающее, особенно, когда я говорю, что в документе имеется 17 ошибок! Не отчаивайтесь - валидатор сообщает больше ошибок, чем существует в действительности, так как часто ошибка в начале страницы будет каскадом порождать наведенные ошибки дальше, так как все больше элементов кажутся незакрытыми или неправильно вложенными. Необходимо просто подумать о том, что означают сообщения об ошибках, и искать очевидные ошибки в разметке. Таблица 24.1 ниже показывает все исправленные ошибки, чтобы можно было получить валидную страницу, вместе с объяснением, что было неправильно, и сделанное для разрешения проблемы исправление.

    Исправленные ошибки, чтобы сделать пример страницы допустимым
    Сообщение об ошибке Логика Сделанное исправление
    Строка 8, столбец 461: отсутствует атрибут "colspan" Мы знаем, что имеется атрибут colspan, и это допустимый HTML, поэтому почему сообщение о том, что он не существует? Подождите, может быть это означает, что он используется с элементом, на котором не должен использоваться? Конечно, он используется на элементе a — неверно! Удален атрибута colspan из элемента a
    Строка 13, столбец 7: тип документа не допускает здесь элемент "h3"; пропущен один из начальных тегов "object", "applet", "map", "iframe", "button", "ins", "del". <h3>My possessions</h3> Опять на первый взгляд это кажется странным — элемент h3 правильно закрыт, и допустим в этом контексте. Необходимо отметить, что часто это сообщение об ошибке означает, что поблизости имеется незакрытый элемент … Добавлен закрывающий тег p в строке выше данного заголовка
    Строка 19, столбец 40: тип документа не допускает здесь элемент "li"; пропущен один из начальных тегов "ul", "ol", "menu", "dir". <li>A diary, from the year 1874<li> Это достаточно просто — можно сразу увидеть из представленной строки, что в конечном теге li отсутствует закрывающая косая черта (/) Добавлена закрывающая косая черта в рассматриваемой строке
    Строка 23, столбец 9: отсутствует конечный тег для "html", но было определено OMITTAG NO.</body> Опять легко понять, что это означает, что конечный тег html отсутствует. Объяснение сообщения об ошибке даже начинается со слов "Вы могли не закрыть элемент". Добавлен отсутствующий конечный элемент html.

    После исправления этих ошибок валидатор выдает теперь достаточно удовлетворительное сообщение об успехе, как показано на рис.24.2 :

    (рис 24.2) Сообщение об успехе, говорящее, что все ошибки были исправлены

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

    Заключение

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

    Другие инструменты, с которыми стоит познакомиться

  • Меню отладки )
  • Букмарклет общей валидации (https://www.squarefree.com/bookmarklets/validation.html)
  • Расширение панели )
  • Панель инструментов разработчика в IE
  • )
  • )
  • Контрольные вопросы

  • Что происходит, когда браузер встречает недействительный HTML?
  • Какая возникает в этом случае проблема?
  • Будет ли использование frameset в документе проверяемом согласно doctype HTML 4 Strict порождать ошибку?
  • Об авторе

    Марк Норман Френсис работает с Интернет с момента изобретения Web. Он работает в настоящее время в компании Yahoo! в качестве архитектора внешнего интерфейса для крупнейшего в мире Web -сайта, определяя лучшие методы, стандарты кодирования и качества разработки Web.

    До

    Источник: Andy Budd http://flickr.com/photos/andybudd/98405468/

    Материалы этого курса имеют лицензию Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.
    Вернуться к учебному плану