首页 文章

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

提问于
浏览
148

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

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

Note: 不要与要包括的 forbidden 的结束标签相混淆,即:

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

Note: xhtml 与HTML不同 . xhtml是xml的一种形式,它要求每个元素都有一个结束标记 . 结束标记可以是 forbidden 在html中,而 mandatoryxhtml 中 .

是可选的结束标记

  • 理想包括在内,但如果你忘了它们,我们会接受它们,或者

  • 理想情况下不包括在内,但如果你把它们放入,我们会接受它们

换句话说,我应该包括它们,还是不应该包括它们?

HTML 4.01 spec talks about closing element tags being optional,但不包括它们,或者最好不包括它们 .

另一方面,a random article on DevGuru says

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

我问的原因是因为你只是因为兼容性原因而知道它是可选的;他们本来可以做到的( mandatory | forbidden ) .

换句话说:HTML 1,2,3对这些,现在是可选的结束标记做了什么 . HTML 5有什么作用?我该怎么办?

注意

HTML中的某些元素禁止使用结束标记 . 您可能不同意这一点,但这是规范,并且's not up for debate. I'm询问可选的结束标记,以及意图是什么 .

脚注

1HTML 4.01

14 回答

  • 6

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

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

  • 18

    做任何你认为使代码更易读和可维护的东西 .

    就个人而言,我总是倾向于关闭 <td><tr> ,但我永远不会打扰 <li> .

  • 2

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

  • 8

    可选的是在结束时应该在语义上清晰的那些,而不需要结束标记 . 例如 . 每个 <li> 暗示 </li> 如果没有一个在它之前 .

    禁止结束标记全部将紧跟其结束标记,因此每次都必须键入 <img src="blah" alt="blah"></img> 是多余的 .

    我几乎总是使用可选标签(除非我有一个很好的理由不这样做)因为它提供了更易读和可更新的代码 .

  • 4

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

    请注意,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
    

    它只能在验证文档时提供帮助 .

  • 12

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

    Dive Into HTML5的一些摘录:

    [T]事实上,“破坏”的HTML标记仍然在Web浏览器中起作用,导致作者创建破碎的HTML页面 . 很多破页 . 据估计,目前网络上超过99%的HTML网页至少有一个错误 . 但是因为这些错误不会导致浏览器显示可见的错误消息,所以没有人修复它们 . W3C认为这是网络的一个基本问题,他们开始纠正它 . 1997年发布的XML打破了宽容客户的传统,并强制要求所有使用XML的程序必须将所谓的“格式良好”错误视为致命错误 . 在希腊领导人德拉科因相对轻微的违法行为而设立死刑之后,第一次失误失败的概念被称为“严苛的错误处理” . 当W3C将HTML重新构造为XML词汇表时,他们强制要求使用新的application / xhtml xml MIME类型提供的所有文档都会受到严格的错误处理 . 如果您的XHTML页面中只有一个格式错误,那么Web浏览器别无选择,只能停止处理并向最终用户显示错误消息 . 这个想法并不普遍受欢迎 . 由于现有页面的估计错误率为99%,向最终用户显示错误的可能性以及XHTML 1.0和1.1中缺少新功能以证明成本合理,因此Web作者基本上忽略了application / xhtml xml . 但这并不意味着他们完全忽略了XHTML . 哦,绝对不是 . XHTML 1.0规范的附录C为这个世界的网络作者提供了一个漏洞:“使用类似XHTML语法的东西,但继续使用text / html MIME类型提供服务 . ”这正是成千上万的Web开发人员所做的事情 . :他们“升级”为XHTML语法,但仍然使用text / html MIME提供服务类型 . 即使在今天,数以百万计的网页声称是XHTML . 它们从第一行的XHTML doctype开始,使用小写标记名称,在属性值周围使用引号,并在空元素(如
    和<hr />)之后添加尾部斜杠 . 但是这些页面中只有一小部分是使用application / xhtml xml MIME类型提供的,这会触发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]那些提出不断发展的HTML和HTML表单的人面临两种选择:放弃或继续他们在W3C之外的工作 . 他们选择了后者,注册了whatwg.org域名,2004年6月,WHAT工作组诞生了 .

    [T]他工作组正在悄悄地做其他一些事情 . 其中一个是规范,最初被称为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工作组多年来的贡献的 Value ,但在与参与者讨论后,W3C管理层决定允许工作组的章程在2009年底到期而不是续签 . 获胜的是那些发货的 .

  • 0

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

    这是一个有趣的推论 . 我对它的解读是,几乎在任何时候都可以可靠地推断标签,标签是可选的 . 该设计表明其目的是使其快速简便地编写 .

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

    HTML 2的DTD嵌入在RFC中,与原始HTML DTD一起,在整个地方都有可选的开始和结束标记 .

    HTML 3被放弃了(感谢浏览器大战)并被HTML 3.2(用于描述当时的Web状态)所取代 .

    HTML 5有什么作用?

    HTML 5从一开始就面向“铺设牛路” .

    我该怎么办?

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

    有些人认为显性标签因其在读者眼前而更易于提高可读性和可维护性 .

    有些人认为推断标签更易于提高可读性和可维护性,因为它不会使编辑器变得混乱 .

  • 2

    HTML 5有什么作用?

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

    我该怎么办?

    这是一种风格问题 . 我试着永远不要省略结束标记,因为它有助于我严谨,而不是省略必要的标签 .

  • 48

    如果它是多余的,请将其删除 .

    如果它有用(即使是一个看似微不足道的目的,比如安抚你的IDE或安抚你的眼睛),请把它留在里面 .

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

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

    所以,解决方案是:不要出汗 . 转到实际的东西事项 . :)

  • 57

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

  • -1

    我的建议是省略大多数可选的关闭标记,以及您可以使用的所有可选属性 . 许多IDE都会抱怨,所以你可能无法省略其中的一些,但通常情况下,文件较小,杂乱程度较低 . 如果你有代码生成器肯定会省略结束标记,因为你可以从中获得一些好的大小减少 . 通常情况下,这种方式并不重要 .

    但是当它确实重要的话就行动吧 . 在我最近的一些工作中,通过消除open标签的大多数生成的end和冗余值属性,我能够将渲染的HTML的大小从1.5 MB减小到800 KB,其中元素的文本与值 . 我有大约200个标签 . 我可以完全以其他方式实现这一点,但这将是更多的工作($$$),所以这使我可以轻松地使页面更具响应性 .

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

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

  • 5

    就个人而言,我是XHTML的粉丝,就像ghoppe一样,“我试着永远不要省略结束标签,因为它有助于我严谨而不会省略必要的标签 . ”

    如果你认为包含它们会使文档更容易使用,因为良好形式的概念与有效性相反是一个XML概念,当你使用某些关闭标记时,你会失去这种好处 . 所以唯一的问题就变成了有效性......如果它没有它们仍然有效......你可以节省带宽,不是吗?

  • 1

    使用结束标记可以更容易地处理片段,因为它们的行为不依赖于兄弟元素 . 仅此原因应该足够引人注目 . 有没有人处理单片html文档?

  • -2

    在某些大括号语言(如C#)中,如果只有两行长,则可以省略if语句周围的花括号 . 例如...

    if([条件])
    [码]

    但你不能这样做......

    if([条件])
    [码]
    [码]

    第三行不会是if语句的一部分 . 它会损害可读性,并且很容易引入错误,并且很难找到 .

    出于同样的原因,我关闭所有标签 . 像img标签这样的标签仍然需要关闭,而不是单独的结束标签 .

相关问题