IE9和Chrome14都将TBODY记录为tagName
<table>
The HTML5 spec on <table>明确指出：
后跟零个或多个tbody元素或一个或多个tr元素
此外。 The HTML5 spec on <tr>明确指出：
作为表元素的子元素，在任何标题，colgroup和thead元素之后，但仅当没有tbody元素是表元素的子元素时。
为什么浏览器会破坏我的DOM并在
时注入<tbody>
“向后兼容性”的答案绝对没有意义，因为我特意选择了HTML5 doctype。
答案 0 :(得分：39)
“向后兼容性”的答案绝对没有意义 因为我特意选择了HTML5文档类型。
但是，浏览器不区分HTML版本。具有HTML5 doctype和HTML4 doctype的HTML文档（除了FPI中没有URL的HTML4过渡文档类型的小例外）将以相同的方式进行解析和呈现。
我引用the relevant part of HTML5 parser description：
8.2.5.4.9“在表格中”插入模式
...
标记名称为以下值之一的开始标记：“td”，“th”，“tr”
表现为好像标签名为“tbody”的开始标记令牌 看到，然后重新处理当前令牌。
答案 1 :(得分：18)
您完全错过了HTML5规范中指定tree is constructed。
的方式的部分规范允许您编写table，而不包含隐含的tbody元素。就像您跳过html，head或body开始或结束标记一样，您的页面仍然可以正确呈现。
我认为如果您的内容因任何原因而遗漏，您希望DOM包含body。 tbody也是如此。它已被添加，因为它明确假设您忘记自己添加它。
标签名称为以下之一的开始标记：“td”，“th”，“tr”
表示好像已经看到标签名为“tbody”的开始标记令牌，然后重新处理当前令牌。
答案 2 :(得分：7)
根据我的经验，浏览器不区分HTML5和HTML4文档。它们的行为相同。 <!doctype html>不会在浏览器中触发任何特殊行为。
对于“HTML5文档”，<!doctype html> 不保留 - 它只是触发标准模式的最简单的doctype。
答案 3 :(得分：5)
这很大程度上是因为HTML5将HTML 4和XHTML 1.x的后继版本合并为一个规范。
当引入XHTML 1.0并且浏览器开始尝试使用XML解析器时，他们遇到了问题。作者习惯于在没有<table>的情况下撰写<tbody>。由于不允许XML解析器推断HTML解析器之类的标签，因此帮助作者转换到XHTML（当时看起来是个好主意）的最佳方法是通过允许{{1在DOM中成为<tr>的直接子节点。 （DOM尽可能相同，无论它是源自HTML解析还是XML解析。）因此浏览器实现了对此的支持。
现在HTML5内容模型在HTML5的HTML和XHTML序列化之间共享，因此它必须允许这两种安排，即有或没有tbody。
另一方面，在“HTML语法”（不适用到XML解析器）一节中，它清楚地表明HTML解析将推断tbody标签。
当<table>作为<table><tr><td>my text</td></tr></table>提供时，在DOM中创建的表结构将tr作为tbody的直接子节点，tbody是表的直接子节点。 HTML5内容模型说这没关系。
当text/html作为<table><tr><td>my text</td></tr></table>提供时，在DOM中创建的表结构将tr作为表的直接子项。 HTML5内容模型说这也没问题。
也可以通过脚本创建一个tr作为表的直接子节点。出于同样的原因，浏览器会将此视为大多数人期望的表行。
答案 4 :(得分：3)
这是出于“历史原因”（即向后兼容性，这对HTML非常重要）：
由于历史原因，某些元素有额外的限制 甚至超出其内容模型给出的限制。
table元素不得包含tr个元素，即使这些元素也是如此 根据技术上允许元素在table元素内部 本说明书中描述的内容模型。 （如果是tr元素 被置于标记中的table内，实际上意味着tbody在它之前开始标记。）
请注意，this quote来自"HTML Syntax"部分。本节仅适用于文档，创作工具和标记生成器，并且明确不适用于一致性检查器（需要使用HTML parsing algorithm）。
所以：规范说根据内容模型和解析规范允许在tr之外使用tbody，但生成HTML（包括你）的任何内容都应该使用tbody。
答案 5 :(得分：1)
向后兼容性不仅仅与doctype有关，脚本可能依赖于tbody元素。