为什么不使用XHTML5？

53

因此，有人告诉我HTML5是向前迈出的一大步。我知道的最后一步是XHTML的引入。优势显而易见：简单，严格，使用标准XML解析器和生成器来处理网页的能力，等等。

HTML5如此回滚，这真是多么奇怪和令人沮丧：我们再次使用了非标准语法；再次，我们必须处理历史包and和解析复杂性；再次，我们不能使用我们的标准XML库，解析器，生成器或转换器。XML所带来的所有优势（可扩展性，名称空间，标准化等），以及W3C出于充分的理由而花了十年的时间，都失去了。

很好，我们有XHTML5，但似乎它没有像HTML5编码那样流行。例如，参见此SO问题。甚至HTML5规范都说HTML5（而不是XHTML5）是“建议大多数作者使用的格式”。

我的事实有误吗？否则，为什么我是唯一一个有这种感觉的人？人们为什么选择HTML5而不是XHTML5？

— Jameshfisher
source

6

+1我发现，我并不是唯一一个对HTML5中所有XML优势的丧失感到沮丧的人。

— 阿森尼·穆尔坚科

好的问题，好了。

— Konrad Rudolph

1

我希望我不是唯一一个对HTML5中所有XML缺点的丧失感到高兴的人。例如，让我们比较有效的HTML5和有效的XHTML。HTML5：<!DOCTYPE html>Hello World，XHTML：

<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0  Transitional//EN" "DTD/xhtml1-transitional.dtd"><html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><title></title></head><body>Hello World</body></html>

— zzzzBov 2011年

@zzzzBov，您绝对不是唯一一个高兴的人，这就是为什么我首先问这个问题。另外：您不会认真写作<!DOCTYPE html>Hello World，是吗？在此验证器上尝试。

— jameshfisher 2011年

1

@eegg，显然你没读过的规格可选的开始标记，因为我严重会写<!DOCTYPE html>Hello World!，因为它是完全有效的HTML5。较短的文件意味着较少的带宽开销，这相当于为大公司节省了很多钱（您是否看到过Google为www.google.com发送的邮件？）。

— zzzzBov 2011年

25

我建议阅读我们如何到达这里？。马克·皮尔格里姆（Mark Pilgrim）给出了出色的HTML历史，直至HTML5。

从本质上讲，我的理解是，许多网页甚至没有利用XHTML的“ X”，因为它们没有为其指定正确的MIME类型。

— 假说
source

18

是的我对该故事的总结是：“嘿，没有人符合规范。也许我们可以通过指定人们可以犯任何他们想要的错误来使他们符合规范。然后，我们所有的文档都将没有错误。并符合标准。” 在最初没有人遵守规范的前提下编写规范不会带来任何好处。

— jameshfisher 2011年

1

@eegg，最后一行显示您对现实的无知。假设没有人是完美的，很多事情就已经做好了。规范没有说“如果您犯了任何错误，一切都会被破坏”，而是说：“如果您犯了[这种类型的错误]，那么[结果]就应该发生”。如果必须要有100％正确的拼写，标点和语法才能出版，那么我们的书架上会有几本书？

— zzzzBov 2011年

6

@zzzzBov，您对已出版书籍的类比很奇怪。为什么HTML解析器比[语法错误]和[错误信息]解析器更宽容？想象一下，如果我们的C编译器尽最大努力以静默方式重新解释损坏的语法，那么我们将陷入混乱。

— jameshfisher 2011年

@eegg，我可以像会如果任何其他语言解析器反应更宽容的方式语法错误发生的事情：我们会花更少的时间追捕放错地方的括号和失踪半冒号和更多的时间打字的功能代码。我并不是说优秀的程序员仍不会使他们的程序格式正确，但这肯定会帮助平庸的程序员编写工作代码。一个C程序可能最终看起来更类似于该Python程序，因为分号和方括号可能大部分消失，剩下的就是重要的代码。

— zzzzBov 2011年

“请求的资源/past.html在此服务器上不再可用，并且没有转发地址。”

— Marco

6

如果您生成xml兼容的html5，并以xml作为mime类型发送它们，那么xml解析器将被用于所有好的爵士乐回来了；）

编辑：请参阅更多信息：http : //wiki.whatwg.org/wiki/HTML_vs._XHTML

— Deadalnix
source

定义“好爵士”。AFAIK将HTML解析为XML没有任何优势。生成和转换是另外一回事，虽然很方便，但是解析本身并没有带来任何好处，只有缺点（这使外观错误很致命）。

— Joeri Sebrechts

3

@Joeri事实很容易解析，这在我的书中有一个优势，原因有多种（严格的解析有助于发现错误，更好的工具支持，因为工具更容易编写，输入的清理更容易，等等）。

— Konrad Rudolph

您还可以提供标准html中不可用的某些功能，例如micin xhtml和其他xml内容，并且通常使用所有xml功能，例如命名空间。html解析器能够修复错误的源代码-所谓的修饰错误-但这些修复需要付出一定的代价。代价是浏览器需要知道它可能在代码中找到什么，从而限制了可用功能。

— deadalnix11年

3

HTML5是浏览器采用Postel法则（“在接受的内容上保持自由”）的逻辑上和必然的结论。

一旦一个具有足够市场份额的浏览器采用了这一原则，其他浏览器就被迫效仿，不仅因为接受不合格内容而变得自由，而且使它的竞争方式与竞争对手相同。HTML5是这种情况的逻辑结果：浏览器供应商已决定，由于他们不会拒绝任何无效内容（至少不是在HTML级别-Java是另一回事！），所以他们最好还是坐在那里。表格并同意对内容作者可能投掷给他们的任何内容的解释。在这种环境下，他们对标准极客的反应并不友好，他们告诉他们，如果只是拒绝了go一词中形式不正确的内容，他们就不会陷入困境。

因此，您和我可以在场上大喊大叫，并告诉浏览器供应商和他们的用户，如果他们不相信约翰·波斯特尔（John Postel），世界将会是一个更好的地方，但是损害已经造成，并且很难消除。

— 迈克尔·凯
source

3

浏览器的竞争草率的故事是真实的。但这就是问题：这就是存在标准怪胎的原因。 如果所有浏览器从一开始就采取了直截了当的措施，那么像W3C这样的组织就不必在这里控制一切。整点的标准是损害控制; 让标准机构屈服并接受草率是不符合其宗旨的。

— jameshfisher

1

@eegg：HTML5重新定义了解析规则，以使所有输入有效，并仍然具有可预测的结果。如果不可能出现语法错误，则从一开始就排除所有类型的错误。XML具有解析错误的能力是一个设计缺陷，应该这样识别。

— Joeri Sebrechts

1

@Joeri，您的立场似乎是HTML5规范的立场，得出其疯狂的逻辑结论。“ HTML5重新定义了解析规则，以使所有输入均有效” –事实并非如此。解析错误的概念仍然存在。“如果不可能出现语法错误，那么从一开始就排除一整类错误” –也许这是模仿？我在对@pthesis答案的评论中讽刺地解释了这种逻辑。是的，语法错误的类别已删除，将由更大类别的浏览器语法校正错误代替。

— jameshfisher 2011年

2

实际上，与HTML4规范相比，HTML5规范有了很大的改进。特别是，错误条件和无效标记的处理实际上是标准化的，这意味着所有正确实现该标准的浏览器都将以相同的方式处理无效标记。

HTML通常是由人类编写的（通常与某种模板语言结合使用），并且人类会犯错误。只要所有浏览器都以相同的方式处理语法错误，那么“在接受的内容上保持自由”规则是完全可以接受的。

生成有效的XML几乎没有优势，因为（几乎）可以使用处理HTML的工具和库（几乎），并且HTML比XML更易于人类编写。

— 迪恩·哈丁
source

在HTML4规范中，可以。但是我的意思是XHTML1.1 已经对此进行了改进。处理HTML的工具/库通常类似于BeautifulSoup，尽管出色的工具应与创建的解析页面一起消失。

— jameshfisher 2011年

1

无论如何，您永远都不会从客户端获得更简单的解析器或标准XML工具的好处。

Web上有数十亿个HTML页面，其中一些页面是由早已死的人编写的，因此永远不会更新为XML。因此，如果您想创建一个通常有用的用户代理，则无论如何都必须能够解析老式的HTML。可以说XHTML仅引入了额外的复杂性，因为除了已经支持的HTML解析之外，它还需要一种新的解析模式。

在服务器端，例如，您仍然可以利用XML工具。使用XSLT生成XHTML。但是，如果您不是专门使用XML工具链，那么使用XML语法而不只是HTML不会带来任何好处。

（您认为HTML是“非标准”语法是不正确的。HTML的语法在HTML5规范中详细说明了细节，因此它与XML语法一样都是标准。）

— 雅克
source