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+xml MIMEtypes的所有文档都要经过严格的error handling。 如果您的XHTML页面中甚至出现单一格式错误,Web浏览器将别无select,只能停止处理并向最终用户显示错误消息。

这个想法并不普遍。 由于现有页面上的错误率高达99%,为最终用户显示错误的可能性一直存在,以及XHTML 1.0和1.1中的新function缺乏合理的成本,Web作者基本上忽略了application/xhtml+xml 。 但这并不意味着他们完全忽略了XHTML。 哦,绝对不是。 XHTML 1.0规范的附录C给世界的networking作者一个漏洞:“使用类似于XHTML语法的东西,但继续使用text/html MIMEtypes。”这正是成千上万的web开发者所做的:他们“升级”为XHTML语法,但仍然以text / html MIMEtypes提供服务。

即使在今天,数百万个网页声称是XHTML。 他们从第一行的XHTML文档types开始,使用小写的标签名称,围绕属性值使用引号,并在像<br /><hr />这样的空元素之后添加一个尾部的斜线。 但是,这些页面中只有很小的一部分会使用application/xhtml+xml MIMEtypes来触发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中接受的标记