为什么浏览器仍然在 HTML5 中注入 <tbody>？答案

【问题标题】：Why do browsers still inject <tbody> in HTML5?为什么浏览器仍然在 HTML5 中注入 <tbody>？
【发布时间】：2011-11-21 08:47:44
【问题描述】：

HTML5 doctype example.

IE9 和 Chrome14 都将 TBODY 记录为 <table> 内元素的 tagName

The HTML5 spec on <table> 明确指出：

后跟零个或多个 tbody 元素或一个或多个 tr 元素

此外。 The HTML5 spec on <tr> 明确指出：

作为 table 元素的子元素，在任何 caption、colgroup 和 thead 元素之后，但前提是没有 tbody 元素是 table 元素的子元素。

为什么浏览器会破坏我的 DOM 并在

时注入 <tbody>

我没有要一个
没有它完全有效

“向后兼容性”的答案绝对是零意义，因为我特别选择了 HTML5 文档类型。

【问题讨论】：

这个 chrome 是特定的还是出现在其他主要供应商中？
所有浏览器都会发生这种情况。可以在这里找到答案：stackoverflow.com/questions/1678494/…
@jimbojw 遗留代码可以使用 HTML4 doctype
@Raynos 我的意思是，旧版浏览器代码。构成我们浏览器的 DOM 解析算法的代码。
它是如何不符合 HTML 5 的？正如您所指出的，TBODY 不是必需的，但它是完全有效的。

标签： html

【解决方案1】：

“向后兼容”的答案绝对是零意义因为我特别选择了 HTML5 文档类型。

但是，浏览器不区分 HTML 版本。具有 HTML5 doctype 和 HTML4 doctype 的 HTML 文档（除了 FPI 中没有 URL 的 HTML4 过渡 doctype 的小例外）以相同的方式解析和呈现。

我会引用the relevant part of HTML5 parser description:

8.2.5.4.9 “in table”插入模式

...

标签名称为以下之一的开始标签：“td”、“th”、“tr”

就好像一个带有标签名称“tbody”的开始标签令牌已经被看到，然后重新处理当前令牌。

【讨论】：

【解决方案2】：

这在很大程度上是因为 HTML5 将 HTML 4 和 XHTML 1.x 的后续版本合并为一个规范。

当 XHTML 1.0 被引入并且浏览器开始尝试使用 XML 解析器时，他们遇到了一个问题。作者习惯于在没有<tbody>s 的情况下编写<table>s。由于不允许 XML 解析器像 HTML 解析器那样推断标签，因此帮助作者转换到 XHTML 的最佳方法（这在当时似乎是个好主意）是通过允许 <tr> 正确呈现表格s 成为 DOM 中 <table> 的直接子代。（DOM 尽可能地相同，无论它来自 HTML 解析还是 XML 解析。）因此浏览器实现了对此的支持。

现在 HTML5 内容模型在 HTML5 的 HTML 和 XHTML 序列化之间共享，因此它必须允许两种安排，即有或没有 tbody。

另一方面，在“HTML 语法”部分（不适用于 XML 解析器），它清楚地表明 HTML 解析将推断 tbody 标记。

当<table><tr><td>my text</td></tr></table> 用作text/html 时，在DOM 中创建的表结构会将tr 作为表的直接子级tbody 的直接子级。 HTML5 内容模型说这没问题。

当<table><tr><td>my text</td></tr></table> 用作application/xhtml+xml 时，在DOM 中创建的表结构会将tr 作为表的直接子级。 HTML5 内容模型说这也可以。

还可以通过脚本创建一个 tr 作为 table 的直接子级。出于同样的原因，浏览器会将其视为大多数人期望的表格行。

【讨论】：

为什么text/html 注入<tbody>。有充分的理由吗？
@Raynos - 也就是说，正如其他人所指出的那样，为了向后兼容。许多脚本和 css 选择器假定浏览器将继续做他们一直在做的事情，并且那里会有一个 tbody 元素。
但是这些相同的脚本和 css 选择器不会在 application/xhtml+xml 上中断吗？
是的。库代码经常这样做。但是 XHTML 的不同之处在于，大多数将其用作 XML 的作者使用不同的脚本和 CSS 来避免这些问题。

【解决方案3】：

您完全错过了 HTML5 规范中指定 tree is constructed 的部分。

规范允许您编写不带tbody 元素的table，因为它暗示。就像跳过 html、head 或 body 开始或结束标记一样，您的页面仍然可以正确呈现。

我假设您希望 DOM 为您的内容包含一个 body，以防它因任何原因被遗漏。 tbody 也是如此。添加它是因为它明确假设您忘记自己添加它。

The rules for table parsing

标签名称为以下之一的开始标签：“td”、“th”、“tr”

就好像已经看到了一个带有标签名称“tbody”的开始标签令牌，然后重新处理当前令牌。

【讨论】：

【解决方案4】：

根据我的经验，浏览器不会区分 HTML5 和 HTML4 文档。它们对两者的行为相同。 <!doctype html> 不会在浏览器中触发任何特殊行为。

而且<!doctype html> 也不为“HTML5 文档”保留 - 它只是触发标准模式的最简单的文档类型。

【讨论】：

@Raynos 我不使用“HTML5 文档”这个名称。网页是 HTML 文档。有些网页使用 HTML5 中首次定义的功能，有些则没有。但它们都是 HTML 文档。我的回答可能是：将 HTML 文档命名为 HTML5 文档有什么意义？
但我们可以明确定义文档类型为 HTML3、HTML4、当前。这样做有什么意义？
@Raynos 据我所知，应该定义文档类型的唯一原因是触发标准模式。除此之外，doctype 毫无用处。再说一次，据我所知。
@Šime - 对于 浏览器，这是唯一的原因。 验证器是不同的。

【解决方案5】：

这是出于“历史原因”（即向后兼容性，这对 HTML 非常重要）：

由于历史原因，某些元素有额外的限制甚至超出了他们的内容模型给出的限制。

table 元素不得包含 tr 元素，即使这些元素在技术上允许在 table 元素内根据本规范中描述的内容模型。（如果 tr 元素被放在标记中的table 内，它实际上意味着tbody 之前的开始标签。）

请注意this quote 来自"HTML Syntax" 部分。本节仅适用于文档、创作工具和标记生成器，明确不适用于一致性检查器（需要使用HTML parsing algorithm）。

所以：规范说，根据内容模型和解析规范，在 tbody 之外使用 tr 是允许的，但是任何生成 HTML（包括你）的东西都应该使用 tbody。

【讨论】：

这与“作为表格元素的子元素”直接冲突。为什么 WHATWG 规范会覆盖 HTML5 规范所说的内容？为什么会有矛盾？
那么您能解释一下“内容模型”和 DOM 有何不同吗？（通过编辑答案）

【解决方案6】：

向后兼容性不仅仅与文档类型有关，脚本可能依赖于存在的 tbody 元素。

【讨论】：

不要包含不适用于 HTML5 的脚本。如果您选择使用 HTML5，请不要使用错误代码。
@Raynos 虽然我同意，但浏览器是为那些在 HTML 中做坏事的人设计的。