常见浏览器兼容性问题汇总.docx

常见浏览器兼容性问题汇总1 W3C标准规范1.1 W3C简介 万维网联盟创建于1994年，是Web技术领域最具权威和影响力的国际中立性技术标准机构。到目前为止，W3C已发布了200多项影响深远的Web技术标准及实施指南，如广为业界采用的超文本标记语言（标准通用标记语言下的一个应用）、可扩展标记语言（标准通用标记语言下的一个子集）以及帮助残障人士有效获得Web内容的信息无障碍指南（WCAG）等，有效促进了Web技术的互相兼容，对互联网技术的发展和应用起到了基础性和根本性的支撑作用。1.2 主要工作 W3C 最重要的工作是发展 Web 规范，这些规范描述了 Web 的通信协议（比如 HTML 和 XHTML）和其他的构建模块1.3 主要贡献 W3C为解决 Web 应用中不同平台、技术和开发者带来的不兼容问题，保障 Web 信息的顺利和完整流通，万维网联盟制定了一系列标准并督促 Web 应用开发者和内容提供者遵循这些标准。标准的内容包括使用语言的规范，开发中使用的导则和解释引擎的行为等等。W3C也制定了包括XML和CSS等的众多影响深远的标准规范。 但是，W3C 制定的 web 标准似乎并非强制而只是推荐标准。因此部分网站仍然不能完全实现这些标准。特别是使用早期所见即所得网页编辑软件设计的网页往往会包含大量非标准代码。 W3C 致力于对web 进行标准化 W3C 创建并维护了 WWW 标准 W3C 标准被称为 W3C 推荐标准（W3C Recommendations）W3C 最重要的工作是发展 web 规范，也就是描述 web 通信协议（比如 HTML 和 XML）和其他构建模块的“推荐标准”。1.4 w3cschool及w3c在线验证服务W3CSchool 是因特网上最大的 WEB 开发者资源，是完全免费的，是非盈利性的，一直在升级和更新。由W3C提供的验证服务可以为互联网用户检查HTML文件是否附合HTML或XHTML标准。这可以向网页设计师提供快速检查网页错误的方法。对W3C验证这个事，我们知道W3C是通过规则形式验证的，而我们在写程序的时候往往会有一些难以处理的兼容问题，需要一些不规则的写法来解决，而这样的写法可以解决遇到的问题，但又会通不过验证，在这种时候我们肯定会在解决问题为优先的原则。2 浏览器介绍2.1 浏览器概况 2.2 浏览器分析版本介于目前最新版本浏览器例如IE10/11、Safari 7、Firefox 25、Chrome 31已经极大符合W3C标准规范，因此在IE版本中，只做IE6、IE7、IE8分析。2.3 浏览器内核各品牌浏览器的内核是不同的，不同的内核处理同一段代码的时候思路不同。因此可以说，浏览器间内核的差异是产生兼容性问题的根本原因。浏览器名称排版引擎ECMAScript 引擎Internet ExplorerTridentChakra(Jscript引擎)FirefoxGeckoSpiderMonkey(1.0-3.0)RhinoTraceMonkey(3.5-3.6)JaegerMonkey(4.0+)IonMonkey(18+)OdinMonkey(22+)ChromeWebkit(早期)/Blink(28+)V8SafariWebkitSquirrelFish Extreme2.4 浏览器工作模式及缩写上述浏览器，每种都有两到三种工作模式：在这里提到的“模式”是一个与时间点相关联的概念，我们不会因为时间点的不同而更改他们的名称。也就是说，这个“标准模式”是与浏览器的品牌和版本密切相关的，即便是各浏览器最新版本的 “标准模式” 也会有差别。浏览器的工作模式也被成为“渲染模式”，工作模式的差异不仅表现在处理HTML页面的时候，处理XML及非WEB内容时也有模式的差异，本文只讨论处理HTML时的工作模式。为了保证良好的向后兼容性，微软为用户提供了一个“开关”，来决定浏览器的工作模式，就是页面顶部的DTD。IE6,7,8中的“混杂模式”是为了保证将浏览器的行为冻结在IE5.5版本。但随着时间推进和进步，2009年IE8重新定义“标准模式”，再次增强对W3C规范的支持，但为了保持对IE7的兼容，还增加了一种“接近标准模式”。通过以上的内容，我们可以得出结论：如果一个页面能使各浏览器都工作在“标准模式”下，那么各浏览器都将尽量兼容标准，因此各浏览器之间表现出的差异是很少的。相反，如果一个页面使各浏览器都工作在“混杂模式”下，那么各浏览器都将尽量向后兼容，因此各浏览器之间表现出的差异将会最大化。下图附常见的doctype：在编写一个页面时，要使用可以触发各浏览器“标准模式”的DTD，并书写符合规范的代码，以保证您的页面在各浏览器中可以最大程度的兼容。3 问题分类（常见）3.1 HTML渲染相关DTD 之前的非空白字符在某些情况下会使该 DTD 失效标准参考HTML 4.01 规范中提到，DTD 的前面或后面允许出现空白符，这里提到的“空白符”包括空格符、换行符、制表符和注释。问题描述如果在 DTD 之前加入注释或其他内容，在某些浏览器中该 DTD 将无法被识别。造成影响这个问题将导致同一个页面在有些浏览器中工作在标准模式 (S) 下，在其他浏览器中工作在混杂模式 (Q) 下，从而导致该页面的表现在各浏览器中产生较大差异，如布局混乱、内容重叠、功能无法使用等。受影响浏览器IE6DTD 前的任何非空白符都将使浏览器忽略 DTD，包括注释和 XML 声明。IE7 IE8DTD 前的任何非空白符都将使浏览器忽略 DTD，包括注释，但不包括 XML 声明。FirefoxDTD 前的任何包含“”的字符都将使浏览器忽略 DTD，但不包括 XML 声明。Chrome Safari OperaDTD 前的任何非空白符都将使浏览器忽略 DTD，但不包括 XML 声明。问题分析解决方案声明 DTD 时，确保 DTD 之前没有其他字符，即便有，也只能是空格符、换行符和制表符IE 中单元格的 colspan 属性在某些情况下会影响 TABLE 的自动布局标准参考W3C CSS2.1规定，对于跨越多列的单元格，增加这些列的最小宽度，使他们的和至少跟单元格等宽。对于最大宽度也照样处理。如果可能的话，每个扩展到的列增加的宽度应大致相同。问题描述单元格的 colspan 属性在 IE 中可能影响 TABLE 元素的自动布局造成影响严重时导致页面布局混乱受影响浏览器IE6 7 8问题分析td1 td2td3解决方案设置 TABLE 的 table-layout 特性值为 fixed，或使用固定布局的表格元素可避免此问题。各浏览器下使用OBJECT元素和EMBED元素嵌入Flash存在差异标准参考OBJECT元素定义了一个嵌入对象，初衷是取代IMG和APPLET元素，但由于安全性等原因及缺乏浏览器支持导致初衷并未实现。浏览器的对象支持依赖于对象类型。然而，即便是相同的对象类型，各主流浏览器也都使用了不同的代码来加载。问题描述通常情况下，IE 系列浏览器通过 ActiveX 插件使用 OBJECT 元素引入 Flash，而其他浏览器则是通过相应的 NPAPI 插件使用 EMBED 元素。这造成了各浏览器中插入 Flash 的方式的差异造成影响若仅仅使用 OBJECT 元素设置了 classid 属性引入 Flash，则可能造成在某些浏览器中 Flash 无法被引入。而若嵌套的 OBJECT 和 EMBED 元素参数不统一，也可能造成引入的 Flash 在各浏览器中出现差异。受影响浏览器ALL问题分析对于 HTML4.01 规范中的 OBJECT 元素，IE 对 classid 属性有自己的解释方式：类标识符（class identifier）。格式形如：clsid:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX。由 ActiveX 组件注册在 Windows 的系统注册表中。codebase 属性则为该类标识符所对应的 ActiveX 插件的 URI 地址。一般是一个 .cab 安装包。（更多请参考 MSDN：CLASSID Attribute | classid Property 及 Class Identifier 中的内容。）EMBED 元素则是由 NetScape Navigator 2 引入，用于在 HTML 文档中插入符合网景插件应用程序编程接口（NPAPI）规范的插件。NPAPI 插件是跨平台的，并可以在所有实现了此接口规范的浏览器中使用。目前的主流浏览器中 IE 系列以外的浏览器均支持 NPAPI 插件。事实上 IE3.0 就支持 NPAPI，但是在 IE5.5 SP2 后微软出于安全考虑停止了对 NPAPI 的支持，转而推荐用户使用其 ActiveX 技术作为替代。（更多请参考 MSDN：Netscape 式的插件在升级 Internet Explorer 后不工作）EMBED 元素拥有一个名为 pluginspage 的属性，其值为 NPAPI 插件的 URL，与 IE 中 OBJECT 元素的 codebase 属性类似，它告诉了浏览器插件的下载地址。EMBED 元素不属于 HTML4.01 规范中的元素，HTML 文档中直接使用 EMBED 元素可能无法通过 W3C 校验。不过 EMBED 元素目前已经被添加到 HTML5 草案中。（参加 HTML5 草案：4.8.3 The embed element）至此若需要在 HTML 文档中引入一个已安装的通用的插件，如 Flash，则在 IE 中使用 OBJECT 元素，非 IE 中则使用 EMBED 元素。此外 IE 中也支持 EMBED 元素引入设置了正确 MIME 的插件。解决方案1若不考虑 W3C 校验，可统一使用 EMBED 元素嵌入 Flash，这样可以避免因参数不统一导致的兼容性问题。2若需要考虑 W3C 校验，则可使用OBJECT 元素 type、data 属性以及 PARAM 元素的方式。3若必须使用 OBJECT 嵌套 EMBED 元素这种混合方式，则要保证 Flash 文件 URL、为 Flash 传递的参数、宽度、高度、wmode 等参数保持统一。4可以使用开源的 SWFObject 引入 Flash。IE6 IE7 IE8(Q) 中 IMG 元素的 alt 属性在没有 title 属性的情况下会被当作提示信息使用标准参考W3C HTML 4.01 规范规定，alt 属性指定了在 User Agents 不能显示图片、表单和 applets 的时候显示的替换文字。问题描述alt 属性在 IE6 IE7 IE8(Q) 下具有双重意义。在给 IMG、AREA、INPUTtype=image 元素设置的 alt 属性值不但可以作为该元素的替代文字，在该元素没有指定 title 属性时，还可以作为提示信息（tooltip）被显示出来。造成影响若用户需要显示提示框，并且仅指定了 alt 属性，则在 IE8(S) 及其它浏览器中将无法显示提示框；若用户不需要显示提示框，并且指定了 alt 属性，则在 IE6 IE7 IE8(Q) 中仍然会显示提示框。受影响浏览器IE6 7 8(Q)问题分析IE6 IE7 IE8(Q) 对 alt 属性的理解有误，这些浏览器混淆了此属性与 title 属性。 在没有设置 title 属性的情况下，鼠标放在设置了 alt 属性的 IMG AREA INPUTtype=image 元素上时仍会弹出提示框（tooltip）。解决方案若用户需要显示提示框，则指定 title 属性；若用户不需要显示提示框，则指定 title=。IE6 不支持 PNG24 格式图片的半透明效果标准参考无问题描述PNG24 格式图片可以携带 Alpha 半透明通道，以便呈现从透明到不透明间过渡色彩效果，但是 IE6 不支持这种格式原有的透明特性。造成影响带有半透明通道的 PNG24 格式图片在 IE6 中通道颜色被显示成灰色，不具有半透明效果。受影响浏览器IE6问题分析解决方案1使用 IE 专有滤镜 AlphaImageLoader Filter 来修复 IE6 透明通道问题2使用脚本批量处理方式function fixpng24()不同内核的浏览器中文件选择控件的外观也不相同标准参考根据 W3C HTML4.01 规范中的描述，type 属性为 file 的 INPUT 元素在浏览器中将被渲染为一个文件选择控件（file select），这种控件允许用户在其本地选择文件，通常由一个用于显示文件名的只读文本框及一个用于触发选择文件对话框的按钮组成。而规范中对文件选择控件只描述了其应具有功能，并没有限制其呈现方式。所以各浏览器按照自己的方式渲染该控件。问题描述对于文本选择控件 INPUTtype=file ，各浏览器对其有不同形式的渲染，并且某些 CSS 特性也有着不同的表现。其中 Chrome Safari中对文件选择控件的渲染样式与其他浏览器有较大区别，这是由于浏览器所用的 WebKit 内核设计所致。造成影响浏览器之间不同的渲染方式将造成某些视觉上的差异，但并不影响功能的使用受影响浏览器所有浏览器问题分析在不同浏览器呈现方式如下：如果为该控件设置一些css样式，各个浏览器渲染差异就很明显 解决方案在 Chrome Safari 中对于文件选择控件的特殊呈现方式为 WebKit 内核特有，且其渲染方式也符合 W3C 对文件选择控件的规定。一般来说这种差异不会带来严重的兼容性问题。若需要强制在所有浏览器中呈现一样的效果，即文本框+按钮方式，则需要一些处理 form.example input background: url(input_boxes.gif) no-repeat 0 -58px;border: none;width: 241px;height: 20px;padding-left: 3px;padding-top: 3px;form.example input:focus background-color: transparent;form.example div.fileinputs position: relative;height: 30px;width: 300px;form.example input.file width: 300px;margin: 0;form.example input.file.hidden position: relative;text-align: right;-moz-opacity:0 ;filter:alpha(opacity: 0);opacity: 0;z-index: 2;form.example div.fakefile position: absolute;top: 0px;left: 0px;width: 350px;padding: 0;margin: 0;z-index: 1;line-height: 90%;form.example div.fakefile input margin-bottom: 5px;margin-left: 0; var W3CDOM = (document.createElement & document.getElementsByTagName); function initFileUploads() if (!W3CDOM) return; var fakeFileUpload = document.createElement(div); fakeFileUpload.className = fakefile; fakeFileUpload.appendChild(document.createElement(input); var image = document.createElement(img); image.src=button_select.gif; fakeFileUpload.appendChild(image); var x = document.getElementsByTagName(input); for (var i=0;ix.length;i+) if (xi.type != file) continue; if (xi.parentNode.className != fileinputs) continue; xi.className = file hidden; var clone = fakeFileUpload.cloneNode(true); xi.parentNode.appendChild(clone); xi.relatedElement = clone.getElementsByTagName(input)0; xi.onchange = xi.onmouseout = function () this.relatedElement.value = this.value; initFileUploads();IE6 7 8(Q) 中 FIELDSET 元素的宽度不是 auto 时的表现与行内元素相同标准参考FIELDSET 元素用来将表单 (FORM) 内的相关元素(控件)分组，一般结合 LEGEND 使用。FIELDSET 元素是 block-level 元素，它的 CSS 属性 display 为 block。问题描述在 IE6 IE7 IE8(Q) 中，当给 FIELDSET 元素设置了一个固定的宽度时，该元素的表现更像是一个行内元素，虽然它的 display 值仍是 block。造成影响局部布局混乱受影响浏览器IE6 7 8(Q)问题分析根据 HTML 4.01 和 CSS 2.1 中相应规范说明 FIELDSET 元素是个块级元素，但是解决方案通过显式设置 FIELDSET 的样式为 display:block 来修复Firefox 中TEXTAREA元素根据 rows 设置值生成的实际行数为设置值 + 1标准参考根据 W3C HTML 4.01 规范中的描述，TEXTAREA 元素的 rows 属性指定了可视文本的行数。用户应该被允许输入更多行的文本，但当内容超出可视区域时，用户端应该为文本内容提供类似滚动机制。问题描述Firefox 对 TEXTAREA 元素的 rows 属性解释有误，实际显示的 TEXTAREA 元素的行数会比设置的属性值多 1造成影响当仅仅为 TEXTAREA 元素设置 rows 属性以控制其高度时，在 Firefox 中无法得到预期的效果受影响浏览器Firefox问题分析解决方案当我们仅仅为 TEXTAREA 元素设置 rows 属性以控制其高度时，在 Firefox 中无法得到我们预期的效果。且其他浏览器对 rows 属性设置的元素高度也不尽相同，这一点 W3C 没有明确规范 rows 属性计算高度时的具体算法。如果要精确控制 TEXTAREA 元素的尺寸（高度）时，请避免使用 rows 属性改用 CSS 相关设定，以保证所有浏览器拥有统一的视觉样式。IE6 IE7 IE8(Q) 中同一元素重复定义的 style 属性会被合并标准参考HTML 代码中元素的某个属性应在其所在元素标签内具备唯一性，如我们不应该为一个元素定义两个同名属性。问题描述IE6 IE7 IE8(Q) 中会自动合并元素重复的 style 属性造成影响对于 style 属性，由于 IE6 IE7 IE8(Q) 中的特有现象，当我们因为比如输入了多个 style 属性定义元素的内联 CSS 后，会导致与其他浏览器中的 CSS 渲染差异。受影响浏览器IE6 IE7 IE8(Q)问题分析下面代码 DIV 元素的 id name title 属性均定义了两次：123document.getElementById(d) 及 document.getElementById(div) 检测，则仅 document.getElementById(d) 返回了该元素的 DOM 对象，而document.getElementById(div) 返回undefined；同样的对于 name 属性，使用 document.getElementById(d).getAttribute(name) 返回的也是前者的属性值；title 属性则更明显了，当我们将鼠标移至 DIV 上时，弹出的 dt 提示框已经告诉我们前者定义的属性值有效。以上代码在所有浏览器中表现均一致。再看一看对于重复定义的class属性：.dc font-size:24px; .divc text-decoration:underline;123各浏览器的处理结果相同，DIV 中的文字均变为了24px，且均没有出现下划线。与上一节的结论相同，对于 class 属性，仍然是前面先定义的属性值有效。下面测试 style 属性：123DIV 元素内含有两个重复的 style 属性，第一个中写入 CSS 展现灰色背景黑色文字，第二个则是红色背景白色文字。在各浏览器中效果如下：IE6 IE7 IE8(Q)IE8(S) Firefox Chrome Safari Opera可以很清楚的看到在 IE6 IE7 IE8(Q) 中，浏览器会将重复的 style 属性合并，而对于 style 属性中重复的 CSS 样式属性，则采用前面的 style 属性定义。IE8(S) Firefox Chrome Safari Opera 中，则与前面的结论一致，只有第一个 style 属性中的 CSS 代码有效。解决方案不要依赖 IE 的容错机制，避免重复定义 HTML 元素属性IE6 IE7 IE8(Q) 会忽略 LI DD DT 元素的结束标记标准参考根据 W3C HTML 4.01 规范中对HTML中的列表元素进行了详细的描述，其中将列表分为三类：无序信息列表，使用 UL 元素创建，列表项由 LI 元素构成；有序信息列表，使用 OL 元素创建，列表项由 LI 元素构成；定义列表，使用 DL 元素创建，通常由一系列的 项/定义 对（term/definition pairs）组成，即 DT 元素和 DD 元素。任何列表必须包含一个或多个列表元素。问题描述IE6 IE7 IE8(Q) 会忽略 LI DD DT 元素的结束标记，并且位于同一个父元素内的 LI 元素在文档树中会前后相连，位于 LI 元素之后的元素（不包括 LI、DD、DT、HTML、HEAD、BODY、TITLE 等）搞个会被修复到其前面最近的 LI DD DT 元素内，成为该 LI DD DT 元素的子元素。造成影响对 LI DD DT 元素之后出现的非列表元素处理在不同浏览器中导致布局上的差异受影响浏览器IE6 IE7 IE8(Q)问题分析一个 SPAN 元素被插在了第二个 LI 元素之后、第三个 LI 元素之前，对于后面的 DD DT 元素也是如此。这段代码在不同的浏览器环境中的表现如下：IE6 IE7 IE8(Q)IE8(S) Firefox Chrome Safari Opera可以看到，LI DD DT 元素之后出现了非列表元素时，浏览器间对代码的修复特性不相同，在 IE6 IE7 IE8(Q)中，SPAN 元素被移动到了其前面最近的 LI 元素内，成为 LI 元素的子元素在IE8(S) Firefox Safari Chrome中，浏览器没有对代码结构作任何调整，SPAN 元素依然位于第二个 LI 元素之后、第三个 LI 元素之前，由于 LI 元素为块级元素，所以 SPAN 元素的内容独立显示为一行，对于 DD DT 元素也是如此。解决方案虽然 HTML 4.01 规范中没有明确指出列表元素的兄弟元素必须是同一列表元素；但是根据 HTML 语义化理念，建议不要在列表元素 LI DD DT 之后插入其他元素。3.2 CSS渲染相关IE6 7(Q) 8(Q)中A元素的:visited :hover :active伪类未按规范要求的算法来计算针对性标准参考关于A标签：A 标签有四个常用的伪类：:link：适用于未被用户访问过的链接。:visited：适用于已被用户访问过的链接。:hover：在可视化客户端上，适用于光标（鼠标指针）指向一个元素，但还未激活它时。:active：适用于一个元素被用户激活时。CSS 2.1 规范建议，在 A 标签上使用这四个伪类时，声明顺序应为：L-V-H-A。因为只有将 a:hover 放置在 a:link 和 a:visited 之后，才能确保在用户将光标指向 A 元素时，a:hover 内的声明能够覆盖之前 a:link 或 a:visited 中特性名相同的声明。同理，a:active 也应放置在 a:hover 之后，否则 a:active 中特性名相同的声明将被覆盖。当 A 没有 href 属性时，在 IE6 IE7(Q) IE8(Q) 中的 :hover 伪类以及 IE6 IE7 IE8(Q) 中的 :active 伪类会失效。关于针对性： 根据 CSS 2.1 规范的描述，选择器有其针对性（specificity），可以应用到某一元素的多个规则集中，选择器的针对性越高，该规则集的权重也就越高。针对性相同的，后出现的规则集的权重更高。针对性由 a b c d 四组数字组成，按照以下的方式计算：如果样式是在 HTML 代码中以 style=. 的内联样式的方式设置的，则将 a 组记为 1，b c d 三组均记为 0，否则 a 组为 0。将选择器中 ID 属性的数量总合计入 b 组。将选择器中其他属性及伪类的数量总合计入 c 组。将选择器中元素名及伪元素的数量总合计入 d 组。 确定针对性的强弱时，根据各组的数字来计算。a 组数字大的针对性更强，当 a 组的数字相同时，比较 b 组数字的大小，以此类推，最终比较结果更大的针对性更强。* /* a=0 b=0 c=0 d=0 - specificity = 0,0,0,0 */li /* a=0 b=0 c=0 d=1 - specificity = 0,0,0,1 */li:first-line /* a=0 b=0 c=0 d=2 - specificity = 0,0,0,2 */ul li /* a=0 b=0 c=0 d=2 - specificity = 0,0,0,2 */ul ol+li /* a=0 b=0 c=0 d=3 - specificity = 0,0,0,3 */h1 *id=ok /* a=0 b=0 c=1 d=1 - specificity = 0,0,1,1 */ul ol li.red /* a=0 b=0 c=1 d=3 - specificity = 0,0,1,3 */li.red.level /* a=0 b=0 c=2 d=1 - specificity = 0,0,2,1 */#xyz /* a=0 b=1 c=0 d=0 - specificity = 0,1,0,0 */style=. /* a=1 b=0 c=0 d=0 - specificity = 1,0,0,0 */以上各组选择器，最后一行的内联样式针对性最强，倒数第二行有 ID 选择符的次之，往上的每一行依次减弱，最顶部的通配符针对性最弱。问题描述在 IE6 IE7(Q) IE8(Q) 中，A 标签的 :visited :hover :active 伪类声明即便没有以 L-V-H-A 的顺序书写，包含这些选择器的规则集中的、相同特性名的声明都会在相对应的行为发生时生效。而其他浏览器则严格按照规范规定的计算方式来确定选择器的针对性及它们的权重造成影响该问题将造成链接的样式在不同的行为发生时，在各浏览器中的表现不一致受影响浏览器IE6 IE7(Q) IE8(Q)问题分析1. 在 IE6 IE7(Q) IE8(Q) 中，a:hover、a:active 和 a:visited 并没有按照规范描述的算法来计算它们的针对性，而是根据链接的实际状态来决定使用哪个规则集里的声明。它们三个的针对性比 a:link 强。 根据规范规定，A 标签的四个常用伪类在计算针对性时的结果是相同的，因此它们的声明顺序应为：L-V-H-A，以确保各规则集中定义的相同特性名的声明可以按照期望的效果覆盖。分析以下代码： a font:bold 50px Verdana; a:active color:yellow; /* 0,0,1,1 */ a:hover color:blue; /* 0,0,1,1 */ a:visited color:green; /* 0,0,1,1 */ a:link color:red; /* 0,0,1,1 */ text 代码将包含上述四个伪类的规则集的声明顺序写成 A-H-V-L，由于这四个规则集的选择器的针对性相同，因此它们中最后出现的权重最高，即无论页面中链接的状态为 :hover 或 :active，只要它已被访问过，它就会应用 a:visited 中的 color:green（绿色），而未被访问过的情况下，将应用 a:link 中的 color:red（红色）。以上代码中的链接文字在各浏览器的不同状态下的颜色：可见，其他浏览器的表现都是正确的，但在 IE6 IE7(Q) IE8(Q) 中：当链接未被访问过（a:link）时，a:hover 和 a:active 在该链接相应的行为发生时，仍可生效。当链接已被访问过（a:visited）时，a:hover 和 a:active 在该链接相应的行为发生时，不能生效。因此可以得出初步结论：a:hover 和 a:active 并没有按照规范描述的针对性算法来计算，它们的针对性比 a:link 强，但不比 a:visited 强。那么是否 a:visited 比 a:hover 和 a:active 要高呢？调整以上代码的 CSS 部分的顺序后再次测试： a font:bold 50px Verdana; a:visited color:green; /* 0,0,1,1 */ a:active color:yellow; /* 0,0,1,1 */ a:hover color:blue; /* 0,0,1,1 */ a:link color:red; /* 0,0,1,1 */将 a:visited 提前到第二行，测试 a:visited 与 a:active 及 a:hover 的针对性强弱差异。链接文字在 IE6 IE7(Q) IE8(Q) 中的不同状态下的颜色（不再测试其他浏览器）：可见，但在 IE6 IE7(Q) IE8(Q) 中：当链接已被访问过（a:visited）时，a:hover 和 a:active 在该链接相应的行为发生时，仍可生效。再次交换 a:active 与 a:hover 的位置，测试结果相同。结合以上的结论，可知：在 IE6 IE7(Q) IE8(Q) 中，a:hover、a:active 和 a:visited 并没有按照规范描述的算法来计算它们的针对性，而是根据链接的实际状态来决定使用哪个规则集里的声明。它们三个的针对性比 a:link 强。2. 在 IE6 IE7(Q) IE8(Q) 中，a:hover、a:active 和 a:visited 的针对性比其他看起来针对性更强的选择器还要强。事实上，在 IE6 IE7(Q) IE8(Q) 中，a:hover、a:active 和 a:visited 的针对性算法非常特殊，如以下 css 代码：a font:bold 50px Verdana;a:visited color:green; /* 0,0,1,1 */a:hover color:blue; /* 0,0,1,1 */a:active color:yellow; /* 0,0,1,1 */a:link color:red; /* 0,0,1,1 */div a.c2 color:black; /* 0,0,1,2 */div.c1 .c2color:black; /* 0,0,2,1 */看起来最后一行规则集的选择器 div.c1 .c2 的针对性要更强，但实际并非如此，链接文字在 IE6 IE7(Q) IE8(Q) 中的不同状态下的颜色为：而将最后两行代码注释掉，换成以下代码再试：a font:bold 50px Verdana;a:visited color:green; /* 0,0,1,1 */a:hover color:blue; /* 0,0,1,1 */a:active color:yellow; /* 0,0,1,1 */a:link color:red; /* 0,0,1,1 */*div a.c2 color:black;*/ /* 0,0,1,2 */*div.c1 .c2color:black;*/ /* 0,0,2,1 */.c1 a.c2color:black; /* 0,0,2,1 */结果如下：可以得出结论：针对性相同的选择器 div.c1 .c2 和 .c1 a.c2（针对性均为 0, 0, 2, 1）在 IE6 IE7(Q) IE8(Q) 后者的针对性更强，包含 .c1 a.c2 的规则集的权重超过了包含 a:hover、a:active 和 a:visited 的规则集。将 .c1 a.c2 换成针对性更强的 #b1 a（针对性为 0, 1, 0, 1），结果与上表相同。解决方案严格按照标准的建议，以L-V-H-A的顺序声明A标签的伪类，以保证在各浏览器中兼容。IE6 IE7(Q) IE8(Q) 不完全支持 !important 规则标准参考在 CSS2.1 规范 6.4.1 Cascading order 中根据CSS样式的来源和重要性，给出了优先级的升序排列：1.浏览器默认样式；2.浏览器用户自定义一般样式；(未加 !important 的样式)3.开发者定义一般样式；4.开发者定义加了 !mportant 的样式5.浏览器用户自定义加了 !mportant 的样式根据 CSS2.1 规范中的描述，!important 可以提高样式的优先级，他是最高优先权重，无疑对样式优先级影响是巨大的。为了平衡开发者设置的样式和浏览器用户设定的样式，默认开发者设置的样式优于浏览器用户设置的样式；另外，声明了!important 的样式优于其他样式声明。问题描述IE6 IE7(Q) IE8(Q) 中不支持位于同一个选择器内的 !important 规则，他可能会导致实际样式效果与预计不符。造成影响使用 !important 规则而没有考虑 IE6 的情况，可能会使 IE6 中的表现跟其他浏览器有差别。其影响程度跟属性值的重要程度成正比。比如， !important 设置在跟页面布局有很大关系的宽度值上，那么宽度的影响可能会作用于整个布局。受影响浏览器IE6 IE7 IE8(Q)不支持位于同一个选择器内的 !important 规则问题分析在 IE6 IE7(Q) IE8(Q) 中，不完全支持 !important 规则。位于同一个选择器内的 !important 规则将失效。分析以下代码： div width:100px; height:30px; background-color:gold !important; background-color:silver; DIV 是一个宽高固定的长方形。DIV 的颜色进行了两次设置，一次为金色，一次为银色，其中金色在银色的前面，并且颜色值后有 !important 声明；根据 CSS2.1 规范中的描述可知，DIV 最终显示应为金色。下面看若 !important 位于两个选择器内的情况： .c1 background:blue !important; .c2 background:green; 运行后发现所有浏览器中，DIV 元素的背景色均为蓝色。则证明 IE6 IE7(Q) IE8(Q) 支持不位于同一个选择器内的 !important 规则。解决方案这是浏览器的 Bug