DOCTYPE的选择是否会影响DOM，如JavaScript代码所示？ [英] Does the choice of DOCTYPE affect the DOM as seen by javascript code?

问题描述

鉴于使用ASP.NET，javascript，css等技术的大型遗留项目，我想知道如果更改网页的DOCTYPE，比如说，从HTML 4.0过渡到XHTML 1.0 Transitional（或者相反）以任何方式可能会破坏网页的JavaScript功能。

有很多关于不同DOCTYPES如何影响（css）页面渲染的文章和讨论，但是我似乎没有找到任何类似的东西打破任何代码。

我正在寻找一些关于事情的文章的链接，以便更好地发现潜力现有代码中的问题，避免在编写新代码时出现问题。

解决方案

无论更改DOCTYPE是否会破坏任何JavaScript函数，防御性地，这些功能被设计为：）

例如，当以怪癖模式呈现文档时， document.body （BODY）成为所谓的根元素;当以标准模式呈现时，该根元素通常是一个 document.documentElement （HTML）。这是一个相当实质的区别。如果确定浏览器屏幕大小的脚本始终从文档查询 clientWidth / clientHeight 属性。 documentElement ，显然会在怪异模式下报告错误的结果（因为IIRC， document.documentElement.clientWidth / clientHeight 将表示HTML元素的维度，而不是屏幕的）。

大多数JS库通常会明确指出是否支持quirksmode（我们 - Prototype.js - 例如，不支持怪癖模式）

说到 HTML与XHTML ，为了让浏览器将文档呈现为XHTML，您必须首先使用适当的内容-type标头（即application / xhtml + xml）。如果您只将文字更改为XHTML，但仍将文档作为text / html提供，我认识的大部分浏览器仍然会将其解析为HTML文档。

$ b $请注意，到目前为止，IE不了解真正的XHTML内容，这就是为什么以文本/ HTML格式（用HTML4.01 doctype）提供文档是推荐的方法（除非IE是

就真实XHTML文档中的DOM特性而言，我听说过像这样的东西， document.write 不工作，并且访问节点属性应始终通过 getAttribute / setAttribute 执行（而不是通过简单的属性访问器） 。 IIRC，还有一些问题与 innerHTML 。

在真实XHTML文档中缺少关于DOM的信息可能是因为在一般网络的文档/应用程序（即IE不支持）中的不切实际性。

Given a large legacy project utilizing ASP.NET, javascript, css, etc, technologies, I was wondering if changing the DOCTYPE of the web pages, say, from HTML 4.0 Transitional to XHTML 1.0 Transitional (or the other way around) in any way could break the javascript functions of the web pages.

There are plenty of articles and discussions about how different DOCTYPES affect the (css) rendering of pages, but I cannot seem to find anything similar on the subject of breaking any code.

I am looking for links to articles about things to watch out for in general so as to better spot potential problems in existing code and avoid creating problems when writing new code.

解决方案

Whether changing DOCTYPE will break any javascript functions really depends on how defensively those functions are designed :)

For example, when document is rendered in quirks mode, document.body (BODY) becomes a so called "root element"; when rendered in standard mode, that root element is usually a document.documentElement (HTML). This is a rather substantial distinction. If a script that determines browser screen size always queries clientWidth/clientHeight properties off of document.documentElement, it will obviously report incorrect results in quirks mode (since, IIRC, document.documentElement.clientWidth/clientHeight would represent dimensions of HTML element, rather than screen ones).

Most of the JS libraries usually explicitly state whether quirksmode is supported (we - Prototype.js - for example, don't support quirks mode).

Speaking of HTML vs XHTML, in order for browser to render document as XHTML, you must first of all serve it with proper "Content-type" header (i.e. application/xhtml+xml). If you only change doctype to XHTML one, but still serve document as "text/html", most browsers I know will still parse (and render) it as HTML document.

Note that to date, IE doesn't understand "real" XHTML content, which is why serving documents as text/html (with HTML4.01 doctype) is a recommended way to go (unless IE is not among supported browsers, of course).

As far as DOM peculiarities in "real" XHTML documents, I've heard that some things like document.write "don't work" and that accessing node attributes should always be performed via getAttribute/setAttribute (rather than via simpler property accessors). IIRC, there are also some issues with innerHTML.

The lack of information about DOM in "real" XHTML documents is probably due to its impracticality in documents/applications for general web (i.e. IE's lack of support for it).

这篇关于DOCTYPE的选择是否会影响DOM，如JavaScript代码所示？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！