Compatibility of Web Browser

Preface

Browser compatibility is a skill that front-end developers must master. However, those who are new to the front-end or other back-end web developers tend to choose to ignore it, forming two extremes:

1. I used IE6 at the beginning, and there was no problem with IE6, and other browsers were pitfall (many of my colleagues working with the front-end backend came into being like this two years ago, encourage people to use ie6 ....)

2. I want to follow the standard. I only need ff, and IE is a fool. I don't have to worry about him (the mentality of a young man a year ago ...)

Now it seems that the previous ideas are not correct. We are sure to pursue the latest browsers to use the latest technology, but the idea of progressive enhancement and backward compatibility must exist,

This is because IE6's share in China is not negligible.

Aside from the previous principles, let's talk about the actual problem. Which front-end interview does not ask the compatibility question? Which time can we answer well? I didn't say a good deal at all, but I could change it if I knew it wasn't enough,

My front-end time is organized to form this article,There are many shortcomings in this article. I hope you can correct them and add them. If you can form a comprehensive front-end compatibility Article later, it will be great!

Why are there compatibility problems?

Because there are many types of browsers on the market, and different browsers have different kernels, there is a certain discrepancy in the resolution of web pages by various browsers, which is also the main cause of browser compatibility problems, our web pages must run normally on mainstream browsers, so we need to ensure browser compatibility.

Browsers using the Trident kernel: IE, Maxthon, and TT;

Browsers using the gecko kernel: netcape6 and later, Firefox;

Browser using presto kernel: opera7 and later versions;

Web browsers using the WebKit kernel: safari and chrome.

I am talking about compatibility issues, mainly about IE and several mainstream browsers such as Firefox and Google.

For IE browser, IE7 is a span, because the previous version updates are very slow and there are many bugs. Since IE8, the Internet Explorer has gradually followed the standard. After 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 XP share problem, there are still many users using IE7 or earlier versions, so we have to consider compatibility with earlier versions of browsers.

For browser compatibility issues, I generally classify them in this way. html and JavaScript are compatible and CSS is compatible. Among them, HTML-related problems are easy to handle. It is nothing more than a later version browser that uses elements that cannot be identified by a later version browser, so it cannot be parsed. In particular, HTML5 has added many new tags, and earlier browsers have somewhat influenced the progress of the times;

Javascript compatibility

In JavaScript, the basic syntax of Each browser is not much different. Its compatibility problems mainly occur in the implementation of each browser, especially the support for events, here I will talk about several issues I know.

① The method function used to bind an event to the standard event binding is addeventlistener, while ie uses attachevent.

② The standard browser uses event capture to correspond to the event bubbling mechanism of IE (that is, the standard is from the outermost element to the innermost element or IE from the innermost element to the outermost element) finally, the standard party also thinks that IE is more reasonable in this regard, so event bubbling is incorporated into the standard. This is also the third parameter of addeventlistener, and event bubbling is used as the default value.

③ The Event attributes that are useful in event processing are also obtained differently. The standard browser is used as a parameter, While IE is obtained in window. Event mode. The target element IE is E. srcelement, and the standard browser is e.tar get.

④ In IE, TR innerhtml cannot be operated.

⑤ Then, the processing of the IE date function is not consistent with that of other browsers, such as VAR year = new date (). getyear (); in IE, the current year is obtained, but in Firefox, the difference between the current year and the 1900 is obtained.

6. Methods for obtaining DOM nodes are different, and their methods for obtaining sub-nodes are inconsistent.

IE: parentelement. Children Firefox: The meanings of parentnode. childnodes are different in IE and Firefox. Firefox inserts blank text nodes in childnodes using Dom standards. You can avoid this problem by using node. getelementsbytagname.

When the HTML node is missing, ie and Firefox have different interpretations of parentnode. For example:

<Form> <Table> <input/> </table> </form> ie: input. the value of parentnode is null node Firefox: input. the value of parentnode is form. solution: the node in Firefox does not have the removenode method. You must use the following method node. parentnode. removechild (node)

7. The implementation of AJAX is also different;

For JavaScript, there are still many differences among various browsers, but I am not very concerned about them here, because class libraries are generally used during development. If they are not used, all of them build a class library by themselves, so for JS, the compatibility problem is basically solved.

Headaches CSS compatibility

Because the previous understanding of CSS was not deep enough, and it was not systematically studied, CSS was regarded as the most difficult thing at the front-end. But after learning it, CSS was found to be really difficult... There are many things !!!

I think the most troublesome problem is CSS. A little layout bug may lead to misplacement of the entire page. in the user's opinion, this is extremely unprofessional.

Now let me briefly talk about my understanding of CSS compatibility: First, let's talk about the knowledge of hack. (a real master doesn't need hack, but to become a master, you must pass the hack)

1234567891011121314151617181920212223242526272829303132333435363738394041

/* CSS Attribute-level hack */ Color: red;/* all browsers can recognize */ _ Color: red;/* Only IE6 recognition */ * Color: red;/* IE6, IE7 recognition */ + Color: red;/* IE6, IE7 recognition */ * + Color: red;/* IE6, IE7 recognition */ [Color: red;/* IE6, IE7 recognition */ Color: Red \ 9;/* IE6, IE7, IE8, and ie9 recognition */ Color: Red \ 0;/* IE8, ie9 recognition */ Color: Red \ 9 \ 0;/* Only ie9 recognition */ Color: Red \ 0;/* Only ie9 recognition */ Color: red! Important;/* IE6 not recognized! Important is dangerous */ /* CSS selects character-level hack */ * Html # demo {color: red;}/* Only IE6 recognition */ * + Html # demo {color: red;}/* Only IE7 recognition */ Body: Nth-of-type (1) # demo {color: red;}/* ie9 +, ff3.5 +, chrome, Safari, and opera can be recognized */ Head: First-Child + body # demo {color: red;}/* IE7 +, FF, chrome, Safari, and opera can be recognized */ : Root # demo {color: Red \ 9; }:/* ie9 only */ /* Ie condition comment hack */ <! -- [If IE 6]> the content here is only visible to ie6.0 <! [Endif] --> <! -- [If IE 7]> the content here is only visible to ie7.0 <! [Endif] -->

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

① There is a problem with parsing the CSS Box Model in IE6. We know that in terms of width, the sum of the width of the magin, padding, boder, and width7 attributes of a block-level element, it should be equal to the content area (width) of the parent element. If the width is not set to its length, the browser will reset the value of margin-right, their sum is equal to its value. Of course, if we set a negative value for margin, the width of the element may exceed its parent element.

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

② Double margin bug of IE6. After the block-level elements are floating, the original outer margin is 10px, but IE is interpreted as 20px. The solution is to add the display: inline

Problem: If a label in IE6 uses the float attribute and the patch "margin: 10px 0 0 10px" is set, the top margin and the left margin are also 10px, however, the first object is 20 PX away from the left.

Solution: the problem is solved when the display attribute is set to inline.

Note: this is because the default value of the display attribute of a block-level object is block. This is the case when floating is set and its outer margin is set.

Maybe you will ask: "Why is there no double margin bug between the second object and the first object "?

Because float has its own corresponding objects, this problem occurs only when the floating object is relative to its parent object.

The first object is relative to the parent object, and the second object is relative to the first object. Therefore, the second object will not be faulty after being set.

In addition, in some special la S, you may need to combine display: block; and display: inline; to achieve the expected results.

Of course, in the worst case, we can use "margin: 10px 0 0 10px; * margin: 10px 0 0 10px; _ margin: 10px 0 0 0 5px ",

This "Standard attribute; * IE7 recognition attribute; _ IE6 recognition attribute" hack Solution

Summary: this problem occurs only when the floating attribute is set for a block-level object. This problem does not occur for inline objects (Row-level objects. In addition, only the left and right margin values are set to cause problems, and the top and bottom margins are not affected.

1234	<div style="width:200px;height:50px;background:#ccc;"><div style="width:100px; height:50px;float:left;margin-left:10px; background:#eee;"></div></div>

Margin dual layout is one of the classic bugs in IE6. The condition is: Block Element + floating + margin.

I still remember the phase at which I thought I would use CSS. I often encountered this problem and used hack to solve it very skillfully. At that time, I was self-righteous and proud. At that time, it seems like bean sprout.

People with really powerful CSS will basically not encounter this bug. If you encounter this bug from time to time, it means you still have a good way to go with CSS.

My experience is that the less floating, the less code there will be, more flexible pages, and more scalable pages. That's not to mention. It comes down to a certain level. Floating will be used less.

In addition, you do not need to use floating + margin. Therefore, the more difficult it will be to encounter such a bug.

Here is a solution. I don't recommend using hack. Using hack is a little higher level than that of beginners. One page does not have one hack, but the performance of each browser is consistent. This is the level.

Use display: inline; to solve this problem.

Why does display: inline solve this bilateral margin bug? First, the inline element or inline-block element does not have a bilateral margin problem.

Then, float: Left and other floating attributes allow the inline element haslayout to make the inline element behave the same way as the inline-block element. It supports high width, vertical margin, and padding, therefore, all Div class styles can be used on the display inline element.

The above are some of the bugs I remember. Here I will mention haslayout (IE8 discards this attribute ).

In earlier versions of IE browsers, the basic concept is table layout. Almost all elements (except inline elements) are a box, and the content does not exceed the cells in the table, nor does the cells in the table go beyond the table.

After IE6 was launched, CSS changed this assumption because CSS allowed the content to exceed the element. Therefore, the haslayout attribute was created.

In IE6 and IE7, each element has the haslayout attribute, which can be set to true or false.

If it is set to true, the element must be laid out and rendered by itself, so the element will expand to include its overflow content, such as floating or untruncated words.

If haslayout is not set to true, the element must be rendered by an ancestor element. This is where many ie buckets were born. Many bugs in IE are caused by haslayout = false,

Layout has the following features:

Having layout (haslayout = true) elements will not contract, so text truncation and disappearance may occur;

The layout element automatically clears floating;

The relative positioning element has no layout, which may lead to absolute element positioning deviation;

Element margins with layout are not superimposed;

When scrolling, the page jumps;

Border disappears

Pixel Deviation

Haslayout is not a CSS attribute, so we cannot set it like this haslayout: true;

If an element is set to haslayout: True, it will be rendered as a having haslayout,

And vice versa. For some elements, this attribute is true. If triggering is required, the best way is to set the zoom attribute. For which elements are themselves, haslayout: True.

<HTML>, <body> <Table>, <tr>, <TH>, <TD> <IFRAME>, <embed> (non-standard element ),

<Object>, <APPLET> <HR> <input>, <button>, <SELECT>, <textarea>, <fieldset>, <legend>

Zoom: 1, which is considered the best method to trigger layout because it has no effect on the current element. It is easier to trigger haslayout than haslayout = false.

The following attributes and values deploy a given 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, different browsers may have different default settings for some elements, such as the default font of the browser, the default row height, and the default spacing. Therefore, we usually set the default values for several main elements.

Conclusion

The above is my simple understanding of browser compatibility, but there are still many shortcomings. Due to technical limitations, I would like to discuss with you here, hope to accumulate relevant experience in communication, learning, and future work to develop web pages that meet the needs of mainstream browsers