序章
谈谈“浏览器兼容性”的问题？
很多前端的面试或笔试中，都有比较笼统的“说说你所知道的各浏览器存在的兼容问题”，个人感觉这个问题问的太“大”了些，从样式到脚本，都会有很多不一样的地方（特别是IE8-对比主流浏览器）。实际回答的时候就会晕乎乎的不清楚如何抓住重点地来阐述。到底怎样回答这个问题，才能较为全面又不失重点，并让面试官感到满意呢？
首先明确一个概念，“谈谈浏览器兼容性”的问题和“说说你所知道的各浏览器存在的兼容问题”是两个完全不同的问题。
前者，鬼知道他想要问什么，得追问。
比如得问“您说的是哪个浏览器的哪类问题？还是常用浏览的（前端）API差异？渲 染差异？等等。还是要谈谈浏览器为什么存在兼容问题？兼容存在的历史原因？历史必然性等等”。
后者，基本上是个有着较明确边界范围的开放问题。
基本上可以知道，他是想了解你常用的常见到的常解决到的，或者近期刚刚解决过的一些浏览器兼容问题。从而判断你这部分知识面、解决问题的思路等等方面内容，而且不像前者一样慢无边界的。
起码，这么问的是不太闲，不想陪你唠嗑的。如果面试官纠结于你没回答出某个兼容性问题，即使要了你也不要去。 特别是那种还在炫耀IE6+ 1px技能的老先生。 现在还谈IE6+兼容性的面试官，真的挺掉公司的价的。
下面我们由浅到深，由简到易的回答这个笼统的“浏览器兼容性”问题！
CSS篇
1. 一些常见问题汇总
浏览器兼容问题一：不同浏览器的标签默认的外补丁和内补丁不同
问题症状：随便写几个标签，不加样式控制的情况下，各自的margin 和padding差异较大。
碰到频率:100%
解决方案：CSS里 *{margin:0;padding:0;}
备注：这个是最常见的也是最易解决的一个浏览器兼容性问题，几乎所有的CSS文件开头都会用通配符*来设置各个标签的内外补丁是0。浏览器兼容问题二：块属性标签float后，又有横行的margin情况下，在IE6显示 margin比设置的大
问题症状:常见症状是IE6中后面的一块被顶到下一行
碰到频率：90%（稍微复杂点的页面都会碰到，float布局最常见的浏览器兼容问题）
解决方案：在float的标签样式控制中加入 display:inline;将其转化为行内属性
备注：我们最常用的就是div+CSS布局了，而div就是一个典型的块属性标签，横向布局的时候我们通常都是用div float实现的，横向的间距设置如果用margin实现，这就是一个必然会碰到的兼容性问题。浏览器兼容问题三：设置较小高度标签（一般小于10px），在IE6，IE7，遨游中高度超出自己设置高度
问题症状：IE6、7和遨游里这个标签的高度不受控制，超出自己设置的高度
碰到频率：60%
解决方案：给超出高度的标签设置overflow:hidden;或者设置行高line-height 小于你设置的高度。
备注：这种情况一般出现在我们设置小圆角背景的标签里。出现这个问题的原因是IE8之前的浏览器都会给标签一个最小默认的行高的高度。即使你的标签是空的，这个标签的高度还是会达到默认的行高。浏览器兼容问题四：行内属性标签，设置display:block后采用float布局，又有横行的margin的情况，IE6间距bug
问题症状：IE6里的间距比超过设置的间距
碰到几率：20%
解决方案：在display:block;后面加入display:inline;display:table;
备注：行内属性标签，为了设置宽高，我们需要设置display:block;(除了input标签比较特殊)。在用float布局并有横向的margin后，在IE6下，他就具有了块属性float后的横向margin的bug。不过因为它本身就是行内属性标签，所以我们再加上display:inline的话，它的高宽就不可设了。这时候我们还需要在display:inline后面加入display:talbe。浏览器兼容问题五：图片默认有间距
问题症状：几个img标签放在一起的时候，有些浏览器会有默认的间距，加了问题一中提到的通配符也不起作用。
碰到几率：20%
解决方案：使用float属性为img布局
备注：因为img标签是行内属性标签，所以只要不超出容器宽度，img标签都会排在一行里，但是部分浏览器的img标签之间会有个间距。去掉这个间距使用float是正道。（我的一个学生使用负margin，虽然能解决，但负margin本身就是容易引起浏览器兼容问题的用法，所以我禁止他们使用）浏览器兼容问题六：标签最低高度设置min-height不兼容
问题症状：因为min-height本身就是一个不兼容的CSS属性，所以设置min-height时不能很好的被各个浏览器兼容
碰到几率：5%
解决方案：如果我们要设置一个标签的最小高度200px，需要进行的设置为：{min-height:200px; height:auto !important; height:200px; overflow:visible;}
备注：在B/S系统前端开时，有很多情况下我们又这种需求。当内容小于一个值（如300px）时。容器的高度为300px；当内容高度大于这个值时，容器高度被撑高，而不是出现滚动条。这时候我们就会面临这个兼容性问题。
2. CSS hack
请谨慎使用 css hack
In modern computing terminology, a kludge (or often a "hack") is a solution to a problem, doing a task, or fixing a system that is inefficient, inelegant, or even unfathomable, but which nevertheless (more or less) works.
(from wiki: Kludge)
也就是说，hack 是不优雅的、不是最有效的，甚至是不能理解的，但是能搞定问题的解决办法。
那么 CSS hack 呢？CSS hack 就是利用浏览器一些不标准的，或者可以称之为 bug 的特性，达到特定的目的。最常见的各种 hack 是关于 ie 的，尤其是旧版本 ie。这种 hack 比较无奈，但是相对安全，因为旧版本 ie 不再更新了，不会发生变化了。
但是，如果用一些当前浏览器的 bug 来 hack，就是有危险的了。这种 hack 建立在不稳定的浏览器特性上，没有标准可依。当浏览器厂商修复/标准化了这个特性的时候，hack 就可能失效。这样就解释了问题的这句话。说实话，笔者到现在为止还没有用到过CSS hack。个人认为原因有三：1. 笔者太菜，遇到的场景不够丰富，运气好没有踩到过坑；2.一些浏览器bug已经随着浏览器的版本更新被修复掉；3.遇到要使用CSS hack的情况了却没有意识到，换了种方式去实现了。最最最最究极原因，笔者所在的公司不需要支持 IE9 一下的老古董，甚至在某些项目里可以直接舍弃掉IE，是不是很羡慕？
JS篇
1. 集合类对象的()与[]的问题
IE下，可以使用()或[]获取集合类对象；Firefox下，只能使用[]获取集合类对象。
Js代码 ：
document.write(document.forms("formName").src);
//该写法在IE下能访问到Form对象的src属性
解决办法：将document.forms("formName")改为 document.forms["formName"]。统一使用[]获取集合类对象。
2. 对浏览器Native组件调用属性、方法大小写问题
IE：不区分大小写
FF、Chrome：区分大小写
如：Ajax返回的response对象，IE支持response.responseXml和responseXML；FF等浏览器支持response.responseXML，解决办法只有在编写程序时尽量避免不兼容的写法
3. new Date().getYear()
分析原因：在IE中得到的日期是2011，在FF和Safari中看到的日期是111，原因是在FF和safari返回的是当前年份-1900的值。
兼容处理：
Js代码：
//方式一 var year= new Date().getYear(); year = (year<1900?(1900+year):year); document.write(year); //方式二 var year = new Date().getFullYear(); document.write(year);
4. innerText的使用
分析原因:FF不支持innerText，它支持textContent来实现innerText，不过textContent没有像innerText一样考虑元素的display方式，所以不完全与IE兼容。如果不用textContent，字符串里面不包含HTML代码也可以用innerHTML代替。
兼容处理
通过判断不同浏览器做不同的处理
Js代码 javascript
if(document.all){
document.getElementById('element').innerText = "mytext";
} else{
document.getElementById('element').textContent = "mytext";
}注：Safari和Chrome对innerText和textContent都支持。
5. Frame的引用
【分析原因】
IE可以通过id或者name访问这个frame对应的window对象；而FF只可以通过name来访问这个frame对应的window对象。
【应用场景】
在一个页面嵌套了一个iframe页面(下面简称父页面和子页面)。父页面取子页面的值。
Js代码
<iframe id="frame_id" class="lazyload" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAANSURBVBhXYzh8+PB/AAffA0nNPuCLAAAAAElFTkSuQmCC" data-original="frametest.jsp" width="100%" height="100%" title="你好世界">
此时如果父页面想获取子页面例如div中的显示值，IE下可以这样写：
var obj = window.top.frame_id.document.getElementById(div_id); alert(obj.innerText);
但是在FF中却无法取子页面中的值，原因就是FF只支持window.top.frameName来访问子页面中的window对象。所以在IE、safari中是支持通过frameName或是frameId来访问子页面window对象的。
解决方法：
1、尽量都是用frameName去访问子页面window对象。
2、在FF、IE、Safari中都支持window.document.getElementById(frameId)来获得子页面window对象。
HTML 篇
如有以下这样一段代码：
<div id="test"><p>文字</p><p>文字</p> <p>文字</p></div>
单从HTML结构表象来看，ID test 一共有3个P元素子节点。其实，在IE下，这种表象就是实质，而在非IE下，表象的外衣将顷刻被撕开。
为了看出这种区别，我们可以遍历test的子节点，并将其节点个数及节点类型都打印出来：
<script type="text/javascript">var x = document.getElementById("test");var xc = x.childNodes;var xcl = xc.length;for(var i=0;i<xcl;i++){document.write("nodeName = " + xc[i].nodeName + "; nodeType = " + xc[i].nodeType + "<br />");</script>IE的打印结果为：
nodeName = P; nodeType = 1 nodeName = P; nodeType = 1 nodeName = P; nodeType = 1
非IE的打印结果为：
nodeName = #text; nodeType = 3nodeName = P; nodeType = 1 nodeName = #text; nodeType = 3nodeName = P; nodeType = 1 nodeName = #text; nodeType = 3nodeName = P; nodeType = 1 nodeName = #text; nodeType = 3
显而易见，IE的打印结果和我们所说的表象一样：有3个子节点，并且都为P元素；而非IE则表现出极大的差异：居然打印出了7个子节点，当然也包括3个P元素子节点在内，除此之外还多了4个nodeType=3的子节点，我们都知道节点类型为3的节点属于文本节点，但从那段HTML中可以看P与 P之间并无其它的内容出现，那这4个文本节点是怎样凭空出现的呢？
在这种情况下，唯一有可能的原因就是在HTML的书写上，因为这段HTML并不是连续的书写，而是每个节点间都用回车换行了，并且正好出现了4次换行，也许非IE把换行也当成了一个节点。
为了测试，我们可以将那段HTML改写为：
<div id="test"><p>文字</p><p>文字</p><p>文字</p></div>
IE的打印结果为：
nodeName = P; nodeType = 1 nodeName = P; nodeType = 1 nodeName = P; nodeType = 1
非IE的打印结果为：
nodeName = P; nodeType = 1 nodeName = P; nodeType = 1 nodeName = P; nodeType = 1
预想中的情况出现了，这回不论什么浏览器打印出来的都只是3个P子节点。
一些很基础却很不起眼的冷知识
DOCTYPE
1. 作用：声明文档的解析类型(document.compatMode)，避免浏览器的怪异模式。
document.compatMode： BackCompat：怪异模式，浏览器使用自己的怪异模式解析渲染页面。 CSS1Compat：标准模式，浏览器使用W3C的标准解析渲染页面。
这个属性会被浏览器识别并使用，但是如果你的页面没有DOCTYPE的声明，那么compatMode默认就是BackCompat,
这也就是恶魔的开始 -- 浏览器按照自己的方式解析渲染页面，那么，在不同的浏览器就会显示不同的样式。
如果你的页面添加了<!DOCTYPE html>那么，那么就等同于开启了标准模式，那么浏览器就得老老实实的按照W3C的标准解析渲染页面，这样一来，你的页面在所有的浏览器里显示的就都是一个样子了。
这就是<!DOCTYPE html>的作用。
2. 常用的 DOCTYPE 声明:
HTML 5
<!DOCTYPE html>
HTML 4.01 Strict
该 DTD 包含所有 HTML 元素和属性，但不包括展示性的和弃用的元素（比如 font）。不允许框架集（Framesets）。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
HTML 4.01 Transitional
该 DTD 包含所有 HTML 元素和属性，包括展示性的和弃用的元素（比如 font）。不允许框架集（Framesets）。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML4.01Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
HTML 4.01 Frameset
该 DTD 等同于 HTML 4.01 Transitional，但允许框架集内容。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
XHTML 1.0 Strict
该 DTD 包含所有 HTML 元素和属性，但不包括展示性的和弃用的元素（比如 font）。不允许框架集（Framesets）。必须以格式正确的 XML 来编写标记。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XHTML 1.0 Transitional
该 DTD 包含所有 HTML 元素和属性，包括展示性的和弃用的元素（比如 font）。不允许框架集（Framesets）。必须以格式正确的 XML 来编写标记。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
XHTML 1.0 Frameset
该 DTD 等同于 XHTML 1.0 Transitional，但允许框架集内容。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
XHTML 1.1
该 DTD 等同于 XHTML 1.0 Strict，但允许添加模型（例如提供对东亚语系的 ruby 支持）。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
废话太多了，你只需要记住每个页面头部都写这么一句话就ok了！
<!DOCTYPE html>
浏览器渲染原理
Web页面运行在各种各样的浏览器当中，浏览器载入、渲染页面的速度直接影响着用户体验简单地说，页面渲染就是浏览器将html代码根据CSS定义的规则显示在浏览器窗口中的这个过程。先来大致了解一下浏览器都是怎么干活的：
1. 用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
2. 浏览器开始载入html代码，发现<head>标签内有一个<link>标签引用外部CSS文件；
3. 浏览器又发出CSS文件的请求，服务器返回这个CSS文件；
4. 浏览器继续载入html中<body>部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了；
5. 浏览器在代码中发现一个img标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
6. 服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；
7. 浏览器发现了一个包含一行Javascript代码的<script>标签，赶快运行它；
8. Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个
（style.display=”none”）。杯具啊，突然就少了这么一个元素，浏览器不得不重新渲染这部分代码；
9. 终于等到了</html>的到来，浏览器泪流满面……
10. 等等，还没完，用户点了一下界面中的“换肤”按钮，Javascript让浏览器换了一下<link>标签的CSS路径；
11. 浏览器召集了在座的各位span ul li 们，“大伙儿收拾收拾行李，咱得重新来过……”，浏览器向服务器请求了新的CSS文件，重新渲染页面。
浏览器每天就这么来来回回跑着，要知道不同的人写出来的html和css代码质量参差不齐，说不定哪天跑着跑着就挂掉了。好在这个世界还有这么一群人——页面重构工程师，平时挺不起眼，也就帮视觉设计师们切切图啊改改字，其实背地里还是干了不少实事的。
说到页面为什么会慢？那是因为浏览器要花时间、花精力去渲染，尤其是当它发现某个部分发生了点变化影响了布局，需要倒回去重新渲染，内行称这个回退的过程叫reflow。
reflow几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引起浏览器的 reflow。鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲染。通常我们都无法预估浏览器到底会reflow哪一部分的代码，它们都彼此相互影响着。
reflow问题是可以优化的，我们可以尽量减少不必要的reflow。比如开头的例子中的 img 图片载入问题，这其实就是一个可以避免的reflow——给图片设置宽度和高度就可以了。这样浏览器就知道了图片的占位面积，在载入图片前就预留好了位置。
另外，有个和reflow看上去差不多的术语：repaint，中文叫重绘。 如果只是改变某个元素的背景色、文字颜色、边框颜色等等不影响它周围或内部布局的属性，将只会引起浏览器repaint。repaint的速度明显快于 reflow（在IE下需要换一下说法，reflow要比repaint 更缓慢）。
从浏览器的渲染原理讲CSS性能
平时我们几乎每天都在和浏览器打交道，写出来的页面很有可能在不同的浏览器下显示的不一样。苦逼的前端攻城师们为了兼容各个浏览器而不断地去测试和调试，还在脑子中记下各种遇到的BUG及解决方案，而我们好像并没有去主动地关注和了解下浏览器的工作原理。如果我们对此做一点了解，我想在项目过程中就可以根据它有效的避免一些问题以及对页面性能做出相应的改进。今天我们主要根据浏览器的渲染原理对CSS的书写性能做一点改进，下面让我们一起来揭开浏览器的渲染原理这一神秘的面纱吧：
最终决定浏览器表现出来的页面效果的差异是：渲染引擎 Rendering Engine（也叫做排版引擎），也就是我们通常所说的“浏览器内核”，负责解析网页语法（如HTML、JavaScript）并渲染、展示网页。相同的代码在不同的浏览器呈现出来的效果不一样，那么就很有可能是不同的浏览器内核导致的。
我们来看一下加载页面时浏览器的具体工作流程：
1、解析HTML以重建DOM树（Parsing HTML to construct the DOM tree ）：渲染引擎开始解析HTML文档，转换树中的标签到DOM节点，它被称为“内容树”。
2、构建渲染树（Render tree construction）：解析CSS（包括外部CSS文件和样式元素），根据CSS选择器计算出节点的样式，创建另一个树 —- 渲染树。
3、布局渲染树（Layout of the render tree）: 从根节点递归调用，计算每一个元素的大小、位置等，给每个节点所应该出现在屏幕上的精确坐标。
4、绘制渲染树（Painting the render tree） : 遍历渲染树，每个节点将使用UI后端层来绘制。
主要的流程就是：构建一个dom树，页面要显示的各元素都会创建到这个dom树当中，每当一个新元素加入到这个dom树当中，浏览器便会通过css引擎查遍css样式表，找到符合该元素的样式规则应用到这个元素上。
注意了：css引擎查找样式表，对每条规则都按从右到左的顺序去匹配。 看如下规则：
#nav li {}看起来很快，实际上很慢，尽管这让人有点费解。我们中的大多数人，尤其是那些从左到右阅读的人，可能猜想浏览器也是执行从左到右匹配规则的，因此会推测这条规则的开销并不高。在脑海中，我们想象浏览器会像这样工作：找到唯一的ID为nav的元素，然后把这个样式应用到直系子元素的li元素上。我们知道有一个ID为nav的元素，并且它只有几个Li子元素，所以这个CSS选择符应该相当高效。
事实上，CSS选择符是从右到左进行匹配的。了解这方面的知识后，我们知道这个之前看似高效地规则实际开销相当高，浏览器必须遍历页面上每个li元素并确定其父元素的id是否为nav。
*{}额，这种方法我刚写CSS的也写过，殊不知这种效率是差到极点的做法，因为*通配符将匹配所有元素，所以浏览器必须去遍历每一个元素，这样的计算次数可能是上万次！
ul#nav{} ul.nav{}在页面中一个指定的ID只能对应一个元素，所以没有必要添加额外的限定符，而且这会使它更低效。同时也不要用具体的标签限定类选择符，而是要根据实际的情况对类名进行扩展。例如把ul.nav改成.main_nav更好。
ul li li li .nav_item{}对于这样的选择器，之前也写过，最后自己也数不过来有多少后代选择器了，何不用一个类来关联最后的标签元素，如.extra_navitem，这样只需要匹配class为extra_navitem的元素，效率明显提升了
对此，在CSS书写过程中，总结出如下性能提升的方案：
1.避免使用通配规则 如 *{} 计算次数惊人！只对需要用到的元素进行选择
2.尽量少的去对标签进行选择，而是用class 如：#nav li{},可以为li加上nav_item的类名，如下选择.nav_item{}
3.不要去用标签限定ID或者类选择符 如：ul#nav,应该简化为#nav
4.尽量少的去使用后代选择器，降低选择器的权重值 后代选择器的开销是最高的，尽量将选择器的深度降到最低，最高不要超过三层，更多的使用类来关联每一个标签元素
5.考虑继承 了解哪些属性是可以通过继承而来的，然后避免对这些属性重复指定规则
选用高效的选择符，可以减少页面的渲染时间，从而有效的提升用户体验（页面越快，用户当然越喜欢_）,你可以看一下CSS selectors Test，这个实验的重点是评估复杂选择符和简单选择符的开销。也许当你想让渲染速度最高效时，你可能会给每个独立的标签配置一个ID，然后用这些ID写样式。那的确会超级快，也超级荒唐！这样的结果是语义极差，后期的维护难到了极点。
但说到底，CSS性能这东西对于小的项目来讲可能真的是微乎其微的东西，提升可能也不是很明显，但对于大型的项目肯定是有帮助的。而且一个好的CSS书写习惯和方式能够帮助我们更加严谨的要求自己。
结语
能看到这里，你才是赚到了。上面BB了那么多，想必客官一定看得头晕雾绕了。大家心里一定有个疑问，浏览器兼容性有这么恶心人吗？有没有一个好的解决方案呢？答案是一定的，那就是框架，各种各样的框架。
啥是框架？
框架从本质上来说，就是帮你干活，让你少操心，什么兼容性了、底层的东西了统统交给我。你只需要告诉我你要干嘛，我全帮你搞定了。当然了，帮你搞定兼容性也是有代价的，那就是牺牲性能换兼容性。不过在这个硬件过剩的时代，使用框架所消耗掉的那点性能绝对是可以接受的，反正我相信大家肯定不愿意天天被测试追着问 "xxx,IE下又白屏了，IE下又没居中了，IE下样式又乱掉了...."。嗯，笔者对 IE 绝对没(shen)有(wu)成(tong)见(jue).
作者：麻辣小隔壁
链接：https://www.jianshu.com/p/a1f237dacf5b
共同学习，写下你的评论
评论加载中...
作者其他优质文章
