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

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

《常见浏览器兼容性问题汇总doc.docx》由会员分享，可在线阅读，更多相关《常见浏览器兼容性问题汇总doc.docx（16页珍藏版）》请在冰豆网上搜索。

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

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

常见浏览器兼容性问题汇总1W3C标准规范1.1W3C简介万维网联盟创建于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推荐标准（W3CRecommendations）W3C最重要的工作是发展web规范，也就是描述web通信协议（比如HTML和XML）和其他构建模块的“推荐标准”。

1.4w3cschool及w3c在线验证服务W3CSchool是因特网上最大的WEB开发者资源，是完全免费的，是非盈利性的，一直在升级和更新。

由W3C提供的验证服务可以为互联网用户检查HTML文件是否附合HTML或XHTML标准。

这可以向网页设计师提供快速检查网页错误的方法。

对W3C验证这个事，我们知道W3C是通过规则形式验证的，而我们在写程序的时候往往会有一些难以处理的兼容问题，需要一些不规则的写法来解决，而这样的写法可以解决遇到的问题，但又会通不过验证，在这种时候我们肯定会在解决问题为优先的原则。

2浏览器介绍2.1浏览器概况2.2浏览器分析版本介于目前最新版本浏览器例如IE10/11、Safari7、Firefox25、Chrome31已经极大符合W3C标准规范，因此在IE版本中，只做IE6、IE7、IE8分析。

2.3浏览器内核各品牌浏览器的内核是不同的，不同的内核处理同一段代码的时候思路不同。

因此可以说，浏览器间内核的差异是产生兼容性问题的根本原因。

浏览器名称排版引擎ECMAScript引擎InternetExplorerTridentChakraJscript引擎FirefoxGeckoSpiderMonkey1.0-3.0RhinoTraceMonkey3.5-3.6JaegerMonkey4.0IonMonkey18OdinMonkey22ChromeWebkit早期/Blink28V8SafariWebkitSquirrelFishExtreme2.4浏览器工作模式及缩写上述浏览器，每种都有两到三种工作模式在这里提到的“模式”是一个与时间点相关联的概念，我们不会因为时间点的不同而更改他们的名称。

也就是说，这个“标准模式”是与浏览器的品牌和版本密切相关的，即便是各浏览器最新版本的“标准模式”也会有差别。

浏览器的工作模式也被成为“渲染模式”，工作模式的差异不仅表现在处理HTML页面的时候，处理XML及非WEB内容时也有模式的差异，本文只讨论处理HTML时的工作模式。

为了保证良好的向后兼容性，微软为用户提供了一个“开关”，来决定浏览器的工作模式，就是页面顶部的DTD。

IE6,7,8中的“混杂模式”是为了保证将浏览器的行为冻结在IE5.5版本。

但随着时间推进和进步，2009年IE8重新定义“标准模式”，再次增强对W3C规范的支持，但为了保持对IE7的兼容，还增加了一种“接近标准模式”。

通过以上的内容，我们可以得出结论如果一个页面能使各浏览器都工作在“标准模式”下，那么各浏览器都将尽量兼容标准，因此各浏览器之间表现出的差异是很少的。

相反，如果一个页面使各浏览器都工作在“混杂模式”下，那么各浏览器都将尽量向后兼容，因此各浏览器之间表现出的差异将会最大化。

下图附常见的doctype在编写一个页面时，要使用可以触发各浏览器“标准模式”的DTD，并书写符合规范的代码，以保证您的页面在各浏览器中可以最大程度的兼容。

3问题分类（常见）3.1HTML渲染相关DTD之前的非空白字符在某些情况下会使该DTD失效标准参考HTML4.01规范中提到，DTD的前面或后面允许出现空白符，这里提到的“空白符”包括空格符、换行符、制表符和注释。

问题描述如果在DTD之前加入注释或其他内容，在某些浏览器中该DTD将无法被识别。

造成影响这个问题将导致同一个页面在有些浏览器中工作在标准模式S下，在其他浏览器中工作在混杂模式Q下，从而导致该页面的表现在各浏览器中产生较大差异，如布局混乱、内容重叠、功能无法使用等。

受影响浏览器IE6DTD前的任何非空白符都将使浏览器忽略DTD，包括注释和XML声明。

IE7IE8DTD前的任何非空白符都将使浏览器忽略DTD，包括注释，但不包括XML声明。

FirefoxDTD前的任何包含“td1td2td3解决方案设置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属性有自己的解释方式类标识符（classidentifier）。

格式形如clsidXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX。

由ActiveX组件注册在Windows的系统注册表中。

codebase属性则为该类标识符所对应的ActiveX插件的URI地址。

一般是一个.cab安装包。

（更多请参考MSDNCLASSIDAttribute|classidProperty及ClassIdentifier中的内容。

）EMBED元素则是由NetScapeNavigator2引入，用于在HTML文档中插入符合网景插件应用程序编程接口（NPAPI）规范的插件。

NPAPI插件是跨平台的，并可以在所有实现了此接口规范的浏览器中使用。

目前的主流浏览器中IE系列以外的浏览器均支持NPAPI插件。

事实上IE3.0就支持NPAPI，但是在IE5.5SP2后微软出于安全考虑停止了对NPAPI的支持，转而推荐用户使用其ActiveX技术作为替代。

（更多请参考MSDNNetscape式的插件在升级InternetExplorer后不工作）EMBED元素拥有一个名为pluginspage的属性，其值为NPAPI插件的URL，与IE中OBJECT元素的codebase属性类似，它告诉了浏览器插件的下载地址。

EMBED元素不属于HTML4.01规范中的元素，HTML文档中直接使用EMBED元素可能无法通过W3C校验。

不过EMBED元素目前已经被添加到HTML5草案中。

（参加HTML5草案4.8.3Theembedelement）至此若需要在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。

IE6IE7IE8Q中IMG元素的alt属性在没有title属性的情况下会被当作提示信息使用标准参考W3CHTML4.01规范规定，alt属性指定了在UserAgents不能显示图片、表单和applets的时候显示的替换文字。

问题描述alt属性在IE6IE7IE8Q下具有双重意义。

在给IMG、AREA、INPUT[typeimage]元素设置的alt属性值不但可以作为该元素的替代文字，在该元素没有指定title属性时，还可以作为提示信息（tooltip）被显示出来。

造成影响若用户需要显示提示框，并且仅指定了alt属性，则在IE8S及其它浏览器中将无法显示提示框；若用户不需要显示提示框，并且指定了alt属性，则在IE6IE7IE8Q中仍然会显示提示框。

受影响浏览器IE678Q问题分析IE6IE7IE8Q对alt属性的理解有误，这些浏览器混淆了此属性与title属性。

在没有设置title属性的情况下，鼠标放在设置了alt属性的IMGAREAINPUT[typeimage]元素上时仍会弹出提示框（tooltip）。

解决方案若用户需要显示提示框，则指定title属性；若用户不需要显示提示框，则指定title““。

IE6不支持PNG24格式图片的半透明效果标准参考无问题描述PNG24格式图片可以携带Alpha半透明通道，以便呈现从透明到不透明间过渡色彩效果，但是IE6不支持这种格式原有的透明特性。

造成影响带有半透明通道的PNG24格式图片在IE6中通道颜色被显示成灰色，不具有半透明效果。

受影响浏览器IE6问题分析解决方案1使用IE专有滤镜AlphaImageLoaderFilter来修复IE6透明通道问题2使用脚本批量处理方式functionfixpng24不同内核的浏览器中文件选择控件的外观也不相同标准参考根据W3CHTML4.01规范中的描述，type属性为“file“的INPUT元素在浏览器中将被渲染为一个文件选择控件（fileselect），这种控件允许用户在其本地选择文件，通常由一个用于显示文件名的只读文本框及一个用于触发选择文件对话框的按钮组成。

而规范中对文件选择控件只描述了其应具有功能，并没有限制其呈现方式。

所以各浏览器按照自己的方式渲染该控件。

问题描述对于文本选择控件“INPUT[typefile]“，各浏览器对其有不同形式的渲染，并且某些CSS特性也有着不同的表现。

其中ChromeSafari中对文件选择控件的渲染样式与其他浏览器有较大区别，这是由于浏览器所用的WebKit内核设计所致。

造成影响浏览器之间不同的渲染方式将造成某些视觉上的差异，但并不影响功能的使用受影响浏览器所有浏览器问题分析在不同浏览器呈现方式如下如果为该控件设置一些css样式，各个浏览器渲染差异就很明显解决方案在ChromeSafari中对于文件选择控件的特殊呈现方式为WebKit内核特有，且其渲染方式也符合W3C对文件选择控件的规定。

一般来说这种差异不会带来严重的兼容性问题。

若需要强制在所有浏览器中呈现一样的效果，即文本框按钮方式，则需要一些处理form.exampleinput{backgroundurlinput_boxes.gifno-repeat0-58px;bordernone;width241px;height20px;padding-left3px;padding-top3px;}form.exampleinputfocus{background-colortransparent;}form.examplediv.fileinputs{positionrelative;height30px;width300px;}form.exampleinput.file{width300px;margin0;}form.exampleinput.file.hidden{positionrelative;text-alignright;-moz-opacity0;filteralphaopacity0;opacity0;z-index2;}form.examplediv.fakefile{positionabsolute;top0px;left0px;width350px;padding0;margin0;z-index1;line-height90;}form.examplediv.fakefileinput{margin-bottom5px;margin-left0;}varW3CDOMdocument.createElementfunctioninitFileUploads{ifW3CDOMreturn;varfakeFileUploaddocument.createElementdiv;fakeFileUpload.classNamefakefile;fakeFileUpload.appendChilddocument.createElementinput;varimagedocument.createElementimg;image.srcbutton_select.gif;fakeFileUpload.appendChildimage;varxdocument.getElementsByTagNameinput;forvari0;iIE678Q中FIELDSET元素的宽度不是auto时的表现与行内元素相同标准参考FIELDSET元素用来将表单FORM内的相关元素控件分组，一般结合LEGEND使用。

FIELDSET元素是block-level元素，它的CSS属性display为block。

问题描述在IE6IE7IE8Q中，当给FIELDSET元素设置了一个固定的宽度时，该元素的表现更像是一个行内元素，虽然它的display值仍是block。

造成影响局部布局混乱受影响浏览器IE678Q问题分析根据HTML4.01和CSS2.1中相应规范说明FIELDSET元素是个块级元素，但是解决方案通过显式设置FIELDSET的样式为displayblock来修复Firefox中TEXTAREA元素根据rows设置值生成的实际行数为设置值1标准参考根据W3CHTML4.01规范中的描述，TEXTAREA元素的rows属性指定了可视文本的行数。

用户应该被允许输入更多行的文本，但当内容超出可视区域时，用户端应该为文本内容提供类似滚动机制。

问题描述Firefox对TEXTAREA元素的“rows“属性解释有误，实际显示的TEXTAREA元素的行数会比设置的属性值多“1“造成影响当仅仅为TEXTAREA元素设置“rows“属性以控制其高度时，在Firefox中无法得到预期的效果受影响浏览器Firefox问题分析解决方案当我们仅仅为TEXTAREA元素设置“rows“属性以控制其高度时，在Firefox中无法得到我们预期的效果。

且其他浏览器对“rows“属性设置的元素高度也不尽相同，这一点W3C没有明确规范“rows“属性计算高度时的具体算法。

如果要精确控制TEXTAREA元素的尺寸（高度）时，请避免使用“rows“属性改用CSS相关设定，以保证所有浏览器拥有统一的视觉样式。

IE6IE7IE8Q中同一元素重复定义的style属性会被合并标准参考HTML代码中元素的某个属性应在其所在元素标签内具备唯一性，如我们不应该为一个元素定义两个同名属性。

问题描述IE6IE7IE8Q中会自动合并元素重复的“style“属性造成影响对于“style“属性，由于IE6IE7IE8Q中的特有现象，当我们因为比如输入了多个“style“属性定义元素的内联CSS后，会导致与其他浏览器中的CSS渲染差异。

受影响浏览器IE6IE7IE8Q问题分析下面代码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-size24px;}.divc{text-decorationunderline;}123各浏览器的处理结果相同，DIV中的文字均变为了24px，且均没有出现下划线。

与上一节的结论相同，对于“class“属性，仍然是前面先定义的属性值有效。

下面测试“style“属性123DIV元素内含有两个重复的“style“属性，第一个中写入CSS展现灰色背景黑色文字，第二个则是红色背景白色文字。

在各浏览器中效果如下IE6IE7IE8QIE8SFirefoxChromeSafariOpera可以很清楚的看到在IE6IE7IE8Q中，浏览器会将重复的“style“属性合并，而对于“style“属性中重复的CSS样式属性，则采用前面的“style“属性定义。

IE8SFirefoxChromeSafariOpera中，则与前面的结论一致，只有第一个“style“属性中的CSS代码有效。

解决方案不要依赖IE的容错机制，避免重复定义HTML元素属性IE6IE7IE8Q会忽略LIDDDT元素的结束标记标准参考根据W3CHTML4.01规范中对HTML中的列表元素进行了详细的描述，其中将列表分为三类无序信息列表，使用UL元素创建，列表项由LI元素构成；有序信息列表，使用OL元素创建，列表项由LI元素构成；定义列表，使用DL元素创建，通常由一系列的“项/定义“对（term/definitionpairs）组成，即DT元素和DD元素。

任何列表必须包含一个或多个列表元素。

问题描述IE6IE7IE8Q会忽略LIDDDT元素的结束标记，并且位于同一个父元素内的LI元素在文档树中会前后相连，位于LI元素之后的元素（不包括LI、DD、DT、HTML、HEAD、BODY、TITLE等）搞个会被修复到其前面最近的LIDDDT元素内，成为该LIDDDT元素的子元素。

造成影响对LIDDDT元素之后出现的非列表元素处理在不同浏览器中导致布局上的差异受影响浏览器IE6IE7IE8Q问题分析一个SPAN元素被插在了第二个LI元素之后、第三个LI元素之前，对于后面的DDDT元素也是如此。

这段代码在不同的浏览器环境中的表现如下IE6IE7IE8QIE8SFirefoxChromeSafariOpera可以看到，LIDDDT元素之后出现了非列表元素时，浏览器间对代码的修复特性不相同，在IE6IE7IE8Q中，SPAN元素被移动到了其前面最近的LI元素内，成为LI元素的子元素在IE8SFirefoxSafariChrome中，浏览器没有对代码结构作任何调整，SPAN元素依然位于第二个LI元素之后、第三个LI元素之前，由于LI元素为块级元素，所以SPAN元素的内容独立显示为一行，对于DDDT元素也是如此。

解决方案虽然HTML4.01规范中没有明确指出列表元素的兄弟元素必须是同一列表元素；但是根据HTML语义化理念，建议不要在列表元素LIDDDT之后插入其他元素。

3.2CSS渲染相关IE67Q8Q中A元素的visitedhoveractive伪类未按规范要求的算法来计算针对性标准参考关于A标签A标签有四个常用的伪类link适用于未被用户访问过的链接。

visited适用于已被用户访问过的链接。

hover在可视化客户端上，适用于光标（鼠标指针）指向一个元素，但还未激活它时。

active适用于一个元素被用户激活时。

CSS2.1规范建议，在A标签上使用这四个伪类时，声明顺序应为L-V-H-A。

因为只有将ahover放置在alink和avisited之后，才能确保在用户将光标指向A元素时，ahover内的声明能够覆盖之前alink或avisited中特性名相同的声明。

同理，aactive也应放置在ahover之后，