Таблицы против div'ов. Из ада в.... ад?

+18

За последние несколько лет в массовом порядке вебдизайнеры и верстальщики перешли с табличной вёрстки на вёрстку div'ами. Это, конечно, здорово, но многие ли из них осознают, по каким причинам произошёл этот переход и как теперь надо правильно верстать? Поэтому неудивительно, что часто начинает казаться, что половина просто перешло из табличного ада в ад с дивами и продолжает выдавать что-то непонятное и невразумительное.

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

Картинка от lpinc.1988

Табличный ад

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

MAMA (Metadata Analysis and Mining Application) – это своеобразная поисково-аналитическая система от Opera Software, которая просматривает веб-странички и выдаёт данные об их структуре. На основе этих данных можно сделать следующие выводы: среднестатистический вебсайт имеет табличную структуру с тремя уровнями вложенности; среди десяти самых популярных тэгов присутствует вся троица table, tr и td; на восьмидесяти процентах от всех просмотренных страничек присутствует табличный элемент.

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

Простота использования.

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

Наличие у таблиц атрибутов делает гораздо более лёгким и процесс освоения вёрстки, ведь в случае div'ов разработчику приходится использовать атрибут стиля или внешнюю таблицу стилей. Кроме того таблицы не разрываются слишком широким контентом, и колонки не плющатся своими же соседями, как может происходить при div вёрстке. Всё это даёт ощущение безопасности и надёжности.

Поддержка

Таблица описывается набором тэгов – table в качестве оболочки, tr для каждого ряда и td для ячейки. Тэги thead и tbody не определяют структуры страницы, поскольку применяются для добавления контенту семантических значений. Для удобства чтения, каждому тэгу предоставляется, как правило, своя собственная строка кода. Со всеми этими тэгами а ещё и дополнительным кодом для контента, а также использованием colspan и rowspan атрибутов код становится весьма длинным и стороннему человеку разобраться в такой структуре становится весьма нелегко и весьма затратно по времени, ведь ему приходится пробираться через большое количество кода.

   1. <table cellpadding="0" cellspacing="0" border="0">  
   2.     <tr>  
   3.         <td colspan="3" height="120px">....</td>  
   4.     </tr>  
   5.     <tr>  
   6.         <td class="menu" valign="top">...</td>  
   7.         <td class="content" valign="top">...</td>  
   8.         <td class="aSide" valign="top">...</td>  
   9.     </tr>  
  10.     <tr>  
  11.         <td colspan="3"&gt...</td>  
  12.     </tr>  
  13. </table>  
   1. <div id="header">...</div>  
   2. <div id="menu">...</div>  
   3. <div id="content">...</div>  
   4. <div id="aSide">...</div>  
   5. <div id="footer">...</div>  

Как мы видим из примера, табличная структура описывается гораздо большим количеством кода по сравнению с div структурой. Ну а теперь представьте, как в разы возрастает эта разница, когда структура странички усложняется. Кроме того в структурах на основе div'ов можно пропустить div тэг menu и использовать ненумерованный список (UL) в качестве контейнера вместо него.

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

Другая проблема здесь заключается в том, что таблицы не помогают разделить дизайн и контент. Тэги border, width, cellpadding и cellspacing, согласно MAMA используется в 90 процентах сайтов использующих таблицы. Это добавляет кода в HTML, который должен был быть в таблице стилей. Увеличение размеров кода замедляет разработку и повышает расходы на поддержку, потому что существует ограничение на количество строк кода, которое программист может производить в час, а большой размер кода затрудняет его понимание другими кодерами. Разработчики могут даже не понимать свой собственный код в результате через некоторое время.

Чем больше размер кода, тем тяжелее файлы и тем дольше загрузка. А сейчас, когда всё больше людей начинает пользоваться интернетом посредством мобильных устройств, время загрузки страничек довольно важно. Вебсайты должны нормально выводиться не только на экраны обычных мониторов, а плохой код существенно ограничивает их возможности. Кроме того чем больше код – тем больше багов, ведь количество багов на количество срок кода у девелопера обычно довольно стабильно. Так как таблицы увеличивают размер кода, значит и вероятность ошибок вывода такого сайта будет большим.

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

Гибкость использования с различными медиаустройствами.

В идеальном случае одна и та же разметка должна быть и для принтера и для мобильного устрой1ства и вывода на обычный экран и прочие девайсы. А использование таблиц в качествен структуры лишает страницу какой-либо гибкости в плане передвижения колонок. Также как возможности «спрятать» колонку. Может возникнуть и необходимость переместить какую-либо колонку или, например, соорудить версию для печати – при табличной вёрстке вам придётся создавать и кодировать для каждого устройства или типа отображения отдельную страницу, что требует дополнительных средств и денег на реализацию и поддержку, в то время как в вёрстке div’ами, где дизайн и контент разделены этих трат можно избежать.

Полезно прочитать (англ.)

Вебсайты из табличного ада:

Div – ад

Div ад – это когда при вёрстке структуры использовано div элементов гораздо больше, чем необходимо.

Тэг div – это элемент уровня блока, который определяет раздел в документе, поэтому они и пригодны к созданию структуры странички на их основе. Также данные тэги используют для описывания и структурирования контента, когда это нельзя делать более семантически верными тэгами. Однако когда верстальщик не до конца понимает семантическое значение других тэгов блок-уровня, зачастую он злоупотребляет и использует слишком много div’ов. Некоторые программисты ошибочно считают, что чем больше div’ов, тем лучше. Но есть ли смысл выбирать лучшее из худшего?

Картинка от myladyhawk

Простота использования.

Научиться правильно создавать структуры на основе div’ов гораздо сложнее, чем таблицы. Разработчик должен знать CSS и понимать разницу между блочными и строчными элементами, знать, когда использовать float’ы и когда использовать абсолютное позиционирование, и как разрешать браузерные ошибки.

Визуально представить, что представляет собой элемент, представленный div тэгом не так просто, как таблицу. С другой стороны в div’е хорошо то, что это отдельный элемент, вследствие этого он не имеет родительских ограничений как табличный td элемент, а значит, является гораздо более гибким в применении.

Использование div для создания структуры странички делает её более хрупкой – в предельных случаях, когда контент слишком велик, это может приводить к «наплыванию» или «переползанию» div’ов. Правда, справедливо это в первую очередь для старых браузеров, более новые (от IE 6 и выше) обычно особых проблем с правильным отображением страничек на div’ах не испытывают.

Разбираться с браузерными глюками сначала кажется довольно непростым занятием, однако с приобретением опыта разработчику удаётся разобраться со всеми ошибками гораздо быстрее и с меньшими затратами ресурсов серого вещества. Поддержка W3C стандартов становится всё лучше и лучше, а сейчас в связи с тем, что Firefox и Safari набирают всё большую популярность, а также выходом Google Chrome конкуренция на рынке браузеров обостряется, и мы вправе надеяться, что они будут по этой причине совершенствоваться гораздо быстрее.

Поддержка

Самая большая проблема с div’ами, заключается в том, что иногда их использую при вёрстке слишком часто. Необходимо помнить, что div’ы следует использовать только для создания структуры, а в качестве заполнителя только когда ни один другой элемент блочного уровня не может верно описать контент. Div - это тег для логической группировки элементов.

Глубоко вложенные div тэги – это без сомнения путь в ад в плане сложности поддержки. Любой девелопер ещё два раз подумает, прежде чем возьмётся разбираться в таком коде, которые совершенно не читаем. На самом деле, улучшает читаемость кода описательные классы и структура имён, но использования их в случае вложенных div‘ов, далеко не всегда просто.

Слишком много div‘ов – это верный признак того, что контент описан неправильно. Это значит, что div’ы используются, по сути, вместо семантических тэгов блок уровня. К примеру, заголовки должны описываться только тэгами h1-h5. Использование семантического кода уменьшает размер кода в целом, а заодно, исключая лишние div и float тэги, снижает вероятность появления ошибки отображения в каком-нибудь браузере.

Отключение таблицы стилей для Twitter.com демонстрирует нам симпатичный образчик семантически верного кода и правильного понимания принципов вёрстки, с использованием списков, заголовков, HR и fieldset и т.д.

Идентификаторы и классы могут нести семантическое значение, недоступные других тегов. Проблема заключается в том, что эти значения не являются стандартизованными. Например, div id = "banner", может обозначать как обычный баннер, так и медийную программу с достаточно сложным современным алгоритмом показа рекламы. Да и вообще, классы и идентификаторы, которые имеют добавленное к ним семантическое значение, не должны заменять тэги с аналогичным встроенным семантическим значением.

Тем не менее, правильное придание семантического значения, сиречь семантически верных имён, классам и идентификаторам значительно увеличивает читабельность кода и помогает избежать использования бессмысленных и бесполезных имён классов, типа bigRedText, которые имеют не функциональное значение, а являются описательными. Кроме того, поисковые машины, такие как Google используют достаточно сложные алгоритмы, которые способны оценивать семантическое значение классов и идентификаторов.

Одним из интересных технологий данного типа является microformats, которые строятся на идее семантических классов. С помощью специальных стандартизированных форматов, содержимое может быть автоматически обработано microformat-понимающим ПО.

   1. <div class="vcard">
2. <span class="tel">
3. <span class="type">home</span>:
4. <span class="value">+1.415.555.1212</span>
5. </span>
6. </div>
Присутствие атрибута style свидетельствует о том, что данный вебсайт томится в div аду, потому что он не имеет какого-либо конкретного поведения рендеринга. 53,54% всех веб-сайтов проиндексированных МАМА содержат атрибут стиля, и 35.40% от всех веб-сайтов, которые имеют divs, использующие атрибут style. Использование классов и идентификаторов позволит разделить дизайн и контент сайта и очистить его от излишне широкораспространённого атрибута style.

Классы и идентификаторы также облегчат доступ к элементам в Document Object Model (DOM) через скрипты.

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

Вот еще несколько причин, почему машины должны быть в состоянии правильно понимать и оценивать содержание сайта:

 <ul>

  • Спайдеры сканируют веб-страницы для индексации поисковыми системами. Семантически верное представление контента делает положение сайта в выдаче более высоким.
  • Скринридерами пользуются люди с нарушенным зрением. Они читают вслух содержимое для пользователя, или отправляют его на дисплей Брайля. Кроме того, люди с ослабленным зрением привыкли пользоваться клавиатурными командами для навигации и сёрфинга по страничкам и их содержимому. Они могут также получить список всех заголовков и ссылок на страницы, и каждая из этих списков обладает мета-информацией о том, сколько элементов он содержит. Настройка атрибута языка также важно, ведь скринридер прочитать содержимое пользователю на правильном языке. Значение семантической разметки иллюстрируется путем сопоставления strong и b тегов. Strong тэг несёт семантическое значение содержимому, а тэг b имеет лишь только визуальный смысл. В результате, люди, использующие скринридеры, не будут получать такую же информацию о содержании страницы, как люди, которые могут непосредственно увидеть саму страничку. Многие страны уже имеют законы, предписывающие правительственным веб-сайтам обязательно иметь accessibility поддержку. Остальные, будьте уверены, скоро за ними последуют.
  • Дисплей Брайля, фото от cobalt123

    Каждый лишний div усложняет читаемость кода, увеличивает размер кода, а значит и время загрузки странички и т.д. В общем, переиспользование div‘ов также плохо для сайта, как и использование таблиц для вёрстки страниц, разве что удобней в использовании с разными девайсами, но сути дела это не меняет.

    Приведём несколько примеров неправильного использования div‘ов:

    Меню

       1. <div id="menu">
    2. <div class="selected">
    3. <div class="graphicLeft">
    4. <div class="graphicRight">
    5. <a href="#">Home</a>
    6. </div>
    7. </div>
    8. </div>
    9. <div>
    10. <div class="graphicLeft">
    11. <div class="graphicRight">
    12. <a href="#">About</a>
    13. </div>
    14. </div>
    15. </div>
    16. ...
    17. </div>
    Классический пример перегруженного div тэгами меню. Использование списка и display:block для тэга ссылки в таблице стилей прекрасно бы заменили всё это div безумство.

    Заголовки

       1. <div class="headingOne">My heading</div>
    2. <div class="headingTwo">My heading</div>
    3. <div class="headingThree">My heading</div>
    Подобные заголовки только добавляют визуальный эффект контенту. Семантическое значение заголовка теряется и скринридеры и спайдеры не смогут его определить как, собственно, заголовок. (Тот же самый случай, как и в случае тэгов strong и b)

    Списки

       1. <div class="news">
    2. <img />
    3. <h2 />
    4. <p />
    5. <a />
    6. </div>
    7. <div class="news">
    8. <img />
    9. <h2 />
    10. <p />
    11. <a />
    12. </div>
    Девелоперы, которые не видят особого смысла в использовании списков, вместо них применяют div‘ы для каждого элемента. Списки же позволяют зарезервировать семантически важные имена для классов для более рачительно го использования, а кроме того позволяют скринридерам определить количество элементов.

    Различная ширина контейнеров.

    Страница 1

       1. <div id="contentNormal"></div>
    2. <div id="aSideNormal"></div>
    Страница 2
       1. <div id="contentWide"></div>
    2. <div id="aSideSmall"></div>
    Когда каждая колонка на страничке имеет свой контейнер, это приводит к росту числа бесполезных div‘ов. Это можно легко исправить, добавив класс тегу body. Пусть каждый контейнер будет просто наследовать класс тэга body, а мы представим каждой странице свой собственного формата в таблице стилей. Это делает её гораздо более удобной для чтения. Улучшение читаемости как HTML, так и таблицы стилей упрощает их поддержку.

    Гибкость использования с различными медиаустройствами.

    Даже вебсайт из div ада может быть достаточно гибким в плане применение медиа, по крайней мере, до тех пор, пока в нём дизайн отделён от контента и располагается в таблице стилей. Рекомендую прочитать прекрасную статью “Going to Print” на A List Apart , чтобы лучше понять, как создавать вебсайт, удобный к распечатке. Вообще-то эта тема лежит несколько за пределами нашей статьи, но стоит упомянуть, что при div-структура гораздо более гибким, чем табличная в плане поддержки различных устройств. В этом случае не придётся создавать отдельные странички для каждого вида отображения контента, что сокращает затраты на разработку и поддержку. Использование при вёрстке div’ов позволяет разработчику передвигать и прятать колонки, используя display: none в таблице стилей.

    Полезно прочитать (англ.)

    Вебсайты из div ада.

    Из ада в рай

    Фото от supernova9

    Правильное использование div’ов

    Перед тем как создать div разработчик должен хорошо подумать: «А нужен ли он мне, или же я могу обойтись в данном случае тэгом блочного уровня?». Грамотное использование тэгов h1- h5 для заголовков и ul и dl для списков, да и про тэг параграфа не стоит забывать, к слову. Ещё один элемент, который не требует помещения в div – это form. Для большей гибкости построения и применения форм, попробуйте сочетать fieldset элемент со списком: контент будет иметь семантическое значение, а разработчик элементы блочного уровня для вёрстки.

    Поскольку div размечает за один раз только один блок, при грамотном использовании в сравнении с табличной вёрсткой кода получается значительно меньше, чем при вёрстке посредством табличной структуры. Меньше кода – проще поддержка, быстрее разработка, меньше время загрузки и меньше багов, это можно повторять и повторять каждый раз. Если вы стремитесь к минимизации размера кода, значит у вас правильный подход к работе. Когда структура закодирована верно, дополнительные div’ы нужны только для графики. Но при этом, когда мы не можем задать фон или границы на уровне блока, вполне нормально задать их в div‘е, ведь как бы мы не стремились к идеальной чистоте кода, эти устремления не должны идти в ущерб дизайну.

    Посмотрите сколько элементов блок уровня на главной странице Yahoo.com. На этом скриншоте плагином Web Developer для Firefox синим выделены таблицы и элементы блок уровня. Мог ли Yahoo использовать меньше контейнеров?

    Полезные советы

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

    Меню

       1. <ul id="menu">
    2. <li><a href="#">Home</a></li>
    3. <li><a href="#">Products</a></li>
    4. <li><a href="#">About</a></li>
    5. </ul>
    Меню гораздо проще представлять в виде списка нежели оформлять div‘ами. Тэг li – это элемент блочного уровня и может обладать бэкграунд свойствами. Таким образом, два элемента блочного уровня содержат начало и конец разметки каждого пункта меню. Кроме того, как уже говорилось выше, использование списков делает страничку более доступной для прочтения слабовидящим, а также позволяет вставлять вложенные списки в качестве подменю.

    Заголовки

       1. <h1>Main heading</h1>
    2. <h2>Normal heading</h2>
    Используйте заголовки везде, где это возможно. Они добавляют семантическое значение контенту и способствуют повышению рейтинга сайта в поисковых системах. Они также помогают людям, которые используют скринридер, чтобы получить доступ и понимать содержание странички.

    Списки новостей

       1. <ul class="newsList">
    2. <li>
    3. <img />
    4. <h2 />
    5. <p />
    6. <a />
    7. </li>
    8. <li>
    9. <img />
    10. <h2 />
    11. <p />
    12. <a />
    13. </li>
    14. </ul>
    Группируйте похожие элементы контента и помещайте их в списки. Удивительно, как много в интернете всего находится в списках. Списки - идеальные контейнеры. Они экономят множество строк кода, делают его гораздо более лёгким в восприятии и понимании, по сравнению с таблицами или мешаниной из div’ов.

    Различная ширина для контейнеров

    HTML

       1. <body class="newsShow">  
       2.     <div id="content"></div>  
       3.     <div id="aSide"></div>  
       4. </body>
    

    CSS

       1. /* Containers /
    2. #content { float: left; }
    3. #aSide { float: right; } 4.
    5. /
    Page structures */
    6. .newsShow #content { width: 80%; }
    7. .newsShow #aSide { width: 20%; }
    8.
    9. .home #content { width: 70%; }
    10. .home #aSide { width: 30%; }
    11.
    12. .oneColumn #content { width: 100%; }
    C классом для тэга body нет нужды в contentSmall, contentNormal, contentWider и т.д. Достаточно сослаться на контейнер через родительский класс body, а затем управлять шириной в таблице стилей. Последняя будет более читаема, а разработчику не придётся обращаться к такому большому количеству классов как обычно. Тип страницы (body class) подскажет, как обращаться.

    Отображение перечней

       1. <dl>
    2. <dt>Your name is:</dt>
    3. <dd>Susan Hanson</dd>
    4. <dt>Your address is:</dt>
    5. <dd>Street name 1</dd>
    6. <dt>You live in:</dt>
    7. <dd>Oslo</dd>
    8. </dl>
    Используйте dl тэг при необходимости вывода парных значений данных. Многие люди использовали бы для этого таблицу, но использование тэга dl помогает уменьшить количество кода и делает возможным двигать dt и dd тэги, а также устанавливать их ширину для более симпатичного дизайна и удобной разметки. Тэг dl семантически связывает dl и dt тэги, которые, кстати, оба являются блок-элементами.

    Формы

       1. <form>
    2. <ul>
    3. <li>
    4. <fieldset>
    5. <legend>Person info</legend>
    6. <ul>
    7. <li>
    8. <label for="name">Name:</label>
    9. <input type="text" name="name" id="name" />
    10. </li>
    11. <li>
    12. <label for="age">Age:</label>
    13. <input type="text" name="age" id="age" />
    14. </li>
    15. ...
    16. </ul>
    17. </fieldset>
    18. </li>
    19. <li>
    20. <fieldset>
    21. <legend>Address info</legend>
    22. <ul>
    23. <li>
    24. <label for="address">Address:</label>
    25. <input type="text" name="address" id="address" />
    26. </li>
    27. <li>
    28. <label for="zip">Zip:</label>
    29. <input type="text" name="zip" id="zip" />
    30. </li>
    31. ...
    32. </ul>
    33. </fieldset>
    34. </li>
    35. ...
    36. </ul>
    37. </form>

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

    Использование div’ов для создания структуры (заголовок, меню, колонтитул и т.д.), а элементов блочного уровня, например, p, ul, dl и form там, где они необходимы, сделает мир намного более симпатичным местом для жизни. Списки уже широко используется, они прекрасны в качестве контейнеров. И не забудьте добавить сразу класс тегу body. Когда разработчики начинают кодировать чисто и семантически верно, они никогда уже не возвращаются обратно к своим ошибкам или заблуждениям.

    Полезно прочитать (англ.)

    Советы о переходе от таблиц к div-структурам

    <ul>
    

  • Идите от внешней таблице к вложенным. Удаляйте таблицы одну за одной, заменяя их надлежащей разметкой правильно описывающей и формирующей контент. В результате может оказаться, что таблице совсем не нужны были. Начиная с внешней таблицы, вы постепенно будете делать остальной код более читабельным, и вам будет становиться проще. Если наружная таблицы являются частью базовой структуры, их удаление и замена может повлиять сразу на несколько страниц. Также полезный совет - начинать работу на самых важных и популярных страницах в первую очередь.
  • Не вводите новые таблицы, если только они не используются для табличных данных.
  • Разделяйте дизайн и содержание. Размещайте структурный код в таблице стилей, а разметка пусть сообщает браузеру какой пере ним контент.
  • Каждый раз, когда кто-то работает на странице, он должна проверять, нельзя ли сделать код более семантически верным, более ясным и чистым. Замена сразу всей системы вполне вероятно будет стоить больше, нежели её пошаговая оптимизация.
  • Не продолжайте писать некачественный код, если у вас сайт уже содержит его, даже несмотря на то, что это может показаться более удобным на данный момент. Пишите только качественный и напоминайте себе, что плохой код рано или поздно всё равно придётся переписывать заново. А оно вам надо? Написание чистого и правильного кода, так или иначе, в конце концов, сэкономит вам ваше же время.
  • Будущее

    Две технологии, которые придут к разработчикам в будущем в плане структуры страничек выглядят наиболее интересно – первая из них это HTML 5, который придёт со структурными тегами, обладающими семантическим значением и табличным лэйаутом для CSS, вторая, CSS 3, будет обладать мультистолбцовым лэйаутом.

    HTML 5

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

    Это поможет машинам гораздо лучше понимать и оценивать сайты:

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

    Наряду с новыми структурными элементами, HTML 5 также вводит много новых тегов. Некоторые из наиболее интересных элементов:

    • video и audio теги принесет новое, семантически важное значение разметки контента и разрешит потоковое проигрывание непосредственно в браузере.
    • Формы будут получать новую и усовершенствованную семантику для ввода данных и их валидации.
    • Новый тэг canvas будет обладать API для 2D рисования.

    HTML 5 также будет содержать много новых API, таких как:

    • 2D рисование в режиме реального времени
    • Контроль за проигрыванием медиа
    • Хранение данных в браузере
    • Редактирование
    • Перетаскивание
    • Обмена сообщениями и нетворкинга
    • Управления кнопкой "Назад"
    • MIME и обработчик протокола регистрации

    Работа над HTML 5 началась в конце 2003 года и список этапов с названиями статусов следующий:

    • First W3C Working Draft in October 2007
    • Last Call Working Draft in October 2009
    • Call for contributions for the test suite in 2011
    • Candidate Recommendation in 2012
    • First draft of test suite in 2012
    • Second draft of test suite in 2015
    • Final version of test suite in 2019
    • Reissued Last Call Working Draft in 2020
    • Proposed Recommendation in 2022

    Это может выглядеть смешным (разработка с 2003 по 2022 это же целых 19 лет!). Однако надо учитывать тот факт, что HTML 5 должен заменить сразу три технологии HTML 4, DOM2 HTML и XHTML1. Это не означает, что разработчики не смогут начать работать с HTML 5, до 2022, просто спецификации могут быть изменены в течение этого периода. В зависимости от того, как быстро разработчики браузеров смогут реализовать все функции, возможно начало использование HTML 5 уже до 2012 года. Тем более что часть функционала будущего уже реализовано в новых версиях современных браузеров. Семантическая структура HTML 5 поможет разработчикам избежать использования лишних div тэгов, но семантически правильная разметка контента всё равно останется важной задачей для кодера. По-прежнему важным останется и понимание разницы между элементами блочного и строчного уровня.

    Табличная разметка через CSS.

    Еще одна новая функция – это отображение блок-элементов в виде таблицы с помощью CSS. Display атрибут для оболочки будет применятся к тэгу table, а display атрибут для блок элементов типа столбцов будет применятся к table-cell. Табличная разметка через CSS будет более надежной, чем float модель, в которой разметка может рваться при использовании больших шрифтов. Еще одним положительным эффектом является то, что столбцы автоматически будет равны по высоте.

    С выходом IE8, все три основных браузеров сейчас поддерживают разметку блоков через таблицы с помощью CSS. Однако ещё должно пройти определённое время, пока абсолютное большинство пользователей придёт к использованию современных браузеров с поддержкой данной функции.

    HTML

       1. <body>
    2. <ul id="menu">
    3. <li><a href="#">Home</a></li>
    4. <li><a href="#">Products</a></li>
    5. <li><a href="#">About</a></li>
    6. </ul>
    7. <div id="content">
    8. <p>Fusce quis velit...</p>
    9. </div>
    10. <div id="aSide">
    11. <p>Praesent iaculis commodo elit...</p>
    12. </div>
    13. </body>
    CSS
       1. body { display: table; table-layout: fixed;}
    2. #menu, #content, #aSide { display: table-cell; }
    3. #menu { width: 20%; border: 2px solid red;}
    4. #content { width: 50%; border: 2px solid blue; }
    5. #aSide { width: 29%; border: 2px solid green;}
    Оболочка (в данном примере это body) выставлена отображаться как table, а соответствующие колонки выставлены для отображения как table-cell. Как показывает пример, работает это и со списками, что позволяет сократить количество div'ов. Это сокращённый вариант примера, нормальная структура содержала бы ещё и колонтитулы. Тогда бы требовался ещё один div для ряда, содержащего menu, content и aSide. Контейнер, содержащий каждый ряд должен иметь атрибут display выставленный в table-row. Контейнер каждого ряда необходим, чтобы разрывать строку после колонок.

    Данный пример показывает как указанный выше код отображается в Firefox

    Мультистолбцовая вёрстка страницы через CSS

    Немного CSS3 магии позволит разработчикам организовать текст в колонках внутри элемента. Это будет возможно двумя путями: либо определить ширину столбца или их количество

    Multi-column схема в настоящее время поддерживается в Mozilla и браузерах на основе Webkit, в которых эти свойства описываются при помощи префиксов -moz-и-webkit-, соответственно.

    Column width

    Число отображаемых столбцов зависит от того, какая установлена ширина колонки (интервалы между колонками контролируется свойством column-gap) и какая ширина у контейнера.

       1. -webkit-column-width: 8em;
    2. -webkit-column-gap: 1em;
    3. -moz-column-width: 8em;
    4. -moz-column-gap: 1em;

    Column count

       1. -webkit-column-count: 2;
    2. -webkit-column-gap: 1em;
    3. -webkit-column-rule: 1px solid black;
    4. -moz-column-count: 2;
    5. -moz-column-gap: 1em;
    6. -moz-column-rule: 1px solid black;

    Свойство column-count определяет, на сколько колонок разделён текст в элементе. Ширина колонок зависит от того, насколько широк контейнер, интервалы между колонками и их границы.

    Полезно прочитать (англ.)

    Понимание разницы между блочными и строчными элементами.

    Элемент блочного уровня это HTML тэг, такой как p, table, h1 или div, который генерирует разрыв строки. Элементы блок-уровня обладают пятью свойствами расположения: height, width, margin, border и padding. Строчный элемент, такой как span или anchor не разрывает строку и не является таким гибким контейнером как блочный элемент. Блочный элемент не может быть внутри строкового элемента. Прочитайте больше об этом, походив по линкам в секциях "Дальнейшее чтение", ведь понимание разницы между блочными или строковыми элементами – это краеугольный камень в верстке и программированию страниц.

    Об авторе

    Геир Вавик (Geir Wawik) - работает senior консультантом в Miles, Норвегия. Его основной задачей является разработка дружественных пользователю и acessebility интерфейсов.

    Источник - smashingmagazine.com | Оригинал</

    +18

    Wargaming / Гейм Стрим

    Wargaming — признанный лидер среди издателей free-to-play игр в жанре ММО и разработчик с мировым именем. Основана в 1998 году. За время своего существования компания преуспела в нескольких жанрах, выпустив более десяти успешных проектов, среди которых серия пошаговых стратегий Ma...

    Обсуждение17

    Picture_1756?1356409853
    +3

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

    Missing-male

    Admins, could you please give the possibility to delete or at least preview comments?

    Picture_54?1356409795
    faketail
    – программист в BELHARD

    Превью может быть и появится (ещё точно не решено), а опция удаления комментариев точно нет - это банально повергает любую дискуссию в хаос.

    Missing-male
    Andrey_Bas
    – Software Engineer в EPAM Systems

    +1

    При добавлении коментария, у меня вместо обычных русских букв была выдана кодировка в стиле %040 - и так далее. Ладно, занова набирать как-то нет сил. Главная мысль что я хотел выразить в подтверждение статьи - это то, что действительно некоторые кодеры переусердствую с дивами до такой степени, что в код вообще смотреть страшно, особено страшно в тако случае бесконечно использование вообще пустых тегов div (и не только div), понят значение которых порой не представляется возможном даже после долгого разбирательства.

    P.S. действительно отличная статья

    Missing-male
    +1

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

    Picture_1442?1356409841
    +1

    &#1087;&#1088;&#1080;&#1089;&#1086;&#1077;&#1076;&#1080;&#1085;&#1103;&#1102;&#1089;&#1100;: &#1086;&#1090;&#1083;&#1080;&#1095;&#1085;&#1099;&#1081; &#1087;&#1086;&#1089;&#1090;! &#1074;&#1089;&#1077; &#1074; &#1090;&#1077;&#1084;&#1091;. &#1076;&#1091;&#1084;&#1072;&#1102;, &#1086;&#1095;&#1077;&#1085;&#1100; &#1084;&#1085;&#1086;&#1075;&#1080;&#1084; &#1087;&#1086;&#1084;&#1086;&#1078;&#1077;&#1090; &#1089;&#1090;&#1072;&#1090;&#1100; &#1083;&#1091;&#1095;&#1096;&#1077;...

    Missing-male
    +1

    Молодцом герр Геир Вавик! Очень грамотно пишет.

    А кто переводил?

    Missing

    автор поста и переводил

    Missing-male
    +1

    Автору поста спасибо.

    Picture_2608?1356409880
    -1

    отличная статья! но сложно верстать сразу "по-райски"

    это все равно, что оптимизировать софт в процессе разработки - мало ли с чем столкнешься при верстке других страниц

    поэтому сначала прописывается всё в style, и только в конце верстки создаются необходимые классы с их наследованями и т.п.

    Missing-male
    +1

    А почему не наоборот? Создаем и описываем класс по мере появления необходимости, а не "сначала все в style, и только в конце верстки..."

    Missing-male
    Andrey_Bas
    – Software Engineer в EPAM Systems

    Я всегда в начале создаю класс и дополняю, не капельки не мешает, а в style что-то пихать вообще необходимости не вижу, так что 1

    Picture_2608?1356409880
    +7

    когда на черновую уже сверстаны пару страниц, да, - на них основывается верстка остальных страниц

    как раз в этот момент и имеет смысл создавать классы, и дальше просто дополнять их при необходимости

    но чтобы сверстать основной стиль сайта в этих двух страницах, бывает приходится часто исправлять стили/классы, поэтому проще и быстрее паддинги, флоаты и т.п. прописывать в style, и потом только выносить их в css

    Missing-male
    Andrey_Bas
    – Software Engineer в EPAM Systems

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

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

    Не будем развязывать по этому поводу холивар...

    А вообще, хотелось бы дополнительно отметить то, что в статье одной из главных мыслей было использование тегов исходя из их семантики - я считаю именно этому необходимо удилить внимание и как можно больше. Это является важным как для последующей поддержки кода, так и для его разбора "машинным" способом - и это действительно проблема. Многие вертальщики (это исходя из анализа и собственного кода в том числе) забыли о семантике тех или иных тегов. Ну, если еще с тегами заголовка

    ...

    ., то вот теги списков, параграфов, выделения - забыты порой напрочь. Я не буду далеко ходить за примером, я сам для выделения полужирным всегда пишу и не задумываюсь даже, тогда как использование действительно позволяет предать семаньтическим смысл выделения в данном отрывке текста. Подключив к нему (я про тег strong сейчас) CSS класс, можно без проблем настроить кроссбраузерное отображение к данному элементу, но при этом в отличии от тека оно получит некую чувственную окраску. Также и с остальными подобными тегами...

    Picture_2608?1356409880

    Согласен с вами об удобстве разработки в к-л среде. И про статью полностью согласен - повторюсь, громадное за нее спасибо.

    Picture_2197?1356409867

    Статья-то неплохая, но цивилизованный мир уже года три уже только так и верстает.

    Правда, хоть статей тысячи на эту тематику, нет ни одной адекватной книги-учебника по дивной вёрстке.

    Missing-male

    Да, статья отличная) Узнал немного нового. Спасибо.

    Загружено 1 из 17 комментариев


    Авторизуйтесь, чтобы оставлять комментарии