“表格数据”的正确定义在 HTML 中
我有一个迂腐的论点需要解决。
作为一个真正的 koolaid 饮用者，当谈到 HTML 时，我非常关注语义标记。因此，我当然讨厌看到不属于它们的桌子。表格的经验法则是，您应该只将它们用于“表格数据”，但我注意到这是一个定义不明确的短语。我想将以下数据制作为表格，但我办公室的其他人不同意在这种情况下表格在语义上是正确的（而不是 dl 或 ul 等）：
------------------
| SomeEmployee |
|----------------|
| Field | val |
| Field | val |
| Field | val |
| Field | val |
------------------
在办公室（和互联网）周围询问，我得到了以下一些关于什么使数据“表格化”的答案：
- “您可以放入电子表格中的任何内容”（我见过在电子表格中创建的整个设计模型，所以这对我来说似乎有些缺乏）
- 可以很好地映射到数据库表的数据（例如，具体而言，行和列数据）
- “文本、预格式化文本、图像、链接、表单、表单字段、其他表等”。 （感谢 W3C，这真的很有帮助）
等等。这些似乎都不是规范的定义，并且它们没有提供很好的分界线来做出决策。所以，我问你们，聪明的同胞们：我们应该如何定义表格数据。
如果可能的话，请注明答案的来源，以防止出现一串“我认为是这样”的答案。
谢谢！
乔
I have a pedantic argument that needs resolution.
As a proper koolaid drinker when it comes to HTML, I'm all about semantic markup. As a result, of course I hate to see tables where they don't belong. The rule of thumb for tables is that you should only use them for "tabular data", but it has come to my attention that this is a really poorly defined phrase. I wanted to make the following data a table, but others at my office disagreed that a table would be semantically correct in this case (as opposed to a dl or ul, etc):
------------------
| SomeEmployee |
|----------------|
| Field | val |
| Field | val |
| Field | val |
| Field | val |
------------------
Asking around the office (and the interwebs), I got some of the following answers on what makes data "tabular":
- "Anything that you would put in a spreadsheet" (I've seen entire design mockups created in spreadsheets, so this seems somewhat lacking to me)
- Data that would map well to a database table (e.g. row and column data, specifically)
- "Text, preformatted text, images, links, forms, form fields, other tables, etc." (thanks W3C, that's really helpful)
And so on and so forth. None of these seem to be canonical definitions, and they don't provide great dividing lines to make decisions on. So, I ask you, my clever compatriots: how should we define tabular data.
If at all possible, please cite the sources for your answers to prevent a string of "well I think" answers.
Thanks!
Joe
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
维基百科在其内部文章写作指南中有一些切实可行的规则。它们远非详尽的定义，但在 IMO 的实际使用中效果很好。
整个定义值得一读，但有一段让我觉得特别好：
Wikipedia has some down-to-earth rules in its internal article-writing guidelines. They're far from an exhaustive definition but work well in real-world use IMO.
The whole definition is worth reading, but one paragraph strikes me as especially nice:
您的示例的问题在于它分为两列。
在这个限制下，使用 TABLE 标签还是 DL 标签之间的区别有些模糊。唯一的区分方法是在 dl 中，DT 标签应该是标签，而 dd 应该保存“数据”。如果您放入 DT 标签中的“数据”不是 DD 标签的标签（也称为元数据），那么您应该使用表格。在你的例子中，这是一种字典，我肯定会使用 dl 标签。我将使用一个表，其中两列中的每一列中的数据代表一个事物的独立属性。但就像我说的，这种区别已经模糊了。
在您的“表”中，“字段”列在我看来更像是元数据。所以规则是：总是使用语义上最具体的标签。在这种情况下，DL。
我绝不会为此使用 ul 或 ol 标签。很简单，它们适用于单列列表。此外，不要求列表的每一行都是数据，即表示给定事物的属性。 UL 或 OL 标签中的内容没有与之关联的元数据：与 DL 标签和 TABLE 标签不同，UL 和 OL 标签不提供任何元数据标记。
转向您问题的更一般方面，以下内容适用：
与真爱一样，当您看到表格数据时，您就知道它。
就像您看到它时就知道的任何事物一样，精确的定义将填满一本难以理解的哲学。首先，在提出问题之前，您需要定义数据的含义。
考虑到这些注意事项，并且只是为了进行心理练习，我们开始：
A.-表格数据必须是结构化数据：数据必须是分层的或关系的。我的意思是应该可以将数据转换为一个或另一种结构（或两者）。
这允许派生出以下规则，这些规则几乎锁定了数据表中可以包含的内容，从而回答您的问题并遵守使用标签的 W3C 要求：
原子性：数据的每个行必须代表一个同一事物的单个单元。即，表的每个单元格中的数据必须是数据的每个行所代表的属性。这很快就会告诉您为什么有些内容应该放在 UL 标签中：它们是非结构化列表，即每行可以引用非常不同的事物，这与结构化数据相反，其中每行始终代表一类事物的不同实例。< /p>
单元格：将事物的每个属性放入标签（也称为单元格）中应该是可行的。每个单元格的内容必须是数据；不允许使用布局元素。请注意，这不包括诸如列标题之类的附件，它们不应使用标签，而应使用功能上更合适的标签。
数据的行定义或“格式”：每行 () 中的数据必须映射到预定义的“格式”。我所说的格式是指描述给定事物的属性列表。在下文中，术语“属性”和“列”可互换使用。
COLUMN ORDER：此格式必须严格排序。即，行与行之间的列顺序不能改变。
行独立性：每行中的数据不得依赖于其他行中的数据。它也不应该依赖于任何其他行的存在。每行中的数据仅依赖于“格式”。
行完整性：每行中的数据必须符合格式定义的约束。
相关数据：需要对上述规则进行扩展，以考虑相关和分层数据。通过扩展格式以允许本身就是表的列类型可以轻松完成此操作。
在上述规则中，没有任何地方规定“列”应该水平组织。这允许行具有更多“结构”并且仍然符合规则 0 - 6。例如，允许“子”数据的子表出现在与其“父”记录对应的数据下方。或不。或者可以在其他单元格中显示一个大的备注字段。仅仅因为它是表格数据并不意味着它不能有布局。
图像数据：目录中的产品图像是数据。然而，在图像的情况下，列约束是图像必须与“格式”的其他“列”相关。例如，这会淘汰仅设置行的物理高度和/或宽度的透明 gif。由于它与行中的其他数据没有内在关系，因此不满足规则 0 - 7。
B.- 表格数据不包括非结构化数据。这更多的是一个推论，但解决了标签的“邪恶”：
上面的内容只不过是用废话来完善您自己在问题中陈述的以下规则：
电子表格或数据库表中的任何内容，同时排除与数据无关的电子表格的使用。
表格数据只不过是结构化数据，这不是废话，这是显而易见的，但可能含糊不清。我所说的结构化是指它必须构成一个“强类型”集合。
我再次注意到，这个定义不包括列标题、标题、页脚的文本。换句话说，表格数据是与 tbody 标签一起使用的。表标签中的其他所有内容都是元数据，它们引用表格数据，但不是表格数据的一部分。
上述规则将数据定义为符合列约束的内容。
所以我想现在您需要列约束的定义。但话又说回来，当你看到一个你就知道一个......
The problem with your example is that it is in two columns.
In that limit, the distinction between whether to use a TABLE tag or a DL tag blurs somewhat. The only way to distinguish would be that in the dl, the DT tag should be a label and the dd should hold "data". If the "data" you put in the DT tag is NOT a label (aka Metadata) to the DD tag, then you should use a table. In your example, that is a sort of dictionary, I would definitely use a dl tag. I would use a table where the data in each of the two columns represent INDEPENDENT attributes of one thing. But like I say, the distinction blurs.
In your "table", the Field column looks to me more like metadata. So the rule there would be: always use the most semantically specific tag. In this case, a DL.
What I would NEVER do is use a ul or ol tag for this. Quite simply, they are for single column lists. Also, there is no requirement for each row of the list to be data, ie, attributes that represent a given thing. Content that goes in the UL or OL tags does not have metadata associated with it: the UL and OL tags don't provide any markup for metadata, unlike DL tags and TABLE tags.
Moving onto the the more generic aspect of your question, the following applies:
As with true love, you know tabular data when you see it.
And as with anything that you know when you see it, the precise definition would fill a volume of indigestible philosopy. For a start, you would need to define what you mean by data before you even ask the question.
With those caveats in mind, and just for the mental exercise, here we go:
A.- TABULAR DATA MUST BE STRUCTURED DATA: The data must be either hierarchical or relational. By this I mean that it should be POSSIBLE to cast the data into one or the other structure (or both).
This allows the following rules to be derived, that pretty much lock down what CAN go in a table of data, thereby answering your question and complying with W3C requirements for use of the tag:
ATOMICITY: Each ROW of data must represent an individual UNIT of the same thing. Ie, the data in each CELL of the table, MUST be an attribute of what each ROW of data represents. This quickly tells you why some things should go in UL tags: they are UNSTRUCTURED LISTS, ie, each row can refer to very different things, as opposed to STRUCTURED DATA, where each row ALWAYS represents a different instance of a class of thing.
CELLS: It should be viable to put each attribute of the thing in a tag (aka cell). The content of each cell must be data; layout elements are not allowed. Note that this excludes accessory things like column headers, which should not use tags and should use the functionally more appropriate tag.
ROW DEFINITION OR 'FORMAT' OF THE DATA: The data in each row () must map to a predefined 'format'. By format, I mean a list of attributes that describe a given thing. In what follows, the terms attribute and column are used interchangeably.
COLUMN ORDER: This format must be strictly ordered. Ie, the order of the columns must not change from row to row.
ROW INDEPENDENCE: The data in each row must not depend on the data in other rows. Nor should it depend on the existence of any other row. The data in each row is only dependent on the 'format'.
ROW INTEGRITY: The data in each row must comply with the constraints defined by the format.
RELATED DATA: An extension to the above rules is required to account for related and hierarchical data. This is easily done by extending the format to allow a column type that is itself a table.
In the above rules, nowhere does it state that the "columns" should be organised horizontally. This allows the rows to have more "structure" and still comply with rules 0 - 6. For example, a sub table of "child" data is allowed to appear BELOW the data corresponding to its "parent" record. Or not. Or a large Memo field could be displayed the other cells. Just because it is tabular data does not mean it cannot have layout.
IMAGE DATA: a product image in a catalogue is data. However, in the case of images, the column constraint is that the image MUST relate to the other "columns" of the "format". This knocks out, for example, a transparent gif that justs sets the physical height and or width of a row. As it has no intrinsic relationship to the other data in the row, it is not fulfilling rules 0 - 7.
B.- TABULAR DATA DOES NOT INCLUDE UNSTRUCTURED DATA. This is more of a corollary, but addresses the "evils" of the tag:
The above does little more than use bullshit to polish the following rule that you yourself stated in your question:
Anything that goes in a spread sheet or a database table, whilst excluding uses of spreadsheets that do not relate to data.
What isn't bullshit is the obvious, yet potentially vague statement that tabular data is nothing other than structured data. By structured, I mean that it has to constitute a "strongly typed" collection.
Again, I note that this definition excludes the text for column headers, captions, footers. In other words, tabular data is what goes with the tbody tag. Everything else within the table tag is metadata that refers to, but is not part of, the tabular data.
The above rules define data as something that complies with a column constraint.
So I guess now you need a definition of a column constraint. But then again, you know one when you see one...