说到底,为什么选择 XHTML 而不是 HTML?

我想知道为什么我应该使用 XHTML 而不是 HTML。

XHTML 应该是“模块化的”,但我还没有看到任何服务器端语言利用了这一点。

XHTML 也更严格,我看不出有什么好处。XHTML 提供了什么我如此迫切需要的东西?它如何使我的代码“更好”?

编辑: 我在评论中发现的另一个问题是: XHTML 的解析速度比 HTML 快吗?

编辑2: 在阅读了你所有的评论和链接后,我确实同意另一篇文章应该是正确的答案,所以我选择了一个直接链接到最好的来源。

同时,这也表明人们甚至没有阅读就对绿色评论投了赞成票。

17609 次浏览

对于一个网站的访问者来说,它可能不会产生任何明显的差异。此外,使用 XHTML 通常更痛苦,因为至少有一个广泛使用的浏览器仍然不知道如何处理它,在这种情况下,您需要将它作为 text/HTML 提供(这会产生无效的 HTML)。

如果您的 HTML 将由自动化工具定期处理,而不是由人类读取,那么您可能希望使用 XHTML,因为它的结构更严格,而且 XML 更容易解析(从应用程序的角度来看)。但这并不是说 XML 天生就容易解析)。

除此之外,我没有看到任何令人信服的理由使用它,虽然。XHTML 是在一种利用 HTML 的 XML 特性的方法中创建的,基本上可以归结为“带有一些恼人的副作用的 HTML 4”(至少是 IMHO)。

看看 http://www.w3.org/MarkUp/2004/xhtml-faq#need,除了模块化之外,还有一些很好的理由。

我喜欢 XHTML,因为它更严格,布局更清晰。HTML 是古怪的,浏览器必须接受像 <b><i>sadasd</b></i>这样的东西。 虽然这是一个非常简单的例子,但是它可能会变得更加混乱,不同的浏览器可能会以不同的方式布局。

另外,我认为 XHTML 必须“更快”,因为浏览器不必进行那种“修复”。

XHTML 强制您保持整洁。

例如,在 HTML 中,您可以写:

<img src="image.jpg">

这不太符合逻辑,因为 img标记永远不会被关闭。然而,在 XHTML 中,您必须整齐地关闭标记,如下所示:

<img src="image.jpg" />

我喜欢用一些能让我保持整洁的东西。

史蒂夫

在我看来,至少在理论上,严格是一件好事,因为在 HTML 中,你不需要严格,而且由于这一点和 HTML5的垃圾,浏览器有先进的错误纠正算法,将最好地利用破碎的 HTML。问题是,算法并不完全一样,会导致你无法预测的奇怪行为。另一方面,对于 XHTML,您通常拥有良好、有效的 XHTML,因此不需要错误校正算法,也就是说,整个 Browser 行为是可预测的。此外,严格的代码使您的工具更容易使用代码。因此,使用 XHTML 实际上不会有什么损失,但是还是有可能获得一些好处的。当 HTML5最终出现时,纯 HTML 的情况会变得更糟,而“你接受什么就开放什么”将导致所描述的奇怪行为。但至少这是一种标准的奇怪行为。唉。

另一方面,如果您使用像 Visual Studio 这样的优秀 IDE,几乎不可能生成破碎的 HTML 代码,因此结果是相同的。

作为一个程序员,你应该非常关心你的代码。

另一方面,XHTML 遵循严格的结构和语法规则,将 HTML 转换成一种合适的语言。

XHTML 对每个人都有好处,因为它将帮助网络发展到每个人(所有浏览器)都能就如何显示网页达成一致的地步。

XHTML 是 XML 的后代,对于为分析语法健全的 XML 文档而构建的解析器来说,这样做要容易得多。

如果您看不到 XHTML 的好处,那么您可以使用 MSWord 来创建 HTML 文档。

一些不同之处在于:

  • XHTML 标记必须正确嵌套
  • 文档必须有一个根元素
  • XHTML 标记总是小写
  • 标记必须始终关闭(例如,在 XHTML 中使用 <br>标记必须在 XHTML 中使用结束标记 <br /><br></br>)

这里有一些关于它的链接

维基 XHTML

Wiki HTML 对 XHTML

XHTML 1.0建议的副标题:

HTML 4在 XML 1.0中的重新表述

目前存在许多处理 XML 的工具。通过使用 XHTML,您可以使用大量的工具对页面进行操作,并以编程方式提取信息。

如果使用 HTML,这也是可能的。现有的工具可以解析 HTMLDOM 树。但是,这些工具通常比 XML 工具更加专门化。您可能找不到与 HTML 兼容的您喜欢的 XML 数据处理工具。此外,现在 XML 有如此多的用途,以至于您可能正在将 XML 用于应用程序的其他部分; 为什么不也使用同一个 XML 解析器来解析您的 Web 页面呢?这就是 XHTML 背后的动机。

如果您对 HTML 4.01已经很熟悉了,那么您已经有了一个使用 HTML 4的已建立的项目,并且没有大量的空闲时间,那么就使用 HTML 4.01吧。如果您有空闲时间,无论如何都要学习 XHTML 1.1,并在 XHTML 1.1中开始您的新项目——这样做没有什么坏处。如果您使用的不是 HTML 4.01,或者对 HTML 4非常不熟悉,那么就学习 XHTML 1.1。

使用带有正确 DocType 的 XHTML 将迫使浏览器以更符合标准(严格)的模式呈现内容。这使得不同的浏览器表现得更好,最重要的是,它们之间更加相似。这使得你作为一个网页开发者的工作变得更加容易,因为它减少了在所有浏览器中使内容看起来相同所需的浏览器特定调整的数量。

QuirkSmode.org 有很多关于这个主题的好信息。

我本来打算把这个作为一个评论添加到其他的帖子中,但是它变得有点太大了。

大多数人似乎都忽略了 XHTML 背后的目的。开发 XHTML 规范的主要原因之一是在标记中不强调与表示相关的标记,而是将表示推迟到 CSS。虽然这种分离可以通过普通的 HTML 来实现,但是规范并没有提倡这种行为。

分离元标记和表示是为“可编程网络”开发的一个重要组成部分,它不仅会提高搜索引擎优化,并为屏幕阅读器/文本浏览器访问,而且还会导致你的网站更容易被那些希望以编程方式访问它的人分析(在许多简单的情况下,这可以消除开发一个特定的 API 的需要,甚至只是允许客户端脚本做一些事情,比如,随时识别电话号码)。如果您的网页符合 XHTML 规范,那么可以使用与 XML 相关的工具和诸如 XPath 之类的东西轻松地遍历它... ... 对于那些希望从您的网站提取特定信息的人来说,这是一个极好的消息。

开发 XHTML 并不是为了自己使用,而是与各种其他技术一起使用。它在很大程度上依赖于对 CSS 的使用,并且为诸如微格式(不管你喜欢还是讨厌它们)之类的东西奠定了基础,以便为常见的数据表示提供标准化的标记。

不要被那些认为 XHTML 无关紧要、限制过多、毫无意义的人愚弄了... ... 它的创建目的似乎是95% 的世界人民忽视或不知道的。

无论如何都要使用 HTML,但是要将其用于它所擅长的地方,并且在查看 XHTML 时采用相同的方法。


关于解析速度 ,我想 XHTML 和 HTML 对实际文档的解析几乎没有什么区别。这种权衡纯粹取决于您如何使用可用的标记来描述文档。由于需要的属性、正确的关闭等原因,XHTML 标记往往会更长,但是会放弃对文档本身中的任何表示性标记的需要。在这种情况下,我认为你是在比较一种苹果,和一种非常微小的不同类型的苹果... 它们是不同的,但是当你想要的只是一个健康、美味的苹果时,它不太可能有任何结果(在解析和渲染方面)。

XHTML 允许使用所有为 XML 设计的工具,其中包括 XSLT、嵌入 SVG 等等。

使用 XHTML

  • 快速 失败。如果有任何不一致,将在验证过程中发现。
  • 它通过将语义标记与表示等分离来鼓励 更好的设计
  • 它是结构化的 ,这意味着您可以将其视为一个数据对象,并对其运行各种查询。例如,您可以在您的网站中找到所有的地址或引用。
  • 你可以做 构建时优化。因为它是格式良好的 XML,所以您可以在构建期间轻松地执行查找/替换操作。或任何文档管理和操作。
  • 您可以编写 XSLT 或其他 转换脚本来以编程方式将您的 XHTML 转换为其他平台。例如,您可以拥有一个针对 iPhone 的 XSLT,它可以转换所有 XHTML,使其与 iPhone 兼容或更加用户友好
  • 您自己就是 未来的证明。将 XHTML 转换为更新的语义也是非常容易使用的转换。
  • 搜索引擎将继续发展,以收集更多的语义信息作为 可编程网络可编程网络的一部分。
  • DOM 操作 更可靠,因为它是结构化的。
  • 从算法的角度来看,它产生 更容易更快的解析

XHTML 是一个很好的站点,因为如果你想要有效的代码,你需要为残疾人社区提供一些帮助,因为屏幕阅读器需要图片和链接标签的 alt 和 title 部分。 解析速度必须更快,因为与 HTML 不同,解析器不需要检查标记是否正确关闭,是否正确嵌套等等。 另外,使用它更好,因为它是严格的,但它有助于您在学习编程语言时更有逻辑地思考(在我看来)。

我相信 XHTML 解析起来更快(或者应该更快)。有效的 XHTML 文档必须写入更严格的规范,因为在解析时错误是致命的,而 HTML 更为宽松,并且允许在我的注释之前提到的奇怪内容,比如乱序结束标记等。我发现这有助于揭示 HTML 和 XHTML 解析之间的区别:

Http://wiki.whatwg.org/wiki/html_vs._xhtml#parsing

可能使用 XHTML 而不使用 HTML 的一个原因可能是,您希望将移动用户作为受众的一部分。如果我没记错的话,很多手机使用的是 XML 解析器,而不是 HTML 解析器来显示网页。如果您正在为桌面浏览器编写代码,HTML 可能是可以接受的。

也就是说,如果要以 text/HTML 形式提供数据,应该使用 HTML:

Http://www.hixie.ch/advocacy/xhtml

我很惊讶这里的所有答案都推荐 XHTML 而不是 HTML。我坚定地持相反的观点——在可预见的将来,您不应该使用 XHTML。原因如下:

  • 没有浏览器解释 XHTML作为XHTML,除非您将其作为 imetype application/xhtml+xml提供。如果只使用默认的 imetype,所有浏览器都会将其解释为 HTML-例如,接受未封闭或嵌套不当的元素。

  • 然而,实际上你不应该这样做,因为 Internet Explorer 不能识别 application/xhtml+xml,并且不能完全渲染页面。

  • XHTML 和 HTML 之间的 DOM 有很大的不同。由于目前所有所谓的 XHTML 页面都是作为 HTML 提供的,所以所有的 javascript 代码都是使用 HTMLDOM 编写的。如果对 XHTML imetype 的支持变得足够重要,足以说服人们开始使用它,那么他们的大部分 javascript 代码将会崩溃——即使他们认为他们的页面可以验证为 XHTML。

使用 超文本标示语言(HTML4或 HTML5)。

  • HTML 可以充分利用 CSS,可以进行验证和明确解析。结构和表示的分离已经在 HTML4中完成,而 XHTML 只是继续这样做。

  • 所有浏览器都支持 HTML。只有一些浏览器支持 XHTML,而那些支持 XHTML 的浏览器通常对 HTML 有更成熟、更好的测试和优化支持(这是由于页面的 很小的一部分使用 XML 模式造成的)。

  • 如果您关心 IE 和 Google,那么您必须使用 HTML 或 XHTML 规范附录 C 中定义的 XHTML 和 HTML 的子集。后者几乎是两个世界中最糟糕的,因为这样的 XHTML 不能用标准的 XML 工具生成,不能使用 XHTML 新的扩展机制,并且比单独使用 HTML 有更多的限制。

  • XHTML1.0现在已经有10多年的历史了,它是在“ Web1.0”时代设计的,正如 W3C 的负责人所说,现在回想起来,这并没有奏效,需要采取更好的方法。W3C HTML5是在我们讲话的时候编写的,它满足了当今 Web 应用程序的需求,并且具有非常好的向后兼容性。

  • HTML5弥补了 HTML4和 XHTML1之间的许多差距(例如增加了内联 SVG,MathML i RDF) ,清理了 XHTML1.0和 XHTML1.1之外的语言。

  • 在可以预见的将来,Web 浏览器不会支持 XHTML2。它很可能会支持 永远不会(所有浏览器厂商都大力支持[ X ] HTML5,有些厂商已经声明他们不会实现 XHTML2)。


XHTML1.0具有与 HTML4.01相同的 没错语义和表示与结构的分离。如果有人不这么认为,那就是 还没看说明书。我鼓励大家阅读规格说明书——它出人意料地短小而无趣。

  • 样式表是在 HTML4.01中引入的,在 XHTML1.0中 没有发生了变化。
  • 表示元素在 HTML4.01中被弃用,在 XHTML1.0中被去除 没有

XHTML 神话


HTML 和 XHTML 之间没有难以处理的差异,这会使解析一个比解析另一个慢得多。这取决于解析器是如何实现的。

  • 为了理解实体,SGML 和 XML 解析器都需要加载和解析整个 DTD。仅此一项工作通常比解析文档本身的工作量更大。HTML 解析器几乎总是“欺骗”并使用硬编码的实体和元素信息。浏览器中的 XHTML 解析器也会作弊。
  • HTML 的解析需要处理隐含的开始和结束标记,而实际的 HTML 需要额外的工作来处理放错位置的标记。
  • 正确解析 XHTML 需要跟踪 XML 名称空间。
  • 严格的 XML 规则要求检查每个字符是否正确编码。HTML 解析器可能不会受到影响,但是 OTOH 需要寻找 <meta>

与下载文档、构建 DOM、运行脚本、应用 CSS 和浏览器必须做的所有其他事情相比,解析成本的总体差异很小。

我建议现在就开始使用 HTML 5,而不是继续讨论 HTML 4.01严格与 XHTML 严格的区别。John Resig,jquery,去年提出了类似的建议的作者,在他的博客上。

HTML5文档类型以其美丽的简单性将在所有浏览器(包括 IE6)中触发标准模式。

<!DOCTYPE html>

就是这样。

HTML5提供了一些令人兴奋的新特性,比如 <canvas>标记,它有可能将 javascript 应用程序开发推向下一个层次。HTML5也有适当的媒体支持(媒体是当今网络的一个相当重要的方面!)以 <video><audio>标签的形式。

如果您喜欢 XHTML 的语法,即关闭诸如 <br />之类的“空”标记,那么在 HTML5中是完全支持的。来自 W3C 的卡尔 · 杜布斯特(Karl Dubost)的文章 了解如何编写 HTML 5:

自动关闭标记是允许的,并符合 HTML 5。

与 HTML5相比,XHTML2受到的关注相对较少。HTML 5是网络标记的未来,这一点越来越清楚。微软最新的浏览器 IE8还是将 XHTML 呈现为 text/xml 作为 text/html。

微软在 W3C HTML 工作组中有一个共同主席,他们对 HTML5有一个隐含的支持。所有的浏览器供应商都已经公开宣布了他们对 HTML5的支持。

最终,即使 XHTML2重新获得了业界的支持,拥有两个相互竞争的标准也不是什么大问题。这两种语言都支持 XML 名称空间(在 HTML 5中,HTML 的序列化即 DOCTYPE 切换)。

您应该阅读 小心 XHTML,它是一篇内容丰富的文章,警告了 XHTML 相对于 HTML 的一些缺陷。

在读到 XHTML 之前,我对它非常热衷,但它确实提出了几个有效的观点。包括以下位;

XHTML 1.x 不是“未来兼容的”。目前处于起草阶段的 XHTML 2与 XHTML 1.x 不向后兼容。XHTML 2将对文档的编写和结构进行许多重大改变,即使您的站点已经使用 XHTML 1.1编写,为了将其转换为正确的 XHTML 2,通常也需要进行完整的站点重写。在大多数情况下,一个简单的 XSL 转换是不够的,因为有些语义不能正确翻译。

HTML 4.01实际上更加兼容未来。编写到现代支持级别的有效 HTML 4.01文档将是有效的 HTML 5,而 HTML 5是浏览器开发人员和 W3C 最关注的地方。

在某些项目中,未来的兼容性可能非常大。这篇文章还提出了其他一些好的观点,但是我认为这对我来说可能是最突出的。

不要把这篇文章误认为是对 XHTML 的激烈抨击,作者确实谈到了 XHTML 的优点,但是在深入讨论之前,最好先了解一下它的缺点。

有趣的发展: XHTML2工作组预计在2009年底停止工作,W3C 将增加关于 HTML5的资源

2009年07月02日: 今天主任宣布,当 XHTML 2工作组章程按计划于2009年底到期时,该章程将不再续签。通过这样做,并通过增加工作组中的资源,W3C 希望加快 HTML 5的进展,并澄清 W3C 对 HTML 未来的立场。FAQ 回答了有关 XHTML 2工作组可交付成果的未来以及与 HTML 相关的各种讨论的状态的问题。了解有关 HTML 活动的更多信息。

我想这让 HTML 的未来变得非常清晰。