归根结底,为什么选择XHTML而不是HTML?[关闭]


77

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

XHTML应该是“模块化的”,但是我还没有看到任何服务器端语言可以利用其中的任何一种。

XHTML也更加严格,我看不出它的优势。XHTML提供了我急需的什么功能?它如何使我的代码“更好”?

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

EDIT2:在阅读了所有评论和链接之后,我确实同意另一篇文章应该是正确的答案,因此我选择了直接链接到最佳来源的文章。

此外,这表明人们甚至没有阅读绿色评论就对它发表了评论。


12
+1我很想知道现代浏览器是否可以更快地解析它,因为常规HTML的混乱程度较小,它们只能使用常规XML解析器。
多米尼克·罗杰

好问题; 我认为我的意见不值得回答,但我认为大多数时候都在浪费时间。做兼容的HTML并称之为一天。
Paolo Bergantino,

4
每次我参与XHTML时,我希望HTML5会有所吸引...
annakata,2009年

1
这个问题已经问了好几次了,例如,在“相关”列中看到(当前)顶部链接……
PhiLho

2
@WebDevHobo:请重新考虑更改已接受的答案,因为它没有任何可靠的消息来源支持,并且有消息来源对此予以
Kornel

Answers:


47

您应该阅读“当心XHTML”,这是一篇内容丰富的文章,警告有关XHTML优于HTML的陷阱。

在阅读XHTML之前,我对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的优点,但是在您深入之前要意识到这些缺点是一件好事。


3
一篇不错的文章和道具,向您展示给我们。
2009年

9
XHTML 1.x是“未来兼容的”。XHTML 2工作组的章程现已到期。-现在已经取代由XHTML5
Casebash

3
html5不是xhtml。xhtml将会死亡,xhtml2将永远不会消失
Neil McGuigan

1
@MrLister您的意思是XHTML实际上会捕获语法错误并发出信号,而不是无声地纠正它们并在代码中留下潜在的错误这一事实?
娜雪(Nayuki)

1
@Nayuki XHTML5(与HTML5或更早版本的XHTML不同)无法识别实体名称,例如 é。因此,我将所有XHTML文件都保留在XHTML 1.1中。
李斯特先生,

39

我打算将其添加为其他帖子之一的评论,但是它变得太大了。

大多数人似乎缺少的基本点是XHTML的目的。开发XHTML规范的主要原因之一是在标记中不强调与表示相关的标签,并将表示推迟到CSS。虽然可以使用纯HTML来实现这种分离,但规范并未促进这种行为。

分开元标记和表示形式是开发“可编程网络”的重要组成部分,不仅会改善SEO,并改善屏幕阅读器/文本浏览器的访问权限,而且还会使那些希望以编程方式访问它(在许多简单情况下,这可以消除开发特定API的需要,甚至可以只允许客户端脚本执行诸如轻松识别电话号码之类的操作)。如果您的网页符合XHTML规范,则可以使用与XML相关的工具轻松地遍历该网页,诸如XPath之类的东西对那些希望从您的网站中提取特定信息的人来说是个好消息。

XHTML不是为使用而开发的,而是与其他各种技术一起使用的。它在很大程度上依赖于CSS的表示形式,并为诸如Microformats(无论您是喜欢还是讨厌它们)之类的东西奠定了基础,从而为通用数据表示提供了标准化的标记。

不要被认为XHTML无关紧要,过于严格和毫无意义的人群愚弄……它的创建目的是让全世界95%的人似乎忽略/不知道。

一定要使用HTML,但是要使用HTML来实现其优点,并且在查看XHTML时应采用相同的方法。


关于解析速度,我认为XHTML和HTML之间的实际文档解析几乎没有差异。权衡将完全取决于您如何使用可用的标记来描述文档。由于必需的属性,适当的关闭等原因,XHTML标记往往会更长一些,但是会放弃对文档本身中任何表示性标记的需求。在这种情况下,我认为您正在谈论的是将一种类型的苹果与类型稍有不同的苹果进行比较...它们是不同的,但不会有任何后果(就解析和渲染而言) ),那么您想要的只是一个健康美味的苹果。


14
尽管XHTML的目标值得称赞,但浏览器供应商在XHTML或CSS方面都表现不佳。正确的XHTML当前使Web开发变得更加困难。当工具和浏览器的供应商改变这种情况时,也许我们将能够开始看到一些好处,但是最能受益的不是站点开发人员,而是SE供应商。想象一下,能够将您的网站中收集到的丰富而有意义的信息呈现到网站本身不需要访问的程度吗?您的广告收入会怎样?您认为住在象牙塔中的人是谁?
AnthonyWJones

1
良好的抗辩论点;我明白了您的意思,但是隔离点并不完全与XHTML相关,因为您可能会说RSS提要已经做到了。但是,人们仍然访问网站,因为许多人不喜欢通过提要阅读。关键是允许更轻松地访问数据并在语义上进行标记,而不是将其隐藏在与表示相关的,格式不正确的标签中。使您的网站易于访问且对处理“有意义”只是对您的好处。关于浏览器渲染标记。我可以同意,但首先请向我展示HTML呈现的一致性。
詹姆斯·B

3
总结的总结是,XHTML的互操作性优势受到浏览器供应商不足的威胁。
annakata

6
将表示与标记分离是一个目标,它使用严格的doctype早于XHTML。HTML 4确实淘汰了表示性标记,而倾向于结构性标记。仅仅因为几乎每个人都使用HTML 4 Transitional并不意味着它是一个好主意,甚至不被规范所推荐。除此之外,您没有得到真正的分离,因为您几乎总是必须根据自己的风格来调整标记。CSS Zen Garden很不错,但是对于某些CSS效果,您需要多层<div> s。这并不是将样式和内容组合完美地分离。HTML和XHTML非常相像这里
乔伊

2
这个概念早于XHTML,但是XHTML却将其作为优先事项,并且该规范试图对它进行某种形式的严格控制。HTML4对表示和标记分离的“支持”充其量不过是草率的。<div>不是表示性标签,它们用于按逻辑方式划分信息。仅仅因为未正确使用它们,并不意味着XHTML规范将以任何方式失效。XHTML比HTML鼓励更好的做法,并且对不良语法的要求更为严格。对于那些希望开发基于标准的Web的人来说,这是双赢的局面。
詹姆斯·B

18

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

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

除此之外,我看不出有任何令人信服的理由使用它。XHTML的创建方法是利用XML的XML功能,基本上可以归结为“具有一些烦人的副作用的HTML 4”(至少是IMHO)。


5
+1。我完全同意。XTHML是居住在象牙塔中的委员会进行开发的另一个示例(CSS是我想到的另一个示例)。
AnthonyWJones

2
完全同意XHTML,但是CSS的发展一直很好,直到他们最近才决定让浏览器供应商确定标准是什么之前。CSS的问题在我看来是100%供应商的错。
annakata

10
我从根本上不同意这里提出的论点。我本来要发表评论,但是评论太大了,成为了答案(如下)。XHTML规范。并不是为了简化解析而开发的(尽管这样做确实做到了),而是为了支持各种技术,这些技术包括比HTML所允许的更完整的结构。也许是由象牙塔中的人开发的……但是,当您从整个Web角度查看事物时,该规范变得更加有意义。
詹姆士·B

3
我猜所有对该文章的支持都表明两点:1.许多人确实还不了解XHTML(请参阅James的回答),以及2.由于其有用性,对此感到非常沮丧。谁该怪?我猜想XHTML的“公开性”确实非常糟糕。
康拉德·鲁道夫

1
@Konrad:毫无疑问,XHTML很有用,但是那些被推崇的可能是:1)正如您所说的那样,沮丧的是,实际上XHTML必须(当前)必须用作HTML!2)仅向人类用户输出简单信息,而不针对外部解析器,并且不需要模块化或其他高级功能(命名空间...)。
PhiLho

16

使用HTML(严格的HTML4或HTML5)。

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

  • 所有浏览器都支持HTML。只有某些浏览器支持XHTML,而那些浏览器通常支持XHTML,并且它们对HTML的支持更加成熟,经过了更好的测试和优化(这是因为一小部分页面使用XML模式)。

  • 如果您关心IE和Google,则必须使用HTML或XHTML的子集以及XHTML规范的附录C中定义的HTML。后者几乎是两全其美,因为无法使用标准XML工具生成此类XHTML,不能使用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名称空间。
  • Draconian XML规则要求检查每个字符是否正确编码。HTML解析器可能会避免这种情况,但是他们需要寻找OTOH <meta>

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


13

我很惊讶这里所有的答案都推荐XHTML over HTML。我坚决持有相反的意见-在可预见的将来,您不应使用XHTML。原因如下:

  • 除非您将其用作mimetype,否则没有浏览器会将XHTML解释XHTML application/xhtml+xml。如果仅使用默认的模仿类型提供服务,则所有浏览器都会将其解释为HTML-例如,接受未闭合或嵌套不正确的元素。

  • 但是,您绝对应该这样做,因为Internet Explorer无法识别application/xhtml+xml,并且将无法完全呈现页面。

  • XHTML和HTML之间的DOM有显着差异。由于目前所有所谓的XHTML页面都将用作HTML,因此所有JavaScript代码都是使用HTML DOM编写的。如果对XHTML模仿类型的支持变得足够重要,足以说服人们开始使用它,那么他们的大多数javascript代码都会中断-即使他们认为自己的页面可以验证为XHTML。


1
这几乎不是重点...好像没有人使用过它,它将如何成为公认的标准?有很多变通办法,就像有大量的Web新兴技术一样(糟糕的是,即使具有透明性的PNG在IE中也需要变通办法)。
詹姆斯·B

5

我不建议继续讨论HTML 4.01 Strict与XHTML Strict,而是建议立即开始使用HTML 5。jQuery的作者John Resig去年在他的博客上提出了类似的建议

HTML 5 doctype以其精美的简洁性将在所有浏览器(包括IE6)中触发标准模式。

<!DOCTYPE html>

而已。

HTML 5提供了一些令人兴奋的新功能,例如<canvas>标记,可以将javascript应用程序开发推向新的高度。HTML 5还以<video><audio>标记的形式对媒体提供了适当的支持(如今,媒体是Web上相当重要的一部分!)。

如果您喜欢XHTML的语法,即关闭诸如<br />HTML之类的“空”标记,则HTML 5完全支持。从W3C的帖子的Karl Dubost学习如何编写HTML 5

自动关闭标签是允许的,并且与HTML 5一致。

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

Microsoft是W3C HTML工作组的联合主席,并且隐含了对HTML 5的支持。所有浏览器供应商都公开宣布支持HTML 5。

归根结底,即使XHTML2重新获得了业界的支持,与过去一样,拥有两个相互竞争的标准也不会是一个重大问题。两种语言都支持XML名称空间(在HTML 5的情况下,HTML的序列化即DOCTYPE切换)。


忍不住同意HTML5确实是一个非常有前途的标准。我确实希望它的性能比XHTML2规范更好。
詹姆斯·B

1
不过,不关闭标签会使我感到肮脏。
2009年

2
@WebDevHobo,您可以关闭标签,它们仍将根据HTML 5正确验证-这是规范的一部分。我本人也喜欢这种方式(有关引用,请参见发布的最新信息)。
巴亚德·兰德尔

4

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

我赞成XHTML,因为它更严格且布局更清晰。HTML很古怪,浏览器必须接受<b><i>sadasd</b></i>。尽管这是一个非常简单的示例,但它也可能引起更多混乱,并且不同的浏览器可能会以不同的方式布置事物。

我也认为XHTML必须“更快”,因为浏览器不必进行这种“赔偿”。


浏览器不具备接受不当嵌套标签(您的例子是无效的HTML),但他们做的-因为作者使用它们,并且在用户抛出错误,而不是渲染页面是无益的。即使充当application / xhtml + xml,许多浏览器如果遇到格式错误,也会切换到text / html模式。
昆丁

<b>和<i>标记在演示性方面也已弃用在html中。<strong>和<em>是语义等效项。
巴亚德·兰德尔

@Bayard:尽管<b>和<i>只是演示性的,但并未被弃用。w3.org/TR/REC-html40/present/graphics.html#edef-B(在XHTML和HTML5中均未更改)。当然,如果其他元素更合适,则不应该使用它们,但是HTML并没有包含所有元素,并且对斜体字使用<em>也是错误的。
Kornel

3

一些区别是:

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

这里有一些链接

Wiki XHTML

Wiki HTML与XHTML


“#XHTML标记总是小写#标记必须总是关闭(例如,在XHTML中使用<BR>标记在XHTML中必须具有结束标记<BR />或<BR> </BR>)”为什么您<br / >大写?
安东尼·卡西,

......这是一个忙碌的一周!;)好地方,我已经编辑过了。
kevchadders,2009年

1
HTML元素也可以正确嵌套。有时,开始标签或结束标签是可选的或被禁止的。HTML文档必须具有一个根元素。
昆丁

2
问题不在于差异,我想海报者知道它们之间的差异
PhiLho

2

作为程序员,您应该非常担心自己的代码。HTML很丑陋,并且遵循一些规则。

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

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

XHTML是XML的后代,在为分析语法上合理的XML文档而构建的解析器中,XHTML更加容易。

如果您看不到XHTML的好处,则不妨使用MS Word创建HTML文档。


4
HTML具有非常严格的语法和语义规则。它们只是与XML不同。您可能需要阅读规范:)
乔伊(Joey)

HTML4有。HTML5具有纠正错误的规则(或者至少有很多人希望它具有纠正错误的规则),即不再具有严格的句法和语义规则。HTML4的问题在于,浏览器已经纠正了错误,使“严格语法”成为一个笑话。
OregonGhost,

2
“如果看不到XHTML的好处,那么不妨使用MS Word创建HTML文档。” ....真的吗?
Paolo Bergantino,

我知道HTML 4.1的规范,但我不认为这就是WebDevHobo的要求。大多数人没有意识到HTML 4.1是一个规范,因此他们像上面的<b> <i>错误</ b> </ i>那样编写所需的代码。另外,我从未说过它没有规则,只是规则更少。请修改-1,因为此参数更多地是关于使用标准,而不是存在html标准(请告诉IE6)。
安东尼卡西

2
您说HTML很丑...我说XML / XHTML同样丑而且比较冗长,因此它传播了更多的丑味。更重要的是,我仍然看不到会阻止浏览器供应商“友好”并尽最大努力(不兼容)来处理不兼容的XHTML的方法,就像他们现在使用HTML一样,并为我们提供了MSIE6-for-XHTML再次。
戴夫·谢罗曼

2

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


SVG在理论上是不错的选择,但是大多数网页都涉及到SVG的MSIE问题。(并且正在进行用HTML5描述SVG的工作)
Quentin

我不会说允许,但是会更容易。HTML允许通过<object>和data:URI进行SVG(虽然不太漂亮,但可能)。XSLT可以输出HTML,并且有一些工具可以解析HTML并将其传递给XSLT处理器(例如,在PHP中,您只需将loadXML()更改为loadHTML()即可使用)。
Kornel

Gecko上的数据URI中的SVG不允许使用任何样式(错误308590),这使它成为一种无法启动的样式。

2

有趣的发展:XHTML 2工作组有望在2009年底停止工作,W3C将增加HTML 5的资源

2009年7月2日:今天,主管宣布,当XHTML 2工作组章程于2009年底按期到期时,该章程将不会续签。通过这样做以及通过增加工作组中的资源,W3C希望加快HTML 5的进度,并阐明W3C在HTML的未来方面的立场。FAQ回答了有关XHTML 2工作组的可交付成果的未来以及与HTML相关的各种讨论的现状的问题。了解有关HTML活动的更多信息。

好吧,我想这很清楚HTML的未来。


1

XHTML迫使您保持整洁。

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

<img src="image.jpg">

这不是很合逻辑,因为img标签永远不会关闭。但是,在XHTML中,您被迫整齐地关闭标签,如下所示:

<img src="image.jpg" />

我喜欢使用强迫我保持整洁的东西。

史蒂夫


我认为img标签永远不会关闭是有道理的。HTML!= XML,并且由于img标签没有内容,为什么要关闭它。
Pim Jager,2009年

3
只要您不孤立地对待它,这是完全合乎逻辑的。没有必要让img元素具有内容,因此DTD表示它不能具有内容。由于它没有内容,因此可以(以100%的可靠性)暗示start标记之后出现的所有内容都在元素外部。结果是结束标签被禁止。结果是较小的标记。它不那么直观,但是一旦学习了规则,就更容易编写。
昆汀2009年

2
1)斜杠前的空间已经过时,我怀疑仍然有许多Netscape浏览器需要它。2)您可以使用HTML整洁,关闭所有接受结尾部分的标签。但实际上,对于开发人员而言,执行规则可能会更容易。
PhiLho

@Pim Jager和@David Dorward:我明白您在使用没有内容的图像元素时所说的话,但是我认为XHTML的处理方式更合乎逻辑且一致。
史蒂夫·哈里森

@PhiLho:1)谢谢,我会调查一下。2)我同意。
史蒂夫·哈里森

1

XHTML 1.0建议的副标题:

XML 1.0中HTML 4的重新编写

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

如果要使用HTML,这也是可能的。有一些工具可以解析HTML DOM树。但是,这些工具通常比XML工具更专业。您可能找不到最喜欢的与HTML兼容的XML数据处理工具。此外,如今XML的用途非常广泛,以至于您可能在应用程序的其他部分使用XML。为什么不还使用相同的XML解析器来解析您的网页?这就是XHTML的动机。

如果您已经熟悉HTML 4.01,那么您已经建立了使用HTML 4的项目,并且没有大量的业余时间,只需使用HTML 4.01。如果您有空余时间,无论如何都要学习XHTML 1.1,并在XHTML 1.1中启动新项目-这样做没有任何害处。如果您使用的不是HTML 4.01,或者完全不熟悉HTML 4,则只需学习XHTML 1.1。


使用XHTML的危害是缺乏IE兼容性或将自己限制为XHTML和HTML的通用子集。例如,您不能使用XML序列化程序安全地生成“附录C” XHTML(例如<script />将使非XML解析器感到困惑)。
Kornel

你是对的。编写答案时,我并没有考虑生成XHTML。是的,我在考虑HTML和XHTML的通用子集,以避免IE解析问题。
韦斯利

1

将XHTML与正确的DocType一起使用将迫使浏览器以更符合标准(严格)的模式呈现内容。这使得不同的浏览器表现得更好,最重要的是,彼此之间更相似。这使您作为Web开发人员的工作变得更加轻松,因为它减少了使所有浏览器中的内容看起来相同所需的特定于浏览器的调整量。

Quirksmode.org在此主题上有很多不错的信息。


2
将HTML与正确的Doctype一起使用还将使浏览器进入“标准”模式。哎呀,将nonsenseML与疯狂的Doctype结合使用也会做到这一点。
昆汀

0

我认为严格性至少在理论上是一件好事,因为在HTML中,您不需要严格,并且由于这样和HTML5垃圾,浏览器具有先进的纠错算法,可以最大限度地提高性能。坏掉的HTML。问题是,算法不完全相同,并且会导致您无法预测的异常行为。另一方面,使用XHTML时,您通常拥有良好的有效XHTML,因此不需要纠错算法,即整个浏览器行为都是可预测的。另外,严格的代码使您的工具更易于使用代码。因此,使用XHTML实际上并没有什么损失,但是仍有一些潜在的收获。当HTML5最终发布并“接受您所接受的东西”时,使用纯HTML会使情况变得更糟。将导致所描述的奇怪行为。但这至少是一种标准化的奇怪行为。叹。

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


4
浏览器之所以能够进行错误更正,是因为人们编写了错误的HTML,而不是因为HTML“不够严格”。XHTML没什么不同-支持它的大多数浏览器都会对格式不正确的数据抛出错误,然后使用HTML解析器对其进行解析。(并且它们将尝试对无效的XHTML格式正确的错误进行纠正)。
昆丁

1
实际上,那是错误的。浏览器将通过“格式不正确的数据”的错误,然后停止解析。根据规格。他们不会继续尝试解析它。(继续,尝试一下。获取一个随机的HTML文档。将文档类型更改(或添加)为XHTML。在Firefox中打开。观察Firefox如何不尝试从遇到的第一个错误中恢复。显示页面,这意味着HTML也是有效的XHTML,通常不会如此(任何BR,IMG,HR或其他自闭标签在XHTML和HTML中具有不同的形式)
Alya

Firefox抛出黄色的死亡画面。大多数支持XHTML的浏览器不支持。例如,Opera提示用户将页面视为text / html:realtech.burningbird.net/image-galleries/screenshots/…(而且,如果我没记错的话,WebKit只是在不提示的情况下切换到text / html)
昆汀

@David:从技术上来说,您是正确的,现在浏览器进行错误更正的原因是不好的HTML。但这无关紧要,因为我们在哪里。不管标准中定义了什么,纯HTML都在所有浏览器中均具有错误纠正功能,我们将永远不会放弃它。因此,实际上,在大多数浏览器中,HTML不如XHTML严格。
OregonGhost,

0

使用XHTML

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

2
如果您验证HTML,也会发现这些不一致之处。使用Transitional / Strict(而不是HTML / XHTML)可以更好地表示分离的结构和表示形式。HTML也是结构化的。您也可以使用HTML进行这些操作(只是不能使用XML解析器)。XHTML并不更加结构化。从算法的角度来看,如果要使其在MSIE中运行,则必须将其用作text / html,这样浏览器就不会受益。
昆丁

@David:您可以在平面文件日志上运行查询并进行操作(请参阅日志解析器),但这并不意味着它非常适合该任务。XML具有广泛的应用程序,并且工具生态系统更加丰富。例如,如果您使用的是NAnt,则可以使用XPath从一个XHTML文件中获取部分树,然后在构建时将它们注入到另一个树中。MSIE问题不应表示XHTML有问题。如前所述,随着XHTML的发展,随着浏览器的改进,您将获得一些未来的证明。无论哪种情况,它都不会以浏览器结尾。有可编程的网络和语义搜索引擎。
09年

验证!=检查格式是否正确。向我展示XHTML规范在何处将语义与表示分离。向我展示XHTML规范在何处定义了HTML4之外的结构。借助HTML / SGML解析器,XSLT可以读写HTML。XHTML没有引入新的语义。Google将XHTML解析为HTML。RDFa使用HTML。W3C计划在未来20年内使用HTML5。大多数JS库不适用于XML DOM。具有名称空间的XML是要解析的PITA。
Kornel

@porenL,一些有趣的观点表明您是个书呆子,需要对实际情况持开放态度。首先,XHTML是XML,这意味着它是一种数据结构。如果您的含义尚不清楚,请考虑一个简单的场景,您可以将XHTML片段发送到服务器,该片段可以将其作为XmlFragment对象接受,传递给它,甚至可以将其直接持久保存到数据库中或在进行任何更改后将其序列化回服务器。所有这些对您都丢失了,因为您陷入了关于规格的
学问式

(...继续)我提到过像nAnt这样的工具,它们支持XPath,而XHTML对此非常有用–我没有时间或意愿使其与HTML一起使用。那只是一种工具和一种情况,还有许多其他情况。由于它是数据结构,因此挖掘起来也容易得多。我在命名空间问题上同意您的观点,但是我尚未遇到JS库的问题。
09年

0

XHTMl是一个很好的使用立足点,因为如果您想要有效的代码,则由于屏幕阅读器需要image和link标签的alt和title部分,您将需要向残疾人社区提供某些方面的帮助。解析到一定程度必须更快,因为与HTML不同,解析器无需检查标记是否未正确关闭,是否正确嵌套等。使用它也是更好的选择,因为它是严格的但是在学习编程语言方面,它可以帮助您(在我看来)更理性地思考。


1
当涉及到alt和title属性时,XHTML 1.0、1,1和HTML 4.01具有相同的要求和规则。如果将XHTML视为XML,从理论上讲它解析起来会更快,但是由于IE不支持,因此必须将它作为text / html来使用才能使其正常工作,因此无法实现这一好处。
昆丁

许多屏幕阅读器用户都使用IE(主要是因为很长一段时间以来,其他浏览器都无法很好地与他们一起使用),并且IE根本不支持XHTML(当您不发送正确的MIME类型时,它可能看起来是相反的)。如果您确实使用过XHTML,那么实际上会让大多数屏幕阅读器用户完全无法访问页面。
Kornel

0

我相信XHTML解析(或应该更快)。有效的XHTML文档必须按照更严格的规范编写,因为解析时错误是致命的,而HTML的宽容性更大,并允许在我的注释之前提到奇怪的内容,例如混乱的结束标记等。我发现这有助于发现HTML和XHTML解析之间的差异:

http://wiki.whatwg.org/wiki/HTML_vs._XHTML#解析

之所以可能会使用XHTML而不是HTML,可能是因为您打算让移动用户成为受众的一部分。如果我还记得的话,许多电话使用的只是XML解析器,而不是HTML解析器。如果您是为台式机浏览器编写的,则HTML可能是可以接受的。

就是说,如果您仍然要以text / html形式提供数据,则应该使用HTML:

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


1
HTML不会“禁止”关闭标记混乱。它只是不要求解析器抛出错误-我从来没有拥有可以处理XHTML但不能处理HTML的手机(而且我使用移动互联网已经很多年了)
昆汀,2009年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.