Правильное определение "табличных данных" в HTML

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

В качестве правильного пьющего кулада, когда дело касается HTML, я все о семантической разметке. В результате, конечно, мне не нравится видеть таблицы, в которых они не принадлежат. Эмпирическое правило для таблиц состоит в том, что вы должны использовать их только для "табличных данных", но мне пришло в голову, что это очень плохо определенная фраза. Я хотел бы сделать следующие данные таблицей, но другие в моем офисе не согласились с тем, что в этом случае таблица будет семантически корректной (в отличие от dl или ul и т.д.):

------------------
| SomeEmployee   |
|----------------|
| Field    | val |
| Field    | val |
| Field    | val |
| Field    | val |
------------------

Спросив вокруг офиса (и межсетевых экранов), я получил некоторые из следующих ответов о том, что делает данные "табличными":

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

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

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

Спасибо!

Джо

Ответ 1

В своих внутренних правилах написания статей в Википедии есть некоторые простые правила. Они далеки от исчерпывающего определения, но хорошо работают в ИМО в реальном мире.

Весь смысл стоит прочитать, но один абзац поражает меня как особенно приятное:

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

Ответ 2

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

В этом пределе различие между использованием тега TABLE или тега DL несколько размывается. Единственный способ отличия в том, что в dl DT-тег должен быть меткой, а dd должен содержать "данные". Если "данные", которые вы помещаете в тег DT, НЕ являются меткой (ака метаданные) для тега DD, тогда вы должны использовать таблицу. В вашем примере это своего рода словарь, я бы определенно использовал dl-тег. Я бы использовал таблицу, в которой данные в каждом из двух столбцов представляют НЕЗАВИСИМЫЕ атрибуты одной вещи. Но, как я уже сказал, различие размывается.

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

То, что я НИКОГДА не делал, это использовать для этого ul или ol. Проще говоря, они предназначены для отдельных столбцов. Кроме того, для каждой строки списка нет требования быть данными, то есть атрибутами, которые представляют собой данную вещь. Содержимое, которое идет в тегах UL или OL, не имеет связанных с ним метаданных: теги UL и OL не предоставляют разметки для метаданных, в отличие от тегов DL и тегов TABLE.

Переходя к более общему аспекту вашего вопроса, применяется следующее:

Как и в случае с настоящей любовью, вы знаете табличные данные, когда видите это.

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

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

A. - ТАБЛИЧНЫЕ ДАННЫЕ ДОЛЖНЫ БЫТЬ СТРУКТУРИРОВАННЫМИ ДАННЫМИ: Данные должны быть либо иерархическими, либо реляционными. Под этим я подразумеваю, что ВОЗМОЖНО лить данные в одну или другую структуру (или и то, и другое).

Это позволяет получить следующие правила, которые в значительной степени блокируют то, что МОЖЕТ входить в таблицу данных, тем самым отвечая на ваш вопрос и соблюдая требования W3C для использования тега:

ATOMICITY: Каждая ROW данных должна представлять отдельный UNIT того же самого. То есть, данные в каждой ячейке таблицы, ДОЛЖНЫ быть атрибутом того, что представляет каждый ROW данных. Это быстро говорит вам, почему некоторые вещи должны идти в тегах UL: это НЕЗАКОННЫЕ СПИСКИ, т.е. Каждая строка может ссылаться на очень разные вещи, а не на СТРУКТУРИРОВАННЫЕ ДАННЫЕ, где каждая строка ВСЕГДА представляет собой другой экземпляр класса вещей.
КЛЕТКИ: Должно быть целесообразно поместить каждый атрибут вещи в тег (aka cell). Содержимое каждой ячейки должно быть данным; элементы макета не допускаются. Обратите внимание, что это исключает дополнительные вещи, такие как заголовки столбцов, которые не должны использовать теги и должны использовать функционально более подходящий тег.
ОПРЕДЕЛЕНИЕ РЯДА ИЛИ "ФОРМАТ" ДАННЫХ: данные в каждой строке() должны отображаться в предопределенный "формат". По формату я имею в виду список атрибутов, которые описывают данную вещь. В дальнейшем атрибуты и столбец терминов используются взаимозаменяемо.
COLUMN ORDER: Этот формат должен быть строго упорядочен. То есть порядок столбцов не должен меняться от строки к строке.
НЕЗАВИСИМОСТЬ КАДРОВ: данные в каждой строке не должны зависеть от данных в других строках. Он также не должен зависеть от существования какой-либо другой строки. Данные в каждой строке зависят только от "формата".
Целостность строк: данные в каждой строке должны соответствовать ограничениям, определенным форматом.
СВЯЗАННЫЕ ДАННЫЕ: для учета связанных и иерархических данных требуется расширение для вышеуказанных правил. Это легко сделать, расширив формат, чтобы позволить типу столбца, который сам является таблицей.
В приведенных выше правилах нигде не говорится, что "столбцы" должны быть организованы по горизонтали. Это позволяет строкам иметь больше "структуры" и по-прежнему соответствовать правилам 0 - 6. Например, подкатегория "дочерних" данных может отображаться НИЖЕ данных, соответствующих ее "родительской" записи. Или нет. Или большое поле Memo может отображать другие ячейки. Просто потому, что это табличные данные не означает, что он не может иметь макет.
ДАННЫЕ ИЗОБРАЖЕНИЯ: образ продукта в каталоге - это данные. Однако в случае изображений ограничение столбца заключается в том, что изображение ДОЛЖНО относиться к другим "столбцам" "формата". Это выбивает, например, прозрачный gif, который justs устанавливает физическую высоту и/или ширину строки. Поскольку он не имеет неотъемлемой связи с другими данными в строке, он не выполняет правила 0 - 7.

B. - ТАБЛИЧНЫЕ ДАННЫЕ НЕ ВКЛЮЧАЮТ НЕСТРУКТУРИРОВАННЫЕ ДАННЫЕ. Это скорее следствие, но обращение к "злу" тега:

Все, что является макетом, например, связано с компоновкой содержимого и страницы, в отличие от самого содержимого, НЕ является табличными данными.

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

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

То, что не дерьмо, - это очевидное, но потенциально неопределенное утверждение о том, что табличные данные - это не что иное, как структурированные данные. По структурированному я имею в виду, что он должен составлять "строго типизированную" коллекцию.

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

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

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