Go Web front-End browser compatible

Transferred from: http://www.admin10000.com/document/1900.html

Objective

Browser compatibility is a skill that front-end developers have to master, but first-in-the-front classmates or other background web developers tend to be easy to ignore and form two extremes:

1 I was the first to use IE6,IE6 on no problem, other browser pit dad (more appear with the front end of the classmate together, niche 2 years ago in this state, encourage others to use IE6 .... ）

2 I have to follow the standard, I just want FF, IE is the pit Dad's thing, I do not have to ignore him (niche a year ago mentality ...) ）

Now it seems that the previous ideas are wrong, we should certainly pursue the latest browser using the latest technology, but progressive enhancement, backward compatible ideas 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 never once said yes, know enough to change,

My front-end time has been organized 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.

Browsers using the 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.

And I now say that the compatibility problem, mainly refers to 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 added a lot of new tags, the low version of the browser a little impact on the progress of the Times AH;

JavaScript compatibility issues

In JavaScript, the basic syntax of the browser is not a big difference, and its compatibility problem is mainly in the implementation of the 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

② Standard browser uses event capture to correspond to the event bubbling mechanism of IE (that is, the standard from the outer element to the most internal element or IE from the most internal element to the outer element) finally standard side also feel ie this aspect is reasonable, so will 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

④ is not able to operate TR innerHTML in IE.

⑤ 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)

⑦ on the implementation of Ajax is also different;

As far as JavaScript is concerned, there are still a lot of differences between browsers, but I have become less concerned about the development process, because we generally use the class library, if not used, will accumulate to form a class library, so in terms of JS, the compatibility problem basically solved.

Annoying CSS compatibility

Because of the previous understanding of the CSS is not deep enough, and did not learn the system, so once thought that CSS is the most difficult front-end things, but really learned, 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 the hack this off)

1234567891011121314151617181920212223242526272829303132333435363738394041

/* CSS属性级Hack */ color:red; /* 所有浏览器可识别*/ _color:red; /* 仅IE6 识别 */ *color:red; /* IE6、IE7 识别 */ +color:red; /* IE6、IE7 识别 */ *+color:red; /* IE6、IE7 识别 */ [color:red; /* IE6、IE7 识别 */ color:red\9; /* IE6、IE7、IE8、IE9 识别 */ color:red\0; /* IE8、IE9 识别*/ color:red\9\0; /* 仅IE9识别 */ color:red \0; /* 仅IE9识别 */ color:red!important; /* IE6 不识别!important 有危险*//* CSS选择符级Hack */ *html #demo { color:red;} /* 仅IE6 识别 */ *+html #demo { color:red;} /* 仅IE7 识别 */ body:nth-of-type(1) #demo { color:red;} /* IE9+、FF3.5+、Chrome、Safari、Opera 可以识别 */ head:first-child+body #demo { color:red; } /* IE7+、FF、Chrome、Safari、Opera 可以识别 */ :root #demo { color:red\9; } : /* 仅IE9识别 *//* IE条件注释Hack */ <!--[if IE 6]>此处内容只有IE6.0可见<![endif]--><!--[if IE 7]>此处内容只有IE7.0可见<![endif]-->

Next, let's talk about some bugs I know:

①CSS box model in IE6, we know that in terms of 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 we generally set the width if it does not reach its length, the browser resets the value of the margin-right, their sum equals its value, of course, if we set a negative value for margin, then the width of the element may exceed its parent element.

In the standard, width is padding occupied area, but after IE6 set width, its true width for the width-its padding and border*2, I generally use csshack technology processing

②ie6 double margin Bug, the block-level element floating after the outer margin 10px, but IE interpreted as 20px, the solution is to add display:inline

Problem: Under IE6 If a label uses the float property, and the other patch "margin:10px 0 0 10px" is set, 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 are there no double margin bugs between the second object and the first object?"

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 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

Summary: This behavior occurs only if the block-level object has a floating property set, and the inline object (row-level object) does not occur. 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.

1234	<divstyle="width:200px;height:50px;background:#ccc;"><divstyle="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:left allow the inline element to haslayout, allowing the inline element to behave like inline-block elements, supporting high widths, vertical margin, and padding, so div All the styles of class can be used on this display inline element.

These are some of the bugs I remember, and here I'll mention haslayout (IE8 discard this attribute).

In IE, the low version of the 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. Many bugs under IE browser are caused by Haslayout = False,

The layout element has the following characteristics:

The owning layout (haslayout=true) element does not shrink, so text truncation and disappearance may occur;

Layout elements for floating automatic cleanup;

Relatively positioned elements have no layout, which can lead to absolute element positioning deviations;

The outer margin of the element having the layout is not superimposed;

When scrolling, the page will bounce;

Border disappears

Pixel deviation

Haslayout is not a CSS property, so we can't do this to set it haslayout:true;

An element is set to Haslayout:true will be rendered into a having haslayout,

Vice versa. Some of the elements themselves are true, and if they need to be triggered, the best way is to set their zoom properties; Which elements themselves are haslayout:true

<object>, <applet>

Zoom:1 is considered to be the best way to trigger layout because it has no effect on the current element. Triggering haslayout is relatively simpler than haslayout=false.

The following properties and values will be laid out given an element

Position:absolute Float:left or right Display:inline-block;width:any value other than auto;

Height:any value other than Auto;zoom:any value other than normal (*); WRITING-MODE:TB-RL

Finally, because individual browsers set inconsistent defaults for some elements, they can also result in differences in performance, such as browser default font, default row height, default spacing, and so on. So we typically set default values for several major elements.

Conclusion

The above is my simple understanding of browser compatibility, but there are a lot of shortcomings, due to the limitations of technology, here to communicate with you experts, I hope in the exchange of learning and work in the future to accumulate relevant experience, to make a Web page to meet the mainstream browser.

Go Web front-End browser compatible