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 的一种形式,它要求 每个元素具有结束标记。HTML 中的结束标记可以是 禁止,而 xhtml中的结束标记可以是 强制性的

是可选的结束标记

  • 理想的 包括,但我们会接受他们,如果你忘记了他们,或
  • 理想的 没有包括,但我们将接受他们,如果你把它们

换句话说,应该我包括他们,或者我应该 没有包括他们?

HTML 4.01规范提到关闭元素标记是可选的,但没有说是否最好包括它们,或者最好不包括它们。

另一方面,一篇关于 DevGuru 的文章说:

结束标记是可选的。但是,建议包含它。

我问这个问题的原因是因为出于兼容性的考虑,知道是可选的; 如果可以的话,他们会制作它们(强制性的 | 禁止)。

换句话说: HTML 1、2、3对这些现在可选的结束标记做了什么。HTML 5做什么?应该做什么?

注意

HTML 中的一些元素由于具有结束标记而成为 禁止。你可能不同意这一点,但这是规范,不容争辩。我在问关于 可以选择结束标签的问题,以及它的意图是什么。

脚注

1 HTML 4.01

36726 次浏览

执行您认为可以使代码更易读和更易维护的任何操作。

就个人而言,我总是倾向于关闭 <td><tr>,但我永远不会与 <li>烦恼。

HTML 5做什么?

这个问题的答案可以在 W3C 工作草案中找到: Http://www.w3.org/tr/html5/syntax.html#syntax-tag-omission

那我该怎么办?

这是风格问题。我试图从来不省略结束标签,因为这有助于我严格和 没有省略标签是必要的。

我认为最好的答案是包括结束标签的可读性或错误检测。但是,如果有大量生成的 HTML (比如数据表) ,则可以通过省略可选标记来节省大量带宽。

可选项都是那些在语义上应该清楚它们的结束位置,而不需要结束标记的项。 例如,如果在每个 <li>之前没有一个 </li>,那么它就意味着一个 </li>

被禁止的结束标记之后都会立即跟上它们的结束标记,所以每次都必须键入 <img src="blah" alt="blah"></img>是有点多余的。

我几乎总是使用可选标记(除非我有一个很好的理由不这样做) ,因为它使代码更具可读性和可更新性。

我问这个问题的原因是因为出于兼容性的考虑,它是可选的; 如果可以的话,他们也会这样做(强制性 | 禁止性)。

这是个有趣的推论。我对它的理解是,几乎在任何时候都可以可靠地推断出标记,标记是可选的。该设计表明,其目的是使其快速、易于编写。

HTML 1、2、3对这些现在可选的结束标记做了什么。

HTML 2的 DTD 嵌入在 RFC中,与原来的 HTML DTD一样,RFC中到处都有可选的开始和结束标记。

HTML 3被抛弃了(感谢浏览器大战) ,取而代之的是 HTML 3.2(它被设计用来描述当时网络的现状)。

HTML 5做什么?

HTML 5从一开始就面向“铺平道路”。

那我该怎么办?

啊,这是主观的和争论性的:)

有些人认为,显式标签更好的可读性和可维护性的优点是在读者的眼前。

有些人认为,由于不会把编辑器弄得乱七八糟,所以推断出的标签更具可读性和可维护性。

就我个人而言,我是 XHTML 的粉丝,就像 ghoppe 一样,“我尽量不忽略结束标记,因为它有助于我严格,而不是省略必要的标记。”

但是

如果你故意使用 HTML 4。N,不能说包含它们使得消费文档更加容易,因为格式良好而非有效性的概念是一个 XML 概念,当您使用 禁止某些 close 标记时,您就失去了这个好处。所以唯一的问题就是有效性,如果没有它们还是有效的,你还不如节省带宽,不是吗?

对于禁用的关闭类型,可以使用如下语法: <img /> With the />来关闭 xml 中接受的标记

在某些情况下,明确的标签会有所帮助,但有时候这是不必要的迂腐。

注意,HTML 规范清楚地指定了省略标记的有效时间,所以这并不总是一个错误。

例如,你永远不需要 </body></html>。没有人会记得显式地放置 <tbody>(以至于 XHTML 为它制造了异常)。

您不需要 </head><body>,除非您有实际搜索 <head>的 DOM 操作脚本(那么最好显式地关闭它,因为隐含结束 <head>的规则可能会让您感到惊讶)。

嵌套列表实际上最好不要使用 </li>,因为这样就更难创建错误的 ul > ul树。

有效期:

<ul>
<li>item
<ul>
<li>item
</ul>
</ul>

无效:

<ul>
<li>item</li>
<ul>
<li>item</li>
</ul>
</ul>

请记住,无论您是否尝试关闭所有元素,结束标记都是隐含的。放置结束标记不会自动使解析更加健壮:

<p>foo <p>bar</p> baz</p>

将解析为:

<p>foo</p><p>bar</p> baz

它只有在验证文档时才有帮助。

在一些像 C # 这样的花括号语言中,如果 if 语句只有两行长,那么可以省略它周围的花括号。比如说。

([条件])
[代码]

但你不能这么做。

([条件])
[代码]
[代码] < br/>

第三行不会是 if 语句的一部分。它会影响可读性,而且很容易引入 bug,而且很难找到。

出于同样的原因,我关闭所有标记。像 img 标记这样的标记仍然需要关闭,只是没有单独的结束标记。

如果是多余的,就不要写。

如果它有用(即使是一个看起来微不足道的用途,比如安抚 IDE 或者安抚眼睛) ,那么就把它留在里面。

在定义良好的规范中,很少看到不影响行为的可选项。当然,除了“评论”。但是 HTML 规范与其说是设计规范,不如说是当前主要实现状态的文档。因此,当一个条目在 HTML 中是可选的,而且似乎没有任何用途时,我们可以猜测,可选的性质仅仅是在特定浏览器中记录了一个怪异之处。

查看上面链接的 HTML-5规范 RFC 部分,您会发现可选标记奇怪地链接到注释的存在!这应该告诉你,作者没有戴设计帽子。相反,他们在主要实现中玩的是“记录怪癖”的游戏。所以在这方面我们不能太认真对待规范。

所以,解决办法就是: 不要担心,转移到真正重要的事情上去。 :)

如果您正在编写一个 HTML 解析器,那么解析包含可选结束标记的 HTML 或不包含可选结束标记的 HTML 会更容易吗?我认为可选的结束标记的存在将使它更容易,因为我不必推断结束标记应该在哪里。

出于这个原因,我总是包含可选的结束标记-理论上,我的页面可能会渲染得更快,因为我为浏览器的 HTML 解析器创建了更少的工作。

我在这里添加了一些链接,以帮助您了解 HTML 的历史,让您了解各种矛盾。这不是您问题的答案,但是您将在阅读这些不同的摘要后了解更多。

以下节选自 深入研究 HTML5:

事实上,“破碎的”HTML 标记仍然可以在浏览器中使用,这导致了作者创建破碎的 HTML 页面。很多页都坏了。据估计,超过99% 的 HTML 网页至少有一个错误。但是因为这些错误不会导致浏览器显示可见的错误消息,所以没有人修复它们。

W3C 认为这是互联网的一个根本问题,他们开始着手解决这个问题。发布于1997年的 XML 打破了原谅客户机的传统,强制要求所有使用 XML 的程序必须将所谓的“格式良好”错误视为致命错误。这种在第一个错误上失败的概念被称为“严厉的错误处理”,以希腊领导人 德拉科的名字命名,他对相对较轻的违法行为实行死刑。当 W3C 将 HTML 重新表述为 XML 词汇表时,他们要求使用新的 application/xhtml+xml MIME 类型的所有文档都要经受严格的错误处理。如果您的 XHTML 页面中出现一个格式良好的错误[ ... ] ,Web 浏览器将别无选择,只能停止处理并向最终用户显示错误消息。

这个想法并不普遍流行。现有页面的估计错误率为99% ,向终端用户显示错误的可能性始终存在,XHTML 1.0和1.1缺乏新的特性来证明成本,网页作者基本上忽略了 application/xhtml+xml。但这并不意味着他们完全忽略了 XHTML。当然不是。XHTML 1.0规范的附录 C 给了世界各地的 web 作者一个漏洞: “使用看起来有点像 XHTML 语法的东西,但是继续使用 text/html MIME 类型。”成千上万的 web 开发人员正是这样做的: 他们“升级”到 XHTML 语法,但仍然使用 text/html MIME 类型。

即使在今天,数以百万计的网页声称是 XHTML。它们从第一行的 XHTML doctype 开始,使用小写标记名称,在属性值周围使用引号,并在空元素(如 <br /><hr />)后面添加一个尾部斜杠。但是这些页面中只有一小部分使用 application/xhtml+xmlMIME 类型,这将触发 XML 严格的错误处理。任何使用 text/html的 MIME 类型ーー不管文档类型、语法或编码风格ーー的页面都将使用“宽容的”HTML 解析器进行解析,无声无息地忽略任何标记错误,并且即使页面在技术上已经损坏,也不会提醒最终用户(或任何其他人)。

XHTML 1.0包含了这个漏洞,但是 XHTML 1.1弥补了这个漏洞,还没有最终完成的 XHTML 2.0继续了需要严格错误处理的传统。这就是为什么有数十亿页面声称是 XHTML 1.0,而只有少数页面声称是 XHTML 1.1(或 XHTML 2.0)。那么,您真的在使用 XHTML 吗?检查您的 MIME 类型。(实际上,如果您不知道您使用的是什么 MIME 类型,我可以非常肯定地说,您仍然在使用 text/html。)除非您使用 application/xhtml+xml的 MIME 类型为页面提供服务,否则所谓的“ XHTML”只是名义上的 XML。

那些提出了不断发展的 HTML 和 HTML 表单的人面临两个选择: 放弃,或者在 W3C 之外继续他们的工作。他们选择了后者,注册了 whatwg.org域名,并于2004年6月注册了 “什么工作组”诞生了域名。

[ T ]什么工作组也在悄悄地做其他一些事情。其中之一是最初称为 Web Forms 2.0的规范,它向 HTML 表单添加了新类型的控件。(您将在 疯狂的一种形式中了解更多关于 Web 表单的内容。)另一个是名为“ Web 应用程序1.0”的规范草案,其中包括主要的新特性,如 直接模式的绘画画布和对 没有插件的音频和视频的本地支持。

2009年10月,W3C 关闭 XHTML 2工作组发表了这份声明来解释他们的决定:

当 W3C 在2007年3月发布 HTML 和 XHTML 2工作组时,我们表示将继续监视 XHTML 2的市场。W3C 认识到向社区发出关于 HTML 未来的明确信号的重要性。

虽然我们认识到 XHTML 2工作组多年来所做贡献的价值,但在与与会者讨论之后,W3C 管理层已经决定允许工作组的章程在2009年底到期,而不再延长。

赢的人就是运输的人。

使用结束标记使得处理片段更加容易,因为它们的行为不依赖于兄弟元素。这个理由本身就足够令人信服了。现在还有人处理单片 HTML 文档吗?

我的建议是省略大多数可选的关闭标记和所有可选的属性。许多 IDE 会抱怨,因此您可能无法忽略其中的一些,但是通常对于较小的文件大小和较少的混乱来说,这样做更好。如果您有代码生成器,肯定会省略那里的结束标记,因为您可以从中获得一些很好的大小减少。通常不管怎样都无所谓。

但是当它真的重要的时候,然后采取行动。在我最近的一些工作中,我能够通过消除为开放标签生成的大部分 end 和冗余值属性(其中元素的文本与值相同) ,将呈现的 HTML 的大小从1.5 MB 减少到800 KB。我有大约200个标签。我完全可以通过其他方式实现这一点,但是这将需要更多的工作($$$) ,因此这使我能够轻松地使页面更具响应性。

只是出于好奇,我发现如果在不需要的属性周围删除引号,我可以节省20KB,但是我的 IDE (Visual Studio)不喜欢它。我还惊讶地发现 ASP.NET 生成的真正长的 ID 占了我文件的20% 。

那种认为我们可以得到任何相关的 HTML 部分严格有效的想法,首先是被误导的,所以做任何对您和您的客户最有效的事情。我见过或使用过的大多数工具都会说它们生成了 xhtml,但它们并不能真正100% 地工作,而且严格遵守也没有任何好处。