Часть 1: Хаос таблиц и div-блоков
Таблицы
Вы обязательно столкнётесь с хаосом таблиц, если вам нужно использовать таблицы для создания дизайна. Таблицы увеличивают сложность разметки и ухудшают её техподдержку. Кроме этого, страницы, созданные на основе таблиц, очень тяжело поддаются расширяемости, в них трудно добавлять новые элементы. Следовательно, таблицы очень сильно ограничивают функциональность сайта.
Статистические исследования, проводимые MAMA (Metadata Analysis and Mining Application - Анализ метаданных и добыча данных приложений), показали, что в среднем таблично-ориентированные сайты содержат в своём коде вложенные таблицы (таблицы в таблице) и глубина вложения в среднем составляет три уровня. При этом количество таблично-ориентированных сайтов составляет 80% от всех сайтов, которые были проанализированы MAMA.
Популярность таблиц для построения каркаса сайта объясняется их интуитивной понятностью использования. Мы сталкиваемся с табличными (табулярными) данными каждый день и понимаем их концепцию.
С технической точки зрения веб-верстальщику не нужно изучать и использовать стили, поскольку внешний вид таблиц можно регулировать при помощи стандартных HTML-аттрибутов, неотъемлемых от тагов <table>, <tr> и <td>. Кроме того при использовании таблиц верстальщик не сталкивается с проблемой "съезжания" столбцов таблиц вниз, как это часто бывает с div-блоками. Таким образом таблицы создают ощущение надёжности и стабильности.
Однако, если мы захотим модифицировать табличный сайт, использующий простейшие тэги <table>, <tr> и <td>, то мы столкнёмся с проблемами. Например, если нам понадобится убрать какую-то колонку из таблицы, то нам придётся пройтись по всем горизонтальным её строкам (<tr></tr>). А если нам вздумается "повернуть" таблицу на 90 градусов, то, фактически, весь код должен быть переписан заново. А если в таблице используются тэги <colspan> и <rowspan>? Путаница и хаос возрастают в разы!
Да и просто табличный код занимает больше места и состоит из большкго количества тэгов. Сравните, как один и тот же фрагмент разметки выражается таблицей...
<table cellspacing="0" cellpadding="0" border="0">
<tbody><tr>
<<d colspan="3" height="120">....</td>
</tr>
<tr>
<td class="menu" valign="top">...</td>
<td class="content" valign="top">...</td>
<td class="aSide" valign="top">...</td>
</tr>
<tr>
<td colspan="3">...</td>
</tr>
</tbody></table>
... и div-блоками:
<div id="header">...</div>
<div id="menu">...</div>
<div id="content">...</div>
<div id="aSide">...</div>
<div id="footer">...</div>
Сложность табличного кода растёт приблизительно в два раза быстрее сложности блокового кода по мере увеличения размера страницы. Особенно если учесть, что многие (90% от всех табличных сайтов по статистике MAMA) дизайнеры-"табличники" для задания дизайна таблицы используют аттрибуты border, width, cellpadding and cellspacing, которые прописываются к каждой строке и даже к каждой ячейке!
Громоздкий код приводит к трудности его понимания и расширения. Многие дизайнеры с трудом понимают свой собственный код, что уж говорить о тех, кому поддержка сайта переходит "в наследство". В результате, возрастате число ошибок в коде. Помимо этого табличный код загружается дольше. А веб-дизайнеры должны понимать, что число мобильных пользователей интернета неуклонно растёт.
Таблицы предназначены для представления табулярных данных, а не для построения структуры сайта.
DIV-блоки
Тэг <div/> предназначен для задания блока в HTML-документе. Блоки предназначены именно для создания структуры документа, его каркаса. Помиме этого блоки очень удобны для описания фрагментов страницы, которые не могут быть описаны другими тэгами (таблицы, списки, элементы ввода и др.). Когда разработчик сайта не понимает семантику блоков, он начинает использовать их к месту и не к месту и возникает хаос блоков.
Для того, чтобы правильно использовать div-блоки, нужно знать CSS, разницу между блоковоми и линейными элементами, между плавающим расположением и абсолютным позиционированием, нужно знать различия в браузерах и методы их (различий) устранения.
Недостаток блочного метода перед табличным - это неочевидность его визуального представления. Все знают, как выглядят таблицы. А блоки? С другой стороны, блок задаётся лишь одним тэгом, а не целым набором вложенных друг в друга тэгов. А следовательно, блок более гибок для модификации.
К сожалению, блочная структура не такая стабильная, как табличная: блоки могут "съехать" и весь дизайн страницынарушится. Однако стандарт W3C всё больше и больше уточняется, а браузеры с течением времени станомяься более "умными", поэтому блочная вёрстка становится всё более предсказуемой.
Основная проблема блочного метода - сличком частое и не всегда уместное использование тэгов div, которые должны использоваться лишь для логического группирования фрагментов страницы. Кроме этого, можно значительно улучшить читаемость кода, если придать блокам семантику через аттрибуты id (идентификаторы) и class (классы).
А вы знаете, что Google повышает релевантость сайта, если его код семантически продуман?
Из семантической направленности классов и идентификаторов выросла идея микроформата. Как говрмится в
википедии:
"Добавление микроформатов к обычной веб-странице позволит компьютерам обрабатывать HTML-текст и загружать информацию в базы данных. Например, поисковые роботы смогут находить контактную информацию, события и обзоры." <div class="vcard">
<span class="tel">
<span class="type">home</span>:
<span class="value">+1.415.555.1212</span>
</span>
</div>
Слишком частое использование аттрибута style может привести к тому, что, опят-таки, возникнет блочный хаос, особенно, если страница часто модифицировалась. Возвращаясь к статистике MAMA, 53.54% всех просканированных сайтов используют аттрибут style, причём 35.40% сайтов используют этот аттрибут в тэге div. Классы и модификаторы являются средством отделения кода (HTML-размётку) от его дизайна (стилей). Они также облегчают обращение к жлементам страницы в модели DOM.
Избыточное употребление тэга div и увелечение ярусов вложенности, также, как и в случае с таблицами, увеличивает размер страницы, время её загрузки и её гибкость для дальнейшей модификации. Рассмотрим несколько примеров.
Меню
<div id="menu">
<div class="selected">
<div class="graphicLeft">
<div class="graphicRight">
<a href="#">Home</a>
</div>
</div>
</div>
<div>
<div class="graphicLeft">
<div class="graphicRight">
<a href="#">About</a>
</div>
</div>
</div>
...
</div>
Это типичное злоупотребление тэгами div для построения меню. Его можно было бы избежать, использовав обычный список со стилем "display: block".
Заголовки
<div class="headingOne">My heading</div>
<div class="headingTwo">My heading</div>
<div class="headingThree">My heading</div>
Да, визуальный эффект заголовков можно создать, но семантика утрачена. Помните, поисковые системы повышают релевантность страницы относительно запросов пользователей, если она содержит заголовки с клбчевыми запросами, а заголовки помечаются тэгами h1, h2, h3 и т.д.
Список новостей
<div class="news">
<img />
<h2 />
<p />
<a />
</div>
<div class="news">
<img />
<h2 />
<p />
<a />
</div>
Использование обычного списка улучшило бы читаемость кода и уменьшило бы количество div-тэгов.
Разная ширина для разных контейнеров
Контейнер 1
<div id="contentNormal"></div>
<div id="aSideNormal"></div>
Контейнер 2
<div id="contentWide"></div>
<div id="aSideSmall"></div>
Если для каждой колонки на сайте создавать собственный контейнер, то может возникнуть ситуация, когда создано слишком много ненужных идентификаторов. Это можно исправить, добавив класс к тэгу <body/>. А потом каждый контейнер в body может просто наследовать этот клас, а потом разметка каждой отдельной страницы будет задаваться таблицей стилей. Таким образом повышается читаемость и содержимого и разметки. Плюс повышается гибкость поддержки такой страницы.
Кроме того, использование блочной структуры позволяет "на лету" генерировать страницы для печати, что невозможно при использовании таблиц. Например, вы можете скрыть верхнее меню в версии для печати, просто указав соответсвующему div-блоку меню стиль display: none.
Пример сайта в блоковом хаосе: фотохостинг Photobucket
Оригинальная статья на английском языке: http://www.smashingmagazine.com/2009/04/08/from-table-hell-to-div-hell/
