Preface browser compatibility is a skill that front-end developers must master, but first-class students or other back-end Web developers tend to be easy to ignore and form two extremes: I started with ie6,ie6. Other Browsers Pit Daddy (many classmates with front end back end, niche 2 years ago in this state, encourage others to use IE6 ... I have to follow the standard, I just want FF, ie is the pit father of the thing, I do not have to ignore him (the mentality of a year ago ...) Now it seems that the previous ideas are wrong, we should certainly pursue the latest browser using the latest technology, but progressive enhancement, the idea of backward compatibility must have, because now IE6 in China's share is not to be underestimated. Aside from the previous sermon, we talk about the actual problem, which of the front-end interview does not ask compatibility issues? What time can we answer again? Anyway, I did not once said, know enough and then can change, my front-end time has been collated to form this article, the article has a lot of shortcomings, I hope you correct, supplemented, if you can form a more comprehensive front-end compatible article on the good Great Yan! Why are there compatibility issues? Because of the wide variety of browsers in the market, and the different browsers of their core is not the same, so the browser of the parsing of the page has a certain discrepancy, which is the main reason for browser compatibility problems, our web pages need to operate in the mainstream browser, you need to do a good browser compatibility. Browser using Trident kernel: IE, Maxthon, TT; browser using gecko kernel: Netcape6 and above, FireFox; Browsers using the Presto kernel: Opera7 and above; browsers using the WebKit kernel: Safari, Chrome. What I am now talking about is the compatibility issue, mainly to say IE with several mainstream browsers such as Firefox,google. For IE, IE7 is also a span, because the previous version of the update is very slow, a lot of bugs. Starting from IE8, ie gradually follow the standard, to IE9 since everyone agreed that the standard is very important, it can be said that the compatibility is better, but in China, due to the problem of XP, the use of IE7 below the user is still a lot, so we have to consider the compatibility of the lower version of the browser. For browser compatibility issues, I am generally classified as such, Html,javascript compatible, CSS compatible. HTML related issues are relatively easy to deal with, nothing more than a version of the browser with a low version of the browser unrecognized elements, resulting in it can not be resolved, so the usual note is. In particular HTML5 has added many new tags, and the lower version of the browser is a bitThe impact of the progress of the times, JavaScript compatibility issues in JavaScript, the basic syntax of the browser is not a big difference, its compatibility problems are mainly in the implementation of various browsers, especially the support of the event has a lot of problems, here I say I know a few questions. ① the method function that binds the event in the standard event binding is AddEventListener, and IE uses the Attachevent② The standard browser uses event capture to correspond to the event bubbling mechanism of IE (that is, the standard is from the outer element to the most inner element or IE from the most inner element to the outer element). Finally, the standard side also felt that IE is more reasonable, so the event bubbling into the standard, This is also the origin of the third parameter of AddEventListener, and event bubbling as the default value. ③ event handling is also very useful in obtaining the events property is not the same, standard browser is as a parameter with people, and IE is window.event way to get, get the target element ie for e.srcelement Standard browser for E.target④ Then in IE is unable to operate the TR innerHTML ⑤ and then the IE Date function processing is not consistent with other browsers, such as: Var year= new Date (). GetYear (); You will get the current year in IE, but in Firefox you will get the difference between 1900 and previous years. The methods of obtaining DOM nodes are ⑥, and the method of obtaining child nodes is inconsistent. Ie:parentelement Parentelement.children Firefox:parentnode parentnode.childnodes childNodes The meaning of the subscript is different in IE and Firefox, Firefox uses the DOM specification, which inserts a blank text node in ChildNodes. It is generally possible to avoid this problem by Node.getelementsbytagname (). When nodes in HTML are missing, IE and Firefox interpret ParentNode differently. For example:<form> <table> <input/> </table> </form> IE:input.parentNode values are NULL nodes The value of Firefox:input.parentNode is the form solution: the node in Firefox does not have a Removenode method and must use the following method Node.parentNode.removeChild (node) ⑦ There is also a difference in the implementation of Ajax, in the case of JavaScript, the bigThe difference between the browser is still a lot of, but the specific I became here are not concerned about, because we generally use the development process library, if not used, will accumulate their own to form a class library, so in terms of JS, the compatibility problem basically solved. The headache of the CSS compatibility because the previous understanding of the CSS is not deep enough, and did not go through the system of learning, so once thought that CSS is the most difficult front-end things, but really learning, only to find that CSS is really difficult ... There are a lot of things ah!!! I think the most troublesome problem is the CSS problem, because a little layout bug, may lead to the entire page dislocation, in the user's opinion this is very unprofessional. Now I would like to briefly say my understanding of CSS compatibility issues: First say a little hack knowledge (the real master is not hack, but to become a master must pass hack this)/* CSS property level hack */ color:red; /* All browsers are recognized */ _color:red; /* Only IE6 identification */ *color:red; /* IE6, IE7 identification */ +color:red; /* IE6, IE7 identification */ *+color:red; /* IE6, IE7 recognition */ [color:red;/* IE6, IE7 recognition */ color:red\9;/* IE6, IE7, IE8, IE9 recognition */&N bsp; color:red\0; /* IE8, IE9 identification */ color:red\9\0; /* Only IE9 identification */ color:red; /* Only IE9 identification */ color:red!important; /* IE6 does not recognize!important is dangerous */ /* CSS selector level hack */ *html #demo {color:red;}/* Only IE6 recognition */&NBSP;&N bsp; *+html #demo {color:red;}/* Only IE7 recognition */&NBSP;&NBSp; body:nth-of-type (1) #demo {color:red;}//ie9+, ff3.5+, Chrome, Safari, Opera can recognize */ head: First-child+body #demo {color:red;}/* ie7+, FF, Chrome, Safari, Opera can recognize */ :root #demo {color:red\9; }:/* Only IE9 recognize */ /* ie conditional comment hack */ <!--[if IE 6]> here only IE6.0 visible <! [endif]--> <!--[if IE 7]> this content is only IE7.0 visible <! [endif]--> next talk about some of the bug:①css box models that I know are problematic in IE6, and we know that for width, the sum of the width of the magin, padding, and Boder,width7 attributes of a block-level element, should be equal to the content area (width) of its parent element, and if we generally set the width to not reach its length, the browser resets the value of margin-right to its sum equal to its value, of course, if we set a negative value for margin, then the element's width may exceed its parent element. In the standard, width is padding occupied area, but again IE6 set width, its true width for the width-its padding and border*2, I generally use csshack technology to deal with ②ie6 double margin Bug, After the block-level elements floating originally outside the 10px, but IE interpreted as 20px, the solution is to add display:inline,, the problem: under IE6 If a label uses the float property, and also set the patch "margin:10px 0 0 10px" can be seen, The top and left margins are also 10px, but the first object is 20px from the left. , workaround: The problem is resolved when the display property is set to inline. , description: This is because the default display property value for block-level objects is block, which occurs when a float is set and its margin is set. You might ask, "Why is there no double between the second object and the first object?Double margin bug? " Because floats have their corresponding objects, this problem only occurs with floating objects that are relative to their parent objects. The first object is relative to the parent object, and the second object is relative to the first object, so the second object does not have a problem after it is set. In addition, in some special layouts, it may be necessary to combine display:block and display:inline to achieve the desired results. Of course in the worst case, we can use "margin:10px 0 0 10px;*margin:10px 0 0 10px;_margin:10px 0 0 5px", this "standard attribute; *ie7 recognition attribute; _ie6 Recognition attribute" Hack way to solve, summarize: This behavior occurs only when a block-level object has a floating property set, and the inline object (row-level object) does not appear this problem. And only the values of the left and right margins are set to go wrong, and the top and bottom margins do not appear to be problematic. <div style= "Width:200px;height:50px;background: #ccc;" ><div style= "width:100px; height:50px;float:left;margin-left:10px; Background: #eee; " ></div></div>margin double layout can be said to be one of the classic bugs under IE6. The resulting condition is: block element + floating +margin. Remember that I think it will be the CSS stage, this problem I often met, will be very skilled with hack solve this problem, then also self-righteous, complacent. Now it seems that the young man at that time was like a bean sprout dish. Real CSS really bad people will not encounter this bug, if you encounter this bug every now and then, that your CSS has a good way to go. My experience is that the less floating, the less code, there will be more flexible pages, there will be more extensibility of the page. This is not much to say, due to a certain level, float will be used less. In addition, you will avoid using floating +margin. Therefore, the later the more difficult to encounter this bug. Here is the solution, using hack I am not recommended, using hack belong to a slightly higher level than beginners. A page, not a hack, but each browser performance consistent, this is the level. Use Display:inline to solve this problem. And why Display:inline can solve this bilateral bug, first of all, the inline element or inline-block element is not a bilateral distance problem. Then, floating properties such as Float:leftThe inline element can be haslayout, allowing the inline element to behave like the inline-block element, supporting high widths, vertical margin, and padding, so all of the div class styles can be used in this display On the inline element. There are voids at the bottom of the ③ie6 sheet; there are many ways to fix this bug, either by changing the layout of the HTML, or by setting the IMG to Display:block, or by setting the Vertical-align property to Vertical-align:top Bottom Middle Text-bottom can be solved. (but recently I found this problem in other browsers also reflected) ④ie6 3px bug two floating layer in the middle of the gap, this IE 3PX bug is also often appear, the solution is to the right element is also floating Float:left or relative IE6 definition. Left margin-right:-3px; Classic Two-column layout, float:left;width:200px; The second one, margin-left,200px; They create a 3px spacing between them. ⑤ in IE6 There is no concept of min-width, its default width is min-width, so sometimes too many fonts it will choose to open the container. ⑥ie6 cannot define a container of about 1px height because of the default row heights, there are many workarounds, such as: Overflow:hidden zoom:0.08 Line-height:1px⑦ using margin:0 Auto , the method makes the container center still does not work in the IE6, we want to use Text-align:center; ⑧ to its parent container to be clicked visited hyperlink style not to have hover and active, many people should have encountered this problem, The workaround is to change the ordering of CSS properties: l-v-h-a <style type= "Text/css" > A:link {} a:visited {} a:hover {} a:active {}/style> ⑨ in When using absolute positioning/relative positioning, setting z-index may fail in IE because its elements depend on the z-index of its parent element, and the parent element defaults to 0. So the child element Z-index high, and the parent element bottom, still does not change its display order; 10, margin overlay problem: #box {margin:10px;} #box p {margin:20px; background:gray;} <div id= "box" ><p>dd</p></div> the code causes the margin overlay, and the margin runs outside the div package, and the bug is caused by the height of the block-level child elements. If an element has no vertical border or padding, its height is the distance between the top and bottom border of the child element that contains it. Above is some of the bugs I remember, here I'll mention haslayout (IE8 discard this attribute). in IE low-version browser is basically the era of table layout, almost all elements (except inline elements) is a box, the content will not exceed the table cells, table cells will not exceed the table. After IE6 launch, CSS changes this hypothesis-because CSS allows content to go beyond elements. So the Haslayout attribute was born. in Ie6,ie7, each element has haslayout this property, which can be set to TRUE or false. If set to True, the element has to self-layout and render, so the element expands to contain the content it overflows, such as floating or not truncated words. If Haslayout is not set to true, then the element relies on an ancestor element to render it. This is the place where many ie bugs are born. IE browser a lot of bugs are caused by Haslayout = False, the layout element has the following characteristics: 1, has the layout (haslayout=true) element does not shrink, so the text truncation may occur, disappear phenomenon; 2. The layout element to the floating automatic cleanup, 3, the relative positioning element does not have the layout, this may lead to the absolute element localization deviation, 4, has the layout the element margin does not overlap, 5, scrolls, the page will have the beating; 6, the border disappears 7, the pixel deviation haslayout is not a CSS property, So we can't do this. Set it haslayout:true; an element is set to Haslayout:true will be rendered into a having haslayout, vice versa. Some elements themselves this property is true, if the need to trigger, the best way is to set its Zoom property, which elements themselves are haslayout:true
Web front end Browser compatibility personal experience summary
