Структура HTML-документа: Doctype Definition, Head и вёрстка

    Самые основы HTML и создание с их помощью простого сайта мы изучаем в этом разделе. А здесь — смотрим подробнее на разные важные штуки.

    Упрощённо схема HTML-документа выглядит следующим образом:

< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" >
< html>
    < head>
       < meta http-equiv="Content-Type" content="text/html; charset=windows-1251">
       < title>Заголовок документа< /title>
    < /head>
    < body>
    < /body>
< /html>

    Начнём по порядку с самой верхней секции.

§1. Doctype Definition — объявление типа документа

    Как не прискорбно звучит, но многие вебмастера либо пренебрегают этим тегом, либо абсолютно не догоняют его назначения.

    Тег DOCTYPE обязателен и должен идти первой строкой. Он является ключевым элементом, задающим формат синтаксиса документа. Без него просто-напросто нельзя создать валидный документ.

    Почему так важен этот тег? Разбираем порядок обработки страницы браузером. Перед тем как браузер обработает любой html\xhtml-документ, он должен знать с какого рода документом ему предстоит работать, по каким правилам рендерить страницу, какие теги допустимы. Если браузер не может прочесть или найти объявление типа документа, он переходит в так называемый обобщённый режим или Quirks Mode.

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

    Каждый браузер будет обрабатывать документ по-своему — можно забыть про одинаковый внешний вид страницы в разных программах. Либо придётся навешать кучу хардкорных CSS-фиксаторов.

    Представим ситуацию: пользователь, сёрфящий в Интернете браузером IE 8, заходит на страничку с отсутствующим объявлением типа документа. Что произойдёт?

• ~ Браузер начнёт рендерить страницу по правилам HTML 4 в режиме обратной совместимости с IE 6.
• ~ Итог на экране: кривая страница, половина скриптов не выполняется.

    Делаем выводы.

    В целом, это не просто хороший тон и показатель вашей грамотности. Doctype Definition задает ритм написания самого документа.

    Рассмотрим наиболее актуальные варианты на сегодняшний день.

§1.1 HTML 4

• 1. HTML 4 Strict — строгий


• 2. HTML 4 Transitonal — переходный

§1.2 Стандарт XHTML 1.0

• 1. xHTML 1.0 Strict — строгий


• 2. xHTML 1.0 Transitonal — переходный

§1.3 Стандарт HTML 5

• html — для всех документов

    Можно рассматривать Doctype Definition в качестве ГОСТ'а. Любите качественную тушёнку произведённую с соблюдением ГОСТ'а? Также и браузеры с поисковиками любят странички, написанные в соответствии со спецификацией. Вы же не собираетесь угощать гостей беспонтовщиной?

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

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

    Дальше разберёмся с < head> — головой документа.

§2. Секция < head>

    Теперь подробнее рассмотрим секцию < head>. Её еще принято называть головой (заголовком) документа.

    Вспоминаем нашу схемку:

< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" >
< html>
    < head>
       < meta http-equiv="Content-Type" content="text/html; charset=windows-1251">
       < title>Заголовок документа< /title>
    < /head>
    < body>
    < /body>
< /html>

§2.1 Head: общая информация

    Голова документа должна начинаться сразу после тега < html> и заканчиваться перед тегом < body> (началом тела документа). Позиция выбрана не случайно и несёт некоторую смысловую нагрузку. Обычно секция < head> содержит в себе такую информацию:

    Список далеко неполный, но для того, чтобы начать понимать — этого вполне достаточно.

    Здесь стоит обратить внимание на несколько моментов:

§2.2 Позиционирование title относительно кодировки

    Разбираемся с порядком. Очень часто встречается ошибка с позиционированием заголовка документа < title>.

Не стоит задавать его до объявления кодировки!

    Это связано не только с безопасностью. Если заголовок будет идти первым, всегда есть шанс, что браузер попытается самостоятельно определить кодировку документа.

    Поэтому задаем тег title после объявления кодировки:

< head>
   < meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   < title>Shift The Web Expirience!< /title>
< /head>

    Великолепно, теперь браузер сможет прочитать заголовок документа и правильно вывести его в своём интерфейсе, а злоумышленники получат дополнительную порцию геморроя при попытке XSS-инклюдинга (вид атаки посредством включения Java Scripts в код страницы; делится на активный и пассивный).

§2.2.1 Актуальные языковые кодировки

    Теперь о кодировках. Мы не будем рассматривать экзотические варианты, в нашем случае вполне достаточно двух:

UTF-8 — самая распространённая кодировка в Интернете. Реализует представление Юникода (Unicode). Совместима с 8-битным кодированием текста.

Windows-1251 — поддерживает практически все русские типографические символы. Была создана на базе кодировок, использовавшихся в ранних «самопальных» русификаторах Windows в 1990—1991 гг.

    Здесь стоит заметить, что лучшим вариантом является utf-8, именно её рекомендует консорциум W3C. Однако, не стоит ориентироваться лишь на рекомендации консорциума — первоначальное внимание стоит уделить рекомендации вашей CMS. Например Data Life Engine (DLE) вот уже сколько времени упорно использует только windows-кодировку. Вы даже можете попробовать сменить её на другую, но результат вас огорчит: на экране вы увидите нечитабельную кашу из знаков вопроса или характерные для ошибок чтения ромбики со знаками вопроса внутри.

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

    Также стоит отметить, что размеры файлов в кодировке windows и unicode будут отличаться. Как правило, разница практически не ощутима для документов на английском языке. Для русского языка в UTF-8 размер файла будет больше, чем для windows-1251.

§2.3 Порядок подключения каскадных таблиц стилей CSS и Java Script'ов

    Порядок подключения CSS (каскадных таблиц стилей, в современном вебдизайне в css-файле хранится всё визуальное оформление сайта) критично сказывается на порядке наложения правил оформления HTML-элементов. Это значит, что последний подключённый файл CSS будет иметь приоритет над предыдущими.

    Т. о. становится реальным для разных страниц применить свои правила оформления — просто подключите к нужной странице корректирующий файл последним.

    В отношении JavaScript правила такие: библиотеки функций и фреймворки, например Jquery или MooTools, подключаются первыми. За ними идут плагины и вызовы необходимых функций с параметрами. Если перепутать порядок подключения, скрипты работать не будут!

    Пример подключения библиотеки Jquery и плагина к ней:

< head>
   < script type="text/javascript" src="path/jquery.js">< /script>
   < script type="text/javascript" src="path/plagin.js">< /script>
< /head>

    Дальше мы познакомимся с видами вёрстки.

§3. Виды вёрстки — табличная и блочная

Теперь поговорим об актуальных на сегодняшний день способах вёрстки. Здесь можно выделить 2-3 направления:

§3.1 Табличная вёрстка

    Как правило, начинающие верстальщики первой осваивают табличную вёрстку. Отчасти это происходит потому, что делают сайты на бесплатных хостингах с конструкторами, отчасти по причине того, что она более логична и требует меньших знаний CSS. Я не окажусь исключением — начинал с таблиц.

    Что характерно для табличной вёрстки, так это замусоренный код и практическое отсутствие вынесенной во внешний файл стилизации. Тегов будет больше, а если учесть, что для визуального оформления таблицы к каждому тегу прилагается порядка семи параметров (width, height, border, cellpadding, cellspacing, align, valign и др.), нетрудно представить, сколько времени займёт вёрстка и какого огромного размера будет только каркас.

    Таблицы достаточно капризны. Пропустив один тег или не закрыв всего один столбец, вы рискуете потратить кучу времени на поиски причины поплывшего дизайна. Дополнительные неудобства будут при попытке что-то поправить или переверстать.

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

§3.2 Блочная вёрстка

    На сегодняшний день верстать блоками актуально не просто в угоду моде, это показатель профессионализма. Из плюсов можно отметить компактный код, сравнительную простоту вложенности, скорость разработки и правок. Минус — требуется знание CSS.

    Без утайки скажу, что блочная вёрстка позволяет в буквальном смысле слова творить увертюры сколь угодно сложной логики, что благотворно сказывается на SEO. Например, визуально «хлебные крошки» (так называют навигацию, отражающую положение пользователя относительно корня сайта, на данной странице это строка «Главная > Вебмастеру...») можно расположить над контентом, а в коде они будут под ним. Или «приклеить» панель авторизации к верхней рамке браузера, а в коде отправить её в самый конец.

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

§3.3 Комбинированная вёрстка

    Такая вёрстка подразумевает наличие как таблиц, так и блоков. Правило здесь простое: «Таблицы в дивах, таблиц как можно меньше».

§3.4 Суть вёрстки

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

    Консорциум W3C задаёт стандарты и ритм, наше с вами дело — блюсти спецификацию. Хуже никому не будет.

Автор: Shift.