HTML：包括还是排除可选的结束标记？

149

一些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的随机文章说：

结束标记是可选的。但是，建议将其包括在内。

我问的原因是因为您只是出于兼容性原因才知道它是可选的。如果可以的话，他们本来可以将它们设置为（强制 | 禁止）。

换句话说，HTML1、2、3对这些（现在是可选的）关闭标记做了什么。HTML 5会做什么？那我该怎么办？

注意

HTML中的某些元素禁止带有结束标记。您可能不同意这一点，但这只是规范，不值得争论。我问的是可选的结束标记，目的是什么。

脚注

1个 HTML 4.01

html  html4 
— 伊恩·博伊德（Ian Boyd）
source
4
棘手的问题...一些w3c建议甚至都包含同时执行这两个示例的示例：w3.org/TR/html401/struct/global.html#id-and-class第一个示例包含结束</p>标记，第二个示例省略了它们！
— 理查德JP Le Guen 2010年
只是要澄清一下-对于HTML5中的禁止标签，“显式” / XML有效解决方案是使用来关闭它们/>，例如<meta charset="utf-8" />即使<meta charset="utf-8">有效的HTML5吗？
— cboettig 2012年
@cboettig是的。<meta charset="utf-8" />是无效的 HTML，它必须是<meta charset="utf-8">。另一方面<meta charset="tuf-8">是无效的 xhtml，它必须是<meta charset="utf-8" />
— Ian Boyd
@IanBoyd真的吗？在HTML5中？在对多语种HTML / XHTML草案W3C手册说，使用<meta charset="UTF-8"/>与关闭标签。否则，polyglot或xhtml怎么能验证为html5和xml？
— cboettig 2012年
@cboettig你是对的。多语言标记（即HTML兼容的XHTML文档）不能是有效的HTML 4.01。HTML5（仍在开发中）具有Void元素的概念-不能具有end标签的元素。大概大多数浏览器都很温和，并且会原谅您的标记错误。
— 伊恩·博伊德

Answers:

49

可选的都是在结尾处应在语义上清晰的选项，而无需end标签。EG都<li>暗示着</li>如果没有正确的权利。

禁止的结束标签都将紧跟其结束标签，因此必须<img src="blah" alt="blah"></img>每次键入都是多余的。

我几乎总是使用可选标签（除非我有很好的理由不这样做），因为它使代码更具可读性和可更新性。

— 贫民窟
source
18
我现在看到了。 <LI>就像一颗子弹。没有人愿意将整个项目符号包起来<LI>...</LI>。因此，以这种方式LI匹配人们在标记过程中自然会写的内容。段落标记（<P>）也一样，在文字处理中，您需要在段落的开头添加一个段落标记；而不是每个人的末尾。因此，在这种解释中，关闭标签是可选的，因为没有普通人会认为拥有它们。另外，元素本身没有内容-元素就是内容。
— 伊恩·博伊德
8
你是什么意思的我几乎总是使用可选的标签 -你的意思是你有结束标签，或者你离开它？（我得到的印象是，你有它，当我看到你的答案-但通过上面的注释伊恩·博伊德给我你的印象排除它。）
— KajMagnus
3
@IanBoyd最后一段呢？
— Pacerier
22
@Pacerier人们已经撰写了数百年的文字段落。段落结束时，没有人会感到困惑。
— 伊恩·博伊德
4
HTML5的相关链接，适用于那些试图查找实际参考文档时找到此答案的人：w3.org/TR/html5/syntax.html#optional-tags
— Mike'Pomax'Kamermans
59

在某些情况下，显式标签会有所帮助，但有时是不必要的修饰。

请注意，HTML规范清楚地指定了何时省略标记才有效，因此它并不总是错误。

例如，您永远不需要</body></html>。没人记得<tbody>明确声明过（以至于XHTML对此做了例外）。

你不需要</head><body>，除非你有DOM-操作的脚本，实际上搜索<head>（那么最好明确地关闭它，因为默示结束规则<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

它仅在您验证文档时有用。

— 内核
source
4
等等，为什么<p>foo <p>bar</p> baz</p>不解析为两个嵌套p标签？
— 埃里克（Eric）2010年
19
因为一个<P>元素不能包含块级元素，所以 <P>是一个块级元素。来自（w3.org/TR/REC-html40/struct/text.html#edef-P）“ P元素代表一个段落。它不能包含块级元素（包括P本身）。”
— 伊恩·博伊德
1
@IanBoyd您的意思是不管CSS规则如何都不能包含块级元素？
— Pacerier
6
@Pacerier CSS不能以任何方式影响DOM。首先解析DOM，然后CSS对其进行显示。CSS block显示与HTML的块级内容是完全不同的（默认情况下，大多数HTML块级元素都显示为CSS块）。
— Kornel
2
@ anton1980不，这不一样。明确指定了省略的可选结束标记的处理方式，并且可以在所有兼容的浏览器中可靠地工作。OTOH一个虚构的<t>不会像工作<title>。
— Kornel 2012年
18

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

Dive Into HTML5的一些摘录：

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

W3C将此视为网络的基本问题，因此他们着手对其进行纠正。XML于1997年发布，它打破了宽恕客户的传统，并要求所有使用XML的程序都必须将所谓的“格式正确”错误视为致命错误。在希腊领导人德拉科（Draco）因相对较小的违反法律而判处死刑之后，这种导致第一个错误失败的概念被称为“严厉的错误处理” 。当W3C将HTML重新格式化为XML词汇表时，他们要求使用新application/xhtml+xmlMIME类型提供的所有文档都必须经过严格的错误处理。如果您的XHTML页面中甚至只有一个格式正确的错误，[...] Web浏览器别无选择，只能停止处理并向最终用户显示错误消息。

这个想法不是普遍流行的。Web作者基本上没有考虑到现有页面上的估计错误率为99％，向最终用户显示错误的可能性以及XHTML 1.0和1.1中新功能的缺乏以证明成本的合理性application/xhtml+xml。但这并不意味着他们完全忽略了XHTML。哦，绝对不是。XHTML 1.0规范的附录C给世界各地的网络作者带来了一个漏洞：“使用看起来像XHTML语法的东西，但继续使用text/htmlMIME类型提供它。” 这正是成千上万的Web开发人员所做的：他们“升级”为XHTML语法，但仍使用text / html MIME类型为其提供服务。

即使在今天，数百万的网页也声称是XHTML。它们从第一行的XHTML文档类型开始，使用小写标记名称，在属性值周围使用引号，并在诸如<br />和的空元素后面添加斜杠<hr />。但是，这些页面中只有一小部分具有application/xhtml+xmlMIME类型，该类型会触发XML的严厉错误处理。MIME类型为的任何页面text/html（无论文档类型，语法或编码样式如何）都将使用“宽容”的HTML解析器进行解析，静默忽略任何标记错误，并且即使这些页面也不会警告最终用户（或其他任何人）在技​​术上被打破了。

XHTML 1.0包含了这个漏洞，但是XHTML 1.1弥补了这个漏洞，并且从未完成的XHTML 2.0延续了要求严格的错误处理的传统。这就是为什么有数十亿个页面声称是XHTML 1.0，而只有少数几个声称是XHTML 1.1（或XHTML 2.0）的原因。那么，您真的使用XHTML吗？检查您的MIME类型。（实际上，如果您不知道所使用的MIME类型，我们可以保证您仍在使用text/html。）除非您为MIME类型为的网页提供服务，否则您的application/xhtml+xml“ XHTML”仅是XML名称。

提出不断发展的HTML和HTML表单的人们面临着两个选择：放弃或继续在W3C之外的工作。他们选择了后者，并注册了whatwg.org域名，WHAT工作组于 2004年6月成立。

那个工作组也在悄悄地从事其他一些工作。其中之一是规范，最初被称为Web Forms 2.0，它向HTML表单添加了新的控件类型。（您将在《疯狂的形式》中了解有关Web表单的更多信息。）另一个是名为“ Web Applications 1.0”的规范草案，其中包括主要的新功能，例如直接模式绘图画布以及对不带插件的音频和视频的本机支持。

2009年10月，W3C 关闭了XHTML 2工作组并发布了此声明，以解释他们的决定：

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

尽管我们认识到XHTML 2工作组多年来所做的贡献的价值，但在与参与者讨论之后，W3C管理层决定允许工作组的章程在2009年底到期，而不是续订。

获胜者就是运送者。

— 斯里卡·多迪
source
12

我问的原因是因为您只知道出于兼容性原因它是可选的。如果可以的话，他们本来可以（强制|禁止）制造它们的。

这是一个有趣的推论。我的理解是，几乎可以在任何时候可靠地推断出标签，标签都是可选的。该设计表明，这样做的目的是使其快速且易于编写。

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

HTML 2的DTD嵌入在RFC中，RFC与原始HTML DTD一起在各处具有可选的开始和结束标签。

HTML 3被遗弃了（由于浏览器大战），并被HTML 3.2（旨在描述当时的网络状态）取代。

HTML 5会做什么？

HTML 5从一开始就致力于“铺平道路”。

那我该怎么办？

啊，现在这是主观和争论的了:)

有人认为，显式标签由于位于读者的眼前，因此对可读性和可维护性更好。

有人认为，推断的标签由于不会使编辑器混乱，因此对可读性和可维护性更好。

— 昆汀
source
1
+1我没有想到过“可靠推断”的概念。因此，提倡这样的想法：一种或另一种方式实际上没有任何意图。我假设该规范试图与现有的HTML内容和HTML规范尽可能地兼容。
— 伊恩·博伊德
抱歉，戴夫，我把它交给了贫民窟。他需要代表:)但是您有相同的想法，但链接和引用的内容更多。但是很好的答案。
— 伊恩·博伊德
6

如果多余，请忽略它。

如果它有一个目的（甚至是看似微不足道的目的，例如增加您的IDE或增加您的眼睛），则将其保留。

在定义明确的规范中很少会看到不影响行为的可选项目。当然，除了“评论”。但是HTML规范不是设计规范，而是更多有关当前主要实现状态的文档。因此，当某项在HTML中是可选的而似乎毫无用处时，我们可能会猜测，可选的性质仅仅是特定浏览器中一个怪癖的文档。

查看上面链接的HTML-5规范RFC部分，您会看到可选标记奇怪地链接到注释的存在！那应该告诉您作者没有戴设计帽。相反，他们在主要实现中正在玩“记录怪癖”的游戏。因此，我们在这方面不能太重视规范。

因此，解决方案是：不要流汗。继续进行真正重要的事情。:)

— 约翰
source
5

我认为最好的答案是包括关闭标签以提高可读性或错误检测。但是，如果您有大量生成的HTML（例如，数据表），则可以通过省略可选标签来节省大量带宽。

— 加布
source
2
理查德（Richard）：当您具有深层嵌套的结构时，您会更容易发现错误，因为结束标记会提供有关意图的更多信息。
— 加布
1
我认为“关闭标签可提供有关意图的更多信息”是此问题的最佳简洁答案。以一种或另一种方式争论一个明确的理由。
— 2015年
4

我的建议是，省略大多数可选的关闭标签以及所有可以忽略的可选属性。许多IDE都会抱怨，因此您可能无法忽略其中的一些，但是通常更适合较小的文件大小和较少的混乱情况。如果您有代码生成器，则肯定在那里省略了结束标记，因为您可以从中获得一些不错的尺寸减小。通常，无论哪种方式都没有关系。

但是，当事情变得重要时，请对其采取行动。在我最近的一些工作中，我消除了open标记的大多数生成的end和多余值属性，从而将呈现的HTML的大小从1.5 MB减少到800 KB，其中元素的文本与值。我大约有200个标签。我可以完全采用其他方法来实现，但这将需要更多工作（$$$），因此这使我可以轻松地使页面更具响应性。

出于好奇，我发现如果删除不需要的属性周围的引号，则可以节省20 KB，但我的IDE（Visual Studio）不喜欢它。我也惊讶地发现ASP.NET生成的超长ID占我文件的20％。

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

— 用户名
source
我几乎无法接受省略可选的结束标记，但是我发现省略属性的引号是一个相当糟糕的主意。您冒着这样的风险在某些浏览器中破坏您的网站。如果您有800kb的html文件，说明您在做严重错误的事情。
— Christoph'Oct
2
@Christoph：根据HTML规范，完全可以省略可选的结束标记（如</p>或</li>）。如果浏览器不了解，则说明浏览器存在问题。
— Konrad Borowski
2

就个人而言，我是XHTML的粉丝，并且像ghoppe一样，“我尝试从不省略结束标签，因为它有助于我变得严谨，并且不省略必要的标签。”

但

如果您故意使用HTML 4.n，则不能说包含它们使使用文档变得更容易，因为格式正确（而不是有效性）的概念是一种XML概念，当您使用该格式时就会失去这种好处。禁止某些关闭标签。因此，唯一的问题就是有效性……如果没有它们，它仍然有效……您还可以节省带宽，不是吗？

— 理查德JP Le Guen
source
2

使用结束标记使处理片段更加容易，因为它们的行为不依赖于同级元素。仅此一个原因就足够令人信服。是否有人再处理单片html文档了？

— 窗帘狗
source
1

在某些大括号语言（例如C＃）中，如果if语句只有两行，则可以省略大括号。例如...

如果（[条件]）
    [代码]

但是你做不到...

如果（[条件]）
    [代码]
    [代码]

第三行将不属于if语句。它会损害可读性，并且容易引入错误并且很难发现错误。

出于相同的原因，我关闭了所有标签。像img标签这样的标签仍然需要关闭，只是不需要单独的关闭标签。

— 米格尔
source
您能举一个非常棘手的HTML示例吗？以我的经验，可选的结束标签并没有那么欺骗。
— Kornel
我记得几年前IE7出现问题，当时我在它所包含的文本的另一行上找到了开头的li标记，没有结尾的li，IE7像对待一个大项目符号一样对待所有项目符号。将标签和文本放在一行上，或关闭标签，将解决此问题。但是，我现在似乎无法对此进行复制，因此它可能也与正在播放的CSS有关。但是我不会因为把它当作“我在加拿大完全有一个女朋友！”而怪你。故事。
— MiguelR 2010年
0

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

因此，我总是包括可选的结束标记-从理论上讲，我的页面可以更快地呈现，因为我为浏览器的HTML解析器创建的工作量更少。

— 乔尔·穆勒（Joel Mueller）
source
1
我不同意; 相对于有效性而言，格式正确的概念是仅XML的概念，当您的元素具有禁止使用 close标签的元素时，它就变得无关紧要。
— 理查德JP Le Guen 2010年
1
我理解这一点，但是即使您的HTML标签没有，呈现的DOM元素也有一个开始和一个结束。如果包含<li>不带结束标记的标记，则浏览器在某个时候将不得不确定元素的结尾，并像在该点放置了结束标记一样进行操作。这可能是一个相对琐碎的逻辑，但是“一些”仍然比“没有”更多，并且我认为假设省略可选的结束标记比包含它们来使浏览器进行更多的工作是没有道理的。
— Joel Mueller 2010年
这是一个有趣的观点，但我仍然不同意。关闭标签是可选的，因为他们将被要求，并根据验证规则从而隐含......所以，当解析器到达那里有一个点有是根据验证关闭标签，不能就这样说，消耗的任务关闭标签（如果存在）会降低速度吗？
— 理查德JP Le Guen 2010年
@Richard-我想这取决于特定浏览器中的实际实现，但是我很难相信这样一个想法，即明确告诉您要结束元素的位置比告诉浏览器找出原因要糟糕。您。
— Joel Mueller 2010年
@RichardJPLeGuen我猜，这完全取决于规则的外观。当您关闭</table>且堆栈中包含时<table><tbody><tr><td>，只需关闭所有内容，直到匹配即可<table>。对于<p>在非时钟环境中打开也是如此。但我不知道，情况可能会困难得多。
— maaartinus
-1

尽您所能，使代码更具可读性和可维护性。

我个人总是倾向于封闭<td>和<tr>，但我绝不会费心<li>。

— 马修·威尔逊
source
1
我希望对最初的设计决策提供一些指导，如果可以的话，他们会做x的。
— 伊恩·博伊德
之间的区别是什么<td>，<li>这使您不必理会<li>？对我来说，没有什么区别。
— ghoppe
没有技术差异，这纯粹是主观的。如果关闭td和tr，我觉得可以更好地阅读HTML。但是我从来没有觉得李的需要。
— 马修·威尔逊
-2

对于禁止的关闭类型，请使用如下语法：<img />使用/>来关闭xml中接受的标签

— 丹妮
source
1
它在HTML4中不起作用（它与功能稍有不同的晦涩的SGML语法匹配）。在HTML5中是允许的，但没有意义。
— Kornel
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.