无效的XHTML是否可以接受？

Question

我注意到很多网站，包括SO，使用XHTML作为标记语言，然后不遵守规范。只需浏览SO的源代码就会缺少段落，无效元素等的结束标记。

如果工具（和开发人员）要生成无效标记，那么他们应该使用XHTML文档类型吗？浏览器是否应该更加坚定地接受糟糕的加价？

在有人喊叫伪君子之前，我的博客有一条涉及captha的无效标记（或者我最后一次检查时），这涉及到noscript标签的样式。

Answer 1

有many reasons个使用有效标记。我最喜欢的是它允许你使用验证作为回归测试的一种形式，一旦错误达到某个临界质量，就可以防止相当于“delta rot”的标记导致真正的渲染问题。实际上，允许像拼写错误和错误嵌套/未封闭标签这样的“懒惰”错误来积累，这简直太草率了。有效标记是识别passionate programmers的一种方式。

还存在调试问题：有效标记还为您提供了一个稳定的基线，可以从中解决不可避免的跨浏览器兼容性问题。没有重视他的时间的Web开发人员应该开始调试浏览器兼容性问题，而不首先确保标记至少语法有效 - 并且任何其他无效标记应该有充分的理由在那里。

（顺便提一下，stackoverflow.com无法完成这两项测试，也没有解决问题的建议were declined。）

所有这些都说，要回答您的具体问题，除非您计划生成有效（或 格式正确）标记，否则使用其中一个XHTML文档类型可能并不值得。 XHTML的主要优点源于XHTML是XML，允许通过使用XML的工具和技术进行处理和转换。如果您不打算制作XHTML格式良好的XML，那么选择该doctype毫无意义。最新的HTML 4规范可能会做你需要的一切，而且它更宽容。

Answer 2

我们应该始终尝试根据标准进行验证。我们确信该网站将在当前浏览器和未来的浏览器上显示和正常工作。

Answer 3

我不认为，如果您指定了doctype，则有任何理由不遵守此doctype。

使用XHTML可以轻松实现自动错误检测，可以自动检查每个更改是否存在无效标记。这可以防止错误，尤其是在使用自动生成的内容时对于使用模板引擎（JSP，ASP.NET StringTemplate等）的Web开发人员来说，复制/粘贴一个结束标记太少或太多都非常容易。如果这是您唯一的错误，可以立即检测并修复。我曾经为一个每页有165个验证错误的网站工作，其中2或3个是实际的错误。在其他错误的混乱中很难找到这些。自动验证可以在源头上防止这些错误。

毋庸置疑，选择一个标准并坚持使用它永远不会有利于与其他系统（屏幕抓取器，屏幕阅读器，搜索引擎）的互操作性，我从来没有遇到过使用CSS解决方案的有效语义XHTML的情况适用于所有主流浏览器。

显然，在处理复杂系统时，并不总是能够坚持使用您的doctype，但这主要是由于不同团队之间的不正确沟通，这些团队开发了这些系统的不同部分，或者很可能是遗留系统。在最后一种情况下，最好隔离这些案例并相应地更改您的文档类型。

务实并且不遵守XHTML是好的，因为有人这么说，不管成本如何，但目前有关CSS和浏览器，测试和验证工具的知识，大部分时间的好处远大于成本。

Answer 4

你可以说我对XHTML有效性有强迫症。我发现代码中的大多数问题都不是有效的，程序员不知道HTML和XHTML之间的区别。我已经写了100％有效的XHTML和CSS或者现在一段时间，并且从来没有与其他浏览器有任何重大的渲染问题。如果你保持一切有效，并且不要尝试任何过于异国情调的明智，那么你将节省大量的修复时间。

Answer 5

我根本不会使用XHTML来拯救自己的哲学压力。它并不像任何浏览器那样像XHTML那样对待它。

如果页面以application / xhtml + xml的形式发送，浏览器将拒绝不良标记，但它们很少。这很好。

我会更关心像使用Stack Overflow在线使用CSS和JavaScript这样的事情，因为它们会使维护更加困难。

Answer 6

虽然我相信努力争取有效的XHTML和CSS，但由于种种原因，这通常很难做到。

• 首先，可以通过AJAX加载一些内容。有时，片段未正确插入现有DOM中。
• 您正在查看的HTML可能并非在同一文档中生成。例如，页面可以由组件或模板组成，然后在浏览器呈现之前将其抛出。这不是一个借口，但你不能假设你所看到的HTML是一次手动编码的。
• 如果Markdown生成的某些代码无效，该怎么办？你不能责怪Stack Overflow没有生成有效的代码。
• 最后，DOCTYPE的目的不是简单地说“嘿，我正在使用有效的代码”，但它也是为了让浏览器了解您正在尝试做的事情，这样它至少可以接近正确解析该信息。

我认为大多数开发人员都没有指定DOCTYPE，然后明确地不遵守它。

Answer 7

虽然我同意“如果它呈现罚款然后不担心它”的说法，但是遵循标准是有好处的，尽管它现在可能没有得到完全支持。你仍然可以使用Table进行布局，但这并不是一个好理由。

Answer 8

不，如果不能保证格式良好，则不应使用XHTML，如果不使用XML序列化程序生成标记，实际上无法保证。阅读about producing XML。

格式良好是将XHTML与HTML区分开来的事物。带有“只有一个”标记错误的XHTML不再是XHTML。 每次都必须完美。

如果“XHTML”网站似乎出现了一些错误，那就是因为browsers ignore the DOCTYPE并将网页解释为HTML。

请参阅强制将页面解释为XHTML的XHTML proxy。大部分时间they fail miserably。这就是为什么XHTML的未来不确定和why development of HTML has been resumed。

的原因之一

Answer 9

这取决于。我有issue with my blog YouTube视频导致无效的XHTML，但它渲染得很好。另一方面，我有一个“有效的XHTML”链接，并且“有效的XHTML”声明和无效的XHTML的组合不是专业的。

因为SO没有声称有效，我认为这是可以接受的，但就个人而言，如果我是杰夫，即使它在现代浏览器中看起来很好，也会尝试修复它，但是有些人宁愿继续前进完成任务而不是修复不存在的错误。

Answer 10

只要它适用于IE，FF，Safari，（在此插入其他浏览器），你应该没问题。验证并不像在多个浏览器中正确呈现一样重要。仅仅因为它是有效的，并不意味着它可以在IE中正常工作，例如。

在您的网站上运行Google Analytics或类似工具，查看您的用户使用的浏览器类型，然后判断您需要哪些浏览器支持最多，并在您有空余时间时担心不太重要的浏览器。< / p>

Answer 11

我说，如果它渲染好，那么它的像素是否完美并不重要。

需要一段时间才能让网站以您希望的方式运行并运行，返回并进行更改会改变页面呈现的方式，然后您必须修复那些问题

现在，我并不是说你应该建立草率的网页，但我认为没有理由修复那些没有破坏的网页。浏览器不会在不久的将来随时放弃对纠错的支持。

Answer 12

我不明白为什么当某些浏览器在正确呈现标准代码时出现问题时，每个人都会试图让他们的网站符合标准。我已经在网页设计中工作了10年，我停止了双重编码（阅读：黑客css），并改变了愚蠢的东西，这样我就可以在我的网站上放一个按钮了。

我相信使用＆lt; DIV＆GT;无论如何都会导致你无效，没有它就会更难做任何主要的JavaScript / AJAX。

Answer 13

有太多的标准，它们被严格“强制执行”或支持，我认为这不重要。不要误解我的意思，我认为应该有标准，但因为没有强制执行，没有人跟随它们，这是一个巨大的螺旋式下降。

Answer 14

对于那里99.999％的网站来说，这无关紧要。我唯一重要的时候，我通过HTMLTidy运行HTML输入到XHTML-ize，然后在上面运行我的处理。

差不多，这是旧程序员的公理：信任没有输入。