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

269

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

<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.

Vilx-
источник
6
@JuhaUntinen: это ... звучит маловероятно. Источник?
Пол Д. Уэйт
5
@ PaulD.Waite - Я думаю, сегодня это все еще верно. Прочитайте другие ответы. Если таблица не имеет table-layout:fixed, она должна быть загружена полностью, прежде чем она может быть отображена. В современных широкополосных сетях этот эффект просто менее заметен.
Vilx-
4
@JuhaUntinen: Это не совсем точно. Механизм рендеринга таблиц работал медленнее, когда вы использовали проценты для ширины столбцов, так как вся таблица должна была быть загружена, прежде чем браузер мог начать выяснять, насколько велика задача сделать все. Это было слишком сложно из-за вложенных таблиц. Однако тогда были (и все еще существуют) способы ускорить рендеринг таблиц FAR FAR. Лишь очень немногие разработчики пытаются освоить свое ремесло достаточно хорошо и вместо этого запрыгивают на подножки.
NotMe
4
Еще в прежние времена мы привыкли имитировать div с таблицами.
Уайетт Барнетт
4
Кто-то читал, что он не должен использовать таблицы для разметки, и считал, что они вообще не должны использовать таблицы. Я ненавижу эту тенденцию.
Кейси

Ответы:

120

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

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

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

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

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

whostolemyhat
источник
6
Я принимаю этот ответ, потому что кажется, что больше ничего полезного не приходит. Есть ответы с большим количеством голосов, но они в основном говорят «потому что семантика» (и единственная причина, по которой они могут предоставить семантику, это программы чтения с экрана, что меня не убеждает). В ответе @ HorusKol упоминалась отзывчивость раньше вашей, но ваша - более важная. Если в будущем появится лучший ответ, я изменю его на принятый.
Vilx-
5
Это смешно и лениво. Все, что вы делаете с <div>«таблицами», вероятно, может быть сделано с обычными, поэтому буквально нет причин (кроме старых версий IE и лени) использовать несемантические элементы для построения таблиц. Тем не менее, фактические табличные данные кажутся редкими в Интернете, так что, возможно, это не проблема.
Вы
1
@Vilx: Вы задали вопрос «Почему люди делают таблицы с div», на что вы получаете ответы. Например, вы можете не заботиться о средствах чтения с экрана, но это не меняет того, что доступность - это реальная проблема для многих и (вместе с поисковыми системами) основная причина, по которой многие люди выбирают семантический HTML.
JacquesB
13
Для всех намерений и целей это совершенно неправильно. Если ваши данные являются табличными, они помещаются в таблицу. Утверждать, что таблицы ведут себя особенно плохо на мобильном устройстве, - это BS. Вы можете так же легко изменить свойства отображения элементов таблицы, чтобы они не являлись табличными значениями, как можно сделать так, чтобы элементы, не относящиеся к таблице, имели значения таблиц.
cimmanon
8
Я считаю, что этот ответ немного вводит в заблуждение. Адаптивные таблицы - это хороший дизайн, но он не зависит от вопроса, следует ли использовать <table> или <div> - вы можете использовать один и тот же визуальный эффект. Действительно, это является ключевым в идее разделения структуры и представления. Это правда, что более старые версии IE не допускали переопределения стиля таблицы, но более старые версии IE также не поддерживали display: table, поэтому вы не могли использовать адаптивные таблицы в любом случае.
JacquesB
153

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

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

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


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

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

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

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

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

JacquesB
источник
14
@ Vilx- зачем использовать <em>и <strong>вместо того , <b>и <i>? Потому <b>и <i>не о семантике тега. <table>имеет смысловое значение. Использование его для чего-то, что не является таблицей, усложняет понимание семантического значения документа.
22
@ Vilx- The book <i>Peoplesoft</i> is the <em>best</em> book on the subject. Собирает <i>вокруг лучше всего было бы неправильно , потому что это означает нечто иное , чем <i>вокруг названия книги. Для получения дополнительной информации см. Почему теги <b>and <i>устарели? а какая разница между <b>и <strong>, <i>и <em>?
19
Если вам все равно, что означает ваш контент, я настоятельно рекомендую вам прекратить использовать любые элементы, кроме форм и элементов div. Просто добавьте классы, чтобы применить стили и поведение.
Рич Ремер
9
@ Vilx-: Когда вы говорите, что заботитесь об опыте своих пользователей, вы, похоже, имеете в виду лишь часть своих пользователей. Основная причина правильного использования разметки в описываемом вами способе - это доступность, которая напрямую связана с пользовательским интерфейсом пользователей с ограниченными возможностями. Это те люди, которым выгодно, если вы делаете все правильно и игнорируете эти соглашения, что, вероятно, усложнит их работу в Интернете.
Роби
31
@ Vilx-, да, программа чтения с экрана действительно обрабатывает <table> очень иначе, чем <div>. <div> в основном игнорируются и читаются последовательно. Внутри <table> он должен предоставлять различные навигационные клавиши / команды («Перейти к ячейке вправо», «Читать заголовок столбца и строки» и т. Д.) И озвучивать различную информацию о местоположении (когда поток чтения входит в таблицу). это выглядит примерно так: «Таблица 3, строка 1, столбец 1, Lorem Ipsum dolor ... »)
Euro Micelli
102

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

<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, которые позволяют более гибкие подходы к стилю.

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

HorusKol
источник
Имена классов были на самом деле просто примером. В реальной жизни они в основном имеют описательный характер. В любом случае, в вашем примере, почему вы используете <div>вместо <table>? Какие преимущества это предлагает?
Vilx-
1
Хм ... ну, в вашем случае вы фактически делаете два разных представления одного и того же HTML с помощью медиа-запросов. ОК, это хороший вариант использования. Но если бы это было не так, и вы бы знали заранее, что эта галерея миниатюр будет отображаться только в одном месте и только в табличном формате - вы бы использовали <table>тогда или еще display:table? Потому что, ну, в некотором смысле это является табличными данными. За исключением того, что «данные» это картинки, но все же.
Vilx-
15
ну нет, это не табличные данные. Вы представляете это в сетке, которая напоминает таблицу. Табличные данные - это статистика и сравнительная информация - думайте как электронные таблицы. Вы бы сказали, что миниатюра в проводнике Windows - это табличные данные? И всегда ли это будет представлено как стол? Что делать, если вы хотите другой стиль просмотра через 6 или 12 месяцев? Зачем вводить ограничения, которые имеют долгосрочные последствия ради упрямства перед лицом широко распространенной практики?
HorusKol
12
За исключением того, что это не табличные данные, вообще. Нет другой причины, кроме произвольного решения о расположении, что этот контент напоминает таблицу. Это не структурированные данные в столбцах и строках, это список содержимого, размещенный в сетке. - редактировать: что сказал ХорусКол.
Эрик Кинг,
3
Ну, хорошо, это немного растянуло. :) Ну, ты дал мне кое-что подумать! Спасибо тебе за это! Я все еще не убежден на 100%, но, по крайней мере, это то, что нужно. :)
Vilx-
11

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

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

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

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

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

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

Не я
источник
Оффтопик о DOCTYPE: я думал, что, хотя теоретическое различие было (и валидаторы относились к нему серьезно), на практике браузеры не различали их. Хорошо, возможно, были небольшие изменения между разновидностями HTML / XHTML, но версия и информация DTD по крайней мере не использовались. Вот почему HTML5 все равно отказался от всего этого и пошел с этим, <!DOCTYPE html>и именно поэтому он работает даже в старых браузерах, таких как IE6. Я что-то пропустил?
Vilx-
2
@Vilx: Doctype переводит браузер в определенный режим. Помимо всего прочего, он определяет используемую модель коробки. Для ряда типов документов браузеры не выстроились в ряд, потому что использовалась блочная модель. Вот почему так много разработчиков жаловались на то, что браузеры отображали страницы по-разному, и вместо того, чтобы фиксировать тип документа, использовали массивные листы сброса CSS. Однако было несколько типов документов, в которых все браузеры использовали одну и ту же блочную модель - но они никогда не были стандартными, их нужно было знать.
NotMe
@vilx: HTML 5 не бросил все это. Скорее, был добавлен новый тип документа. Дело в том, что самая первая строка, которая появляется в верхней части HTML-документа, имеет решающее значение, и если вы не понимаете, что он делает и как реагируют на него различные браузеры, вы потратите слишком много времени на выяснение, почему ваш макет "сломан" в конкретном браузере.
NotMe
Подождите, так что есть разные DOCTYPEs , которые делают тот же документ делают по- другому? Какие? Имейте в виду, я говорю о разных типах, а не об отсутствии / отсутствии типа (иначе говоря, причудливый режим).
Vilx-
@Vilx: Это немного сложнее, так как некоторые типы документов запускают режим причуд (такой же, как noctype) и некоторые другие типы документов (включая html5 doctype) запускают стандартные режимы, и есть даже некоторые типы документов, которые запускают третий «почти стандартный» "режим в некоторых браузерах.
JacquesB
5

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

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

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

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

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

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

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

сойка
источник
7
по поводу последнего абзаца - вы читали спецификацию HTML5 для этих элементов, не так ли? w3.org/html/wg/drafts/html/master/semantics.html#the-p-element w3.org/html/wg/drafts/html/master/semantics.html#the-ul-element w3.org/ html / wg / drafts / html / master / semantics.html # the-ol-element - особенно, если порядок имеет значение, тогда используйте элемент ol (так как это структурная часть) - вы все равно можете представить его в виде списка маркеров использование CSS
HorusKol
5
и если вы посмотрите на два других ответа здесь, вы увидите, что ни один из них не говорит просто «потому что это правило» - они оба выкладывают очень четкие обоснования для правила и вариантов использования
HorusKol
1
Хм, мне кажется, что я сказал что-то вроде: «Кто-то видит проблему и предлагает правило, чтобы предотвратить ее. Другие видят ценность этого правила. Затем они настаивают на слепой преданности этому правилу, независимо от первоначальной проблемы, которую оно предполагалось. решать и / или независимо от того, какие другие проблемы он создает. " Я не отрицаю, что за правилом стоит разумное мышление. Я просто не согласен с выводом. Конечно, я могу сказать: «У вас есть хорошая точка зрения, но, тем не менее, я не согласен». И, конечно, вы не отрицаете, что есть люди, которые не понимают плюсы и минусы и говорят ...
Jay
1
... "потому что это правило". Я имел много бесед с такими людьми за эти годы, по этому конкретному вопросу и по многим другим. Люди, которые отказываются даже обсуждать плюсы и минусы правила, потому что это правило, конец обсуждения.
Джей
Возникло это печальное представление о том, что HTML-дизайн имеет свои корни в какой-то абстрактной форме разработки, а не в искусстве. Таким образом, в этом ключе некоторые решили, что должны существовать абсолютные правила, аналогичные физике, и гравитация, которой нужно подчиняться, или тот, кто нарушает такие правила, отходит от «более чистой веры». Реальность такова, что ни браузер, ни метафора дизайна не являются непогрешимыми. Будьте осторожны с теми, кто настаивает на обратном.
Дэвид W
5

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

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

Crisfole
источник
3

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>и т. Д.

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

Джонатан Юнис
источник
4
как это может приблизиться к ответу на вопрос?
HorusKol
2
ИМО, в нем обсуждается основной вопрос, почему дизайнеры, разработчики и контент-работники предпочитают использовать общие элементы ( <div>и <span>) вместо конкретных, специально созданных элементов (например <table>). Это немного больше мета, чем просто эти теги, но это говорит непосредственно о шаблонах и принципах использования.
Джонатан Юнис
@HorusKol На самом деле, из всех ответов, приведенных здесь, этот наиболее соответствует вашему ответу и поддерживает его. Я бы сказал, что они хорошо сочетаются.
Джонатан Юнис
1
Я не знаю, смогу ли я пойти так далеко, чтобы сравнивать div(как общий) с table(как специально построенный). Они , как специально построенный для двух различных (хотя , возможно , частично перекрывающих друг друга) целей. Это, я полагаю, суть вопроса.
Эрик Кинг,
@EricKing Справедливо сказать, что divу этого есть цель. Но divи spanне имеют очень специфическую намеченную цель , которая table, thead, и tdт.д. делать. Никто не будет волноваться, если вы будете использовать divэлементы misc для боковых панелей, вставлять кавычки, группировки разделов и т. Д. - практически в любом месте документа. Попробуйте сделать это с неохваченной thead, tdили li. Вместо «специально созданного», может быть, «определенного» или «с определенной предполагаемой ролью».
Джонатан Юнис
0

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

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

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

Роберт Манн
источник