通过 Doctype 启用浏览器模式
为了即能解析那些满足Web标准的网页，又能解析那些过去20年来遗留下来的传统的网页，现代浏览器一般都实现了多种网页解析的模型。本文将介绍这些解析模型都是什么，以及它们是如何触发的。
内容概述
本文档的主要结论是，你应当在你HTML文档（所有以text/html类型处理的内容）的源代码顶部加上<!DOCTYPE html>。（详见下文）
如果你还想确保使用IE8/IE9/IE10的用户不做任何操作就可以让网页以IE7的形式显示，你可以在你的服务器上为所有text/html的响应添加HTTP头"X-UA-Compatible: IE=Edge"，还可以在HTML文档的head内的最上方加上<meta http-equiv="X-UA-Compatible" content="IE=Edge">。然而这将会导致HTML文档不能通过校验（HTML document invalid）。其实即使你不加上这些IE-specific声明，IE大部分情况下的默认行为也是合理的，因此，你也不需要对这些IE-specific过于依赖。（下文将会介绍例外的情况）
本文档的适用范围
本文档几乎覆盖了所有的浏览器，包括以Firefox为代表的Gecko内核的浏览器、以Safari/Chrome为代表的Webkit内核的浏览器、Opera、Konqueror、IE for Mac、IE for Windows/Windows Phone以及那些内嵌IE内核的其它浏览器。下面我们将不再使用这些浏览器引擎的名称，而是以各引擎的典型浏览器的名称来代替。
本文档重点说明的不是这些模式的具体行为，而是它们的选择机制。希望能让你明白如何避免（不小心使用）那些过期的模式，而不是告诉你如何故意使用这些过期的模式实现最佳的行为。
模式介绍
本文将介绍以下这些模式:
适用于text/html类型的常见模式
对text/html类型的内容来说，模式的选择取决于对文档的doctype探测（参见下文的doctype探测章节）。在IE8及更高版本的浏览器中，模式还取决于一些其它因素。在IE8及更高版本浏览器，对于不在微软提供的黑名单上的网站，模式取决于doctype。如果安装了Google Chrome Frame，将会受到另外一些因素的影响，甚至会影响到IE6和IE7。
-
怪癖模式（Quirks Mode）
在怪癖模式中，为了避免“破坏”那些根据上世纪90年代末流行的实践创作的页面，浏览器违反了现代的Web格式规范。不同的浏览器实现了不同的怪癖行为。以前，不同的浏览器实现了不同的怪癖模式，比如IE6/7/8/9里的怪癖模式就是IE5.5模式，其它浏览器的怪癖模式则是对近乎标准模式的一种修改。最近各浏览器已经开始在它们的怪癖模式里应用相同的行为，尤其要提到的是IE10的怪癖模式已不再模仿IE5.5，而是与其它浏览器的怪癖模式保持一致。目前WHATWG正在制定怪癖模式的标准。
和其它浏览器中的怪癖模式一样，IE10的怪癖模式有时会被称为"互操作性怪癖模式"(interoperable Quirks mode）以与IE10的模仿IE5.5的怪癖模式（Internet Explorer 5 Quirks）进行区别。
如果你正在编写一个新的页面，请使用标准模式，而坚决不要使用怪癖模式。
-
标准模式（Standards Mode）
标准模式中，这些浏览器将尝试以各自实现的程度规范正确地处理文档。。
不同的浏览器遵循不同的阶段，所以标准模式也不是一个单一目标。
HTML标准中称这种模式为 “非怪癖模式”（no quirks mode）。
-
近乎标准模式（Almost Standards Mode）
Firefox, Safari, Chrome, Opera (从7.5开始), IE8, IE9 and IE10 还有一个称为近乎标准模式（the Almost Standards mode）的模式，这种模式以传统的方式设定表格的垂直高度，而没有遵从CSS2的标准。Mac IE 5、Windows IE 6/7、Opera prior to 7.5以及Konqueror并不需要该模式，因为这些浏览器的标准模式也没有按照CSS2的标准设定表格的垂直高度。事实上，相对于较新的浏览器的标准模式，它们的标准模式更接近于近乎标准模式。回顾过去, 如果没有"标准模式"与"近乎标准模式"的区别，Web或许会更好，可以默认使用近乎标准模式的行为，再利用样式表特性选择标准模式下的行为。然而，你还是应该用标准模式，而不要用近乎标准模式。HTML标准中称这种模式为有限怪癖。
适用于application/xhtml+xml类型的模式（XML模式）
在Firefox, Safari, Chrome, Opera 和 IE9 里，如果HTTP响应中的Content-type是application/xhtml+xml时会触发XML模式，需要强调的是触发条件是HTTP的 Content-type，不是HTML中的<meta...>元素，也不是HTML的doctype。在XML模式下，这些浏览器将以各自实现的程度规范正确地处理XML文档。
IE6/7/8不支持application/xhtml+xml，Mac版的IE5也不支持。
在基于Webkit的Nokia S60浏览器上，由于考虑到在围墙花园（译者按：walled garden，指的是一个控制用户对网页内容和服务进行访问的环境，围墙花园把用户限制在一个特定的范围内，它允许用户访问指定的内容，同时防止用户访问其他未被允许的内容。）环境下对病态内容的兼容性，application/xhtml+xml的HTTP Content-type并不触发XML模式。因为传统的移动浏览器并没有使用真正的XML解析器，那些病态内容也会被作为XML对待。
我并没有测试 Symbian3上的默认浏览器。
我没有对Konqueror进行过充分的测试，不好说这个浏览器的具体行为。
微软额外提供的一些IE-Specific模式
下面列出了一些额外的IE-specific模式，这些模式并不适用于HTML5，也不适用于其它不支持这些模式的浏览器，它们通过配置来激活，还可以通过"X-UA-Compatibleas"的HTTP头，或者html里的meta元素进行激活。
-
Internet Explorer 5 Quirks
除了互操作性怪癖模式外，IE10还有一个称为Internet Explorer 5 Quirks的模式，它模仿了IE5.5的行为，这种模式在IE6/7/8/9中称为怪癖模式。
-
Internet Explorer 7 Standards
IE8/9/10使用该模式模拟IE7的标准模式。
-
Internet Explorer 8 Standards
IE9/10使用该模式模拟IE8的标准模式。
-
Internet Explorer 8 Almost Standards
IE9/10使用该模式模拟IE8的近乎标准模式行为。在界面上的开发者工具箱中，这个模式与IE8标准模式没什么区别。
-
Internet Explorer 9 Standards
IE9/10使用该模式模拟IE9的标准模式。
-
Internet Explorer 9 Almost Standards
IE10使用该模式模拟IE9的近乎标准模式行为。在界面上的开发者工具箱中，这个模式与IE9标准模式没什么区别。
-
Internet Explorer 9 XML
IE10使用该模式模拟IE9的XML模式行为。在界面上的开发者工具箱中，这个模式与IE9标准模式没什么区别。
值得注意的是，对上一版本的IE的模拟并不够完美，我自己就遇到过一些例子：比如在IE7以上的版本中使用IE7的标准模式对@font-face（像 EOT字体）的处理是不同的；还有，在IE10的IE9模式下CSS的2D变换是不需要-ms-前缀的，但是真正的IE9却需要该前缀。如果你认同本文给出的建议，请不要过于关注这些模式，这些兼容模式也将不会对你的产品带来不好的影响。然而对于快捷测试来说，相对于在虚拟机中使用老版本的IE进行测试，还不如在一个较新的IE上使用不同的兼容模式进行测试。
另外，IE10的Windows Phone版与Windows桌面版相同，都有上面所说的这些模式。
Google额外提供的一些IE-Specific模式
当安装了Google Chrome Frame后，IE6/7/8/9（不包括Windows8以及2013年2月的Windows7上的IE10）还可提供以下这些额外的模式。
-
Chrome Quirks
此模式相当于Google Chrome上的怪癖模式。
-
Chrome Standards
此模式相当于Google Chrome上的标准模式。
-
Chrome Almost Standards
此模式相当于Google Chrome上的近乎标准模式。
非Web模式
有些模式还提供了一些与Web内容不相关的模式。在这里提到这些模式仅仅出于对此文档的完整性考虑。包括Opera的WML2.0模式，Mac OS X 10.5上WebKit浏览器上的特殊模式（用于传统的Dashboard widgets，或许这个模式目前仍有更新，我没有考察不是很确定）。以及为Mac OS X上内嵌WebKit浏览器的应用程序单独提供的模式。
模式的影响
模式的主要影响如下:
页面布局
除IE外，对于text/html类型的模式主要影响样式表布局以及样式系统。例如，表格内不会继承样式表；在IE和Opera的老版本中的怪癖模式下，盒模型变成了IE5.5的盒模型。本文档并不会枚举所有的怪癖布局，你可以查阅 Mozilla文档 以及 怪癖模式标准 获得完整列表。
在近乎标准模式中（在所有包含此模式的浏览器中），仅含有图片的单元格高度的计算方式与标准模式不同。
在XML模式中，选择器对查询条件的大小写有不相同的处理行为，另外，对于那些没有实现更多的样式表规范的老版本浏览器中，并不包含对body元素的特殊规则。
内容解析
也有一些差异会影响到HTML和CSS的解析，并且可能会导致一些正常的页面被错误的解析。 这些差异会随着对布局的影响而同时产生影响。重要是要知道怪癖模式和标准模式的主要差别在于CSS布局和CSS的解析，而不是对HTML的解析。对于已经兼容HTML5的浏览器，也有一些关于HTML解析的差异。
一些人会把标准模式误认为是“严格解析模式”，他们会觉得这样的话，浏览器会强制遵守HTML语法规则，会对HTML标记的正确性进行评估。事实上既然在标准模式下，浏览器仍会对HTML标签进行必要的修复。（2000年夏，Netscape 6 发布前，Gecko浏览器确实包含一些强制按HTML语法规则进行解析的模式，其中一种模式称为“标准定义”，这些模式并不能兼容目前的网页内容，已经过期了。）
另外一个常见的误解是关于解析XHTML的。大家通常认为声明为XHTML的doctype会带来不同的解析。事实上XHTML文档也是text/html类型的，也只是“蛋花标签汤”而已，到处都是额外的斜线》只有文档以XML类型（如application/xhtml+xml或application/xml）输出时才会触发与HTML解析完全不同的XML模式的解析。
脚本
虽然怪癖模式主要影响的是CSS，但是还有一些脚本也会受到影响。直到Firefox14，其近乎标准模式下，还是不能直接使用标签的ID来引用标签对象。在Firefox的怪癖模式中有document.all对象，但是在其它模式中却没有该对象。当在IE中模拟低版本IE时，这些影响更搞笑。
在XML模式中，一些DOM API表现很不一样，因为对XML的DOM API与HTML是完全不同的，唉，实在很遗憾。
doctype嗅探（也叫doctype转换）
现代浏览器使用doctype嗅探来决定text/html文档的引擎模式。这意味着模式的选择是基于HTML文档开始的文档类型声明（或缺少）。（这不适于使用XML文档类型的文档。）
文档类型声明（doctype）是SGML的语法伪造，SGML是个旧式的标记框架，HTML5之前的HTML就是依据其定义的。HTML4.01规范中，文档类型声明描述的是HTML的版本信息。尽管名字叫“文档类型声明”且HTML 4.01规范所描述的是关于“版本信息”，文档类型声明并不适用把SGML或XML文档分类为特定类型的文档，即使它看起来像是（因为名字）。（更多内容在附录中）
HTML4.01规范和ISO 8879（SGML）都没有说关于使用文档类型声明作为引擎模式转换的任何事情。doctype嗅探是基于观察，在doctype嗅探被设计时，绝大部分的怪癖文档既没有文档类型声明也没有引用旧的DTD。HTML5接受这个事实，且定义了text/html中doctype作为唯一的模式转换。
典型的预HTML5（pre-HTML5）文档类型声明包含（被空白分开）“<!DOCTYPE”字符串，根元素（“html”）的通用标识符， “PUBLIC”字符串，处于引号中的DTD公共标识符，同一DTD的可能系统标识符（URL）和字符 “>”。文档类型声明位于文档的根元素开始标签之前。
选择Doctype
text/html
下面是创建新的text/html文档时如何选择doctype的简单指南：
-
标准模式，最前沿的验证
<!DOCTYPE html>
如果想验证诸如<video>、<canvas>和ARIA这样的新特性，那么这样做是对的。注意，HTML5的有效定义依旧在变化中，请确保在Firefox、Safari、Chrome、Opera9或Opera10中测试图像对齐。在Internet Explorer中测试图像对齐是不足够的，无论如何请确保在IE8中也进行了测试。
-
标准模式，更稳定的验证目标
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
这个doctype也会触发标准模式，但是由于对新功能不了解，这些传统的验证不是很精确，为避免你的组织需要进行对验证目标的守旧的策略。你还是应该把使用<!DOCTYPE html>修改为你们组织的设计策略。
另外，如果你使用表格显示切片图像，你最好使用标准模式。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
它会触发近乎标准模式。请注意，如果以后移植到HTML5上，基于利用表格实现的切片图像的布局可能会被破坏（完整标准模式也如此）。所以最好现在就确认你的设计是兼容标准模式的吧。
-
故意要使用怪癖模式
没有doctype。
请别这样做。故意为怪癖模式所做的设计将会困扰你、你的同事以及你未来的继任者。
如果你仍然想支持IE6，对IE6使用条件注释做一个特别的hack比应用怪癖模式更好。
我不推荐任何的XHTML doctype，因为XHTML被用作text/html被认为是有害的。如果你选择使用XHTML doctype，那么请注意XML声明会使IE6触发怪癖模式（IE7不会）。
application/xhtml+xml
对application/xhtml+xml的简单指南是绝不使用doctype。该方式下的网页不是“严格一致”的XHTML1.0，但这并不重要。（请看后面的附录）
IE8/9/10相关的问题
A List Apart上的这篇文章介绍说，IE8除doctype外会使用基于meta元素的模式转换作为模式选择的因素之一。（请看Ian Hickson、David Baron、David Baron again、Robert O’Callahan和Maciej Stachowiak的评论。）
IE8有4种模式：IE5.5怪癖模式、IE7标准模式、IE8 近乎标准模式和IE8标准模式。IE9有7种模式：IE5.5怪癖模式、IE7标准模式、IE8 近乎标准模式、IE8标准模式、IE9 近乎标准模式、IE9标准模式和IE9 XML模式。IE10有11种模式：IE5.5怪癖模式、IE7标准模式、IE8 近乎标准模式、IE8标准模式、IE9 近乎标准模式、IE9标准模式、IE9 XML模式、IE10怪癖模式、IE10近乎标准模式、IE10标准模式以及IE10 XML模式。模式的选择取决于来自几个方面的数据：doctype、meta元素、HTTP头、来自微软的定期下载数据、局域网域、用户所做设置、局域网管理员所做设置、父框架的模式（如果有）和地址栏兼容视图按钮被用户触发。（对于嵌入该引擎的其他应用，模式也取决于嵌入的应用。）
幸运的是如果出现下列情况，IE8/9大体上会像其他浏览器一样使用doctype嗅探，而IE10则会严格地使用doctype进行嗅探：
-
作者没有设置X-UA-Compatible HTTP头
-
作者没有设置X-UA-Compatible meta标签
-
域名没有被微软添加到黑名单中
-
局域网管理员没有把该站点放置到黑名单上
-
用户没有按下兼容视图按钮(或以其他方式添加到某个特定的用户黑名单中) (Metro IE10 没有此按钮, 但是桌面里IE10的兼容视图也会影响到Metro模式下的IE10)
-
该站点不在局域网域中
-
用户没有选择以IE7模式显示所有站点
-
页面没有通过frame嵌入到兼容模式的页面中
上述除两个关于X-UA-Compatible的情况外，IE8/9像IE7一样执行doctype嗅探。IE7 emulation就是兼容视图。
在 X-UA-Compatible 情况下，IE8/9的行为和其他浏览器完全不同。想看本页的附录或PDF和PNG格式的流程图。 (与其它浏览器图表的对比：PDF格式) 还有一个从IE5.5到IE9的统一的图 (包括了 Chrome Frame)：PDF格式. (我打算做一个只包含IE9的这么一张图)
不幸的是，没有 X-UA-Compatible的HTTP头或meta标签，即使使用了合适的doctype，IE8/9让用户无意间使页面从标准模式降到IE7模式，这是一种仿真的IE7标准模式。更糟糕的是，局域网管理员也可以这么做。微软也可以把你所用的所有域名到列入黑名单（比如mit.edu）。
为了对付这些影响，doctype是不够的，你需要X-UA-Compatible HTTP头和meta标签。
如果一个新的页面已经使用doctype触发了其它浏览器的标准模式，或者近乎标准模式。那么下面的内容将指导你如何利用X-UA-Compatible HTTP头或meta标签：
-
你的域名没有在微软的黑名单上，而且你更关心网页里没有使用那些令人讨厌的浏览器专属内容，而不在乎用户能不能使用IE7模式显示你的网页。
你不需要添加X-UA-Compatible HTTP头或meta标签。
-
你的域名在微软的黑名单中，或者你的域名里有些网页有问题而导致用户可能会对整个域启用兼容视图，你担心Google或Digg用frame嵌入你的站点，或你想确保用户不能对你的网页使用兼容视图
你可以将此meta标签添加在你的网页里所有脚本之前（在HTML5中该标签是不合法的）：<meta http-equiv="X-UA-Compatible" content="IE=Edge">；或者为你的页面设置此HTTP头：X-UA-Compatible: IE=Edge。
-
你的网站在IE7下运行良好，在IE8/9下不能正常运行
首先你可以将此meta标签添加在你的网页里所有脚本之前（在HTML5中该标签是不合法的）：<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">；或者为你的页面设置此HTTP头：X-UA-Compatible: IE=EmulateIE7。
然后将你的网站修复为不依赖任何非IE7标准的内容，并迁移到IE=Edge。
-
你的网站在IE8下运行良好，在IE9下不能正常运行
首先你可以将此meta标签添加在你的网页里所有脚本之前（在HTML5中该标签是不合法的）：<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8">；或者为你的页面设置此HTTP头：X-UA-Compatible: IE=EmulateIE8。
然后将你的网站修复为不依赖任何非IE8标准的内容，并迁移到IE=Edge。
-
你的网站在IE9下运行良好，在IE10下不能正常运行
首先你可以将此meta标签添加在你的网页里所有脚本之前（在HTML5中该标签是不合法的）：<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9">；或者为你的页面设置此HTTP头：X-UA-Compatible: IE=EmulateIE9。
然后将你的网站修复为不依赖任何非IE9标准的内容，并迁移到IE=Edge。
Google Chrome Frame相关的问题
Google Chrome Frame 是一个适用IE6/7/8/9的浏览器扩展和插件，它使用IE的网络连接但是添加了Google Chrome引擎。安装之后默认还是IE的行为，但是网页却可以使用一个X-UA-Compatible的HTTP头，或者一个meta标签切换到Chrome引擎上。
在任何安装了Chrome Frame的浏览器环境下设置X-UA-Compatible为chrome=1，都会激活Chrome Frame。如果设置X-UA-Compatible为chrome=IE6，则只会为IE6激活Chrome Frame。如果设置X-UA-Compatible为chrome=IE7，则只会为IE6和IE7激活Chrome Frame。如果设置X-UA-Compatible为chrome=IE8，则只会为IE8及以下的浏览器激活Chrome Frame。
这些激活Chrome Frame的指令可以与激活其它IE兼容模式的指令合并起来一起控制IE使用的引擎，使用逗号或分号将这些指令分隔即可，比如：<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=IE8">。
网页一旦激活了Chrome Frame，那么就像在普通的Chrome里那样的选择这四种模式（标准模式、近乎标准模式、怪癖模式、XML模式）之一了。
但是，还有两个避免使用Chrome Frame的关键因素：
-
Chrome Frame不支持IE的可访问性支持。如果激活了Chrome Frame，IE里的内容区域就不能使用IE的可访问性支持了，这就意味着屏幕阅读器以及Window语音识别不能在Chrome Frame下正常运行。
-
你的网站应该告诉那些将要安装Chrome Frame的用户，启用网站安装防御模式，以告诉用户他们为了使用这个网站需要在本机安装一个有权限的本地代码插件。
相关网页链接
-
Eric Meyer写的关于Mac IE 5的模式 Use the Right Doctype
-
Mozilla’s DOCTYPE sniffing 作者：David Baron
-
CSS Enhancements in Internet Explorer 6 作者：Lance Silver，讨论了Windows IE6的模式以及doctype嗅探
-
Faruk Ateş写的关于IE8的 IE8 and the X-UA-Compatible situation
补遗：对XML的实现者和规范作者的恳求
请不要把doctype嗅探带到XML。
doctype嗅探是用标签杂烩汤似的方法解决一个标签杂烩汤问题。doctype嗅探是在HTML4和CSS2规范发布后设计的一种试探方法，它从文档中区分出过时文档以符合其作者可能期望的行为。
偶尔有人建议在XML上使用doctype嗅探来调度不同的处理、识别正在使用的词汇表或激活特性。这是个坏主意。调度和词汇表识别应该是基于名字空间的，而特性激活应该是基于明确的处理指令或元素。
良构（well-formedness）的整个思想是介绍允许XML的无DTD解析，且推广无doctype文档。在正式情况下，两个XML文档有相同的规范形式且应用不同地处理它们（且不同之处并非因为没有选择处理外部实体），这个应用或许被破坏了。在实践情况下，如果两个XML文档导致同样的内容被报告（qnames忽略）给SAX2内容处理器且应用不同地处理文档，这个应用或者被破坏了。考虑到作为 Web作者无法相信每个人都会使用解决额外实体的XMLprocessor来解析其页面（即使一些浏览器看起来这样做，因为它们会映射一定公共的标识符到一个有删节的定义实体的DTD），插入doctype到XML中用于Web是毫无意义的且通常会导致货运崇拜（cargo cultish）习惯。(您仍然使用W3C验证器的DTD覆盖功能来对一个DTD进行验证，虽然W3C验证器会说结果仅仅是暂时有效。或更好的是，你可以用放宽NG验证，它不会污染模式引用的文档。)为了嗅探而要求doctype是非常愚蠢的，即使那是在HTML实践中的解决方法。
此外，当低级别的规范定义两个相等的东西时，高级别的规范不应该尝试给它们不同的含义。请考虑<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">。如果删除公共标识符，依旧指定了同样的DTD，因此doctype<!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">表示和前面的doctype一样。应该不同地嗅探它们么？可以进一步理论。假设复制给example.com一个叫foobar.dtd的DTD：<!DOCTYPE html SYSTEM "http://example.com/foobar.dtd">。这该如何嗅探？应该是同一个意思。甚至整个DTD可以贴在一起。
换句话说，如果有#include “foo.h”，你不应该给名字foo.h绑定任何black magic，因为它应该允许复制foo.h的内容到文档中或复制foo.h到bar.h中且表示#include “bar.h”。
我不担心HTML和SGML构造相同的参数的原因是Web浏览器不会使用真正的SGML解析器去解析HTML，所以我认为伪装成SGML进行处理是没有用的。如果你还不相信，请看W. Eliot Kimber’s comp.text.sgml post about the matter。
附录：text/html中一些doctype的处理方式
下表中，怪癖模式、标准模式和近乎标准分别表示为Q、S和A。当浏览器仅有两种模式时，如果表格单元格的行高和Mozilla的标准模式表现一致时，标准模式标记为“S”，如果表格单元格的行高和Mozilla的几乎标准模式表现一致时，则标记为“A”。
请注意使用XML内容模型的XHTML将会以XML模式进行渲染。
本表中所有的doctype并不都是新建页面的合理选择。本表只是列出了我推荐所依据的数据。
以下是表头的说明：
-
NS6：Mozilla 0.6…0.9.4 and Netscape 6.0…6.2.3
-
Old Moz：Mozilla 0.9.5 through 1.1 alpha and Mozilla 1.0
-
Moz & Safari & Opera 10 & IE10 & HTML5：Mozilla 1.0.1, Mozilla 1.1 beta and later, Firefox, Netscape 7 and later, Safari 0.9 and later, Opera 10 and later, Chrome, Konqueror 3.5, IE10, the HTML5 specified behavior
-
Opera 9.0：Opera 9.0…9.20
-
IE 8, IE 9 & Opera 9.5：IE 8 or IE 9 by default when there is noX-UA-Compatible override nor a Compatibility View override (“A” means the IE8 Almost Standards mode for IE8 and IE9 Almost Standards mode for IE9), Opera 7.5…8.54 and 9.5…9.6
-
IE 7 & Opera 7.10：Windows IE 7, IE 8 with Compatibility View enabled but withoutX-UA-Compatibleoverride (in this case “A” means the IE7 mode) and Opera 7.10…7.23
-
IE 6 & Opera 7.0：Windows IE 6 and Opera 7.0…7.03
-
Mac IE 5：Mac IE 5.0…5.2.3
-
Konq 3.2：Konqueror 3.2.2…3.3 (possibly also 3.1…3.2.1; I have not been able to confirm)
下面是一个表格，如果不能正常显示，请参见原文：https://hsivonen.fi/doctype/
历史记录
Moziila的doctype嗅探代码在2000年10月、2001年9月和2002年6月有大幅度的修改。本文档描述的Mozilla（和 Netscape 6.x）建立的状态可以自2000.10.19起在ftp.mozilla.org上看到。本文档未涉及Mozilla M18（和Netscape 6.0 PR3）中的doctype嗅探的工作方式。Safari的doctype嗅探代码自第一个公开的测试版起也有大幅度的修改。本文档不包括比版本V73也叫0.9更早的行为。
Konqueror3.5之前的doctype嗅探代码似乎来自于Safari的很早的一个版本。Konqueror现在和Safari匹配，其doctype嗅探代码来自Mozilla。
从表中可见，Opera的doctype嗅探正由规律的从类似IE向类似Mozilla转变，虽然Opera9.5和9.6在倒退的路上。同时，Opera怪癖模式的布局行为已从仿效IE6的怪癖模式转换到Mozilla的怪癖模式。
附录：IE8的模式选择
开始选择
-
X-UA-Compatible meta元素
-
IE=7: 使用 IE7 标准模式
-
IE=EmulateIE7: 参见 “怪癖模式或无模式 (兼容模式)”.
-
IE=IE8 or IE=IE7 or IE=a or IE=EmulateIE8 or absent or has script first: 参见 “X-UA-Compatible HTTP 头”.
-
IE=8 or IE=Edge or IE=99 or IE=9.9: 参见 “近乎标准模式Doctype?”.
-
IE=5: 使用怪癖模式 (IE 5.5).
-
X-UA-Compatible HTTP 头?
-
IE=7: 使用 IE7 标准模式
-
IE=EmulateIE7: 参见 “怪癖模式或无模式 (兼容模式)”.
-
IE=IE8 or IE=IE7 or IE=a or IE=EmulateIE8 or absent: 参见 “显示所有互联网站点...预设”.
-
IE=8 or IE=Edge or IE=99 or IE=9.9: 参见 “近乎标准模式Doctype?”.
-
IE=5: 使用怪癖模式 (IE 5.5).
-
怪癖模式或无模式 (兼容模式)
-
Yes: 使用怪癖模式 (IE 5.5).
-
No: 使用 IE7 标准模式
-
显示所有互联网站点...预设
-
Yes: 参见 “怪癖模式或无模式 (兼容模式)”.
-
No: 参见 “显示所有内联网站点...预设”.
-
显示所有内联网站点...预设
-
Yes: 参见“是否在内联网区域”.
-
No: 参见“域名是否在微软管理的列表中”.
-
是否在内联网区域
-
Yes: 参见 “怪癖模式或无模式 (兼容模式)”.
-
No: 参见 “域名是否在微软管理的列表中”.
-
域名是否在微软管理的列表中
-
Yes: 参见 “怪癖模式或无模式 (兼容模式)”.
-
No: 参见 “是否被兼容模式的页面嵌入”.
-
是否被兼容模式的页面嵌入
-
Yes: 参见 “怪癖模式或无模式 (兼容模式)”.
-
No: 参见 “是否按下了兼容模式按钮”.
-
是否按下了兼容模式按钮
-
Yes: 参见 “怪癖模式或无模式 (兼容模式)”.
-
No: 参见 “怪癖模式或无模式 (IE8)”.
-
怪癖模式或无模式 (IE8)
-
Yes: 使用怪癖模式 (IE 5.5).
-
No: 参见 “近乎标准模式Doctype?”.
-
近乎标准模式Doctype?
-
Yes: 使用IE8近乎标准模式
-
No: 使用IE8标准模式
致谢
感谢Simon Pieters、Lachlan Hunt和Anne van Kesteren帮助我改正了各种Opera版本的模式表和他们的评论。感谢Simon Pieters制作了另一份IE8的流程图。