Differences between major browsers Differences between major browsers
http://www.cnblogs.com/lhb25/archive/2013/06/05/html5-and-css3-2013.html
-
1. The representative product of Trident kernel is Internet Explorer, also known as IE kernel. Trident (also known as MSHTML) is a typesetting engine developed by Microsoft. Browsers using the Trident rendering engine include: IE, Maxthon, World Window Browser, Avant, Tencent TT, Netscape 8, NetCaptor, Sleipnir, GOSURF, GreenBrowser and KKman, etc.
-
2
2. The representative work of Gecko kernel, Mozilla Firefox, Gecko is an open source web page layout engine written in C++. Gecko is one of the most popular typesetting engines, second only to Trident. The most famous browsers that use it are Firefox and Netscape 6 to 9.
-
3
3. WebKit core representative works Safari and Chromewebkit are an open source project that contains some components from the KDE project and Apple. It is mainly used in Mac OS systems. It is characterized by a clear source code structure and extremely fast rendering speed. The disadvantage is that the compatibility with web page codes is not high, resulting in some non-standard web pages being unable to display properly. The main representative works include Safari and Google's browser Chrome.
-
4
4. Opera Presto, the representative work of Presto kernel, is a browser layout engine developed by Opera Software for use by Opera 7.0 and above. It replaces the Elektra layout engine used in the old versions of Opera 4 to 6, including adding dynamic features, such that web pages or parts thereof can be rearranged according to DOM and Script syntax events.
-
Original link: https://www.cnblogs.com/lsc-boke/p/5525859.html
Differences between 5 major browsers
Anyone who has ever surfed the Internet is very familiar with browsers. It’s just that users only see the browser itself, but rarely see the core part of the browser—the browser core. Since the development of the first libwww (Library WorldWideWeb) browser, it has experienced countless competitions and eliminations. Common browsers in China now include: IE, Firefox, QQ Browser, Safari, Opera, Google Chrome, Baidu Browser, Sogou Browser, Cheetah Browser, 360 Browser, UC Browser, Aoyou Browser, World Window Browser etc. But currently there are five major mainstream browsers, namely IE, Firefox, Google Chrome, Safari, and Opera.
The most important part of a browser is the kernel of the browser. The browser kernel is the core of the browser, also known as the "rendering engine", which is used to interpret web page syntax and render it onto the web page. The browser kernel determines how the browser displays the content of the web page and the format information of the page. Different browser kernels interpret the syntax of web pages differently, so web developers need to test the rendering effect of web pages in browsers with different kernels.
- Different grammatical interpretations of web pages
- The rendering effect is different
- The performance is different, the execution speed of supported scripts is different, and the situation of supporting partial (hidden elements, etc.) repaint and reflow is more complicated and different.
Let’s briefly introduce the five major browsers. (In chronological order)
1. IE browser:
IE is a browser owned by Microsoft Corporation and is the browser with the largest number of users in China. IE was born in 1994. At that time, in order to compete with Netscape Navigator, which held nearly 90% of the market share, Microsoft developed its own browser Internet Explorer in Windows. This also triggered the first browser war. As you can imagine, Microsoft won a big victory and Netscape had to sell itself to AOL. But in fact, the matter was not over. Netscape later developed the popular Firefox, and Firefox has become one of the top five browsers in the world.
In 1996, Microsoft obtained the source code and authorization of Spyglass Mosaic from Spyglass and began to develop its own browser IE. Later, Microsoft continued to expand its market share by bundling IE and Windows, making IE the absolute mainstream in the market. Nowadays, it is basically impossible to uninstall IE on computers with Windows systems installed.
2. Opera browser:
Opera is a browser owned by the Norwegian Opera Software ASA company. In 1995, opera company released the first version of the Opera browser, using its own developed Presto kernel. At that time, the development team of opera company continued to improve the Presto kernel, making the Opera browser once a top browser. Until 2016, Qihoo 360 and Kunlun Worldwide acquired the Oprea browser, and since then they also abandoned the powerful Presto kernel and switched to Google's open source webkit kernel at the time. Later, Opera browser followed Google and changed the browser core to Blink core. Since then, the Presto kernel has also faded out of the Internet market.
3. Safari browser:
The second browser war started when Apple released the Safari browser. In 2003, Apple developed the Safari browser on the iPhone, using its unique mobile phone market share to quickly become the world's mainstream browser. Safari is the earliest browser to use the webkit kernel and is now Apple's default browser.
4. Firefox browser:
Firefox browser is a browser owned by Mozilla Company, and is also the later browser of Netscape Company mentioned just now. After Netscape was acquired, Netscape personnel founded the Mozilla Foundation, a non-profit organization, and they launched their own browser Firefox in 2004. Firefox uses Gecko as its core. Gecko is an open source project, and the code is completely open, so it is favored by many people. The advent of Firefox accelerated the beginning of the second browser war. The second browser war is different from the first dual-power situation. This time it is characterized by a hundred schools of thought contending, which has since broken IE browser's dominance in the browser market since the acquisition of Netscape in 1998.
5. Chrome browser:
Chrome browser is a browser owned by Google. Since its release, the Chrome browser has always focused on simplicity, speed, and security, so the Chrome browser has been popular until now. At first, Chrome used webkit as the browser kernel. It was not until 2013 that Google announced that it would no longer use Apple's webkit kernel and began to use Blink, a branch kernel of webkit.
The above is an introduction to the five major browsers, followed by the four major cores. While introducing the five major browsers, we have also introduced the four major cores. The four major kernels are: Trident (also known as IE kernel), webkit, Blink, and Gecko. The five major browsers all use a single core, and with the development of browsers, dual cores are now available. Browsers like 360 and QQ use dual cores.
As a front-end developer, it is very necessary to be familiar with the four cores. The different parsing of the four cores makes the web page rendering effect more diverse. The following summarizes the kernels used by commonly used browsers.
1. IE browser kernel: Trident kernel, also commonly known as IE kernel;
2. Chrome browser kernel: collectively referred to as Chromium kernel or Chrome kernel, formerly Webkit kernel, now Blink kernel;
3. Firefox browser kernel: Gecko kernel , commonly known as Firefox kernel;
4. Safari browser kernel: Webkit kernel;
5. Opera browser kernel: initially its own Presto kernel, then Webkit, and now Blink kernel;
6. 360 browser, Cheetah browser kernel: IE + Chrome dual core;
7. Sogou, Aoyou, QQ browser kernel: Trident (compatibility mode) + Webkit (high-speed mode);
8. Baidu browser, Window of the World kernel: IE kernel;
9. 2345 browser kernel: before It is the IE core, and now it is also the IE+Chrome dual core;
Usually we only have the following four common ones. Let’s briefly introduce them below.
Trident: The kernel used by the IE browser. This kernel program was first used in IE4 in 1997. It was modified by Microsoft based on the Mosaic code
and is still used in the current IE9. Trident is actually an open kernel, and its interface kernel design is quite mature, so many
browsers have emerged that use the IE kernel instead of IE (such as Maxthon, The World, TT, GreenBrowser, AvantBrowser, etc.). In addition,
for convenience, many people simply refer to it as the IE kernel (of course, it is not ruled out that some people have to say so because they do not know the name of the kernel). Due to the "monopoly" of IE itself (although IE is not a monopoly in name, in fact, especially from the Windows 95 era to the early days of XP, IE did have a "monopoly" position in terms of market share with the help of Windows) As a result, the Trident kernel has been dominated by one company for a long time. Microsoft has not updated the Trident kernel for a long time. This has led to two consequences - one is that the Trident kernel was almost out of touch with the W3C standard (in 2005), and the other is the large number of Trident kernels. Security issues such as bugs were not resolved in a timely manner, and some developers and scholars committed to open source publicly expressed their views that the IE browser was unsafe. Many users turned to other browsers, such as Firefox and Opera. rise. The significant increase in the market share of non-Trident core browsers has also caused many web developers to begin to pay attention to web standards and the browsing performance of non-IE browsers.
Gecko
/ˈɡekəʊ/
: The kernel started to be used by Netscape 6, and later Mozilla FireFox (Firefox browser) also adopted this kernel. The characteristic of Gecko is that the
code is completely open, so it has a high degree of development, and programmers around the world can It writes code and adds functionality. Because this is an open source
kernel, it is favored by many people. There are also many browsers with the Gecko kernel. This is also an
important reason why the market share of the Geckos kernel can increase rapidly even though it is young. In fact, the origin of the Gecko engine has something to do with IE. As mentioned earlier, IE did not use W3C standards, which led to dissatisfaction among some developers within Microsoft; they founded Mozilla together with some employees of Netscape, which had stopped updating at the time. , based on the Mosaic kernel at that time
, the kernel was rewritten, and Geckos was developed. But in fact, the browser with Gecko core is still Firefox (Firefox) with the most users,
so it is sometimes called Firefox core. In addition, Gecko is also a cross-platform kernel and can be
used in Windows, BSD, Linux and Mac OS X.
Presto: The kernel currently used by Opera. This kernel was first used in Opera 7 in 2003. The characteristic of this engine is that the rendering speed has been optimized to the extreme. It is also currently recognized as the fastest browser kernel for web browsing. However, the price is Sacrificing web compatibility.
In fact, this is a dynamic kernel. The biggest difference from the previous kernels is script processing. Presto has a natural advantage. All or part of the page can be re-parsed in response to script events.
In addition, the kernel has the fastest speed when executing Javascript. According to tests under the same conditions, the time required for the Presto kernel to execute the same Javascript is only about 1/3 of the Trident and Gecko kernels (the Trident kernel is the slowest, but the two There is not much difference).
During that test, because the hardware conditions of Apple machines were different from ordinary PCs, the WebCore kernel was not tested. It's a pity that Presto is a commercial engine. Apart from Opera, the only ones using Presto are NDSBrowser, Wii Internet Channel, Nokia 770 web browser, etc. This has greatly restricted the development of Presto.
Webkit: Apple's own kernel, which is also the kernel used by Apple's Safari browser. The Webkit engine includes the WebCore typesetting engine and the JavaScriptCore parsing engine, both of which are derived from KDE's KHTML and KJS engines. They are free software, licensed under the GPL treaty, and support the development of BSD systems.
Therefore, Webkit is also free software and open source. In terms of security, it is not restricted by IE and Firefox, so Safari browser is still very safe in China.
Limited to the fact that Mac OS X is not widely used and the Safari browser was once only an exclusive browser for Mac OS It has surpassed Opera's Presto - of course, this is due to the surge in popularity after Apple switched to the x86 architecture, and also because Safari 3 finally launched a Windows version.
There are also popular browsers such as OmniWeb and Shiira for Mac.
Google's chrome also uses webkit as the kernel.
The WebKit kernel is also widely used in mobile phones. For example, the Browser kernel engine used by Google's Gphone, Apple's iPhone, and Nokia's Series 60 browser are all based on WebKit.
2. Browser rendering principle (http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.html)
Web pages run in a variety of browsers. The speed at which the browser loads and renders the page directly affects the user experience. Simply put, page rendering is when the browser displays the HTML code in the browser window according to the rules defined by CSS. of this process. First, let’s have a general understanding of how the browser works:
1. The user enters the URL (assuming it is an HTML page and it is the first visit), the browser sends a request to the server, and the server returns the HTML file; 2. The browser
starts Load the html code and find that there is a <link> tag in the <head> tag that refers to an external CSS file;
3. The browser sends a request for the CSS file again, and the server returns the CSS file;
4. The browser continues to load the <body in the html >Part of the code, and the CSS file has been obtained, you can start rendering the page;
5. The browser finds an <img> tag in the code that references an image, and sends a request to the server. At this time, the browser will not wait until the image is downloaded, but will continue to render the following code;
6. The server returns the image file. Since the image occupies a certain area, it affects the arrangement of subsequent paragraphs, so the browser needs to go back and re-render. This part of the code;
7. The browser finds a <script> tag containing a line of Javascript code and runs it quickly;
8. The Javascript script executes this statement, which instructs the browser to hide a certain part of the code
(style.display=”none”). Oops, suddenly such an element is missing, and the browser has to re-render this part of the code;
9. Finally waited for the arrival of </html>, and the browser burst into tears...
10. Wait, it’s not over yet, the user Clicked the "Skin" button in the interface, and Javascript asked the browser to change the CSS path of the <link> tag;
11. The browser summoned everyone present <span><ul><li>"Everyone Pack your bags, we have to start over..." The browser requested
a new CSS file from the server and re-rendered the page.
The browser runs back and forth like this every day. You must know that the quality of the HTML and CSS codes written by different people varies, and it may crash one day while running. Fortunately, there is still a group of people in this world - page reconstruction engineers. They are usually very inconspicuous. They just help visual designers cut pictures and change words. In fact, they do a lot of practical things behind the scenes.
Speaking of why the page is slow? That's because the browser takes time and effort to render, especially when it finds that a certain part has changed slightly and affects the layout, and needs to go back and re-render. Experts call this rollback process called reflow.
Reflow is almost inevitable. Some of the popular effects on the interface now, such as folding and expanding tree-like directories (essentially the display and hiding of elements), etc., will cause the browser to reflow. Mouse sliding, clicking... As long as these actions cause changes in the area, positioning, margins and other attributes of certain elements on the page, they will cause re-rendering within, around, or even the entire page. Usually we can't predict which part of the code the browser will reflow, they all affect each other.
The reflow problem can be optimized, and we can minimize unnecessary reflow. For example, the <img> image loading problem in the example at the beginning is actually a reflow that can be avoided - just set the width and height of the image. In this way, the browser knows the area occupied by the image and reserves the space before loading the image.
In addition, there is a term that looks similar to reflow: repaint, which is called redraw in Chinese. If you just change the background color, text color, border color, etc. of an element without affecting its surrounding or internal layout, it will only cause the browser to repaint. The speed of repaint is obviously faster than reflow (under IE, you need to change the term, reflow is slower than repaint).
3. Talk about CSS performance from the perspective of browser rendering principles (http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.html)
We usually deal with browsers almost every day, and the pages we write are likely to be displayed differently in different browsers. The hard-working front-end siege engineers are constantly testing and debugging in order to be compatible with various browsers, and they also write down various bugs and solutions in their minds, but we don't seem to actively pay attention to and understand the browsing. The working principle of the device. If we understand a little bit about this, I think we can effectively avoid some problems and make corresponding improvements to page performance during the project. Today we mainly make some improvements to the writing performance of CSS based on the rendering principle of the browser (of course, JS will not be considered in this article for now, and will be introduced in subsequent articles). Let us uncover the rendering principle of the browser together. A mysterious veil:
What ultimately determines the difference in the page effects displayed by the browser is: the rendering engine (also called the typesetting engine), which is what we usually call the "browser kernel", is responsible for parsing web page syntax (such as HTML, JavaScript) and rendering, Display web page. If the same code displays different effects in different browsers, it is likely to be caused by different browser kernels.
Let’s take a look at the specific workflow of the browser when loading a page (Figure 1):
(Picture 1)
1. Parsing HTML to construct the DOM tree (Parsing HTML to construct the DOM tree): The rendering engine begins to parse the HTML document and convert the tags in the tree to DOM nodes, which is called the "content tree".
2. Render tree construction: parse CSS (including external CSS files and style elements), calculate the style of the node based on the CSS selector, and create another tree - the render tree.
3. Layout of the render tree: Called recursively from the root node, calculate the size, position, etc. of each element, and give each node the precise coordinates where it should appear on the screen.
4. Painting the render tree: Traverse the render tree, and each node will be drawn using the UI backend layer.
The main process is: build a dom tree, and each element to be displayed on the page will be created in this dom tree. Whenever a new element is added to this dom tree, the browser will search the css style sheet through the css engine and find Style rules matching this element are applied to this element.
#name in {}
It looks fast, but it's actually slow, although that's a bit puzzling#_#. Most of us, especially those of us who read from left to right, probably assume that browsers also perform left-to-right matching, and therefore assume that the overhead of this rule is not high. In our mind, we imagine that the browser will work like this: find the unique element with the ID nav, and then apply this style to the li element of the direct child element. We know that there is an element with the ID nav, and it only has a few child elements, so this CSS selector should be quite efficient.
In fact, CSS selectors match from right to left. After understanding this knowledge, we know that this previously seemingly efficient rule is actually quite expensive. The browser must traverse each li element on the page and determine whether the id of its parent element is nav.
*{}
A given ID can only correspond to one element in the page, so there is no need to add additional qualifiers, and this makes it less efficient. At the same time, do not use specific labels to qualify the class selector, but expand the class name according to the actual situation. For example, it is better to change ul.nav to .main_nav.
ul li li li .nav_item{}
I have written about this type of selector before, and in the end I couldn’t count how many descendant selectors there were. Why not use a class to associate the last tag element, such as .extra_navitem, so that only elements with class extra_navitem need to be matched, which is efficient. significantly improved
In this regard, during the CSS writing process, the following performance improvement solutions were summarized:
Avoid using wildcard rules such as *{} which can be calculated a surprising number of times! Only select the elements that need to be used.
Try to select as few tags as possible. Instead, use classes. For example: #nav li{}. You can add the class name of nav_item to li. Select .nav_item{} as follows and do not use tags
. Limit ID or class selectors such as: ul#nav, which should be simplified to #nav.
Use descendant selectors as little as possible, reduce the weight value of the selector. The overhead of descendant selectors is the highest, and try to minimize the depth of the selector. , no more than three layers at most, use more classes to associate each tag element.
Consider inheritance to understand which attributes can be inherited, and then avoid repeatedly specifying rules for these attributes
. Use efficient selectors to reduce page rendering. time, thereby effectively improving the user experience (the faster the page, the more users will like it^_^), you can take a look at the CSS selectors Test. The focus of this experiment is to evaluate the cost of complex selectors and simple selectors. Perhaps when you want to maximize rendering speed, you might configure an ID for each individual tag and then use these IDs to write styles. That would indeed be super fast and super ridiculous! The result is extremely poor semantics and extremely difficult to maintain later.
But in the final analysis, CSS performance may be really insignificant for small projects, and the improvement may not be obvious, but it will definitely be helpful for large projects. And a good CSS writing habit and method can help us be more strict with ourselves.
Original link: https://blog.csdn.net/qq_36379597/article/details/101382234
Under project
1. Differences between click objects in IE, Firefox and Chrome:
In the project, I made a lot of modal boxes (pop-up layers), which involves the click event of the button to close the modal box (the close button is bootstrap style). Because there are too many events registered on the page, the form of event delegation is used Do it, as we all know the bootstrap style close button is written like this
<button type="button" class="close" data-dismiss="alert" aria-label="Close"><span aria-hidden="true">×</span></button>There is a tag used as an identifier embedded in the button, and when I capture the target event object (event.target), the embedded span tag will be captured in the Chrome browser, while in IE and Firefox, the target event object only Will capture button instead of span. sky! When I was developing in Chrome, I wrote the id to the span tag to accommodate it, but when I debugged it in IE, it didn't take effect. I was depressed all night.
The solution is: instead of nesting span tags, enter the symbol "×" in the button tag (all major input methods have it) and the id is bound to the button tag.
2. Ajax caching problem
When debugging the server, you will always encounter cache problems. This cache not only affects the page refresh after modifying the js code but cannot update the modified js code. What is even more frightening is that in IE, this cache will affect the ajax request. data.
For example: when the page is loaded, we send an ajax request to the background to request data, and then we update a piece of information and send the same request to refresh the page data. These two requests will be regarded as the same request, and the browser knows these two After the request is the same, the data will not be fetched from the server again but only the data of the previous request will be returned, achieving the effect of reducing server requests, but this is not what I want.
The solution is: jq's ajax has a cache option, set it to false or add a timestamp at the end of the URL in the request background, for example:
$.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("删除失败，遇到未知错误请重试");
}
}
})Or set cache to 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("删除失败，遇到未知错误请重试");
}
}
})
Here is a popular science explanation about ajax caching written by someone else’s blog
1: The browser considers GET access to be idempotent.
There is only one result for the same URL [the same means that the entire URL string matches exactly],
so if the URL string does not change during the second visit, the browser will directly take out the result of the first visit
2: POST considers Is it a changing access (the browser thinks that the POST submission must have changed)
to prevent the idempotent access of GET from being added after the URL? +new Date();, [In short, it makes the URL string different for each visit]
This principle should also be followed when designing WEB pages. Original address:
http://www.cnblogs.com/fullhouse/archive/2012/01/17/2324842.html
//------------------Added on 7-22----------------
Ignored a very important issue
3. Problems caused by getComputedStyle in IE
Not long ago I saw the getComputedStyle js method of getting the final style of an element. The original link is from the master Zhang Xinxu: Familiar with the getComputedStyle method of getting the CSS value of an element « Zhang Xinxu-Xin Space-Xin Life
So I want to give it a try in a school project. Due to differences in browsers, this function needs to be written like this to be compatible with IE.
element.currentStyle? element.currentStyle : window.getComputedStyle(element, null)
It can be seen that another method appears here: currentStyle
This method is compatible with IE, but when an element style does not set the width, it will appear as auto in IE!
In this way, it is very difficult when we want to calculate some values. There are two solutions:
1. If your project is not compatible with lower versions of IE (ie9+)
Then you can directly use the getComputedStyle method, which will return the width with a value
2. Switch to offsetWidth or clientWidth with higher compatibility (I was really blind at the time and used the useless method above, but it doesn’t hurt to try new things haha)
//------------------------Added on 2017-10-17--------------------- -
4. The padding attribute cannot be obtained when calling getComputeStyle in firefox
That's right, it's about getComputedStyle again, because differences between browsers will also have differences when calling this method to obtain element attributes, just like this time
In chrome:
window.getComputedStyle(elem, null).paddingThe corresponding padding attribute can be obtained here
In Firefox, you may feel that obtaining padding in this way is a bit too abstract, so there is no padding attribute in the getComputedStyle method, only the following:
The same is true for margin
And border is more
Therefore, in order to be compatible with browsers, please do not abbreviate padding. Please also write clearly what content of border you want to obtain for border.
Article link: https://www.cnblogs.com/stitchgogo/p/7204333.html
Note: The article comes from the Internet