HTML5 doctype示例。
IE9和Chrome14都将TBODY记录为<table>内元素的tagName
<table>上的HTML5规范明确规定:
后接0个或多个tbody元素或一个或多个tr元素
。<tr>上的HTML5规范明确规定:
作为table元素的子元素，位于任何caption、colgroup和head元素之后，但仅当没有tbody元素是table元素的子元素时。
为什么浏览器会破坏我的DOM并在
时注入<tbody>- 我没有要求一个
- 没有 也是完全有效的
"向后兼容性"的答案完全没有意义，因为我特别选择了HTML5文档类型。
"向后兼容"的答案完全没有意义因为我特别选择了HTML5文档类型
但是，浏览器并不区分HTML的版本。使用HTML5 doctype和HTML4 doctype的HTML文档(除了HTML4过渡doctype在FPI中没有URL的小例外)的解析和呈现方式相同。
我将引用HTML5解析器描述的相关部分:8.2.5.4.9 in table插入方式
…
标签名称为:"td"、"th"、"tr"之一的开始标签
就像标记名称为"tbody"的开始标记令牌一样查看，然后重新处理当前令牌。
你完全错过了HTML5规范中规定如何构建树的部分。
规范允许您编写没有tbody元素的table，这是隐含的。就像如果你跳过html, head或body开始或结束标记，你的页面仍然可以正确呈现。
我假设您希望DOM包含一个body为您的内容，如果它被遗漏了任何原因。tbody也是如此。它被添加进来，因为它明确地假设你忘了自己添加它。
表解析规则
标签名称为:"td"、"th"、"tr"之一的起始标签
就像看到了标记名称为"tbody"的开始标记标记一样，然后重新处理当前标记。
根据我的经验，浏览器并不区分HTML5和HTML4文档。两者的行为是一样的。<!doctype html>在浏览器中不会触发任何特殊行为。
和<!doctype html>是不保留为"HTML5文档"-它只是最简单的可能触发标准模式的文档类型。
这主要是因为HTML5合并了HTML 4和XHTML 1的继承者。
当引入XHTML 1.0并且浏览器开始尝试使用XML解析器时，它们遇到了一个问题。作者们习惯于写<table> s而不写<tbody> s。由于XML解析器不允许像HTML解析器那样推断标记，因此帮助作者转换到XHTML的最佳方法(当时这似乎是一个好主意)是通过允许<tr> s成为DOM内<table>的直接子表来正确呈现表。(DOM尽可能是相同的，不管它是源自HTML解析还是XML解析。)所以浏览器实现了对这个的支持。
现在HTML5内容模型在HTML5的HTML和XHTML序列化之间共享，所以它必须允许两种安排，即有或没有body。
另一方面，在"HTML语法"一节中(其中没有将应用于XML解析器)，它清楚地表明HTML解析将推断tbody标记。当<table><tr><td>my text</td></tr></table>被用作text/html时，在DOM中创建的表结构将把tr作为表的直接子体。HTML5内容模型说这没问题。
当<table><tr><td>my text</td></tr></table>被用作application/xhtml+xml时，在DOM中创建的表结构将把tr作为表的直接子表。HTML5内容模型说这也是可以的。
也可以通过脚本将tr创建为table的直接子表。出于同样的原因，浏览器会像大多数人期望的那样将其视为表行。
这是由于"历史原因"(即向后兼容性，这对HTML非常重要):
由于历史原因，某些元素有额外的限制甚至超越了它们的内容模型所给出的限制。
table元素不能包含tr元素元素在table元素中是被允许的本规范中描述的内容模型。(如果是tr元素在标记中放入table，它实际上意味着tbody
请注意，这个引用来自"HTML语法"一节。本节仅适用于文档、创作工具和标记生成器，而不适用于一致性检查器(需要使用HTML解析算法)。
所以:规范说在tbody之外使用tr是允许的，根据内容模型和解析规范，但是任何生成HTML的东西(包括你)都应该使用tbody .
向后兼容性不仅仅是关于doctype，脚本可能依赖于存在的tbody元素