Какая польза от дизайна без таблиц, если вам нужны очищающие блоки во всем мире?

Я понимаю, что цель перехода к тегам <div> из <table> имеет смысл, поскольку она более семантична. Тем не менее, я не понимаю выгоды, полученной, если вам все еще нужен блок клиринга для создания раскладок на основе столбцов. Например:

<!-- Note: location-info & personal-info both float left. -->
<div class="contact"> 
    <div class="personal-info">
        <p>
           Shawn, etc, etc
        </p>
    </div>
    <div class="location-info">
        <p><address>etc</address></p>
    </div>
    <br style="clear:both" /> <!-- clearing block -->
 </div>

Посторонний тег <br> используется строго для описания стиля и требуется, чтобы макет работал. Разве это не разрушает все выгоды от удаления таблиц?

Ответ 1

Что, если бы я сказал вам вы не нужен блок очистки?

.clear-block:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
}

.clear-block {
    display: inline-block;
}
<div id="wrapper" class="clear-block">
    <div style="float:right">
        Your content here
    </div>
    <div style="float:left">
        More content here
    </div>
</div>

Ответ 2

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

Ответ 3

Я понимаю, что цель перехода к тегам <div> из <table> имеет смысл, поскольку она более семантична.

Собственно, это как раз наоборот: переход от <table> до <div> делает ваш HTML менее семантическим. Фактически, вся точка <div><span>) не имеет семантики!

Он всегда меня гадит, когда я вижу лес <div>, описываемый как "семантический HTML". Нет, нет! Этот * un- * семантический HTML! Особенно, если в нем много <div class='float-left'>, <div id='bottom'> и моих личных фаворитов <div class='paragraph'> и <span class='emphasis'>.

Не поймите меня неправильно, использование не-семантического <div>, безусловно, лучше, чем использование неверно-семантических <table> s, но еще лучше было бы использовать семантически правильные элементы, хотя во многих случаях проблема в том, что HTML не предлагает никаких. Например, в вашем фрагменте используется элемент <address>, но в соответствии с спецификация этот элемент не предназначен для разметки адресов! Это только для разметки адреса автора страницы - IOW это совершенно бесполезно.

В примере, который вы опубликовали, отсутствует много контекста, поэтому его трудно сказать, но на самом деле похоже, что вы можете отображать табличные или иерархические данные, и в этом случае <table> или <ul> может быть лучший выбор.


Полностью не связанный с вашим вопросом: вы можете взглянуть на hCard и XOXO микроформаты.

Ответ 5

Я лично использую clearfix hack для моих клиринговых потребностей.

/* Clearfix */
#content:after,
.box:after {
  content:'.';
  display: block;
  clear: both; 
  visibility: hidden; 
  height: 0;
}
#content,
.box {
  zoom: 1; /* IE */
}

Обратите внимание, что я просто запятая разделяет селектора, а не добавляя класс clearfix ко всему. Он работает очень хорошо. Единственная проблема заключается в том, что свойство zoom является специфичным для IE и не проверяет его, но нет никаких побочных эффектов, например, иногда с другими свойствами, например overflow: auto.

Я использую это на профессиональных веб-сайтах в течение 5 лет без проблем.

Ответ 6

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

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