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

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

<div class = "table">
    <div class = "row">
        <div class = "cell"> </div>
        <div class = "cell"> </div>
        <div class = "cell"> </div>
    & Lt; /дел >
& Lt; /дел >

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

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

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

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

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

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

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

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

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

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

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

243 голоса | спросил Vilx- 30 MarpmMon, 30 Mar 2015 20:54:05 +03002015-03-30T20:54:05+03:0008 2015, 20:54:05

8 ответов


100

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

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

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

Есть довольно хороший обзор чувствительных таблиц в CSS-трюках .

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

ответил whostolemyhat 1 PMpWed, 01 Apr 2015 16:51:41 +030051Wednesday 2015, 16:51:41
145
Вопрос: если данные семантически представляют собой таблицу (т. е. набор данных или единиц информации, логически организованных в двух измерениях), или вы просто используете сетку для визуального макета, например. потому что вы хотите, чтобы боковая панель расширялась или что-то в этом роде.

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

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


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

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

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

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

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

ответил JacquesB 30 MarpmMon, 30 Mar 2015 21:20:23 +03002015-03-30T21:20:23+03:0009 2015, 21:20:23
97

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

<div class = "table">
  <div class = "row">
    <div class = "cell"> </div>
    <div class = "cell"> </div>
    <div class = "cell"> </div>
  & Lt; /дел >
& Lt; /дел >

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

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

<div class = "thumbnail-gallery">
  & Lt; & DIV GT;
    <div class = "thumbnail">
      <img src = "" />
      Некоторый текст </p>
    & Lt; /дел >
    <div class = "thumbnail">
      <img src = "" />
      Некоторый текст </p>
    & Lt; /дел >
    <div class = "thumbnail">
      <img src = "" />
      Некоторый текст </p>
    & Lt; /дел >
  & Lt; /дел >
& Lt; /дел >

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

@media screen {
  .thumbnail-gallery {
    display: table;
    пограничный крах: сбой;
    ширина: 100%;
  }

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

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

@media и (max-width: 640px) {
  /** сбросить все элементы галереи эскизов, которые будут отображаться как экран блокировки и заполнения ** /
  .thumbnail-галерея,
  .thumbnail-gallery> ДИВ,
  .thumbnail-gallery .thumbnail {
    display: block;
    ширина: 100%;
  }
}

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

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

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

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

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

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

ответил HorusKol 31 MaramTue, 31 Mar 2015 01:54:23 +03002015-03-31T01:54:23+03:0001 2015, 01:54:23
9

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

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

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

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

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

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

ответил NotMe 1 PMpWed, 01 Apr 2015 19:07:17 +030007Wednesday 2015, 19:07:17
5

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

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

ответил Crisfole 3 PMpFri, 03 Apr 2015 17:32:05 +030032Friday 2015, 17:32:05
4

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

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

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

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

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

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

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

ответил Jay 31 MarpmTue, 31 Mar 2015 22:02:00 +03002015-03-31T22:02:00+03:0010 2015, 22:02:00
2

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

 div {display: inline; }

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

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

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

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

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

Стандартные форматы не могут охватывать все богатство человеческой потребности, желания и разнообразия. Они всегда будут «за кривой» того, что делают люди now . Как они новаторски. Heck, HTML5 по-прежнему находится за кривой на сносках, подзаголовках и других печатных новинках XVII века. В нем отсутствуют функции, необходимые многим информационным работникам и создателям контента. Поэтому мы импровизируем.

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

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

ответил Jonathan Eunice 1 AMpWed, 01 Apr 2015 01:49:46 +030049Wednesday 2015, 01:49:46
0

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

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

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

ответил Robert Munn 5 AMpSun, 05 Apr 2015 04:47:06 +030047Sunday 2015, 04:47:06

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132