HTML:包括或排除可选的结束标记?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/3008593/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-29 03:23:32  来源:igfitidea点击:

HTML: Include, or exclude, optional closing tags?

htmlhtml4

提问by Ian Boyd

Some HTML1closing tags are optional, i.e.:

一些HTML 1结束标记是可选的,即:

</HTML>
</HEAD>
</BODY>
</P>
</DT>
</DD>
</LI>
</OPTION>
</THEAD>
</TH>
</TBODY>
</TR>
</TD>
</TFOOT>
</COLGROUP>

Note:Not to be confused with closing tags that are forbiddento be included, i.e.:

注意:不要与禁止包含的结束标签混淆,即:

</IMG>
</INPUT>
</BR>
</HR>
</FRAME>
</AREA>
</BASE>
</BASEFONT>
</COL>
</ISINDEX>
</LINK>
</META>
</PARAM>

Note:xhtmlis different from HTML. xhtml is a form of xml, which requires everyelement have a closing tag. A closing tag can be forbiddenin html, yet mandatoryin xhtml.

注意:xhtml与 HTML 不同。xhtml 是 xml 的一种形式,它要求每个元素都有一个结束标记。结束标记可以被禁止在HTML,但强制性xhtml

Are the optional closing tags

是可选的结束标签

  • ideally included, but we'll accept them if you forgot them, or
  • ideally notincluded, but we'll accept them if you put them in
  • 理想情况下包括在内,但如果您忘记了它们,我们会接受它们,或者
  • 理想情况下包括在内,但如果您将它们放入,我们会接受它们

In other words, shouldI include them, or should I notinclude them?

换句话说,应该我包括他们,或者我应该包括它们呢?

The HTML 4.01 spec talks about closing element tags being optional, but doesn't say if it's preferable to include them, or preferable to not include them.

如何关闭元素标签是可选的HTML 4.01规范的会谈,但如果它的最好给他们,或者最好包括不包括他们不说。

On the other hand, a random article on DevGuru says:

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

The ending tag is optional. However, it is recommended that it be included.

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

The reason I ask is because you just knowit's optional for compatibility reasons; and they would have made them (mandatory| forbidden) if they could have.

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

Put it another way: What did HTML 1, 2, 3 do with regards to these, now optional, closing tags. What does HTML 5 do? And what should Ido?

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

Note

笔记

Some elements in HTML are forbiddenfrom having closing tags. You may disagree with that, but that is the specification, and it's not up for debate. I'm asking about optionalclosing tags, and what the intention was.

HTML 中的某些元素禁止使用结束标记。您可能不同意这一点,但这是规范,无需辩论。我问的是可选的结束标签,以及意图是什么。

Footnotes

脚注

1HTML 4.01

1HTML 4.01

采纳答案by aslum

The optional ones are all ones that should be semantically clear where they end, without needing the end tag. E.G. each <li>implies a </li>if there isn't one right before it.

可选的都是那些应该在语义上明确结束的地方,不需要结束标签。EG each<li>意味着 a</li>如果在它之前没有一个。

The forbidden end tags all would be immediately followed by their end tag so it would be kind of redundant to have to type <img src="blah" alt="blah"></img>every time.

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

I almost always use the optional tags (unless I have a very good reason not to) because it lends to more readable and updateable code.

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

回答by Kornel

There are cases where explicit tags help, but sometimes it's needless pedantry.

在某些情况下,显式标签会有所帮助,但有时它是不必要的迂腐。

Note that the HTML spec clearly specifies when it's valid to omit tags, so it's not always an error.

请注意,HTML 规范明确指定了省略标签的有效时间,因此并不总是错误。

For example you never need </body></html>. Nobody ever remembers to put <tbody>explicitly (to the point that XHTML made exceptions for it).

例如,您永远不需要</body></html>. 没有人记得<tbody>明确放置(以至于 XHTML 为它设置了例外)。

You don't need </head><body>unless you have DOM-manipulating scripts that actually search <head>(then it's better to close it explicitly, because rules for implied end of <head>could surprise you).

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

Nested lists are actually better off without </li>, because then it's harder to create erroneous ul > ultree.

嵌套列表实际上没有 更好</li>,因为那样创建错误的ul > ul树就更难了。

Valid:

有效的:

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

Invalid:

无效的:

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

And keep in mind that end tags are implied whether you try to close all elements or not. Putting end tags won't automatically make parsing more robust:

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

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

will parse as:

将解析为:

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

It can only help when you validate documents.

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

回答by Srikar Doddi

I am adding some links here to help you with the history of HTML, for you to understand the various contradictions. This is not the answer to your question, but you will know more after reading these various digests.

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

Some excerpts from Dive Into HTML5:

Dive Into HTML5 的一些摘录:

[T]he fact that “broken” HTML markup still worked in web browsers led authors to create broken HTML pages. A lot of broken pages. By some estimates, over 99% of HTML pages on the web today have at least one error in them. But because these errors don't cause browsers to display visible error messages, nobody ever fixes them.

The W3C saw this as a fundamental problem with the web, and they set out to correct it. XML, published in 1997, broke from the tradition of forgiving clients and mandated that all programs that consumed XML must treat so-called “well-formedness” errors as fatal. This concept of failing on the first error became known as “draconian error handling,” after the Greek leader Dracowho instituted the death penalty for relatively minor infractions of his laws. When the W3C reformulated HTML as an XML vocabulary, they mandated that all documents served with the new application/xhtml+xmlMIME type would be subject to draconian error handling. If there was even a single well-formedness error in your XHTML page […] web browsers would have no choice but to stop processing and display an error message to the end user.

This idea was not universally popular. With an estimated error rate of 99% on existing pages, the ever-present possibility of displaying errors to the end user, and the dearth of new features in XHTML 1.0 and 1.1 to justify the cost, web authors basically ignored application/xhtml+xml. But that doesn't mean they ignored XHTML altogether. Oh, most definitely not. Appendix C of the XHTML 1.0 specification gave the web authors of the world a loophole: “Use something that looks kind of like XHTML syntax, but keep serving it with the text/htmlMIME type.” And that's exactly what thousands of web developers did: they “upgraded” to XHTML syntax but kept serving it with a text/html MIME type.

Even today, millions of web pages claim to be XHTML. They start with the XHTML doctype on the first line, use lowercase tag names, use quotes around attribute values, and add a trailing slash after empty elements like <br />and <hr />. But only a tiny fraction of these pages are served with the application/xhtml+xmlMIME type that would trigger XML's draconian error handling. Any page served with a MIME type of text/html— regardless of doctype, syntax, or coding style — will be parsed using a “forgiving” HTML parser, silently ignoring any markup errors, and never alerting end users (or anyone else) even if the pages are technically broken.

XHTML 1.0 included this loophole, but XHTML 1.1 closed it, and the never-finalized XHTML 2.0 continued the tradition of requiring draconian error handling. And that's why there are billions of pages that claim to be XHTML 1.0, and only a handful that claim to be XHTML 1.1 (or XHTML 2.0). So are you really using XHTML? Check your MIME type. (Actually, if you don't know what MIME type you're using, I can pretty much guarantee that you're still using text/html.) Unless you're serving your pages with a MIME type of application/xhtml+xml, your so-called “XHTML” is XML in name only.

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

W3C 认为这是 Web 的一个基本问题,并着手纠正它。XML 于 1997 年发布,打破了宽容客户端的传统,并要求所有使用 XML 的程序必须将所谓的“格式良好”错误视为致命错误。这种在第一个错误上失败的概念被称为“严厉的错误处理”,因为希腊领导人德拉科对他的法律的相对轻微的违法行为判处了死刑。当 W3C 将 HTML 重新表述为 XML 词汇表时,他们强制要求所有使用新application/xhtml+xmlMIME 类型的文档都要进行严格的错误处理。如果您的 XHTML 页面中出现一个格式正确的错误 […],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 />and等空元素后添加尾部斜杠<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。

[T]he people who had proposed evolving HTML and HTML forms were faced with two choices: give up, or continue their work outside of the W3C. They chose the latter, registered the whatwg.orgdomain, and in June 2004, the WHAT Working Group was born.

[T] 那些提议发展 HTML 和 HTML 表单的人面临着两个选择:放弃,或者在 W3C 之外继续他们的工作。他们选择了后者,注册了whatwg.org域名,2004年6月,WHAT工作组诞生了

[T]he WHAT working group was quietly working on a few other things, too. One of them was a specification, initially dubbed Web Forms 2.0, which added new types of controls to HTML forms. (You'll learn more about web forms in A Form of Madness.) Another was a draft specification called “Web Applications 1.0,” which included major new features like a direct-mode drawing canvasand native support for audio and video without plugins.

[T]他什么工作组也在悄悄地做其他一些事情。其中之一是最初称为Web Forms 2.0的规范,它将新类型的控件添加到 HTML 表单中。(您将在A Form of Madness 中了解有关 Web 表单的更多信息。)另一个是名为“Web Applications 1.0”的规范草案,其中包括主要的新功能,例如直接模式绘图画布和对音频和视频的本机支持,无需插件

In October 2009, the W3C shut down the XHTML 2 Working Groupand issued this statement to explain their decision:

When W3C announced the HTML and XHTML 2 Working Groups in March 2007, we indicated that we would continue to monitor the market for XHTML 2. W3C recognizes the importance of a clear signal to the community about the future of HTML.

While we recognize the value of the XHTML 2 Working Group's contributions over the years, after discussion with the participants, W3C management has decided to allow the Working Group's charter to expire at the end of 2009 and not to renew it.

The ones that win are the ones that ship.

2009 年 10 月,W3C关闭了 XHTML 2 工作组发布了以下声明来解释他们的决定

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

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

获胜的是那些运送的人。

回答by Quentin

The reason i ask is because you just know it's optional for compatibility reasons; and they would have made them (mandatory | forbidden) if they could have.

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

That's an interesting inference. My reading of it is that just about any time a tag could be reliably inferred, the tag is optional. The design suggests that the intention was to make it quick and easy to write.

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

What did HTML 1, 2, 3 do with regards to these, now optional, closing tags.

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

The DTD for HTML 2 is embedded in the RFCwhich, along with the original HTML DTD, has optional start and end tags all over the place.

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

HTML 3 was abandoned (thanks to the browser wars) and replaced with HTML 3.2 (which was designed to describe the then current state of the web).

HTML 3 被放弃了(多亏了浏览器War),取而代之的是 HTML 3.2(旨在描述当时的网络状态)。

What does HTML 5 do?

HTML 5 有什么作用?

HTML 5 was geared towards "paving the cowpaths" from the outset.

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

And what should i do?

我该怎么办?

Ah, now that is subjective and argumentative :)

啊,现在这是主观的和有争议的:)

Some people think that explicit tags are better for readability and maintainability by virtue of being in front of the readers eyes.

有些人认为显式标签由于在读者眼前,因此具有更好的可读性和可维护性。

Some people think that inferred tags are better for readability and maintainability by virtue of not cluttering up the editor.

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

回答by ghoppe

What does HTML 5 do?

HTML 5 有什么作用?

The answer to this question is in the W3C Working Draft: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

这个问题的答案在 W3C 工作草案中:http: //www.w3.org/TR/html5/syntax.html#syntax-tag-omission

And what should i do?

我该怎么办?

It's a matter of style. I try to never omit end tags because it helps me to be rigorous and notomit tags that are necessary.

这是一个风格问题。我尽量不要省略结束标签,因为它有助于我保持严谨,而不是省略必要的标签。

回答by John

If it is superfluous, leave it out.

如果它是多余的,请忽略它。

If it serves a purpose (even a seemingly trivial purpose, such as appeasing your IDE or appeasing your eyes), leave it in.

如果它有一个目的(即使是一个看似微不足道的目的,例如安抚您的 IDE 或安抚您的眼睛),请将其保留。

It's rare in a well-defined spec to see optional items that do not affect behavior. With the exception of "comments", of course. But the HTML spec is less of a design spec, and more of a document of the state of current major implementations. So when an item is optional in HTML and it seems to serve no purpose, we may guess that optional nature is merely documentation of a quirk in specific browser.

在定义明确的规范中很少会看到不影响行为的可选项目。当然,“评论”除外。但是 HTML 规范不是设计规范,而是当前主要实现状态的文档。所以当一个项目在 HTML 中是可选的并且它似乎没有任何作用时,我们可能会猜测可选的性质只是特定浏览器中的一个怪癖的文档。

Looking at the HTML-5 spec RFC section linked above, you see that the optional tags are strangely linked to the presence of comments! That should tell you that the authors are not wearing design hats. They are instead playing the game of "document the quirks" in major implementations. So we can't take the spec too seriously in this respect.

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

So, the solution is: Don't sweat it. Move on to something that actually matters. :)

所以,解决方案是:不要出汗。继续做一些真正重要的事情。:)

回答by Gabe

I think the best answer is to include closing tags for readability or error detection. However, if you have lots of generated HTML (say, tables of data), you could save significant bandwidth by omitting optional tags.

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

回答by user1777246

My recommendation is that you omit most optional close tags, and all optional attributes that you can get away with. Many IDEs will complain so you may not be able to get away with omitting some of these but it is generally better for smaller file size and less clutter. If you have code generators definitely omit end tags there because you can get some good size reduction from it. Usually it doesn't really matter one way or the other.

我的建议是省略大多数可选的关闭标签,以及所有可以避免的可选属性。许多 IDE 会抱怨,因此您可能无法忽略其中的一些内容,但通常对于较小的文件大小和较少的混乱情况会更好。如果你有代码生成器,肯定会省略那里的结束标签,因为你可以从中得到一些很好的尺寸缩减。通常,这并不重要。

But when it does matter then act on it. On some recent work of mine I was able to reduce the size of my rendered HTML from 1.5 MB to 800 KB by eliminating most of the generated end and redundant value attributes for the open tag, where the text of the element was the same as the value. I have about 200 tags. I could implement this some other way entirely, but that would be more work ($$$), so this allows me to easily make the page more responsive.

但是,当它确实重要时,就采取行动。在我最近的一些工作中,我能够通过消除大多数为打开标签生成的结束和冗余值属性,将渲染的 HTML 的大小从 1.5 MB 减少到 800 KB,其中元素的文本与价值。我有大约 200 个标签。我可以完全以其他方式实现这一点,但这会增加工作量 ($$$),因此这使我可以轻松地使页面更具响应性。

Just out of curiosity I found that if I removed quotes around attributes that didn't need them I could save 20 KB, but my IDE (Visual Studio) doesn't like it. I also was surprised to find that the really long ID that ASP.NET generates account for 20% of my file.

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

The idea that we could ever get any relevant fraction of HTML strictly valid was misguided in the first place, so do whatever works best for you and your customers. Most tools that I have ever seen or used will say they generate xhtml, but they don't really work 100%, and there isn't any benefit to strict adherence anyway.

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

回答by CurtainDog

Using end tags makes dealing with fragments easier because their behaviour is not dependant on sibling elements. This reason alone should be compelling enough. Does anyone deal with monolithic html documents anymore?

使用结束标签可以更轻松地处理片段,因为它们的行为不依赖于同级元素。光是这个理由就足够令人信服了。有没有人处理单一的 html 文档了?

回答by Richard JP Le Guen

Personally, I'm a fan of XHTML and, like ghoppe, "I try to never omit end tags because it helps me to be rigorous and not omit tags that are necessary."

就我个人而言,我是 XHTML 的粉丝,并且和 ghoppe 一样,“我尽量不要省略结束标签,因为它有助于我保持严谨,而不是省略必要的标签。”

but

If you're deliberately using HTML 4.n, one can't argue that including them makes it easier to consume the document, as the notion of well-formedness as opposed to validity is an XML concept, and you lose that benefit when you forbidcertain close tags. So the only issue becomes validity... and if it's still valid without them... you might as well save the bandwidth, no?

如果您有意使用 HTML 4.n,则不能争辩说包含它们会使文档更容易使用,因为与有效性相对的格式良好的概念是一个 XML 概念,当您禁止某些关闭标签。所以唯一的问题是有效性......如果没有它们它仍然有效......你最好节省带宽,不是吗?