Правильное определение для "табличных данных" в HTML
У меня есть педантичный аргумент, который требует разрешения.
Как истинный любитель koolaid, когда дело доходит до HTML, я все о семантической разметке. В результате, конечно, я ненавижу видеть таблицы, где они не принадлежат. Практическое правило для таблиц заключается в том, что вы должны использовать их только для "табличных данных", но до меня дошло, что это действительно плохо определенная фраза. Я хотел сделать следующие данные таблицей, но другие в моем офисе не согласились с тем, что таблица будет семантически правильной в этом случае (в отличие от dl или же ul, так далее):
------------------
| SomeEmployee |
|----------------|
| Field | val |
| Field | val |
| Field | val |
| Field | val |
------------------
Задавая вопросы по офису (и по сетям), я получил некоторые из следующих ответов о том, что делает данные "табличными":
- "Все, что вы поместите в электронную таблицу" (я видел макеты всего дизайна, созданные в электронных таблицах, так что мне, кажется, этого не хватает)
- Данные, которые будут хорошо отображаться в таблице базы данных (например, данные строк и столбцов)
- "Текст, предварительно отформатированный текст, изображения, ссылки, формы, поля форм, другие таблицы и т. Д." (спасибо W3C, это действительно полезно)
И так далее. Ни одно из этих представлений не является каноническим определением, и они не дают больших разделительных линий для принятия решений. Итак, я спрашиваю вас, мои умные соотечественники: как мы должны определять табличные данные.
Если это вообще возможно, пожалуйста, приведите источники ваших ответов, чтобы не допустить цепочки ответов "хорошо, я думаю".
Спасибо!
Джо
2 ответа
В Википедии есть некоторые практические правила в своих внутренних правилах написания статей. Они далеки от исчерпывающего определения, но хорошо работают в реальных условиях использования IMO.
Целое определение стоит прочесть, но один абзац мне кажется особенно приятным:
Прежде чем форматировать список в форме таблицы, подумайте, будет ли эта информация более понятной благодаря наличию строк и столбцов. Если это так, то стол, вероятно, является хорошим выбором. Если нет очевидных преимуществ наличия строк и столбцов, то таблица, вероятно, не лучший выбор.
Проблема с вашим примером в том, что он в двух столбцах.
В этом пределе различие между тем, использовать ли тег TABLE или тег DL, несколько размывается. Единственный способ различить это то, что в dl тег DT должен быть меткой, а dd должен содержать "данные". Если "данные", которые вы вводите в тег DT, НЕ являются меткой (она же метаданные) для тега DD, то вам следует использовать таблицу. В вашем примере, это своего рода словарь, я бы определенно использовал тег dl. Я бы использовал таблицу, в которой данные в каждом из двух столбцов представляют НЕЗАВИСИМЫЕ атрибуты одной вещи. Но, как я уже сказал, различие размывается.
В вашей "таблице" столбец Field выглядит для меня больше как метаданные. Так что правило там будет: всегда используйте наиболее семантически определенный тег. В этом случае для DL.
Что бы я НИКОГДА не делал, это использовал для этого тег ul или ol. Проще говоря, они для списков с одним столбцом. Также не требуется, чтобы каждая строка списка была данными, то есть атрибутами, которые представляют данную вещь. Контент, который идет в тегах UL или OL, не имеет связанных с ним метаданных: теги UL и OL не предоставляют никакой разметки для метаданных, в отличие от тегов DL и тегов TABLE.
Переходя к более общему аспекту вашего вопроса, применимо следующее:
Как и в случае с настоящей любовью, вы знаете табличные данные, когда видите их.
И, как и все, что вы знаете, когда вы видите это, точное определение будет заполнять объем перевариваемой философии. Для начала вам нужно определить, что вы подразумеваете под данными, прежде чем даже задать вопрос.
С учетом этих предостережений и просто для умственных упражнений, здесь мы идем:
A. Табличные данные должны быть структурированными. Данные должны быть иерархическими или реляционными. Под этим я подразумеваю, что ВОЗМОЖНО приводить данные в одну или другую структуру (или в обе).
Это позволяет получить следующие правила, которые в значительной степени блокируют то, что МОЖЕТ зайти в таблицу данных, тем самым отвечая на ваш вопрос и выполняя требования W3C для использования тега:
АТОМИЧНОСТЬ: каждый ряд данных должен представлять отдельный блок одного и того же. Т.е. данные в каждой ячейке таблицы ДОЛЖНЫ быть атрибутом того, что представляет каждая строка данных. Это быстро говорит вам, почему некоторые вещи должны идти в тегах UL: они являются НЕСТРУКТУРИРОВАННЫМИ СПИСКАМИ, т. Е. Каждая строка может ссылаться на совершенно разные вещи, в отличие от СТРУКТУРИРОВАННЫХ ДАННЫХ, где каждая строка ВСЕГДА представляет отдельный экземпляр класса вещей.
КЛЕТОЧНЫЕ МАТЕРИАЛЫ. Должно быть целесообразно поместить каждый атрибут вещи в тег (ячейка). Содержимое каждой ячейки должно быть данными; Элементы макета не допускаются. Обратите внимание, что это исключает вспомогательные вещи, такие как заголовки столбцов, которые не должны использовать теги и должны использовать функционально более подходящий тег.
ОПРЕДЕЛЕНИЕ СТРОКИ ИЛИ "ФОРМАТ" ДАННЫХ: Данные в каждой строке () должны соответствовать предварительно определенному "формату". Под форматом я подразумеваю список атрибутов, которые описывают данную вещь. В дальнейшем термины атрибут и столбец используются взаимозаменяемо.
ЗАКАЗ КОЛОННЫ: Этот формат должен быть строго заказан. То есть порядок столбцов не должен меняться от строки к строке.
НЕЗАВИСИМОСТЬ СТРОКИ: данные в каждой строке не должны зависеть от данных в других строках. И при этом это не должно зависеть от существования любого другого ряда. Данные в каждой строке зависят только от "формата".
Целостность строки: данные в каждой строке должны соответствовать ограничениям, определенным форматом.
СВЯЗАННЫЕ ДАННЫЕ. Для учета связанных и иерархических данных требуется расширение вышеуказанных правил. Это легко сделать, расширив формат, чтобы разрешить тип столбца, который сам является таблицей.
В вышеприведенных правилах нигде не говорится, что "столбцы" должны располагаться горизонтально. Это позволяет строкам иметь больше "структуры" и при этом соответствовать правилам 0–6. Например, разрешено отображать вложенную таблицу "дочерних" данных НИЖЕ данных, соответствующих ее "родительской" записи. Или нет. Или большое поле Memo может отображаться другими ячейками. То, что это табличные данные, не означает, что они не могут иметь макет.
ДАННЫЕ ИЗОБРАЖЕНИЯ: изображение товара в каталоге - это данные. Однако в случае изображений ограничение столбца состоит в том, что изображение ДОЛЖНО относиться к другим "столбцам" "формата". Это, например, выбивает прозрачный GIF, который устанавливает физическую высоту и / или ширину строки. Поскольку он не имеет внутренней связи с другими данными в строке, он не соответствует правилам 0 - 7.
Б. Табличные данные не включают неструктурированные данные. Это скорее следствие, но устраняет "зло" тега:
- Все, что является макетом, например, связанным с макетом контента и страницы, в отличие от самого контента, НЕ является табличными данными.
Вышесказанное делает нечто большее, чем просто использование ерунды для полировки следующего правила, которое вы сами сформулировали в своем вопросе:
Все, что входит в электронную таблицу или таблицу базы данных, исключая использование электронных таблиц, которые не относятся к данным.
То, что не чушь, - это очевидное, но потенциально смутное утверждение, что табличные данные - это не что иное, как структурированные данные. Под структурой я подразумеваю, что она должна составлять "строго типизированную" коллекцию.
Еще раз отмечу, что это определение исключает текст для заголовков столбцов, подписей, нижних колонтитулов. Другими словами, табличные данные - это то, что идет с тегом tbody. Все остальное в теге таблицы - это метаданные, которые относятся к табличным данным, но не являются их частью.
Приведенные выше правила определяют данные как нечто, соответствующее ограничениям столбца.
Итак, я думаю, теперь вам нужно определение ограничения столбца. Но опять же, вы знаете один, когда вы видите один...