Based on the bugs, troubleshooting, solution process and experience when ul li are nested in each other under IE_javascript skills

Steps to check for bugs

1. Bug location

In a js script, according to the order of script execution, you can use console or alert to determine the code interval where the bug occurs, and then further search for the specific code segment where the bug occurs within the interval.

2. bug fix

Through exclusion, the bug was caused when inserting node content. I used kissy’s DOM.html() method, whose function is similar to the DOM element node innerHTML method. I initially thought that this method caused IE67 rendering. An error occurred, and then I changed to the innerHTML method, but the result was still wrong.

At this time, I thought about memory leaks. I wanted to see if there were circular references or other reasons that caused memory leaks during the loop splicing of strings. Then at the end of some methods, I assigned null to some variables. Prevent memory leaks (although I don't know if it works, but at least I tried this), but the result still doesn't work.

Is it because there is too much data, causing it to crash when rendering? So I reduced the data length for splicing, and it worked. When there are 1 to 3 pieces of data, it can be rendered, which means the method is correct; but for more than 3 pieces of data, IE67 still cannot respond. So I tried to continuously insert data one by one, because if there was no problem inserting one piece of data at a time, I could insert it a few more times, but IE still had problems. In fact, my train of thought had already deviated at this time.

Later I came to see a colleague and he said that he had encountered this problem before and it was caused by the label not being closed correctly under IE67. Yes, this is the real cause of this bug. Later, I printed out the spliced ​​string, and then used the formatting tool to format it. I quickly discovered the problem that occurred when I spliced ​​the string, so I quickly fixed the bug. The online formatting tool I use: http://tool.chinaz.com/Tools/JsFormat.aspx

3. Test

During the test, we wrote a string of html code and left some tags unclosed to see how IE compared with Chrome.

The code is as follows. In the second li tag, we unclose one of the tags in the ul tag

Copy code The code is as follows:

• 
  
  
  ;
                                                                                          
  
  
  
  • inner li
  
  
  • inner li
  
  closederror happened

inner li

 

inner li

 

inner li

It displays normally under IE and chrome, as shown above.

Next, let’s debug through the development tools.

Under IE7~9, the DOM structure is disordered. The sending error is in the unclosed tag. The content of the original third

node is directly inserted into the node. under.

Let’s take a look at the situation in chrome: the third li is rendered into the DOM tree normally, and a span closing tag is automatically added to the span tag where the error occurred

4. Summary

Each browser performs differently when rendering HTML, especially IE and other browsers. The fault tolerance performance of chrome and FF is very good. Even if there is an html tag in the page that is not closed normally, it will intelligently identify it and make it look fine in the browser, and there will be no problem with the final DOM structure. However, it is not good. The bad side is that you don't know there is something wrong with your code and think everything is fine. IE89 can now handle it this way. It seems that there is no problem with the page content. However, through the development tools, you can see that the wrong html code does not have a normal DOM structure. But IE67 will not give you such an opportunity, or it will crash directly.

Chrome allows us to make mistakes, but IE is more strict with us. Although IE gives us a headache, it puts higher requirements on our code! Suddenly I felt that it would be nice to have IE. . .

If one day you find that the DOM structure cannot be rendered under IE, remember to remind yourself whether there are tags in the code that are not closed.