在一天结束时，为什么selectHTML上的XHTML？
我想知道为什么我应该使用XHTML而不是HTML。
XHTML应该是“模块化”的，但我还没有看到任何服务器端语言利用任何。
XHTML也比较严格，我看不出优势。 XHTML提供什么，我需要这么糟糕？ 它如何使我的代码“更好”？
编辑：我在评论中发现的另一个问题：XHTMLparsing比HTML更快吗？
编辑2：在阅读完所有的评论和链接之后，我确实认为另一篇文章应该是正确的答案，所以我select了直接链接到最佳源代码的文章。
而且，甚至没有阅读，就表明人们喜欢绿色评论。
您应该阅读“ 注意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的优点，但是在深入了解XHTML之前，先了解一下缺点吧。
我打算把这个添加到其他post的评论中，但是它增长得有点过大。
大多数人似乎缺less的基本点是XHTML背后的目的。 开发XHTML规范的主要原因之一是不再强调标记中与表示相关的标记，并将表示推迟到CSS。 虽然这种分离可以用简单的HTML来实现，但是这种行为并不是由规范来提升的。
分隔元标记和表示是“可编程networking”发展的重要组成部分，不仅可以提高search引擎优化和屏幕阅读器/文本浏览器的访问权限，而且还可以使您的网站更容易被那些希望以编程方式访问它（在很多简单的情况下，这可以消除开发特定的API的需要，甚至只是允许客户端脚本做的事情，如识别电话号码）。 如果您的网页符合XHTML规范，则可以使用XML相关工具以及XPath等方式轻松遍历…对于想要从您的网站提取特定信息的人来说，这是一个绝佳的新闻。
XHTML本身并没有被开发出来，而是被其他各种技术所使用。 它很大程度上依赖于CSS的使用，并为微格式（无论你喜欢它们还是讨厌它们）提供一个标准化的标记来提供常用的数据表示。
不要被那些认为XHTML是微不足道的人群所迷惑，而是过于狭隘和毫无意义的……它是为了95％的世界似乎忽略/不知道的目的而创build的。
通过所有的手段使用HTML，但用它的好处，并采取相同的方法看着XHTML。
关于parsing速度 ，我想在XHTML和HTML之间parsing实际的文档是没有什么区别的。 权衡将纯粹用你如何使用可用标记来描述文档。 由于所需的属性，正确的closures等，XHTML标签往往会更长，但会放弃在文档本身中的任何表示标记的需要。 在这种情况下，我认为你是在谈论比较一种types的苹果，与一个非常不同的苹果types…他们是不同的，但它不可能是任何结果（在parsing和渲染）当你想要的是一个健康，美味的苹果。
对于一个网站的访问者来说，它可能没有任何明显的差异。 而且，XHTML通常更容易使用，因为至less有一个普遍的浏览器仍然不知道如何处理它，并且在这种情况下（这会产生无效的HTML），您需要将其作为text / html提供。
如果您的HTML将被自动化工具定期处理而不是被人类读取，那么您可能希望使用XHTML，因为它的结构更为严格，而且XML更容易parsing（从应用程序的angular度来看，不是XML固然很容易parsing，虽然）。
除此之外，我没有看到使用它的任何令人信服的理由。 XHTML创build的方法是利用HTML的XMLfunction，基本上归结为“带有几个令人讨厌的副作用的HTML 4”（恕我直言，至less）。
使用HTML （HTML4严格或HTML5）。
-
HTML可以充分利用CSS，可以被明确地validation和parsing。 结构和表示的分离已经在HTML4中完成了，而XHTML只是继续。
-
所有浏览器都支持HTML。 只有一些浏览器支持XHTML，而那些支持XHTML的浏览器通常会有更成熟，更好的testing和优化的HTML支持（这是因为页面的一小部分使用XML模式）。
-
如果您关心IE和Google，则必须使用XHTML规范附录C中定义的HTML或XHTML和HTML子集。 后者在这两个世界中几乎是最糟糕的，因为这样的XHTML不能用标准的XML工具生成，不能使用XHTML的新扩展机制，并且在HTML中单独使用扩展机制。
-
XHTML1.0现在已经超过10年了，它是在“Web1.0”时代devise的，作为W3C的负责人说， 回想起来，它并没有成功，需要更好的方法 。 W3C HTML5是在我们发言的时候编写的，可以解决当前使用的Web应用程序的需求，并且具有非常好的向后兼容性。
-
HTML5closures了HTML4和XHTML1之间的许多空白（例如添加内联SVG，MathML和RDF），清除了XHTML1.0和XHTML1.1中所做的语言。
-
在未来的XHTML2将不会被网页浏览器所支持。 它可能永远不会被支持（所有浏览器厂商都大力支持[X] HTML5，有些已经宣称他们不会实现XHTML2）。
XHTML1.0与HTML4.01具有完全相同的语义和结构分离。 任何人谁说，否则， 没有阅读说明书 。 我鼓励大家阅读规范 – 这是令人惊讶的短而无趣的。
- 样式表是在HTML4.01中引入的，在XHTML1.0中没有改变。
- 表示元素在HTML4.01中被弃用，并且在XHTML1.0中没有被删除。
XHTML神话 。
在HTML和XHTML中没有任何不可分割的差异，这会使parsing速度比另一个慢得多。 这取决于parsing器是如何实现的。
- SGML和XMLparsing器都需要加载和parsing整个DTD才能理解实体。 这本身通常比parsing文档本身更多的工作。 HTMLparsing器几乎总是“作弊”并使用硬编码的实体和元素信息。 浏览器中的XHTMLparsing器也会作弊。
- parsingHTML需要处理隐含的开始和结束标记，而真实世界的HTML需要额外的工作来处理错位的标记。
- 正确的parsingXHTML需要跟踪XML名称空间。
- 严苛的XML规则要求检查每个字符是否被正确编码。 HTMLparsing器可能会消失，但是OTOH他们需要寻找
<meta>。
与下载文档，构buildDOM，运行脚本，应用CSS以及浏览器所需的所有其他操作所花费的时间相比，parsing成本的总体差异很小。
我很惊讶，这里的所有答案都推荐使用HTML的XHTML。 我坚信相反的观点 – 在可预见的将来，你不应该使用XHTML。 原因如下：
-
没有浏览器将XHTML解释为 XHTML，除非您将其作为mimetype
application/xhtml+xml。 如果你只是用默认的mimetype服务它，所有的浏览器都会把它解释为HTML – 例如接受未封闭或不正确嵌套的元素。 -
但是，您绝对不应该这样做 ，因为Internet Explorer无法识别
application/xhtml+xml，并且无法完全呈现页面。 -
XHTML和HTML之间的DOM存在显着差异。 由于目前所有的XHTML页面都是作为HTML服务的，所有的JavaScript代码都是使用HTML DOM编写的。 如果对XHTML mimetype的支持变得足以说服人们开始使用它，那么他们的大部分JavaScript代码都将被破坏 – 即使他们认为他们的页面被validation为XHTML。
我不build议继续讨论HTML 4.01 Strict vs XHTML Strict，而是build议今天开始使用HTML 5。 去年 ，jquery的作者John Resig在他的博客上也提出了类似的build议 。
HTML 5的文档types，它非常简单，将在所有浏览器（包括IE6）中触发标准模式。
<!DOCTYPE html>
而已。
HTML 5提供了一些令人兴奋的新function，例如<canvas>标记，它可以将JavaScript应用程序开发推向更高层次。 HTML5也以适当的方式支持媒体（媒体现在是networking的一个相当重要的方面！）以<video>和<audio>标记的forms。
如果您喜欢XHTML的语法，即closuresHTML 5中完全支持的“empty”标记，请参见W3C文章的Karl Dubost 了解如何编写HTML 5 ：
自动closures标签被允许并符合HTML 5。
与HTML 5相比，XHTML2受到的关注相对较less。HTML 5已成为Web上标记的未来。 微软最新的浏览器IE8 仍然把text / xml作为text / html。
微软在W3C HTML工作组中担任联合主席，他们对HTML 5提供了默认支持。所有浏览器供应商都公开宣布支持HTML 5。
在一天结束的时候，即使XHTML2重新获得业界的支持，也不会像过去那样有两个竞争标准的重大问题。 这两种语言都支持XML命名空间（在HTML 5的情况下，即HTML的序列化，即DOCTYPE切换）。
看看http://www.w3.org/MarkUp/2004/xhtml-faq#need 。 除了模块化之外，还有一些很好的理由。
我喜欢XHTML，因为它更严格，更清晰。 HTML是古怪的，浏览器必须接受像<b><i>sadasd</b></i> 。 虽然这是一个非常简单的例子，但它也可能会变得更加混乱，不同的浏览器可能会以不同的方式进行布局。
另外我认为XHTML必须“更快”，因为浏览器不必做那种“赔偿”。
有些区别是：
- XHTML标签必须正确嵌套
- 这些文件必须有一个根元素
- XHTML标签总是小写
- 标签必须始终closures（例如，使用XHTML中的
<br>标签必须在XHTML中有结束标签或<br></br>）
这里有一些链接
wiki XHTML
维基HTML与XHTML
作为一名程序员，你应该非常关心你的代码。 HTML是丑陋的，遵循一些规则。
另一方面，XHTML将HTML转换成适当的语言，遵循严格的结构和语法规则。
XHTML对每个人都有好处，因为它有助于将networking移动到每个人（所有浏览器）都可以就如何显示网页达成一致的程度。
XHTML是一个XML的后代，而我们这样的parsing器在分析语法上合理的XML文档的工作上更容易。
如果你不能看到XHTML的好处，那么你也可以使用MS Word来创build你的HTML文档。
XHTML允许使用所有为XMLdevise的工具。 其中有XSLT，embeddedSVG等。
XHTML强迫你整洁。
例如，在HTML中，您可以编写：
<img src="image.jpg">
这不是很合乎逻辑，因为img标签永远不会被closures。 然而，在XHTML中，你不得不整齐地closures标签，就像这样：
<img src="image.jpg" />
我喜欢使用强迫我整洁的东西。
史蒂夫
XHTML 1.0build议的副标题：
XML 1.0中对HTML 4的修改
目前存在许多工具来处理XML。 通过使用XHTML，您可以允许使用一大套工具在您的页面上进行操作并以编程方式提取信息。
如果你要使用HTML，这也是可能的。 有一些工具可以parsingHTML DOM树。 但是，这些工具通常比XML更专业。 您可能无法find您最喜爱的与HTML兼容的XML数据处理工具。 而且，现在XML的用途非常多，您可能会将XML用于应用程序的其他部分; 为什么不用同样的XMLparsing器来parsing你的网页？ 这是XHTML背后的动机。
如果您对HTML 4.01已经很熟悉并且很熟悉，那么您已经有了一个使用HTML 4的已经build立的项目，而且您没有很多的空闲时间，只需要使用HTML 4.01即可。 如果你有空余的时间，无论如何学习XHTML 1.1，并用XHTML 1.1开始你的新项目 – 这样做不会有什么坏处。 如果您使用的是HTML 4.01以外的东西，或者对HTML 4非常不熟悉，那么只需要学习XHTML 1.1。
使用正确的DocType使用XHTML将强制浏览器以更符合标准的（严格）模式呈现内容。 这使得不同的浏览器performance得更好，最重要的是，彼此更像。 这使得作为web开发者的工作变得更加容易，因为它减less了浏览器在所有浏览器中使内容看起来相同所需的调整量。
Quirksmode.org在这方面有很多很好的信息。
有趣的发展： XHTML 2工作组预计将于2009年底停止工作，W3C将增加HTML 5的资源
2009-07-02：今天董事宣布，如果XHTML 2工作组章程如期于2009年底届满，章程将不会延期。 通过这样做，并通过增加工作组的资源，W3C希望加快HTML 5的进度，明确W3C对HTML未来的立场。 FAQ回答了有关XHTML 2工作组可交付成果未来的问题以及与HTML相关的各种讨论的状态。 了解有关HTML活动的更多信息。
那么，我想这使HTML的未来很清楚。
在我看来，严格来说至less在理论上是一件好事，因为在HTML中，你并不需要严格，因为这和HTML5的垃圾，浏览器有先进的错误校正algorithm，将使最好的出了破碎的HTML。 问题是，algorithm不完全一样，会导致你无法预测的真正奇怪的行为。 另一方面，使用XHTML，您通常会拥有良好且有效的XHTML，因此不需要纠错algorithm，即整个浏览器行为都是可预测的。 另外，严格的代码使您的工具更容易处理代码。 所以，使用XHTML实际上并没有什么损失，但有一些潜力可以获得。 当HTML5终于出来，而“在你接受的东西上打开”将导致所描述的奇怪的行为，事情会变得更糟。 但至less这是一种标准化的奇怪行为。 叹。
另一方面，如果使用像Visual Studio这样的好IDE，那么生成破坏的HTML代码几乎是不可能的，所以结果是一样的。
使用XHTML
- 失败很快 如果有任何不一致的地方，他们将在validation过程中发现。
- 它通过将语义标记与表示等分开来鼓励更好的devise
- 它的结构意味着您可以将其视为一个数据对象，并针对它运行各种查询。 例如，您可以在您的网站中find所有地址或引文。
- 您可以进行构build时优化 。 由于它是格式良好的XML，您可以在构build时轻松地find/replace操作。 或者任何文件pipe理和操纵。
- 您可以编写XSLT或其他转换脚本，以编程方式将您的XHTML转换为其他平台。 例如，你可以有一个iPhone的XSLT，将所有的XHTML转换为兼容或更友好的iPhone
- 你是未来certificate自己。 将XHTML转换为更新的语义也是非常容易的。
- search引擎将继续发展，收集更多的语义信息作为可编程networking的一部分。
- 由于结构化， DOM操作更可靠。
- 从algorithm的angular度来看，它产生更容易和更快的parsing 。
XHTMl是一个很好的使用方式，因为如果你想要有效的代码，你需要向残疾人社区提供一些方面的帮助，因为屏幕阅读器需要图像和链接标签的替代和标题部分。 因为和HTML不同，parsing器不需要检查标签是否正确closures，是否正确嵌套等等，所以parsing速度必须更快一些。另外，最好使用它，因为它是严格的但是当涉及到学习编程语言时，它可以帮助你更逻辑地思考（在我看来）。
我相信XHTML是（或应该）更快的parsing。 一个有效的XHTML文档必须写入一个更严格的规范，因为parsing时错误是致命的，而HTML更宽松，并允许在我的评论之前提到的奇怪之处，如乱序closures标签等。 我发现这有助于揭示HTML和XHTMLparsing之间的区别：
http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Parsing
如果您打算将移动用户作为受众群体的一部分，则可能会使用HTML上的XHTML。 如果我记得，许多手机使用更多的XMLparsing器，而不是一个HTML显示networking。 如果你正在写桌面浏览器，HTML可能会被接受。
也就是说，如果你打算以text / html方式提供数据，你应该使用HTML：
