Improvements in JavaScript DOM operations

As a web front-end, dealing with and understanding browser differences is an important issue. Below I will introduce a summary of some of my notes at work. First, I will introduce the situation without using a js library.

　1. The setAttribute method sets the element class name: In jQuery, you can directly use the attr() method, which can be used in native JS

element.setAttribute(class, newClassName) //This is the W3C standard and is compatible with It is valid in W3C standard browsers. However, IE is the main theme for domestic users.
element.setAttribute(className, newClassName) //Such a setting is only valid in IE.
element.className = newClassName //All browsers are valid (as long as Support javascript)
Okay, that’s the beginning. The purpose of this article is to introduce the differences between browsers and let front-end friends understand how to use the most effective method to solve the problem. Let’s continue.

　2. FireFox does not have a window.event object, only an event object. IE only supports window.event, while other mainstream browsers support both, so it is generally written as:

function handle(e)
{
e = e || event;
...
}
　3. Principle of DOMContentLoaded event: The window.onload event is triggered after the page parsing/DOM tree establishment is completed and the downloading of all resources such as pictures, scripts, style sheets, etc. of. This is a bit too "late" for many practical applications, which affects the user experience. In order to solve this problem, a DOMContentLoaded method was added to FF. Compared with onload, this method is triggered earlier. It is triggered after the DOM content of the page is loaded without waiting for other resources to be loaded (this is also This is the implementation principle of jquery.ready() event).

//The following is the original analysis of jQuery 1.4.2 version

bindReady: function() {
　if ( readyBound ) {
　　return;
　}
　 readyBound = true;
　 // Catch cases where $(document).ready () is called after the
　　 // browser event has already occurred.
　 if ( document.readyState === "complete" ) {
　　 return jQuery.ready();
　 }
　 // Mozilla, Opera and webkit nightlies currently support this event
　if ( document.addEventListener ) {
　 // Use the handy event callback
　　document.addEventListener( "DOMContentLoaded", DOMContentLoaded, false );
　　 // A fallback to window.onload, that will always work
　　window.addEventListener ( "load", jQuery.ready, false );
　　 // If IE event model is used
　　} else if ( document.attachEvent ) {
　　 // ensure firing before onload,
　 // maybe late but safe also for iframes
document.attachEvent("onreadystatechange", DOMContentLoaded);
　　　 // A fallback to window.onload, that will always work
　　 window.attachEvent( "onload", jQuery.ready );
　　 // If IE and not a frame
　　　/ /continuously check to see if the document is ready
　　var toplevel = false;
　　try {
　　toplevel = window.frameElement == null;
　　} catch(e) {}
　　if ( document.documentElement.doScroll && toplevel ) {
doScrollCheck();
　　}
　　}
}
　 Design idea - Treat Webkit and Firefox equally, and both directly register the DOMContentLoaded event. However, since Webkit was only introduced in version 525 or above, there are hidden dangers of compatibility. For IE, first register the onreadystatechange event of the document. After testing, this method is equivalent to window.onload. It will still wait until all resources are downloaded before triggering. After that, if it is determined that it is IE and the page is not in an iframe, the doScroll method of documentElement is continuously called through setTiemout until the call is successful and DOMContentLoaded is triggered. 1 The principle of jQuery's solution to IE is that under IE, some methods of DOM can only be called after the DOM parsing is completed. doScroll is such a method. In turn, when doScroll can be called, the DOM parsing is completed. Compared with document.write in prototype, this solution can solve the problem of failure when the page has an iframe. In addition, jQuery seems to be worried that this method will fail when the page is in an iframe, so it makes a judgment in the implementation code. If it is in an iframe, it is implemented through the onreadystatechange of the document, otherwise it is implemented through doScroll. However, after testing, doScroll still works even in an iframe.

　4. Learn to use IE’s conditional comments. Many front-ends are always complaining about the evil IE. Indeed, dealing with compatibility issues will indeed become more and more disgusting, but there is no way. Since there is no way to change, then please enjoy...

Version 6

　 Let’s summarize it here for today. I will have time to post an advanced AJAX article when I get back from vacation next week. I hope it can be helpful to novices or people in need. Due to the limited writing style, please forgive me if the writing is not good. I have just started blogging and it is in the growth stage. Haha...