无效的XHTML是否可以接受?

时间:2008-08-06 14:21:19

标签: xhtml markup

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

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

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

14 个答案:

答案 0 :(得分:16)

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

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

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

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

答案 1 :(得分:2)

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

答案 2 :(得分:2)

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

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

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

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

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

答案 3 :(得分:2)

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

答案 4 :(得分:1)

不,如果不能保证格式良好,则不应使用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

的原因之一

答案 5 :(得分:1)

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

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

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

答案 6 :(得分:1)

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

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

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

答案 7 :(得分:1)

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

答案 8 :(得分:0)

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

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

答案 9 :(得分:0)

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

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

答案 10 :(得分:0)

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

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

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

答案 11 :(得分:0)

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

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

答案 12 :(得分:0)

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

答案 13 :(得分:0)

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

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