您可能不再使用 XHTML,但当您编写 HTML 时,您可能比您想象的更多地受到 XHTML 的影响。您很可能正在以 XHTML 的方式编写 HTML。
什么是以 XHTML 方式编写 HTML,什么是以 HTML 方式编写 HTML?让我们来看看。
HTML、XHTML、HTML
在 1990 年代,出现了 HTML。在 2000 年代,出现了 XHTML。然后,在 2010 年代,我们又回到了 HTML。这就是简单的故事。
您也可以从规范的粗略日期判断出来:HTML “1” 1992 年,HTML 2.0 1995 年,HTML 3.2 1997 年,HTML 4.01 1999 年;XHTML 1.0 2000 年,XHTML 1.1 2001 年;“HTML5” 2007 年。
当每个人都相信 XML 和 XML 派生产品是未来时,XHTML 变得流行起来。“所有事物都用 XML”。对于 HTML 来说,这产生了深远的影响:我们学会了以 XHTML 的方式编写它的影响。
以 XHTML 方式编写 HTML
XHTML 方式有详细的记录,因为 XHTML 1.0 在其关于 “与 HTML 4 的差异” 的部分中对此进行了详细描述。
- 文档必须格式良好。
- 元素和属性名称必须为小写。
- 对于非空元素,需要结束标签。
- 属性值必须始终加引号。
- 属性最小化 不受支持。
- 空元素需要关闭。
- 属性值中的空白处理根据 XML 完成。
- 脚本和样式元素需要 CDATA 部分。
- SGML 排除不可用。
- 具有
id
和name
属性的元素,例如a
、applet
、form
、frame
、iframe
、img
和map
,应该只使用id
。 - 具有预定义值集的属性区分大小写。
- 实体引用作为十六进制值必须为小写。
这看起来很熟悉吗?除了标记 CDATA 内容以及处理 SGML 排除之外,您可能遵循所有这些规则。所有规则。
虽然 XHTML 已经消失,但其中许多规则从未被质疑过。有些甚至被提升为 HTML 的“最佳实践”。
这就是以 XHTML 方式编写 HTML 的方式,以及它对该领域产生的持久影响。
以 HTML 方式编写 HTML
让我们通过否定 XHTML 强加的规则来进行回顾。让我们实际做一下(不包括 SGML 部分,因为 HTML 不再基于 SGML)
- 文档可能不是格式良好的。
- 元素和属性名称可能不是小写。
- 对于非空元素,结束标签并不总是必需的。
- 属性值可能并不总是加引号。
- 属性最小化受支持。
- 空元素不需要关闭。
- 属性值中的空白处理不根据 XML 完成。
- 脚本和样式元素不需要 CDATA 部分。
- 具有
id
和name
属性的元素可能不只使用id
。 - 具有预定义值集的属性不区分大小写。
- 实体引用作为十六进制值可能不只为小写。
让我们删除那些深奥的东西;那些看起来无关紧要的东西。这包括 XML 空白处理、CDATA 部分、name
属性值的加倍、预定义值集的大小写以及十六进制实体引用。
- 文档可能不是格式良好的。
- 元素和属性名称可能不是小写。
- 对于非空元素,结束标签并不总是必需的。
- 属性值可能并不总是加引号。
- 属性最小化受支持。
- 空元素不需要关闭。
剥离这些规则之后,这看起来更像是我们使用 HTML,而不是 XML。但我们还没完。
“文档可能不是格式良好的”意味着,如果 HTML 代码无效,是可以的。XHTML 可以指向格式良好,因为 XML 具有严格的错误处理。但是,虽然 HTML 文档即使在包含严重语法和格式良好问题的情况下也能正常工作,但对于专业人士——以及我们的领域来说,使用和滥用这种弹性都没有用。(我在我的文章 “批判性地捍卫前端开发” 中曾经论证过这种情况。)
因此,HTML 方式不会建议“文档可能不是格式良好的”。同样明确的是,不仅结束标签,而且开始标签也不总是必需的。重新措辞和重新排序,这就是本质
- 开始标签和结束标签并不总是必需的。
- 空元素不需要关闭。
- 元素和属性名称可以是小写或大写。
- 属性值可能并不总是加引号。
- 属性最小化受支持。
示例
在实践中,这看起来如何?对于开始标签和结束标签,请注意,许多标签 是可选的。例如,段落和列表在 XHTML 中是这样编写的
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
<ul>
<li>Praesent augue nisl</li>
<li>Lobortis nec bibendum ut</li>
<li>Dictum ac quam</li>
</ul>
但是,在 HTML 中,您可以使用以下代码(它有效)来编写它们
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.
<ul>
<li>Praesent augue nisl
<li>Lobortis nec bibendum ut
<li>Dictum ac quam
</ul>
开发人员还学会了这样编写空元素
<br />
这是 XHTML 带给 HTML 的东西,但正如 斜杠对空元素没有影响 一样,您只需要以下内容
<br>
在 HTML 中,您也可以用全部大写来编写所有内容
<A HREF="https://css-tricks.org.cn/">CSS-Tricks</A>
看起来您在喊叫,您可能不喜欢,但这样写是可以的。
当您要压缩该链接时,HTML 为您提供了一个选项,即 省略某些引号
<A HREF=https://css-tricks.org.cn/>CSS-Tricks</A>
根据经验,当属性值不包含空格或等号时,通常可以省略引号。
最后,HTML–HTML——不是 XHTML–HTML——也允许最小化属性。也就是说,您可以像这样标记一个 input
元素为必需和只读
<input type="text" required="required" readonly="readonly">
您可以最小化属性
<input type="text" required readonly>
如果您不仅利用了引号不需要的事实,而且还利用了 text
是此处 type
属性的默认值(还有更多此类 不需要的属性-值组合),您将得到一个示例,它展示了 HTML 的全部最小化美感
<input required readonly>
以 HTML 方式编写 HTML
以上内容不是对 HTML 在 90 年代状况的表示。当时的 HTML 充斥着用于布局的 <table>
元素,充满了表示性代码,在很大程度上是无效的(就像今天一样),用户代理支持差异很大。然而,这是我们希望在 XML 和 XHTML 出现之前保留的本质。
如果您愿意接受对更全面、现代的 HTML 编写方式的建议,我有一个建议。(HTML 是我的主要关注领域,因此我通过一些文章的链接来补充这一点。)
- 尊重语法和语义。
- 验证您的 HTML,并且只发布有效的 HTML。
- 使用 HTML 提供给您的选项,只要您始终如一地使用即可。
- 请记住,元素和属性名称可以是小写或大写。
- 将 HTML 的使用保持在绝对最小限度
- 请记住,表示性和行为标记应由 CSS 和 JavaScript 处理。
- 请记住,开始标签和结束标签 并不总是 必需的。
- 请记住,空元素不需要关闭。
- 请记住,某些属性具有默认值,这使得 这些属性-值对可以省略。
- 请记住,属性值 可能并不总是 加引号。
- 请记住,属性最小化受支持。
这与 HTML 的三大基本规则 相似,与 更小的负载也会导致更快的网站 的前提一致,并且遵循 最小化 Web 开发理念。所有这些都不是什么新鲜事物——我们的领域可以仅仅决定重新发现它。工具也是可用的:html-minifier 可能是最完善的,并且能够处理所有 HTML 优化。
您已经以 XHTML 的方式学习了 HTML。HTML 不是 XHTML。重新发现 HTML,并帮助塑造一种新的、现代的 HTML 编写方式——它承认 XML,但不一定基于 XML。
我的旅程始于
<marquee>
和<table>
作为网页布局方法的“黑暗”时代,因此我赞赏像 HTML 一样编写 HTML 的怀旧感。但是,我不会建议采用所有这些建议。
如果不有意地告诉代码检查器忽略它们,没有正确使用结束标签(或空元素)会导致错误。
我也不会推荐省略引号,因为...它没有任何好处。
文件大小并没有减少到任何有意义的程度。
您正在引入HTML中可能的故障点,使可维护性成为潜在问题。
您正在绕过一个标准,该标准可被编辑器/代码处理器用来更容易地区分属性/值,这可能会导致代码扫描出现问题。
我强烈不同意省略默认值的说法,因为这再次造成了可维护性问题(以及在某些浏览器中可能出现边缘情况问题?)。
<input>
不如<input type="text">
清晰,作为开发人员,您需要记住您可能不是唯一一个在项目上工作的人。如果省略 12 个字符会导致对HTML实际渲染内容的理解产生混淆,那么通过省略这几个字节并没有什么用处。….
回到过去,全大写HTML似乎是标准,我记得当时的论点是它更易读/更容易区分HTML和内容。
我认为,几乎所有现代编辑器中实现的代码颜色功能使这个论点变得毫无意义,全大写实际上只是个人喜好问题。
….
我完全同意避免冗余,比如
disabled="disabled"
。对我来说,这种属性声明感觉不那么易读...可能是因为我被要求把它解析为“已禁用已禁用”,这只会让我的眼睛抽搐。虽然我乐意将这些功能用于压缩,但实际编写代码需要它易读且可预测,因此所有“你可以跳过 X”都变成了“即使语法允许,你也不能跳过 X”,关闭标记和属性的一致性使得人类更容易处理,即使机器不在乎。
在源代码中多一点冗余会让您未来的生活变得更轻松。
您一直在说HTML,但您应该说SGML。编写HTML有两种方法:作为SGML或作为XML。两者在HTML5中都是有效的。
XHTML不是“不是HTML的方式”,它只是不是SGML的方式。
同样,XML本质上是SGML的一个更严格的子集。
您所说的Linux实际上是GNU + Linux等等等等
抱歉,但我强烈不同意结束标签不是必需的说法。考虑这种情况
结果应该是什么并不直观。
<div>
是一个块元素,所以<ul>
会在它之前终止,对吗?错了。<div>
嵌套在最后一个元素下面。好吧,<strong>
标签必须在它之前终止,对吗?错了!所有后续内容都是粗体。省略结束标签会导致混乱并引入问题。从概念上讲,这是可能的,但在实践中,应该永远不要这样做。好吧,但我们为什么要这样做?有什么好处?
HTML对整体页面大小的贡献非常小,这种“现代”的编写方式使得页面更难处理。
我年纪大了,学的是HTML的HTML方式,后来转到XHTML方式,因为我更喜欢它,但我愿意被说服。
想法很好。
但是,特别是没有关闭
<br>
标签会导致额外的空格被添加到元素的firstChild
文本节点中。当您在由 CSS 样式化的<br>
标签所在位置添加换行符时,也会出现相同的问题,您将在元素之间得到您不希望看到的视觉间距。例如,按钮标签末尾的图标与文本之间的空格会比其他情况稍大。但在这种情况下,这是完全可以避免的 - 因为省略关闭标签会导致额外的空格和换行符被解析为该元素的一部分。
我同意其中一些部分(比如最小化属性),但强烈反对其他一些部分。
省略属性的引号,特别是对于URL,是一个糟糕的想法。仅仅因为你可以,并不意味着你应该这样做。一致性往往比完全的极简主义更好。
我的意思是,您不必在JavaScript中使用换行符,但如果您不使用任何换行符,它将变得难以阅读。分号也是一样,我更喜欢始终使用它们;一致性胜过最大限度的极简主义。
同样,对空元素使用斜杠只是使它们更易读(在我看来);即使计算机不在乎它们,它们也仅仅是为了我们这些愚蠢的人类而存在。
随便怎么说吧,我将始终对没有关闭标签的元素使用自闭合标签。我的强迫症不允许我对一个开始标签和没有结束标签的指示感到满意。
哎呀。我不想回到标签有时关闭有时不关闭,有时大写有时不写大小写的HTML。那些HTML文件看起来很糟糕,应该被淘汰。就像js逐渐被typescript取代一样,我真诚地希望w3c能对HTML应用类似的代码质量机制。
请不要鼓励人们编写糟糕的代码,仅仅因为它可以实现。有了构建链和HTML优化器,这些就不是必需的了,而且只会训练新的web开发人员不关心,并像1990年一样编写代码。请不要。
这些是个人语法偏好,被冠以“最佳实践”的名称,而这种主题贯穿了支持文章。
我同意你的一些偏好,并且很高兴地提醒我们有多种有效的选项。但现实是,它们 *根本不重要*。
没有人通过省略关闭标签,将一个缓慢的网站变成了一个快速的网站。压缩HTML在性能优化列表中的位置非常靠后,以至于除了像谷歌搜索页面那样的超高度优化的东西之外,它几乎不存在。
出于对极简主义或优化的热爱,这样做完全是有效的。也许其中一些会使您的代码更易读。
我认为性能论点具有误导性。您用客观性的外表掩盖了主观的东西。
这些做法也有一些缺点。其中之一是记住你不必记住的东西带来的心理负担。我宁愿把头脑装满诗歌,也不愿记住何时可以省略HTML属性引号的规则。坦率地说,谁在乎呢?始终引用它们,然后继续你的生活。
再说一次,关心这件事并没有错,因为你发现它很有趣。我们都是以不同的方式成为极客,让我们为此欢呼!但这不同于说服正在工作的开发人员去关心。享受你的爱好,但最好不要把它作为那些只想工作的人的实际交通工具。
当然,您可以使用工具来为您完成这些工作。我不喜欢说在使用工具之前必须了解所有规则的心态。工具不仅自动化重复性任务,它们还让我们免于学习不相关的奥秘的苦差事。它们让我们依靠他人的专业知识 - 就像你!
再说一次,对于许多网站来说,考虑到压缩HTML几乎没有性能优势,添加工具是否值得怀疑。这可能取决于它在您现有设置中的添加难易程度。
简单性很少像极简主义者喜欢的那样简单。简化一个维度,您通常会使另一个维度复杂化;完美主义往往会增加整体复杂性。
我不认为我会一直习惯在我的列表中不使用结束标签!
很棒的阅读,但我只会把它交给
Pug
来为我格式化所有内容。读完这篇无政府主义宣言后,我的基本理解是:仅仅因为你可以,并不意味着你应该这样做。总体而言,XHTML是一个改进,并且节省几个字节不值得在编写html时失去可读性。
我认为XHTML太严格了,而且为了一个微不足道的收益付出了高昂的代价,但它确实有道理。可读性在任何语言语法中都很重要(很多)。强制执行不会是答案,但我认为鼓励诸如始终关闭标签和不压制默认参数之类的做法会对代码的可读性有很大帮助(同样,非常重要)。
再说一次,我认为强制执行代码风格不是答案,但鼓励更易读的代码始终是一件好事。
我遵循其中的大部分,是的。除了几个
关闭空标签。2012 年的时候我经常这样做,因为存在兼容性问题。
我还做了一些XHTML的方式,因为它更简单
所有十六进制实体引用必须是小写,无论是颜色代码还是ID,保持它们全部小写更容易管理。
抱歉,我不能同意大部分内容。使用XHTML语法,我可以直观地检查源代码并看到适当的结构。我并不总是能够访问验证HTML的工具。
对我来说,XHTML更自然,因为它要求大多数元素有开始和结束。对于空元素,/ 表示它的结束。对于那些来自后端语言甚至Javascript的人来说,这也带来了一些理智,因为这些语言的语法要求有开始和结束标记。
我偶尔仍然会使用name属性,因为该规范是一个属性,而不是与元素的开始和结束有关。但是,CSS选择器和Javascript API的一部分使用ID属性,因此这可能是name属性不受欢迎的原因,除了表单之外。
我认为像这样的文章,虽然无意中描述了HTML5的真实规范,但实际上是在规范化不良实践。
例如,为了节省几个字节而删除属性引号,将会导致比继续遵循 XHTML 规范更多的问题,尤其是在如今属性通常是动态注入的情况下。
同样,删除闭合标签会导致难以预料的问题,尤其是当 HTML 代码超过几行或由多个开发人员共同工作时,而且你无法确定它是应该嵌套还是仅仅是一个错误。
在 2000 年代初,每个人都更喜欢 XHTML是有原因的。我们不应该忘记那些原因。
不幸的是,许多非浏览器解析器确实期望可选和闭合标签。例如,Bing 期望可选的 head 和 body 标签,否则它可能无法读取某些元数据。一些链接预览器也会失败。
可选的闭合斜杠、引号等完全没有必要,应该由典型的 HTML 压缩器来处理。
XHTML 的很多要点实际上很有道理。你并不“必须”在 HTML 中关闭一个元素,但知道它在哪里结束会有所帮助(但人们并不真正理解 HTML 中“元素”的概念)。
XHTML 影响的一件事是,它从未消失,而且在 web 开发世界中根深蒂固,那就是在 CSS 中将 HTML 元素选择器类型化为小写。这源于 XHTML 规定在 HTML 中,HTML 元素名称最好是小写,但如果你想将文档验证为 XML,则必须是小写,如果你这样做,你就必须在你的样式表中将对它们的引用也写成小写,否则 HTML 中的元素与其在 CSS 中的对应元素匹配将不会起作用。正因为如此,web 开发世界中的每个人都开始在他们的 CSS 中将 HTML 元素引用写成小写,即使它并不需要,即使它会让样式表的可读性降低,即使很少有人知道他们为什么要这样做,而且没有人愿意改变。
当你看到
#header UL LI A:link
很容易快速地判断出 UL LI A 指的是 HTML 元素,而下面的代码则不然
#header ul li a:link
尤其是在筛选大量的 CSS 代码时。然后,当这种混乱发生时,开发人员更难理解 ID、元素、类等之间的区别。然后这种混乱让开发者更容易接受 DIV 汤。
有争议的东西!我心中的强迫症拒绝这样做。
我很想看到将 XHTML 写法转换为 HTML 写法的 VS Code 插件。
是的。当我本能地感觉到它毫无意义时,VSCode 的 html 代码校正让我抓狂。
我想用 HTML 的方式来写 HTML,但我的 IDE 一直在对我大喊大叫。;) 默认的代码样式设置似乎总是 XHTML-HTML。
我可能已经过时了(我在 90 年代初学习 HTML,并在 2000 年代初用它赚到了我的第一笔佣金),但我发现学习和尊重 XHTML 的理念可以帮助你成为更好的前端开发人员,因为它不那么草率,更可预测。仅仅因为 HTML 更宽容,并不意味着我们应该降低我们的标准。这就是我对这件事的看法。
我觉得压缩过的属性已经成为标准。但是可选的闭合标签对我来说就像 JavaScript 中的分号一样。是的,有些人没有使用它,并一直注意情况,但对我来说,这会损害代码的可读性。
我记得我发现了一个奇怪的边缘情况,一个库没有生成
</li>
标签,添加<!doctype html>
导致我正在处理的网站布局崩溃。我只是修复了库以生成</li>
标签,就解决了这个问题。我喜欢避免使用
<head>
等标签,因为我知道浏览器很聪明,会自动添加这些标签,而且我没有为机器人制作网站来垃圾邮件我的评论表单,但总的来说我会关闭我的标签。如果某些机器人因此而崩溃,那么这个机器人就是一个实现得很糟糕的机器人,很快它的开发者就会发现这一点,因为他们会发现一个使用 HTML 压缩器的网站(本文中提到的一个网站每周有 390 万次下载)。我仍然使用<html>
,因为lang
属性。奇怪的是,我看到更多的人关闭自闭合标签(如
</link>
和</br>
),因为 Firefox 在 `view-source:,` 中将它们突出显示为错误,而不是相反。好吧,很多人也忘记关闭非自闭合标签:Firefox 也会突出显示这些错误,而且我见过很多次。我认为“用 HTML 的方式写 HTML”并不会让它变得更好,另一方面,我认为它会让它变得更不安全。使用 XHTML 式的规则可以让非浏览器解析器、linter、html 格式化程序以及许多其他工具更容易处理代码。
感觉好像摆在我们面前有两个选择,写一个更具声明性和可读性的代码,它可以工作,或者写一个更小、更灵活的代码,它也(可能)可以工作,而且我并没有真正看到任何好处。
我已经经历了整个过程,甚至还记得看到
<option>
可以关闭的时候我很震惊!我同意,XHTML 的约束有点过头了,但在我看来,它对 HTML 产生了很大的益处。它带来了更简洁的代码,更少的解释空间,以及更高的一致性。
浏览器非常宽容,但这并不意味着我们必须突破这些界限,除了更轻的代码(这仍然很重要,但考虑到你除了它之外还发布了 JS 库……),它们几乎没有带来任何其他好处。
一致性绝对是关键,你想怎么做就怎么做,但至少保持一致!
好文章。我还没有真正考虑过这个问题。这也是你的观点。:-)
关于英语语法的一个说明,“文档可能不是格式良好的”,这是一个模棱两可的结构。它听起来像是文档不能格式良好是违法的。也许是“文档不必格式良好”,或者“文档可能是格式不规范的”。
很棒的文章!关于不关闭标签的部分让我想起了那些在没有分号的情况下编写 JavaScript 的人。是的,它可以工作,但我认为这只是野蛮的 ;-)
极简主义并不总是最好的选择。我很乐意为项目代码的可读性(从而提高可维护性)多花一些字节。这同样适用于 HTML、CSS 和 JS。
可以在构建过程中设置一个压缩器,这样你就可以在仓库中保留 XHTML-HTML,并只发布干净的 HTML-HTML——这就是我所做的,而且我很开心 ;)
不过,有一个重要的注意事项,你可能需要了解。
在语义上,与
在第二种情况下,图像在技术上是段落的一部分。如果你不小心,它也会影响你的演示效果。
很棒!就我个人而言,你写的越少越好!
恕我直言,我认为“严格”的约定往往会使代码更具可读性。将代码压缩到不明显它做什么的地步,可能会减少几个字节,但代价是可读性大大降低。
对我来说,XHTML 更有意义;不是因为它与 XML 兼容(虽然这是一个巨大的优势);而是因为它意味着有一套你可以始终遵守的规则,以获得有效的代码。当你开始说“实际上 HR 不需要(自)闭合标签”时,你就开始需要记住一系列“这些规则适用于这些东西,但不适用于这些东西,除非你在这种情况下,在这种情况下,你可能还需要这样做……”;即不必要的混乱和复杂,而不是简单的统一性。
XHTML 方法有一些不好的地方;例如,
'readonly="readonly"'
是一个同义反复;为什么不使用'readonly="true"'
……仅仅添加'readonly'
还算可以(它更简洁,如果默认值总是 false,它就很清楚),但这又是矛盾的,所以与其让它等于什么,我宁愿接受它的占用空间。我很好奇,全球到底有多少时间花在了 HTML 设计讨论上,而这些时间本可以被节省下来,方法是说“让我们遵循通用规则”,从而将时间投入到更富有成效的讨论中,例如创建新功能/增加价值。
关于 xhtml 和 html 的一个很好的概述,
缺少的一个元素是通过代码结构来提及 xhtml 页面“硬层次结构”。
在 xhtml 中,标签不能交叉
文本 A
文本 B
[ 因为规则,我无法使用粗体标签来演示 html 和 xhtml 中交叉标签 ]。
文本 A 和文本 B 在 html 中可以显示“粗体”,但在 xhtml 中不行。这对有效的样式工具来说是一个小损失。
页面中需要一个约束:doctype,因为你没有写它,你的页面会进入“怪异模式”,这对浏览器中的所有代码都是一个很棒的工具。
在“怪癖模式”下,由于页面残留的显示方式,没有人可以偏好 xhtml 或 html。
这对所有正在工作的程序员来说是一个巨大的开放大门,无论他们是初学者还是专家。它是一种灵活的代码,可以编写和阅读。
你可以通过删除标签中间的部分来玩 html/xhtml,看看显示和渲染是否仍然正常工作。(它允许性很强,格式不正确,但处于怪癖模式)。
xhtml 已经摒弃了 sgml 风格,并在前面使用开闭标签,因此可读性提高了(因为“代码区域”的开始和结束也是如此)。
然后单标签需要 / : “” 作为闭合。
xhtml 最初是“xml 数据”集成的基础,它是 xml 支持的布局,以及所有 xml 衍生品。
现在的浏览器可以处理很多种编码方式!
大写字母很安静!真的!
感谢您的工作。
我会坚持使用 XHTML 方式,谢谢。我并不支持将松散作为 Web 语言的最初想法。作为管道和机器可读性的粉丝,我非常喜欢 XHTML 的一致性和兼容性。我唯一想念 HTML 方式的东西是属性最小化。
我在 30 年的编码生涯中学到的一件事:代码应该尽可能保持一致。
一致性比特殊规则更容易。我不想记住哪些标签需要闭合。我不想注意可能错误的语法。为什么有人想写大写标签?可读性?这就是语法高亮的功能。
通用规则意味着更少的记忆负担。更少的决定要做出。更少的错误。
每次你使用特殊规则时,你都必须向新的团队成员解释这些规则,而他们每次都会理解错误。
虽然原则上,只使用 HTML 更简洁,但实际上它做了一堆假设。要正确验证它,需要了解所有可能的元素及其可选规则,包括浏览器特定的扩展。否则,我们就会回到过去,当时大多数浏览器都不得不非常宽容地对待当时盛行的糟糕的 HTML 代码。浏览器试图通过猜测作者的意图来解决所有问题,但这并不总是正确的。至少使用正确的 XML 格式,任何文档都可以进行结构验证/解释,而无需了解特殊规则(无论好坏)。虽然扩展元素的使用不像 HTML4/5 标准之前的那么糟糕,但仍然需要考虑到它们。
不过,就我个人而言,当他们使用“html”作为标准的万能 DOCTYPE 时(而不是至少使用“html5”),我对它的标准化失去了信心。
少即是多 - 代码越少,前端和后端的运行速度就越快。
我从未理解为什么要在列表上添加闭合标签 - 所以我不加。我也没有为 br 或 hr 标签添加反斜杠。
使用 strong 而不是 b 来表示粗体,或使用 em 而不是 i 来表示斜体,仍然没有意义。
我认为还有更多类似的情况。或者,是 IMHO。哈哈
我的天哪,我在一个 Discord 频道里因为冒险尝试不闭合标签而被喷了一堆。我的代码仍然验证通过。从一群歇斯底里的群众那里得到的谩骂 - 我就离开了。感谢这篇文章。我喜欢语义 HTML。从 XHTML 的时代过来..(我已经 5 年没有接触 web 设计了)现在有意识地决定如果不需要就不要闭合标签 - 这样可以更加专注。我不知道引号的事,也会把它们去掉。我总是验证我的 HTML,一直都是。