First, preface
The concept of document compatibility mode has been introduced from IE8, and as a developer we can taste it in developer tools through "browser mode" and "Document Mode" (IE11 change to "browser mode" to a more appropriate "user agent string"). Its appearance greatly facilitates the bitter front-end siege lions to adapt to each version of IE, but Jser can not fully trust it, because it is only to provide as much as possible in the document model simulation.
This large part of the content comes from the official commentary: http://msdn.microsoft.com/library/cc288325 (v=vs.85) ASPX, and as far as possible into the personal normal work of the pit to be elaborated.
Second, what is the browser mode?
At first glance "browser mode" really do not understand what meaning, perhaps ie engineers also understand this word is lame, so IE11 simply renamed "User Agent string". Now everyone should know that the goods are used to set up navigator.useragent and navigator.appversion.
It is only important to note that in different versions of IE, it is not the same as the document mode.
IE89, if the browser mode is set to Internet Explorer7, then the document mode can only be set to 7,6,5;
In IE11, the user-agent string setting and the document mode are no more than half-dime relationships.
Iii. What is a document mode?
For browsers with WebKit, Molliza and so on as the kernel, the DOM tree parsing, rendering, JS API and so on is mainly linked to the kernel version, and for IE, these are from IE6 to the document mode. In order to better understand the document mode, we start with the time line from IE5 to learn it!
3.1. From the "Long" IE5
Now, while it's not working with IE5, it has never left us, because IE5 has always survived us in the form of weird patterns (quirks,ie5 document mode). But in that only IE5 era, and there is no quirks this argument, but later IE6 after the introduction gradually to the standard, and IE5 under the DOM tree parsing, rendering and other standards have a very big difference, so the name of the quirks.
3.2. New inventions for compatibility mode--ie6
Due to the IE6 and IE5 Dom tree parsing and so on are very different, resulting in those suitable for IE5 old website can not be displayed on IE6, so there is a new feature-"Compatibility mode" to solve the old site display problems. The IE6 compatibility mode is two, the quirks mode (Quirks) and the IE6 standard mode. (IE7 also only quirks mode and IE7 Standard mode)
IE6 uses the quirks mode (Quirks) By default only if the <! Doctype> uses the IE6 standard mode when declaring a document type as the first line of the document, even if IE does not recognize the document type being declared. (IE7 is also the case)
Note: At this time the compatibility mode is mainly to solve the display problem, to know that the JS is only a small supporting role.
3.3. Document compatibility Mode--IE8 's favorite
The document compatibility mode is an extension of compatibility mode, and for IE8, in addition to providing the quirks mode (Quirks) and IE8 standard modes, IE7 standard mode, analog IE7 mode, and settings are much richer.
Iv. ie8+ How to set the document mode
Common Ways for Developers:
1. "Document Mode" in the developer tool;
2. By adding a meta-data tag such as <meta http-equiv= "x-ua-compatible" content= "ie=7" in the head tag (this example sets the document mode to IE7 standard mode);
3. By <! Doctype> and Delete, in the standard mode and strange mode (Quirks) switch between;
4. Configure via Web server
IIS Web. config configuration information:
<?xml version="1.0" encoding="utf-8"?>< configuration> <system.webServer> "x-ua-compatible" value="ie= EmulateIE7" /> </customHeaders>
Common Ways for users:
1. Click the compatibility View switch in the address bar;
2. If the page is loaded in an intranet zone, the configuration uses Compatibility view to display the pages in the intranet zone;
3. Configure browser to use compatible view to browse all Web pages;
4. Add the Web site to the Compatibility View list.
So we can understand that the document pattern is not completely in our hands, eh ...
V. <meta http-equiv= "x-ua-compatible" > and <! Doctype> affects document mode in a companion
All IE browsers by default (<meta http-equiv= "x-ua-compatible" > with <! Doctype> are not), is the use of strange Mode (Quirks); when there is <! Doctype>, the browser version of the corresponding standard mode (such as IE8 in the IE8 standard mode, IE11 the use of IE11 Standard mode).
It is important to note that when the <meta http-equiv= "x-ua-compatible" > is present, what will be the document mode? Let's take a look at the range of content property values under IE11, as follows:
ie=5, ie=7, IE=EMULATEIE7, ie=8, IE=EMULATEIE8, ie=9, ie=10, ie= 11, Ie=edge
1. Ie=5: Show the use of strange mode;
2. Values of pure numbers such as ie=7: Indicates a standard mode with the corresponding IE version, even if not <! Doctype> as the first line of the document, the document mode still uses the standard mode;
3. Ie=emulateie7 with Emulateie String value: Indicates the mode that uses the simulation corresponding IE version, is to <! Doctype> is used as the first line of the document in standard mode, otherwise in a weird mode.
4. Ie=edge: Represents the document mode in the browser version, such as IE11, to <! DOCTYPE html>, as the first line of the document, uses the IE11 standard mode, otherwise it takes a weird pattern.
Attention:
1. In IE11, ie=10 and Ie=emulateie10 are the same, ie=11, Ie=emulateie11 and Ie=edge are the same;
2. Document mode 10 and above, if the first line of the document is not valid <! Doctype> (What is the effective <! Doctype>, please look forward to "JS Magic Hall: DOCTYPE We should know the basics"), then Document.compatmode return Backcompat, but Document.documentmode return the correct document mode;
3.9 and below the document mode, as long as the first line of the document appears <! Doctype> Document.compatmode returns CSS1COMPAT, whether or not it is valid. When the first line of the document is not <! Doctype> and no standard mode is specified, Document.compatmode returns BACKCOMPAT, and Document.documentmode must return 5.
Six, to <meta http-equiv= "x-ua-compatible" > Learn a little more
6.1. Effective location
Must be placed within the head tag to be valid.
6.2. Multiple labels only the first one is recognized
"x-ua-compatible"Content="ie=7"> <meta http-equiv="x-ua-compatible"Content="Ie=emulateie7"> "Text/javascript">Console.log (document.documentmode);//Output 7</script>6.3. Invalid content value, set to the closest document mode
Ie=a: Document mode is 5
ie=7.5: Document Mode 7
6.4. One label to set multiple document modes, the browser will automatically select the highest available document mode
"x-ua-compatible" content=" ie=7;ie=9;ie=8"> "text/javascript"> // IE11, output 9 </script>
Seven, Jser not too happy
The first discovery ie8+ provide document compatibility mode is really ecstatic, and finally do not have to find the machine to IE678 test, and finally do not have that often hung dead ietester. But later found that the document compatibility mode is only convenient for us to develop debugging, and can not completely replace the IETester, but also can not replace the real IE67 on the test. Because in addition to the browser version of the corresponding document mode, the other document mode is running on the browser core virtual machine, and these virtual machines can only simulate the real browser kernel of most DOM tree parsing, rendering and JS API only. For example, setting the document mode on IE8 is weird, but XMLHttpRequest is still available (XMLHttpRequest is from IE7), so when detecting browser features, feature sniffing is more accurate and useful than judging the browser's document mode.
In addition, from the sixth point of attention, we can see from the IE10 start IE to break away from the IE56789 style, really close to the standard.
1. There is no effective DOCTYPE when the box model rendering mode is strange mode, otherwise, the use of standard mode;
2. The rendering mode of the box model is separated from the document mode, that is, when the rendering mode is in weird mode, the document mode is not 5. This jser still use ie10+ js API, do not endure IE5 suffering;
3. Although Document.compatmode is Backcompat, the rendering mode is called the strange mode, but the IE56789 's strange mode and ie10+ 's strange mode show the effect and the style data obtained by JS are different, ie10+ and WebKit, The effect of Molliza is similar.
Give me a chestnut:
"text/css"> #target { width:100px; height:20px; Border:solid 1px red; 0 auto; } </style> "target" ><div> </body>
The above code is running in weird mode, under IE6789 to div#target automatic horizontal centering, you must add <! DOCTYPE html> turn into standard mode rendering. However, in ie10+, WebKit, and Molliza, the Div#target will automatically center horizontally even in weird mode.
Viii. Summary
From the "browser mode" and "Document Mode" Association, "document Mode" and "box model of the rendering mode" hook, to ie10+ all of a sudden, the three-link cut off, to the standard. Always feel that IE9 is the transition between the non-standard and standard IE, it is now more determined that this is the case.
Perhaps you will see more confusion here, and it seems that understanding the above will add to the burden of development (more points to consider).
In fact, we just have to clear again "Document compatibility Mode" Purpose is good, for the end-user it is to be in the new version of IE as far as possible to display the old site, for developers it is to facilitate debugging new website in the old version of IE display effect and JS effectiveness.
So as an ordinary developer we only need to do three things:
1. With effective DOCTYPE as the first line of the document, ensure that the rendering mode is standard mode;
2. Before the development of the site to set the best operating environment, is appropriate to the IE a few to several, whether suitable for webkit, etc.
3. Develop and make unremitting efforts for compatibility.
As a library or framework developer, because the document schema affects most of the JS API, the rendering mode affects the style values and access methods, and so on, the situation is much more complicated. Therefore the comprehensive document pattern judgment, the characteristic sniff, the rendering pattern judgment is necessary, above content is only digs the pit only.
Respect the original, reprint please specify to: http://www.cnblogs.com/fsjohnhuang/p/3817418.html ^_^ Fat Boy John