HTML：包含或排除可选的结束标记？
某些HTML 1结束标记是可选的 ，即：
</HTML> </HEAD> </BODY> </P> </DT> </DD> </LI> </OPTION> </THEAD> </TH> </TBODY> </TR> </TD> </TFOOT> </COLGROUP> 注意：不要与被禁止包含的结束标记混淆，即：
</IMG> </INPUT> </BR> </HR> </FRAME> </AREA> </BASE> </BASEFONT> </COL> </ISINDEX> </LINK> </META> </PARAM>
注意： xhtml与HTML不同。 xhtml是xml的一种forms，它要求每个元素都有一个结束标记。 结束标签可以在html中被禁止 ，但在xhtml是强制性的。
是可选的结束标签
- 理想地包括在内 ，但如果你忘了他们，我们会接受他们，或者
- 理想情况下不包括在内，但是如果你把它们放进去，我们会接受的
换句话说，我应该包括他们，还是不应该包括他们？
HTML 4.01规范讨论了closures元素标记是可选的 ，但是并没有说是否最好包含它们，或者最好不要包含它们。
另一方面， DevGuru上的一篇随机文章说 ：
结束标记是可选的。 但是，build议将其包括在内。
我问的原因是因为你只是知道这是可选的兼容性的原因; 如果可以的话，他们会做出这些决定（ 强制性的 ）。
换句话说：HTML 1,2,3是做什么的，现在是可选的closures标签。 HTML 5做什么？ 我该怎么办？
注意
HTML中的某些元素被禁止closures标签。 你可能会不同意，但这是规范，而不是辩论。 我在询问可选的结束标签，以及意图是什么。
脚注
1 HTML 4.01
可选的都是应该在语义上清晰的地方，而不需要结束标记。 如果在它之前没有一个权利，那么每个<li>暗示一个</li> 。
禁止的结束标签都会紧接着结束标签，因此每次都必须input<img src="blah" alt="blah"></img> 。
我几乎总是使用可选的标签（除非我有一个非常好的理由），因为它提供了更易于读取和更新的代码。
有些情况下显式标签可以帮助，但有时却是不必要的迂腐。
请注意，HTML规范明确指定何时有效省略标记，因此并不总是错误。
例如，你永远不需要</body></html> 。 没有人记得明确地（明确地指出XHTML为它制定了例外）。
你不需要</head><body>除非你有DOM操作脚本实际上search<head> （那么最好明确地closures它，因为隐含的<head>结尾的规则会让你感到惊讶。
嵌套列表在没有</li>情况下实际上更好，因为那样创build错误的ul > ul树就更困难了。
有效：
<ul> <li>item <ul> <li>item </ul> </ul>
无效：
<ul> <li>item</li> <ul> <li>item</li> </ul> </ul>
请记住，无论您是否尝试closures所有元素，都会隐含结束标记。 放置结束标签不会自动使parsing更健壮：
<p>foo <p>bar</p> baz</p>
将parsing为：
<p>foo</p><p>bar</p> baz
它只能帮助您validation文档。
我在这里添加一些链接来帮助您了解HTML的历史，让您了解各种矛盾。 这不是你的问题的答案，但你会阅读这些不同的摘要后知道更多。
- 我们是怎么来到这里的？ – 潜入HTML5
- networking的历史
- HTML简史
- HTML的历史 – HTML WG维基
Dive Into HTML5中的一些摘录：
事实上，“破碎”的HTML标记仍然在Web浏览器中工作，导致作者创build破损的HTML页面。 很多破碎的页面。 据估计，目前网页上超过99％的HTML页面至less有一个错误。 但是因为这些错误不会导致浏览器显示可见的错误信息，所以没有人修复过这些错误信息。
W3C认为这是networking的一个基本问题，他们着手纠正这个问题。 XML于1997年出版，突破了宽容客户的传统，并规定所有使用XML的程序必须将所谓的“格式良好”错误视为致命的错误。 第一个错误失败的概念被称为“严厉的error handling”，在希腊领导人德拉科（Draco ）对他的法律进行相对轻微的违反之后提起死刑。 当W3C将XML重新表述为XML词汇表时，他们强制要求使用新的
application/xhtml+xmlMIMEtypes的所有文档都要经过严格的error handling。 如果您的XHTML页面中甚至出现单一格式错误，Web浏览器将别无select，只能停止处理并向最终用户显示错误消息。这个想法并不普遍。 由于现有页面上的错误率高达99％，为最终用户显示错误的可能性一直存在，以及XHTML 1.0和1.1中的新function缺乏合理的成本，Web作者基本上忽略了
application/xhtml+xml。 但这并不意味着他们完全忽略了XHTML。 哦，绝对不是。 XHTML 1.0规范的附录C给世界的networking作者一个漏洞：“使用类似于XHTML语法的东西，但继续使用text/htmlMIMEtypes。”这正是成千上万的web开发者所做的：他们“升级”为XHTML语法，但仍然以text / html MIMEtypes提供服务。即使在今天，数百万个网页声称是XHTML。 他们从第一行的XHTML文档types开始，使用小写的标签名称，围绕属性值使用引号，并在像
<br />和<hr />这样的空元素之后添加一个尾部的斜线。 但是，这些页面中只有很小的一部分会使用application/xhtml+xmlMIMEtypes来触发XML的严重error handling。 任何使用MIMEtypes的text/html– 无论是文档types，语法还是编码风格 – 都将使用“forgiving”HTMLparsing器进行parsing，静静地忽略任何标记错误，甚至不会提醒最终用户（或任何其他人）如果这些网页在技术上已经损坏XHTML 1.0包含了这个漏洞，但是XHTML 1.1closures了它，并且未定案的XHTML 2.0延续了要求严格error handling的传统。 这就是为什么有数十亿页声称是XHTML 1.0，而且只有less数声称是XHTML 1.1（或XHTML 2.0）。 那么你真的使用XHTML？ 检查您的MIMEtypes。 （其实，如果你不知道你使用什么MIMEtypes，我几乎可以保证你仍然在使用
text/html。）除非你正在使用MIMEtypes的application/xhtml+xml，你所谓的“XHTML”只是名字上的XML。
曾经提出过发展HTML和HTML格式的人面临着两个select：放弃或继续W3C以外的工作。 他们select了后者，注册了
whatwg.org域名，并于2004年6月成立了WHAT工作组 。
什么工作组也在悄悄地在其他一些事情上工作。 其中之一是一个规范，最初被命名为Web Forms 2.0 ，它将新的控件types添加到HTML表单。 （您将在“疯狂的forms”中了解更多关于Web 表单的知识 ）。另一个是名为“Web Applications 1.0”的规范草案，其中包括一些主要的新function，如直接模式绘制canvas和本地支持audio和video的插件 。
在2009年10月，W3C closures了XHTML 2工作组并发表了这个声明来解释他们的决定 ：
当W3C于2007年3月宣布了HTML和XHTML 2工作组时，我们表示将继续监控XHTML 2的市场.W3C认识到向社区明确表示HTML未来的重要性。
虽然我们认识到XHTML 2工作组多年来的贡献，但经过与与会者的讨论，W3Cpipe理层决定允许工作组的章程在2009年底到期，而不是续约。
赢的是那些出货的。
我问的原因是因为你只是知道它是可选的兼容性的原因; 如果可以的话，他们会做出这些决定（强制性的）。
这是一个有趣的推论。 我的阅读是几乎任何时候一个标签可以被可靠的推断，标签是可选的。 该devise表明，其目的是使其写作快速简单。
关于这些，现在可选的closures标签，HTML 1，2和3做了什么。
RFC 2中embedded了HTML 2的DTD，它与原始的HTML DTD一起，在所有地方都有可选的开始和结束标签。
HTML 3被放弃了（感谢浏览器的战争），取而代之的是HTML 3.2（它被devise来描述当时的networking状态）。
HTML 5做什么？
HTML 5的目标是从一开始就“铺路”。
我该怎么办？
啊，现在是主观的和议论的:)
有些人认为，由于在读者眼前，显式标签对可读性和可维护性更好。
有些人认为推断标签的可读性和可维护性更好，因为不会弄乱编辑。
HTML 5做什么？
这个问题的答案在W3C工作草案中： http : //www.w3.org/TR/html5/syntax.html#syntax-tag-omission
我该怎么办？
这是一个风格问题。 我尽量不要忽略结束标签，因为这样可以帮助我更加严格， 不会遗漏必要的标签。
如果它是多余的，就把它排除在外。
如果它达到了一个目的（甚至是一个看起来很平常的目的，例如安装IDE或安抚你的眼睛），那就把它放在里面。
在定义明确的规范中很less看到不影响行为的可选项目。 除了“评论”，当然。 但是HTML规范不是一个devise规范，更多的是当前主要实现状态的文档。 所以当一个项目在HTML中是可选的，而且看起来没有任何用处时，我们可能会猜测可选的性质仅仅是特定浏览器中的怪癖的logging。
查看上面链接的HTML-5规范RFC部分，您会发现可选标记与评论的存在有着奇怪的联系！ 这应该告诉你，作者没有戴帽子。 他们在主要的实施中正在玩“logging怪癖”的游戏。 所以在这方面我们不能太认真。
所以，解决办法是：不要stream汗。 转移到真正重要的事情上。 🙂
我认为最好的答案是包括结束标签的可读性或错误检测。 但是，如果您有大量生成的HTML（例如数据表），则可以通过省略可选标记来节省大量带宽。
我的build议是，你省略了大多数可选的closures标签，以及所有可选的属性。 许多IDE会抱怨，所以你可能无法摆脱其中的一些，但通常更好的文件小，更less的混乱。 如果你有代码生成器，那么肯定会忽略结束标记，因为你可以从中获得一些好的尺寸减小。 通常这种方式并不重要。
但是，当它确实重要，然后采取行动。 在我的一些最近的工作中，我能够通过消除大部分为打开标记生成的结束和冗余值属性，从而将我呈现的HTML的大小从1.5 MB减less到800 KB，其中元素的文本与值。 我有大约200个标签。 我可以完全实现这一点，但这将是更多的工作（$$$），所以这使我可以轻松地使页面更加快速响应。
只是出于好奇，我发现如果我删除不需要它们的属性的引号，我可以节省20 KB，但我的IDE（Visual Studio）不喜欢它。 我也惊讶地发现ASP.NET生成的真正长的ID占我文件的20％。
我们能够得到任何相关的HTML部分严格有效的想法首先被误导，所以做任何最适合您和您的客户。 我曾经见过或使用过的大多数工具都会说它们会生成xhtml，但是它们并不是100％的工作，反正严格遵守也没有任何好处。
就我个人而言，我是XHTML的粉丝，就像ghoppe一样，“我尽量不要忽略结束标签，因为它能帮助我做到严格，而不是忽略必要的标签。”
但
如果您故意使用HTML 4.n，则不能认为包含它们使得更容易使用文档，因为与有效性相对的格式良好的概念是XML概念，当您禁止某些密切的标签。 所以唯一的问题就变成了有效性，如果没有它们，它仍然是有效的…你可能还要节省带宽，不是吗？
使用结束标签可以更轻松地处理碎片，因为它们的行为不依赖于同级元素。 单凭这个理由应该足够引人注目。 有没有人处理单片html文件了？
在像C＃这样的一些花括号语言中，如果if语句只有两行，就可以忽略大括号。 例如…
如果（[条件]）
[码]
但你不能这样做…
如果（[条件]）
[码]
[码]
第三行不会是if语句的一部分。 这会伤害到可读性，并且可以很容易地引入错误，并且很难find。
出于同样的原因，我closures所有的标签。 像img标签这样的标签仍然需要closures，而不是单独的结束标签。
如果您正在编写HTMLparsing器，parsing包含可选结束标记的HTML或不包含HTML的HTML会更容易一些吗？ 我认为可选的结束标签会使它更容易，因为我不必推断结束标签应该在哪里。
出于这个原因，我总是包含可选的结束标签 – 理论上说，我的页面可能渲染速度更快，因为我正在为浏览器的HTMLparsing器创build更less的工作。
做任何你觉得让代码更具可读性和可维护性的东西。
就我个人而言，我总是倾向于closures<td>和<tr> ，但我永远不会打扰<li> 。
对于禁止closurestypes，请使用如下语法： <img />使用/>closures在xml中接受的标记
