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