XHTML 合规性毫无意义吗？
我现在正在构建一个网站，到目前为止，我已经痛苦地强制所有内容都兼容，并且它在浏览器中看起来几乎相同。 不过，我开始实现一些第三方/免费的 javascript，它们可以执行添加属性等操作（例如 order=2）。 我可以解决这个问题，但这很痛苦，而且我开始失去确保一切有效的原则。 真的，解决这样的问题有什么意义吗？ 我得到了 Firefox 的 HTMLValidator 插件，并且查看了大多数主要网站（包括这个、google 等），它们不是有效的 XHTML 或 HTML。
I'm building a site right now, so far I've painfully forced everything to be compliant and it looks pretty much the same across browsers. However, I'm starting to implement some third party/free javascripts which do things like add attributes (eg. order=2). I could work around this but it's a pain, and I'm starting to lose my principals of making sure everything is valid. Really, is there any point to working around something like this? I got the HTMLValidator plugin for firefox, and looking at most major sites (including this one, google, etc.), they aren't valid XHTML or HTML.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
我认为编写“有效代码”很重要，因为您通过遵循规则树立了榜样。 如果每个开发人员都为 Fx、Safari 和 Opera 编写过代码，我认为 IE 必须比版本 8 更早“开始遵守规则”。
I think writing "valid code" is important, simply because you're setting an example by following the rules. If every developer had written code for Fx, Safari and Opera, I think IE had to "start following the rules" sooner than with version 8.
大多数时候我都会尝试编写兼容的代码，在除一种情况外的所有情况下权衡时间/成本与观众的需求。 如果您的代码需要符合 503 标准，那么编写符合要求的代码符合您和受众的最佳利益。 我遇到过很多屏幕阅读器，当代码稍有偏差时，它们就会崩溃。
就像大多数海报所说的那样，这实际上取决于观众的需求。
I try write compliant code most of the time weighing the time/cost vs the needs of the audience in all cases but one. Where you code needs to be 503 compliant, it is in your best interest and the interest of your audience to write compliant code. I've come across a bunch of screen readers that blow up when the code is even slightly off.
Like the majority of posters said, it's really all about what your audience needs.
无论如何，这并不是毫无意义的，但有足够的理由打破它。 在 CSS 开发的初始阶段，如果您的标记有效，这对于诊断浏览器问题非常有用。 除此之外，如果您想做某事并且您认为最合适的方法是打破验证，通常没问题。
使用自定义属性的替代方法是使用“rel”属性，例如，请参阅 Litebox（及其亲属）。
It's not pointless by any means, but there is plenty of justification for breaking it. During the initial stages of CSS development it's very useful for diagnosing browser issues if your markup is valid. Beyond that, if you want to do something and you feel the most appropriate method is to break the validation, that's usually ok.
An alternative to using custom attributes is to make use of the 'rel' attribute, for an example see Litebox (and its kin).
HTML 有效通常对您和浏览器渲染引擎都有帮助。 浏览器需要处理的怪癖越少，它们就越能专注于添加新功能。 你越严格，你花时间思考为什么这个该死的专有标签在其他浏览器中不起作用的时间就越少。
另一方面，恕我直言，XHTML 更毫无意义，除非您计划将其集成到某些 XML 文档中。 由于IE仍然无法识别它，所以坚持下去是没有用的。
Being HTML Valid is usually a help for both of you and the browser rendering engine. The less quirks the browsers have to deal with, the more they can focus on adding new features. The more strict you are, the less time you'll spend time wondering why this f@#cking proprietary tag does not work in the other browsers.
On the other hand, XHTML is, IMHO, more pointless, except if you plan to integrate it within some XML document. As IE still does not recognize it, it's pretty useless to stay stick with.
当然，您总是可以继续按照您想要的方式编写它，并确保至少它可以工作。 当然，我们已经经历了这种心态，并见证了它的产出，Internet Explorer 6。
我是 Mike Davidson 方法的忠实粉丝以标准为导向的开发。
很多人误解这篇文章的意思是我们不应该按照标准编码。 显然，我们应该这样做，但这不是真正应该考虑的事情。 验证大军总是会谴责那些不进行验证的人，但验证的意义远不止于有效的代码。
因此，不要失去原则，但请记住，如果您遵循标准，那么您将来陷入问题的可能性就会大大降低。 您尝试提供的内容远比其显示方式重要。
Sure, you could always just go ahead and write it in the way you want, making sure that at minimum it works. Of course, we've already suffered this mentality and have witnessed its output, Internet Explorer 6.
I am a big fan of the Mike Davidson approach to standards-oriented development.
A lot of people misunderstand this post to mean that we shouldn't code to standards. We should, obviously, but it's not something that should even really be thought about. The validation army will always decry those that do not validate, but validation means so much more than valid code.
So, don't lose your principles, but remember that if you follow the standards you're a lot less likely to end up in the deep-end of issues in the future. The content you're trying to provide is far more important than how it is displayed.
我还没有遇到过添加非标准属性导致任何浏览器中出现渲染问题的情况。
不要尝试解决这些非标准属性。 验证器作为工具可以方便地仔细检查代码是否存在无意的错误，但众所周知，即使完全有效的 xhtml 也并不总是能够在浏览器中一致地呈现。 很多时候，设计决策要求我们使用浏览器特定的（和非标准的）技巧来实现效果。 这就是网络开发人员的生活，大量未经验证的技术驱动网站（谷歌、雅虎等）就证明了这一点。
I have yet to experience an instance where the addition of a non-standard attribute has caused a rendering issue in any browser.
Don't try to work around those non-standard attributes. Validators are handy as tools to double check your code for unintentional mistakes, but as we all know, even fully valid xhtml will not always render consistently across browsers. There are many times when design decisions require us to use browser specific (and non-standard) hacks to achieve an effect. This is the life of a web developer as evidenced by the number of technology driving sites (google, yahoo, etc.) that do not validate.
请记住，XHTML 标记在大多数浏览器中的呈现方式与没有它时的呈现方式不同。 DOCTYPE 属性确定浏览器呈现的模式并规定允许和不允许的内容。 如果您偏离了 XHTML 合规性，请务必在所有浏览器中重新测试。
就我个人而言，我尽可能坚持最新标准，但您必须权衡时间/金钱与合规性，这取决于大多数人的个人喜好。
Just keep in mind that the XHTML tag renders differently in most browsers than not having it. The DOCTYPE attribute determines what mode the browser renders in and dictates what is and isn't allowed. If you stray from the XHTML compliance just be sure to retest in all browsers.
Personally I stick with the latest standards whenever possible, but you have to weigh time/money against compliance for sure and it comes down to personal preference for most.
就浏览器而言，XHTML 合规性毫无意义，因为：
浏览器没有 XHTML 解析器。 他们有非版本特定的、与 Web 兼容的 HTML 解析器，围绕 http://www 构建 DOM .w3.org/1999/xhtml 命名空间。
一些具有 XML 解析器的浏览器可以将作为 application/xhtml+xml 的 XHTML 标记视为 XML。 这将采用 XML 并为 http://www.w3 中的元素提供默认的 HTML 样式和行为。 org/1999/xhtml 命名空间。 但是，就解析而言，它与 XHTML 无关。 遵循 XML 解析规则，而不是某些 XHTML DTD 的规则。
因此，当您使用 XHTML 标记时，您是在向浏览器提供一些陌生的东西，然后看看它是否按您的预期显示。 问题是，您可以使用任何标记来做到这一点。 如果它按预期渲染并生成正确的 DOM，那么您就做得很好了。 您只需确保牢记 DOCTYPE 切换并确保您不依赖浏览器错误（这样在没有错误的浏览器中事情就不会崩溃）。
XHTML 合规性的好处是语法检查（通过验证）以查看标记是否格式良好。 这有助于避免解析错误。 当然，这也可以使用 HTML 来完成，因此在这种情况下 XHTML 没有什么特别的。 不管怎样，你仍然需要在浏览器中进行测试，并希望浏览器供应商能够制作出出色的 HTML 解析器来接受各种垃圾。
尝试符合浏览器的期望并不是毫无意义的。 HTML5 为这一重大时刻提供了帮助。 而且，说到 HTML5，您可以根据需要定义自定义属性。 只需在它们前面加上 data- 前缀，如
test
所示。
As far as browsers are concerned, XHTML compliance is pointless in that:
Browsers don't have XHTML parsers. They have non-version-specific, web-compatible HTML parsers that build a DOM around the http://www.w3.org/1999/xhtml namespace.
Some browsers that have XML parsers can treat XHTML markup served as application/xhtml+xml as XML. This will take the XML and give default HTML style and behavior to elements in the http://www.w3.org/1999/xhtml namespace. But, as far as parsing goes, it has nothing to do with XHTML. XML parsing rules are followed, not some XHTML DTD's rules.
So, when you use XHTML markup, you're giving something alien to browsers and seeing if it comes out as you intend. The thing is, you can do this with any markup. If it renders as intended and produces the correct DOM, you're doing pretty good. You just have to make sure to keep DOCTYPE switching in mind and make sure you're not relying on a browser bug (so things don't fall apart in browsers that don't have the bug).
What XHTML compliance is good for is syntax checking (by validating) to see if the markup is well formed. This helps avoid parsing bugs. Of course, this can be done with HTML also, so there's nothing special about XHTML in this case. Either way, you still have to test in browsers and hope browser vendors make awesome HTML parsers that can accept all kinds of crap.
What's not pointless is trying to conform to what browsers expect. HTML5 helps with this big time. And, speaking of HTML5, you can define custom attributes all you want. Just prefix them with data-, as in <p data-order="This is a valid, custom attribute.">test</p>.
如果您计划利用 XHTML 作为 XML，那么让您的页面有效且格式良好是值得的。 否则，普通的旧语义 HTML 可能就是您想要的。 无论哪种方式，受众的需求都超过了验证者的需求。
If you're planning on taking advantage of XHTML as XML, then it's worth it to make your pages valid and well formed. Otherwise, plain old semantic HTML is probably want you want. Either way, the needs of your audience outweigh the needs of a validator.
验证对于确定事情何时未能满足您可能同意的标准很有用。 如果您有目的地使用专门添加验证标准之外的内容的工具，显然这不会违反您的个人标准协议。
如果你的老板或客户认为一切都应该返回绿灯，那么这种讨论就会变得更加困难，因为你必须向他们解释上述内容并说服他们这不仅仅是你的懒惰。
也就是说，请确保这不仅仅是因为您懒惰。 虽然验证器可能会令人烦恼地不断地提出第三方属性的每个实例，但这并不会使他们提到的其他验证错误无效（哈）。 作为双重检查工作的一种方式，通常值得进行扫描。
The validation is useful to determine when things are failing to meet standards you presumably agree with. If you are purposefully using a tool that specifically adds something not in the validation standards, obviously that does not break your personal standards agreement.
This discussion gets much more difficult if you have a boss or a client who believes everything should return the green light, as you'll have to explain the above to them and convince them it's not simply you being lazy.
That said, be sure it's not simply be a case of you being lazy. While the validators may annoyingly constantly bring up every instance of the third party attribute, that doesn't invalidate (ha) the other validation errors they're mentioning. It's often worth scanning through as a means of double-checking your work.
标准合规性是为了增加您的页面在您未测试的浏览器中运行的机会。 这包括屏幕阅读器、您测试的浏览器的下一个更新，以及您测试但已被用户以意外方式配置的浏览器。
验证并不能向您保证任何事情，因为您的页面可能会经过验证，但仍然不够明确，以至于有一天它在某些浏览器上的行为不会像您希望的那样。
然而，如果您的页面确实通过了验证，那么您至少可以通过 XHTML 规范来说明它的行为方式。 如果它没有验证，那么您所拥有的只是浏览器编写者之间的一堆非正式约定。
如果您想要做的某件事在一个 HTML 3 中是允许的，但在另一个 HTML 3 中不允许，那么编写有效的 HTML 3 可能比编写无效的 XHTML 更好。
Standards compliance is about increasing the chance that your page will work in the browsers you don't test against. This includes screen readers, and the next update of the browsers you do test against, and browsers which you do test against but which have been configured in unexpected ways by the user.
Validating doesn't guarantee you anything, since it's possible for your page to validate but still be sufficiently ambiguous that it won't behave the way you want it to on some browser some day.
However, if your page does validate, you at least have the force of the XHTML spec saying how it should behave. If it doesn't validate, all you have is a bunch of informal conventions between browser writers.
It's probably better to write valid HTML 3 than invalid XHTML, if there's something you want to do which is allowed in one but not the other.