无效的 XHTML 是否可以接受？
我注意到很多网站（包括 SO）都使用 XHTML 作为标记语言，但却未能遵守规范。 只需浏览 SO 的源代码，就会发现缺少段落结束标记、无效元素等。
那么，如果工具（和开发人员）要生成无效标记，是否应该使用 XHTML 文档类型？ 浏览器是否应该更坚定地接受低劣的标记？
在有人大喊虚伪之前，我的博客有一个涉及 captha 的无效标记（或者我上次检查时确实如此），其中涉及 noscript 标签的样式。
I've noticed a lot of sites, SO included, use XHTML as their mark-up language and then fail to adhere to the spec. Just browsing the source for SO there are missing closing tags for paragraphs, invalid elements, etc.
So should tools (and developers) use the XHTML doctype if they are going to produce invalid mark up? And should browsers be more firm in their acceptance of poor mark-up?
And before anyone shouts hypocrite, my blog has one piece of invalid mark-up involving the captha (or it did the last time I checked) which involves styling the noscript tag.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
对于 99.999% 的网站来说，这真的不重要。 我唯一一次遇到这种情况是，我通过 HTMLTidy 运行 HTML 输入以对其进行 XHTML 化，然后对其进行处理。
几乎，这是老程序员的公理：不信任任何输入。
For 99.999% of the sites out there, it really won't matter. The only time I've had it matter, I ran the HTML input through HTMLTidy to XHTML-ize it, and then ran my processing on it.
Pretty much, it's the old programmer's axiom: trust no input.
标准如此之多，但它们的“执行”或支持却如此糟糕，我认为这并不重要。 不要误会我的意思，我认为应该有标准，但由于这些标准没有得到执行，所以没有人遵循它们，这是一个巨大的螺旋式下降。
There are so many standards and they are so badly "enforced" or supported that I don't think it matters. Don't get me wrong, I think there should be standards but because they are not enforced, nobody follows them and it's a massive downward spiral.
我不明白为什么当某些浏览器在正确呈现标准代码时仍然存在问题时，每个人都在努力使自己的网站符合标准。 我从事网页设计已经有大约 10 年了，我停止了双重编码（阅读：黑客 CSS），并改变愚蠢的东西只是为了我可以在我的网站上放置一个按钮。
我相信使用 < 分区> 无论如何都会导致你无效，并且如果没有它，执行任何主要的 JavaScript/AJAX 都会变得有点困难。
I don't understand why everyone get caught up trying to make their websites fit the standard when some browsers sill have problems properly rendering standard code. I've been in web design for something like 10 years and I stopped double codding (read: hacking css), and changing stupid stuff just so I could put a button on my site.
I believe that using a < div> will cause you to be invalid regardless, and it get a bit harder to do any major JavaScript/AJAX without it.
我说，如果它渲染得很好，那么它的像素是否完美并不重要。
让网站按照您想要的方式启动并运行需要一段时间，返回并进行更改将稍微改变页面呈现的方式，然后您必须解决这些问题。
现在，我并不是说您应该构建草率的网页，但我认为没有理由修复未损坏的内容。 浏览器不会在不久的将来放弃对纠错的支持。
I say, if it renders OK, then it doesn't matter if it's pixel perfect.
It takes a while to get a site up and running the way you want it, going back and making changes is going to change the way the page renders slightly, then you have to fix those problems.
Now, I'm not saying you should built sloppy web pages, but I see no reason to fix what ain't broke. Browsers aren't going to drop support for error correction anytime in the near future.
这取决于。 我的博客存在问题 YouTube 视频导致 XHTML 无效，但呈现良好。 另一方面，我有一个“有效的 XHTML”链接，并且“有效的 XHTML”声明和无效的 XHTML 的组合并不专业。
由于 SO 并不声称有效，我认为这是可以接受的，但就我个人而言，如果我是杰夫，我会很烦恼并尝试修复它，即使它在现代浏览器中看起来不错，但有些人宁愿继续前进并实际完成工作而不是修复不存在的错误。
It depends. I had that issue with my blog where a YouTube video caused invalid XHTML, but it rendered fine. On the other hand, I have a "Valid XHTML" link, and a combination of a "Valid XHTML" claim and invalid XHTML is not professional.
As SO does not claim to be valid, I think it's acceptable, but personally if I were Jeff i would be bothered and try to fix it even if it looks good in modern browsers, but some people rather just move on and actually get things done instead of fixing non-existent bugs.
只要它可以在 IE、FF、Safari（此处插入其他浏览器）中运行，就应该没问题。 验证并不像在多个浏览器中正确呈现那么重要。 例如，仅仅因为它有效，并不意味着它可以在 IE 中正常工作。
在您的网站上运行 Google Analytics 或类似工具，查看您的用户正在使用哪种浏览器，然后判断您最需要支持哪些浏览器，并在您有空闲时间时担心不太重要的浏览器。
So long as it works in IE, FF, Safari, (insert other browser here) you should be okay. Validation isn't as important as having it render correctly in multiple browsers. Just because it is valid, doesn't mean it'll work in IE properly, for instance.
Run Google Analytics or similar on your site and see what kind of browsers your users are using and then judge which browsers you need to support the most and worry about the less important ones when you have the spare time to do so.
不，如果不能保证格式良好，则不应使用 XHTML，并且在实践中，如果不使用 XML 序列化程序生成标记，则无法保证格式良好。 阅读有关生成 XML。
格式良好是 XHTML 与 HTML 的区别。 带有“只有一个”标记错误的 XHTML 不再是 XHTML。 每次都必须完美。
如果“XHTML”网站运行时出现一些错误，那是因为 浏览器忽略 DOCTYPE 并将页面解释为 HTML。
请参阅强制将页面解释为 XHTML 的 XHTML 代理。 大多数时候他们惨败。 这是 XHTML 的未来不确定的原因之一，也是 HTML 的开发已恢复的原因之一。
No, you should not use XHTML if you can't guarantee well-formedness, and in practice you can't guarantee it if you don't use XML serializer to generate markup. Read about producing XML.
Well-formedness is the thing that differentiates XHTML from HTML. XHTML with "just one" markup error ceases to be XHTML. It has to be perfect every time.
If "XHTML" site appears to work with some errors, it's because browsers ignore the DOCTYPE and interpret page as HTML.
See XHTML proxy that forces interpretation of pages as XHTML. Most of the time they fail miserably. This is one of the reason why future of XHTML is uncertain and why development of HTML has been resumed.
虽然我同意“如果它渲染得很好，那就不用担心”的说法，但是遵循标准是有好处的，尽管它现在可能没有得到完全支持。 您仍然可以使用 Table 进行布局，但它不好是有原因的。
while I agree with the sentiment of "if it renders fine then don't worry about it" statement, however it's good for follow a standard, even though it may not be fully supported right now. you can still use Table for layout, but it's not good for a reason.
使用有效标记有许多原因。 我最喜欢的是，它允许您使用验证作为回归测试的一种形式，一旦错误达到一定的临界质量，就可以防止“delta rot”等价的标记导致真正的渲染问题。 事实上，允许诸如拼写错误和错误嵌套/未封闭标签之类的“懒惰”错误累积是非常草率的。 有效标记是识别 充满激情的程序员。
还有调试问题：有效的标记还为您提供了一个稳定的基线，可以从该基线解决不可避免的跨浏览器兼容性问题。 任何重视时间的 Web 开发人员都不应该在没有首先确保标记至少在语法上有效的情况下开始调试浏览器兼容性问题，并且任何其他无效标记都应该有充分的理由存在。
（顺便说一句，stackoverflow.com 未能通过这两项测试，并且解决问题的建议是 拒绝。）
综上所述，为了回答您的具体问题，除非您打算生成有效的（或至少格式良好的）标记，否则可能不值得使用 XHTML 文档类型之一。 XHTML 的主要优点源于 XHTML 是 XML，允许使用 XML 的工具和技术对其进行处理和转换。 如果您不打算使您的 XHTML 格式良好，那么选择该文档类型就没有意义。 最新的 HTML 4 规范可能会满足您所需的一切，而且更加宽容。
There are many reasons to use valid markup. My favorite is that it allows you to use validation as a form of regression testing, preventing the markup equivalent of "delta rot" from leading to real rendering problems once the errors reach some critical mass. And really, it's just plain sloppy to allow "lazy" errors like typos and mis-nested/unclosed tags to accumulate. Valid markup is one way to identify passionate programmers.
There's also the issue of debugging: valid markup also gives you a stable baseline from which to work on the inevitable cross-browser compatibility woes. No web developer who values his time should begin debugging browser compatibility problems without first ensuring that the markup is at least syntactically valid—and any other invalid markup should have a good reason for being there.
(Incidentally, stackoverflow.com fails both these tests, and suggestions to fix the problems were declined.)
All of that said, to answer your specific question, it's probably not worthwhile to use one of the XHTML doctypes unless you plan to produce valid (or at least well-formed) markup. XHTML's primary advantages are derived from the fact that XHTML is XML, allowing it to be processed and transformed by tools and technologies that work with XML. If you don't plan to make your XHTML well-formed XML, then there's little point in choosing that doctype. The latest HTML 4 spec will probably do everything you need, and it's much more forgiving.
我根本不会使用 XHTML 只是为了减轻自己的哲学压力。 无论如何，并不是任何浏览器都将其视为 XHTML。
如果页面作为 application/xhtml+xml 发送，浏览器将拒绝不良标记，但这种情况很少发生。 这可以。
我更关心诸如在 Stack Overflow 中内联使用 CSS 和 JavaScript 之类的事情，因为它们使维护变得更加困难。
I wouldn't use XHTML at all just to save myself the philosophical stress. It's not like any browsers are treating it like XHTML anyway.
Browsers will reject poor mark-up if the page is sent as application/xhtml+xml, but they rarely are. This is fine.
I would be more concerned about things like inline use of CSS and JavaScript with Stack Overflow, just because they make maintenance harder.
尽管我相信要努力实现有效的 XHTML 和 CSS，但由于多种原因，这通常很难做到。
我不认为大多数开发人员指定了 DOCTYPE，然后明确地不遵守它。
Though I believe in striving for valid XHTML and CSS, it's often hard to do for a number of reasons.
I don't think that most developers specify a DOCTYPE and then explicitly fail to adhere to it.
我们应该始终努力使其根据标准进行验证。 我们将确保该网站能够在当前浏览器和未来的浏览器上正常显示和工作。
We should always try to make it validate according to standards. We'll be sure that the website will display and work fine on current browsers AND future browsers.
我认为，如果您指定了一个文档类型，就没有任何理由不遵守该文档类型。
使用 XHTML 使自动错误检测变得容易，每次更改都可以自动检查无效标记。 这可以防止错误，尤其是在使用自动生成的内容时。 对于使用模板引擎（JSP、ASP.NET StringTemplate 等）的 Web 开发人员来说，复制/粘贴一个结束标记太少或太多确实很容易。 当这是您唯一的错误时，可以立即检测到并修复它。 我曾经工作过一个网站，该网站每页有 165 个验证错误，其中 2 或 3 个是实际错误。 在混乱的其他错误中很难找到这些错误。 自动验证可以从源头上防止这些错误。
不用说，选择一个标准并坚持它永远不会有利于与其他系统（屏幕抓取器、屏幕阅读器、搜索引擎）的互操作性，而且我从未遇到过无法为所有人提供有效的语义 XHTML 和 CSS 解决方案的情况主要浏览器。
显然，在使用复杂的系统时，并不总是能够坚持您的文档类型，但这主要是由于开发这些系统的不同部分（或者很可能是遗留系统）的不同团队之间沟通不当造成的。 在最后一种情况下，最好隔离这些情况并相应地更改您的文档类型。
务实一点是好事，不要仅仅因为有人这么说就坚持 XHTML，不考虑成本，但以当前有关 CSS 和浏览器、测试和验证工具的知识，大多数时候好处远远大于成本。
I don't think that, if you specify a doctype, there is any reason not to adhere to this doctype.
Using XHTML makes automated error detection easy, every change can be automatically checked for invalid markup. This prevents errors, especially when using automatically generated content. It is really easy for a web developer using a templating engine (JSP, ASP.NET StringTemplate, etcetera) to copy/paste one closing tag too little or too many. When this is your only error, it can be detected and fixed immediately. I once worked for a site that had 165 validation errors per page, of which 2 or 3 were actual bugs. These were hard to find in the clutter of other errors. Automatic validation would have prevented these errors at the source.
Needless to say, choosing a standard and sticking to it can never benefit interoperability with other systems (screen scrapers, screen readers, search engines) and I have never come across a situation where a valid semantic XHTML with CSS solution wasn't possible for all major browsers.
Obviously, when working with complex systems, it's not always possible to stick to your doctype, but this is mostly a result of improper communication between the different teams developing different parts of these systems, or, most likely, legacy systems. In the last case it's probably better to isolate these cases and change your doctype accordingly.
It's good to be pragmatic and not adhere to XHTML just because someone said so, regardless of costs, but with current knowledge about CSS and browsers, testing and validation tools, most of the time the benefits are much greater than the costs.
你可以说我对 XHTML 有效性有强迫症。 我发现代码无效的大多数问题都来自于程序员不了解 HTML 和 XHTML 之间的区别。 我编写 100% 有效的 XHTML 和 CSS 已经有一段时间了，并且在使用其他浏览器时从未遇到过任何重大的渲染问题。 如果你保持一切有效，并且不要尝试任何太奇特的 css 明智的东西，你将为自己节省大量的修复时间。
You can say that I have an OCD on XHTML validity. I find that most of the problems with the code not being valid comes from programmers not knowing the difference between HTML and XHTML. I've been writing 100% valid XHTML and CSS or a while now and have never had any major rendering problems with other browsers. If you keep everything valid, and don't try anything too exotic css wise, you will save yourself a ton of time in fixes.