“This is the sixth day of my participation in the Gwen Challenge in November. Check out the details: [Last Gwen Challenge 2021]

preface

While the DOM API is already pretty good, standard or proprietary extensions continue to appear to support more functionality. In 2008. Most browsers’ extensions to the DOM are proprietary. Since then, the W3C has moved to formalize these proprietary extensions that have become de facto standards. From this background, two standard Selectors apis and HTML5 have been created to describe DOM extensions. These two standards embody the vision of community building and standardizing certain tools and apis. There is also a smaller ElementTraversal specification that adds some DOM attributes. There are still paving extensions, but these two specifications (especially HTMLS) cover most of them. Proprietary extensions will also be discussed in this chapter. All content in this chapter is supported by all major browsers with the highest market share, unless otherwise noted.

Element traversal

Prior to IE9, the entire space between elements was not treated as a blank node, as other browsers do. This results in divergence on properties like childNodes.Child. To address this difference without affecting the DOM specification, the w3C has implemented a new set of attributes with the new Element Raversal specification. The Clement Traversal API adds five Traversal attributes to the DOM element: n chilaElementCount, which returns the number of child elements (excluding text nodes and annotations); NfirstElementChild, a child of the firstElement type (Element version firstChild); NlastElementChild, which refers to the lastElement child (Element version lastChild); 0previousElementSibling refers to the sibling of the previousElement type (Element version previousSibling); NextElementSibling, points to the sibling of the latter Element type (Element version nextSibling). In supported browsers, all DOM elements have these attributes to facilitate traversal of DOM elements. So developers have to worry about blank text nodes. For example, in the past, to traverse all children of a particular element in a cross-browser manner, the code would look something like this:

let parentElement = document . getElementById (' parent '); \letcurrentChildNode = parentElement . firstChild ; \1/ No child, firstChild returns nul1, skipping the loopwhile ( currentChildNode ){\
 if ( currentChildNode . nodeType ===1){I/If there are element nodes, process accordingly \ processChild (currentChildNode); \ 1f(currentChildNode === parentElement. LastChild)(break; \ currentChildNode = currentChildNode . nextSibling ; \Copy the code

ParentElement = document.getelementBy Id (‘ parent ‘); currentChildElement = parentElement , firstElementChild ; \

Mobile browsers do not provide a console interface directly on the device. Still, there are ways to check for errors on mobile devices. Chrome Mobile and Safari iOs have built-in utilities that allow you to connect devices to the same browser as the host operating system. You can then view the error in the corresponding desktop browser. This involves hardware connection between devices and requires different operation procedures. For example, for Chrome, see the article remote Debugger for Android Devices on the Google Developers website, and for Safari, see Apple Developer Safari Web Inspector Guide. You can also debug directly on your mobile device using third-party tools. The most common Firefox debugging tool is Firebug Lite, which requires adding a Firebug script to the current page through the JavaScript bookmark widget. After the script runs, it can be opened directly on the mobile console.