各主流浏览器的区别各主流浏览器的区别
http://www.cnblogs.com/lhb25/archive/2013/06/05/html5-and-css3-2013.html
-
一、 Trident内核代表产品Internet Explorer，又称其为IE内核。Trident（又称为MSHTML），是微软开发的一种排版引擎。使用Trident渲染引擎的浏览器包 括：IE、傲游、世界之窗浏览器、Avant、腾讯TT、Netscape 8、NetCaptor、Sleipnir、GOSURF、GreenBrowser和KKman等。
-
2
二、Gecko内核代表作品Mozilla FirefoxGecko是一套开放源代码的、以C++编写的网页排版引擎。Gecko是最流行的排版引擎之一，仅次于Trident。使用它的最著名浏览器有Firefox、Netscape6至9。
-
3
三、 WebKit内核代表作品Safari、Chromewebkit 是一个开源项目，包含了来自KDE项目和苹果公司的一些组件，主要用于Mac OS系统，它的特点在于源码结构清晰、渲染速度极快。缺点是对网页代码的兼容性不高，导致一些编写不标准的网页无法正常显示。主要代表作品有Safari 和Google的浏览器Chrome。
-
4
四、 Presto内核代表作品OperaPresto是由Opera Software开发的浏览器排版引擎，供Opera 7.0及以上使用。它取代了旧版Opera 4至6版本使用的Elektra排版引擎，包括加入动态功能，例如网页或其部分可随着DOM及Script语法的事件而重新排版
5大主流浏览器的差异
任何上过网的用户对浏览器是再熟悉不过了。只是用户看到仅仅只是浏览器本身，却很少能看到浏览器最核心的部分—浏览器内核。从第一款libwww（Library WorldWideWeb）浏览器发展至今已经经历了无数竞争与淘汰了。现在国内常见的浏览器有：IE、Firefox、QQ浏览器、Safari、Opera、Google Chrome、百度浏览器、搜狗浏览器、猎豹浏览器、360浏览器、UC浏览器、遨游浏览器、世界之窗浏览器等。但目前最为主流浏览器有五大款，分别是IE、Firefox、Google Chrome、Safari、Opera。
浏览器最重要的部分是浏览器的内核。浏览器内核是浏览器的核心，也称“渲染引擎”，用来解释网页语法并渲染到网页上。浏览器内核决定了浏览器该如何显示网页内容以及页面的格式信息。不同的浏览器内核对网页的语法解释也不同，因此网页开发者需要在不同内核的浏览器中测试网页的渲染效果。
- 对网页的语法解释不同
- 渲染效果不一样
- 性能不一样，支持脚本的执行速度等不一样，而且支持局部（隐藏元素等）repaint和reflow的情况比较复杂不一样
简单介绍一下五大主流浏览器。（按时间顺序）
1、IE浏览器：
IE是微软公司旗下浏览器，是目国内用户量最多的浏览器。IE诞生于1994年，当时微软为了对抗市场份额占据将近百分之九十的网景Netscape Navigator，于是在Windows中开发了自己的浏览器Internet Explorer，自此也引发了第一次浏览器大战。结果可想而知，微软大获全胜，网景不得不将自己卖给AOL公司。但实际上事情并没有结束，网景后来开发了风靡一时的Firefox火狐，至今Firefox也成为世界五大浏览器之一。
1996年，微软从Spyglass手里拿到Spyglass Mosaic的源代码和授权，开始开发自己的浏览器IE。后来，微软以IE和Windows捆绑的模式不断向市场扩展份额，使IE成为市场的绝对主流。现在装了Windows系统的电脑基本无法卸载IE。
2、Opera浏览器：
Opera是挪威Opera Software ASA公司旗下的浏览器。1995年，opera公司发布第一版Opera浏览器，使用自己研发的Presto内核。当时opera公司的开发团队不断完善Presto内核，使Opera浏览器一度成为顶级浏览器。直到2016年奇虎360和昆仑万维收购了Oprea浏览器，从此也丢弃了强大的Presto内核，改用当时Google开源的webkit内核。后来Opera浏览器跟随Google将浏览器内核改为Blink内核。自此Presto内核也淡出了互联网市场。
3、Safari浏览器：
第二次浏览器大战是从苹果公司发布Safari浏览器开始的。2003年，苹果公司在苹果手机上开发Safari浏览器，利用自己得天独厚的手机市场份额使Safari浏览器迅速成为世界主流浏览器。Safari是最早使用webkit内核的浏览器也是现在苹果默认的浏览器。
4、Firefox浏览器：
Firefox浏览器使Mozilla公司旗下浏览器，也是刚才提到的网景公司后来的浏览器。网景被收购后，网景人员创办了Mozilla基金会，这是一个非盈利组织，他们在2004年推出自己的浏览器Firefox。Firefox采用Gecko作为内核。Gecko是一个开源的项目，代码完全公开，因此受到很多人的青睐。Firefox的问世加快了第二次浏览器大战的开始。第二次浏览器大战与第一次二元鼎力的局面不同，这一次的特点就是百家争鸣，也自此打破了IE浏览器从98年网景被收购后独步浏览器市场的局面。
5、Chrome浏览器：
Chrome浏览器是google旗下的浏览器。Chrome浏览器至发布以来一直讲究简洁、快速、安全，所以Chrome浏览器到现在一直受人追捧。最开始Chrome采用webkit作为浏览器内核，直到2013年，google宣布不再使用苹果的webkit内核，开始使用webkit的分支内核Blink。
以上是五大浏览器的简介，接下来是四大内核。在介绍五大浏览器的同时也已经顺便介绍了四大内核。四大内核分别是：Trident（也称IE内核）、webkit、Blink、Gecko。五大浏览器采用的都是单内核，而随着浏览器的发展现在也出现了双内核。像360浏览器、QQ浏览器都是采用双内核。
作为前端开发，熟悉四大内核是非常有必要的。四大内核的解析不同使网页渲染效果更具多样化。下面总结一下各常用浏览器所使用的内核。
1、IE浏览器内核：Trident内核，也是俗称的IE内核；
2、Chrome浏览器内核：统称为Chromium内核或Chrome内核，以前是Webkit内核，现在是Blink内核；
3、Firefox浏览器内核：Gecko内核，俗称Firefox内核；
4、Safari浏览器内核：Webkit内核；
5、Opera浏览器内核：最初是自己的Presto内核，后来是Webkit，现在是Blink内核；
6、360浏览器、猎豹浏览器内核：IE+Chrome双内核；
7、搜狗、遨游、QQ浏览器内核：Trident（兼容模式）+Webkit（高速模式）；
8、百度浏览器、世界之窗内核：IE内核；
9、2345浏览器内核：以前是IE内核，现在也是IE+Chrome双内核；
通常我们比较常见的大约只有以下四种，下面先简单介绍一下。
Trident： IE浏览器使用的内核，该内核程序在1997年的IE4中首次被采用，是微软在Mosaic代码的基础之上修
改而来的，并沿用到目前的IE9。Trident实际上是一款开放的内核，其接口内核设计的相当成熟，因此才有许多
采用IE内核而非IE的浏览器涌现（如 Maxthon、The World 、TT、GreenBrowser、AvantBrowser等）。此外，
为了方便也有很多人直接简称其为IE内核（当然也不排除有部分人是因为不知道内核名称而只好如此说）。由于IE本身的“垄断性”（虽然名义上IE并非垄断，但实际上，特别是从Windows 95年代一直到XP初期，就市场占有率来说IE的确借助Windows的东风处于“垄断”的地位）而使得Trident内核的长期一家独大，微软很长时间都并没有更新Trident内核，这导致了两个后果——一是Trident内核曾经几乎与W3C标准脱节（2005年），二是Trident内核的大量 Bug等安全性问题没有得到及时解决，然后加上一些致力于开源的开发者和一些学者们公开自己认为IE浏览器不安全的观点，也有很多用户转向了其他浏览器，Firefox和Opera就是这个时候兴起的。非Trident内核浏览器的市场占有率大幅提高也致使许多网页开发人员开始注意网页标准和非IE浏览器的浏览效果问题。
Gecko
/ˈɡekəʊ/
： Netscape6开始采用的内核，后来的Mozilla FireFox (火狐浏览器) 也采用了该内核，Gecko的特点
是代码完全公开，因此，其可开发程度很高，全世界的程序员都可以为其编写代码，增加功能。因为这是个开源
内核，因此受到许多人的青睐，Gecko内核的浏览器也很多，这也是Geckos内核虽然年轻但市场占有率能够迅速
提高的重要原因。 事实上，Gecko引擎的由来跟IE不无关系，前面说过IE没有使用W3C的标准，这导致了微软内部一些开发人员的不满；他们与当时已经停止更新了的 Netscape的一些员工一起创办了Mozilla，以当时的Mosaic内核为基础
重新编写内核，于是开发出了Geckos。不过事实上，Gecko 内核的浏览器仍然还是Firefox (火狐) 用户最多，
所以有时也会被称为Firefox内核。此外Gecko也是一个跨平台内核，可以在Windows、 BSD、Linux和Mac OS X
中使用。
Presto： 目前Opera采用的内核，该内核在2003年的Opera7中首次被使用，该款引擎的特点就是渲染速度的优化达到了极致，也是目前公认网页浏览速度最快的浏览器内核，然而代价是牺牲了网页的兼容性。
实际上这是一个动态内核，与前面几个内核的最大的区别就在脚本处理上，Presto有着天生的优势，页面的全部或者部分都能够在回应脚本事件时等情况下被重新解析。
此外该内核在执行Javascrīpt的时候有着最快的速度，根据在同等条件下的测试，Presto内核执行同等Javascrīpt所需的时间仅有Trident和Gecko内核的约1/3（Trident内核最慢，不过两者相差没有多大）。
那次测试的时候因为Apple机的硬件条件和普通PC机不同所以没有测试WebCore内核。只可惜Presto是商业引擎，使用Presto的除开Opera以外，只剩下NDSBrowser、Wii Internet Channle、Nokia 770网络浏览器等，这很大程度上限制了Presto的发展。
Webkit：苹果公司自己的内核，也是苹果的Safari浏览器使用的内核。 Webkit引擎包含WebCore排版引擎及JavaScriptCore解析引擎，均是从KDE的KHTML及KJS引擎衍生而来，它们都是自由软件，在GPL条约下授权，同时支持BSD系统的开发。
所以Webkit也是自由软件，同时开放源代码。在安全方面不受IE、Firefox的制约，所以Safari浏览器在国内还是很安全的。
限于Mac OS X的使用不广泛和Safari浏览器曾经只是Mac OS X的专属浏览器，这个内核本身应该说市场范围并不大；但似乎根据最新的浏览器调查表明，该浏览器的市场甚至已经超过了Opera的Presto了——当然这一方面得益于苹果转到x86架构之后的人气暴涨，另外也是因为Safari 3终于推出了Windows版的缘故吧。
Mac下还有OmniWeb、Shiira等人气很高的浏览器。
google的chrome也使用webkit作为内核。
WebKit 内核在手机上的应用也十分广泛，例如 Google 的手机 Gphone、 Apple 的 iPhone， Nokia’s Series 60 browser 等所使用的 Browser 内核引擎，都是基于 WebKit。
二、浏览器渲染原理（http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.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性能(http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.html)
平时我们几乎每天都在和浏览器打交道，写出来的页面很有可能在不同的浏览器下显示的不一样。苦逼的前端攻城师们为了兼容各个浏览器而不断地去测试和调试，还在脑子中记下各种遇到的BUG及解决方案，而我们好像并没有去主动地关注和了解下浏览器的工作原理。如果我们对此做一点了解，我想在项目过程中就可以根据它有效的避免一些问题以及对页面性能做出相应的改进。今天我们主要根据浏览器的渲染原理对CSS的书写性能做一点改进（当然还有JS本篇文章暂不考虑，后面的文章会做介绍），下面让我们一起来揭开浏览器的渲染原理这一神秘的面纱吧：
最终决定浏览器表现出来的页面效果的差异是：渲染引擎 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样式表，找到符合该元素的样式规则应用到这个元素上。
#nav li {}
看起来很快，实际上很慢，尽管这让人有点费解#_#。我们中的大多数人，尤其是那些从左到右阅读的人，可能猜想浏览器也是执行从左到右匹配规则的，因此会推测这条规则的开销并不高。在脑海中，我们想象浏览器会像这样工作：找到唯一的ID为nav的元素，然后把这个样式应用到直系子元素的li元素上。我们知道有一个ID为nav的元素，并且它只有几个Li子元素，所以这个CSS选择符应该相当高效。
事实上，CSS选择符是从右到左进行匹配的。了解这方面的知识后，我们知道这个之前看似高效地规则实际开销相当高，浏览器必须遍历页面上每个li元素并确定其父元素的id是否为nav。
*{}
在页面中一个指定的ID只能对应一个元素，所以没有必要添加额外的限定符，而且这会使它更低效。同时也不要用具体的标签限定类选择符，而是要根据实际的情况对类名进行扩展。例如把ul.nav改成.main_nav更好。
ul li li li .nav_item{}
对于这样的选择器，之前也写过，最后自己也数不过来有多少后代选择器了，何不用一个类来关联最后的标签元素，如.extra_navitem，这样只需要匹配class为extra_navitem的元素，效率明显提升了
对此，在CSS书写过程中，总结出如下性能提升的方案：
避免使用通配规则 如 *{} 计算次数惊人！只对需要用到的元素进行选择
尽量少的去对标签进行选择，而是用class 如：#nav li{},可以为li加上nav_item的类名，如下选择.nav_item{}
不要去用标签限定ID或者类选择符 如：ul#nav,应该简化为#nav
尽量少的去使用后代选择器，降低选择器的权重值 后代选择器的开销是最高的，尽量将选择器的深度降到最低，最高不要超过三层，更多的使用类来关联每一个标签元素
考虑继承 了解哪些属性是可以通过继承而来的，然后避免对这些属性重复指定规则
选用高效的选择符，可以减少页面的渲染时间，从而有效的提升用户体验（页面越快，用户当然越喜欢^_^）,你可以看一下CSS selectors Test，这个实验的重点是评估复杂选择符和简单选择符的开销。也许当你想让渲染速度最高效时，你可能会给每个独立的标签配置一个ID，然后用这些ID写样式。那的确会超级快，也超级荒唐！这样的结果是语义极差，后期的维护难到了极点。
但说到底，CSS性能这东西对于小的项目来讲可能真的是微乎其微的东西，提升可能也不是很明显，但对于大型的项目肯定是有帮助的。而且一个好的CSS书写习惯和方式能够帮助我们更加严谨的要求自己。
原文链接：https://blog.csdn.net/qq_36379597/article/details/101382234
项目中
1、ie，firefox和 chrome 点击对象之间的差异：
项目中我做了不少模态框（弹出层），这就涉及到了关闭模态框按钮的点击事件（关闭按钮是bootstrap风格的），因为页面注册的事件太多所以用了事件委托的形式去做，众所周知bootstrap 风格的关闭按钮是这样写的
<button type="button" class="close" data-dismiss="alert" aria-label="Close"><span aria-hidden="true">×</span></button>button 里面内嵌一个用作标识符的标签，而当我捕获目标事件对象(event.target) 的时候在chrome 浏览器就会捕获到内嵌的 span 标签，而在ie 和 firefox 中目标事件对象只会捕获到button 而不是 span。 天！我之前在chrome 做开发的时候为了迁就把id 写给了 span 标签然而到了ie 调试的时候却不生效，苦闷了一个晚上。
解决办法是：不用嵌套的span 标签 button 标签里面输入 " × " 这个符号（各大输入法都有）id 绑定在 button标签里。
2、ajax 的缓存问题
在服务器调试时总会遇到缓存的问题，这个缓存不仅影响到修改完 js代码后再刷新页面而无法更新修改后的 js代码，更可怕的是在ie 里这种缓存会影响到ajax 请求的数据。
例如：当页面加载完成时我们发送一个 ajax请求到后台请求数据，之后我们更新了一条信息也发送同样一条请求刷新页面数据，这两条请求就会视为一样的请求，浏览器知道这两条请求一样后就不会再重新从服务器抓取数据而是只返回前一次请求的数据，达到减少服务器请求这样的一个效果，但是这并不是我想要的。
解决办法是：jq 的ajax 有一个 cache 选项，把它设置为false 或者在请求后台的url 最后加一个时间戳，例如：
$.ajax({
url: '/Management/file/ajaxDeleteFile.action?t=' + new Date().getTime,
type: 'POST',
dataType: 'json',
data: "accuid=" + accuid + "&uid=" + uid,
success: function(data){
if (data.code == 100) {
//请求成功后刷新文件列表
depFileListModule.initFileList(curPath,curDepId);
//关闭对话框
s("#drop-file-floor").style.display = 'none';
alert("删除成功");
}else if(data.code == 300) {
//后台状态码为300 表示这个账号在另一个浏览器或终端登录
//返回错误信息并跳转到登陆页
alert(data.message);
window.location.replace("/Management/public/login.action");
}else{
alert("删除失败，遇到未知错误请重试");
}
}
})或者是设置 cache 为false
$.ajax({
url: '/Management/file/ajaxDeleteFile.action',
type: 'POST',
dataType: 'json',
data: "accuid=" + accuid + "&uid=" + uid,
cache: false,
success: function(data){
if (data.code == 100) {
//请求成功后刷新文件列表
depFileListModule.initFileList(curPath,curDepId);
//关闭对话框
s("#drop-file-floor").style.display = 'none';
alert("删除成功");
}else if(data.code == 300) {
//后台状态码为300 表示这个账号在另一个浏览器或终端登录
//返回错误信息并跳转到登陆页
alert(data.message);
window.location.replace("/Management/public/login.action");
}else{
alert("删除失败，遇到未知错误请重试");
}
}
})这里科普一段别人博客写的关于ajax 缓存的解释
1:GET访问 浏览器 认为 是等幂的
就是 一个相同的URL 只有一个结果[相同是指 整个URL字符串完全匹配]
所以 第二次访问的时候 如果 URL字符串没变化 浏览器是 直接拿出了第一次访问的结果
2:POST则 认为是一个 变动性 访问 （浏览器 认为 POST的提交 必定是 有改变的）
防止 GET 的 等幂 访问 就在URL后面加上 ？+new Date();，[总之就是使每次访问的URL字符串不一样的]
设计WEB页面的时候 也应该遵守这个原则 原文地址：
http://www.cnblogs.com/fullhouse/archive/2012/01/17/2324842.html
//------------------ 补充于7-22 ----------------
忽略了一个很重要的问题
3、getComputedStyle 在ie 中引发的问题
不久前看过 getComputedStyle 这个js 获取元素最终样式的方法 原文链接是大神张鑫旭的： 获取元素CSS值之getComputedStyle方法熟悉 « 张鑫旭-鑫空间-鑫生活
所以在学校的项目里面想试一试，因为浏览器的差异，这个函数要兼容ie 需要写成这样
element.currentStyle? element.currentStyle : window.getComputedStyle(element, null)由此可见这里出现了另外一个方法：currentStyle
此方法是兼容ie 的，但是当一个元素样式没有设置宽度在ie 中会显示为 auto！
这样我们想计算一些值时就很困难了，解决方法有两个：
1、如果你的项目不用兼容低版本的ie （ie9+）
那么你可以直接使用getComputedStyle 这个方法，这个方法会返回有值的宽度
2、改用更高兼容性的 offsetWidth 或 clientWidth （当时我真的是眼瞎，竟然用了上面那个那么鸡肋的方法 不过试试新东西也无妨 哈哈）
// --------------------- 补充于2017-10-17 ---------------------
4、firefox 中调用 getComputeStyle 时无法获取 padding 属性
没错又是getComputedStyle 的事，因为浏览器之间的差异在调用这个方法获取元素属性时也会有着差异就像这次
chrome 中：
window.getComputedStyle(elem, null).padding这里完全可以获取到对应的padding 属性
而firefox 中，可能觉得这样获取padding 有点太抽象化了所以getComputedStyle 方法中并没有padding 这个属性只有如下：
同样 margin 也是一样
而border 则更多
所以为了兼容浏览器请不要简写padding了，border也请写清楚要获取border 的什么内容
注意：文章来源于网络