Почему люди делают таблицы с div?

В современной веб-разработке я все чаще сталкиваюсь с этой моделью. Это выглядит так:

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

И в CSS есть что-то вроде:

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

^{* (Имя класса является только иллюстративным; в реальной жизни это обычные имена классов, отражающие сущность элемента)}

Я даже недавно пытался сделать это сам, потому что ... вы знаете, все делают это.

Но я до сих пор не понимаю. Зачем мы это делаем? Если вам нужен стол, то просто взорвать его <table>и покончить с ним. Да, даже если это для макета. Вот для чего нужны столы - выкладывать вещи в табличной форме.

Лучшее объяснение, которое у меня есть, это то, что к настоящему времени все слышали мантру «не используйте таблицы для разметки», поэтому они следуют ей вслепую. Но им все еще нужна таблица для разметки (потому что ничто другое не имеет расширяющих возможностей таблицы), поэтому они создают <div>(потому что это не таблица!), А затем добавляют CSS, который в любом случае делает ее таблицей.

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

Первоначальный аргумент в пользу отказа от таблиц для разметки заключался в том, что впоследствии трудно изменить табличную разметку. Но изменить макет «поддельной таблицы» так же сложно, и по тем же причинам. На самом деле, на практике изменить макет всегда сложно, и почти никогда не достаточно просто изменить CSS, если вы хотите сделать что-то более серьезное, чем незначительные изменения. Вы будете должны понять и изменить HTML структуру для серьезных конструктивных изменений. И таблицы не делают работу сложнее или проще, чем div.

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

Итак ... в попытке превратить это из напыщенной речи в понятный вопрос: что мне не хватает? Каковы реальные преимущества использования «поддельной таблицы» над реальной?

О дубликате ссылки: это не предложение использовать другой тег или что-то еще. Это вопрос об использовании <table>против display:table.

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

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

<div>s используются для создания таблиц вместо <table>тегов по нескольким причинам. Если <table>используются теги, вам нужно переопределить стили и макет браузера по умолчанию перед добавлением собственного кода, поэтому в этом случае <div>теги экономят на большом количестве шаблонного CSS. Кроме того, старые версии IE не позволяют переопределять стили таблиц по умолчанию, поэтому использование <div>s также облегчает кросс-браузерную разработку.

Там довольно хороший обзор адаптивных таблиц на CSS-хитрости .

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

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

Если ваша информация является семантической таблицей, вы используете <table>-tag. Если вам просто нужна сетка для макета, используйте другие подходящие HTML-элементы и используйте их display:tableв таблице стилей.

Когда данные являются семантически таблицей? Когда данные логически организованы по двум осям. Если это имеет смысл с заголовками для строк или столбцов, то у вас может быть семантическая таблица. Примером чего-то, что не является семантически таблицей, является представление текста в столбцах, как в газете. Это не семантически таблица, так как вы все равно будете читать ее линейно, и при удалении презентации не будет никакого значения.

Хорошо, почему бы не использовать <table>все, а не только то, что семантически является таблицей? Визуально это очевидно то же самое (поскольку элемент таблицы просто есть display:elementв таблице стилей по умолчанию).

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

<table>Против display:tableобсуждения просто случай более общего принципа использования семантической разметки. Посмотрите, например: Почему нужно помечать разметку правильно и семантически? или почему семантической разметке уделяется больше внимания для поисковых систем?

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

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

На самом деле, я бы сказал, что использование имен классов, таких как «таблица», в вашем примере демонстрирует, как люди на самом деле не понимают, что они делают, когда пытаются семантическую разметку. Они получают оценки за попытку показать, что контент не является табличными данными , но они теряют оценки за плохие имена классов.

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

Все, что сделал этот разработчик, - это скопировал оригинальную <table>разметку с именами классов CSS. Это означает, что как только этот макет не является таблицей, имена классов не совпадают.

Что должен был сделать этот разработчик, так это рассмотреть, какая информация находится в таблице - это галерея миниатюр? Ну тогда:

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

Теперь я могу создать адаптивный CSS:

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

Почему div, а не таблицы

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

Галерея миниатюр (или многие другие вещи, такие как форма регистрации, меню и т. Д.) Не являются табличными данными. Он может быть представлен как таблица в некоторых макетах дизайна, но в других случаях, например, на узких экранах телефонов, вы хотите использовать более традиционные блочные макеты. Или, возможно, вы хотите отобразить миниатюры на боковой панели, а не в основной области содержимого.

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

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

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

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

Двигатель DIV был другим. Когда браузер обнаружил DIV, он разместил бы его и начал заполнять содержимое встроенным. Конечно, div могут прыгать, как только данные закончат загружаться. Следовательно, почему я появился в цитатах выше. Сроки завершения обоих были одинаковыми, однако таблицы не были составлены до конца, что означало, что пользователь не был уверен, загружается он или нет в течение секунды или двух.

Это стало хуже, поскольку таблицы были вложенными.

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

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

Итак, +1 к вам за вопрос.

Если я смогу получить немного «мета» здесь, это принесет мне две проблемы:

Первый: кто-то предлагает правило по какой-то веской причине, и люди полностью упускают суть, следуя технической букве правила, игнорируя дух. Они находят какой-то способ совершить все плохое, что правило пыталось предотвратить, в то же время технически следуя правилу в его формулировке.

Второе: кто-то видит проблему и предлагает правило для ее предотвращения. Другие видят ценность этого правила. Затем они настаивают на слепой преданности этому правилу, независимо от первоначальной проблемы, которую оно должно было решить, и / или независимо от того, какие другие проблемы оно создает. У меня было много разговоров, где кто-то говорит: «Ты должен сделать Х, потому что это правило», а потом я спрашиваю: «Но зачем нам делать Х?», И они смотрят на меня с недоумением и раздражением и говорят: «Но Я только что сказал вам! Потому что это правило! Я отвечаю: «Но это, кажется, вызывает больше проблем, чем решает. Я думаю, что было бы лучше сделать Y». И затем человек говорит: «Нет, смотри, я покажу тебе. Видишь, это прямо здесь, в этой книге. Х - это правило».

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

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

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

Лично я думаю, что было бы лучше просто объявить: «Тот факт, что что-то находится внутри тега таблицы, не обязательно означает, что он представляет строки и столбцы чисел». Это не было бы возмутительным заявлением. Я никогда не слышал, чтобы кто-то говорил, что тег «p» может использоваться только для вещей, которые действительно являются абзацами грамматически правильных, логически сконструированных английских предложений. Я никогда не слышал, чтобы кто-то говорил, что неправильно использовать тег «ul» для списка, который на самом деле идет в логическом порядке, просто потому, что вам нужны маркеры, а не порядковые номера. И т.п.

Есть уже тонны больших ответов здесь. Но я хотел добавить, что tableэлементы имеют ограничения рендеринга, которые не существуют для divэлементов. Попробуйте создать таблицу, которая выполняет виртуальную прокрутку (например, SlickGrid , DataTables и другие), и вы будете очень разочарованы. Это просто не работает. Большинство (все?) Современных сеток Javascript используют divs, потому что css обеспечивает гораздо более гибкий рендеринг.

Есть и другие ограничения. Мое общее правило заключается в том, что если я собираюсь увидеть всю таблицу на одном экране, и я не хочу какой-либо особой визуализации для нее, я использую tableэлемент, в противном случае я использую div, потому что могу много контролировать результаты Гораздо проще.

HTML и CSS развили определенную степень гибкости, что означает, что даже концептуально «блочные» элементы, такие как <div>(самая старая и самая распространенная форма блочного содержимого HTML), не должны отображаться в виде блоков:

div { display: inline; }

Как вы заметили, <div>подражать можно <table>и подражать своим попутчикам. На самом деле, большинство тегов могут. С учетом их особой роли, я сомневаюсь , что вы могли бы с пользой переназначить теги макросов , как <html>, <head>, <body>и <script>, а «общие» теги , как <div>, <p>, <b>, <em>, <span>, и <pre>? Для захватов. Сделайте блоки встроенных тегов, блоки встроенными, поток предварительно отформатированных тегов, плавающие стационарные. Сойти с ума, если хотите!

Это возможно . Возможно, вы захотите рассказать о том, как мы все должны использовать «семантическую разметку», бла-бла- бла , или поверить в Pythonistas, что «Должен быть один - и предпочтительно только один - очевидный способ сделать это». Тем не менее Тим Тоади - умный и любопытный парень. Если у него будет свободная рука, он изучит их все. Это включает использование доступной гибкости, чтобы сделать замены. Некоторые мудры, некоторые докажут иначе. Но испытание, ошибка и опыт - единственный способ выяснить это. Таким образом, достаточные условия для замены присутствуют.

Я не думаю, что переоценивать, что замена также необходима. Как минимум, это очень удобно . В течение долгого времени, HTML не было <menu>, <section>или <aside>элементы. Тем не менее, веб-страницы и приложения повсюду имеют меню, разделы и боковые панели. Как? Поскольку список HTML элементы ( <ul>, <ol>и <li>) были легко переориентированы и некоторые обычаи переквалифицируются в качестве контейнеров меню и деталей. <div>может стоять на <article>, <section>, <aside>, <figure>, и <summary>. HTML5 догнал и добавил специальные элементы для некоторых ранее не использованных вариантов использования. Это отличное обновление и исправление, чтобы приспособиться к общему, реальному использованию.

Тем не менее, остается много общих идиом, которые не имеют специальных тегов или семантических моделей . Такие вещи, как страницы, сноски, извлекаемые цитаты, потоки комментариев, связанные аватары, «лайки», подзаголовки и субтитры, которые я и многие другие используют каждый день. Что мы собираемся делать? Что мы можем Измените «близкие, но неточные» элементы с классами и идентификаторами, чтобы они могли поддерживать и поддерживать нашу работу в течение следующих пяти или десяти, или даже многих лет, пока не догонят HTML6 или HTML7. HTML / CSS «да, это теоретически X, но мы собираемся пометить его и работать с ним как Y», это невероятно удобно. Обязательно, правда. Это делает веб-контент гибким, а не хрупким.

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

Стандартные форматы не могут охватывать все человеческие потребности, желания и разнообразие. Они всегда будут «за углом» того, что люди делают сейчас . Как они вводят новшества. Черт, HTML5 все еще отстает от сносок, подзаголовков и других нововведений в печати 17-го века. В нем отсутствуют функции, необходимые для многих информационных работников и создателей контента. Итак, мы импровизируем.

Еще более неизменным является то, что информация не подчиняется одному набору правил. Конечно, это начинается как таблица. Но, может быть, вы просто хотите резюме - скажем название для каждой строки, как список. Возможно, это занимает слишком много места, и вы хотели бы использовать его как встроенный список для экономии места. Может быть, у вас есть записи, название которых вы просто хотите, тогда, если вы нажмете, вы увидите основные детали. Или вы хотите, чтобы элементы в сложном списке или таблице были сгруппированы и классифицированы. О, теперь вы хотите, чтобы это транспонировалось и классифицировалось по-другому. Или значения, представленные в виде гистограммы. Это то, что делается каждый день в приложениях, электронных таблицах и визуализации данных. Они являются неотъемлемой частью нашего информационного ландшафта, а также того, что мы хотим и должны делать в Интернете. Люди постоянно реорганизуют форму и представление наших данных. Это не просто одна вещь, или один формат / макет, или одна концепция. Это взаимозаменяемо, семантика зависит от обстоятельств и выбора, который пользователи делают в интерактивном режиме. Да, пометить текст как "выделенный" (<em>), но это просто соглашение. Я работал над документами, по крайней мере, с полдюжины разных «акцентов». Мы должны быть в состоянии настроить и переназначить это для разных целей, разных интерпретаций. Один вид акцента HTML? Мучительно редукционистский. Ограничение. Хрупкое. То же самое относится и к <table>, <p>и т. Д.

Замечательно иметь теги / элементы, которые помогают организовать представление всего сообщества о том, «что и куда идет». Это помогает устанавливать соглашения и идиомы и делает нас коллективно более эффективными. Но способность переназначить вещи, переопределить и изменить эти структуры? Это неотъемлемая часть инклюзивности Интернета и его успеха.

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

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

Взять, например, сайты электронной коммерции. При просмотре списка продуктов в обзоре или результатах поиска, как правило, отображается список продуктов в табличном формате, но эти представления могут быть сгенерированы с использованием div (которые предоставляют более общие и гибкие параметры макета и стиля), а не таблиц. Amazon и eBay являются хорошими примерами такого подхода. Изучите результаты поиска на любом сайте, и вы увидите глубоко вложенный набор элементов div.