Debugging Javascript — Part 2: The DOM
This is Part 2 of a series that will explore debugging of a front-end Javascript application. In the previous part we talked about Source breakpoints and in this article we will be focusing on the DOM and in particular how you can get the most out of the Elements tab.
Disclaimer: By no means this is a thorough guide to the devtools. We are only going to mention the things that most developers tend to use.
Intro
Having talked about how to debug code that’s related to the functionality of a platform, it’s now time to focus on the visual aspects of an app. Ask a developer what he thinks of stylesheets and he’ll probably be irritated even by thinking about them. It’s one of those things that seems easy, but mastering it takes a lot of time. While this is not a course on CSS, we will be pointing out simple tricks that you may or may not know, that might make your life just a tiny bit easier when you are trying to debug the interface of an app.
Like in the previous article we will be using Google Chrome’s Developer tools. To open them, simply hit CMD+Shift+I on Mac ( or CTRL+Shift+I on Windows) and navigate to the Elements tab, which will be our primary focus in this article.
DOM Lookup
The elements tab is where the whole HTML of your website can be found. Each line represents an element, which when clicked will reveal its children elements. You have 3 quick ways to locate the HTML for a particular element in the page:
- The first way is by utilising the inspect element button located in the top left corner of the elements tab (highlighted with a green circle in the screenshot below). Simply click on this button once and then click on an element in your website. This will select and highlight the HTML of this DOM element.
Another way to do that, is to right click on an element in the page and select “Inspect Element”. It will practically do the exact same thing, although I wouldn’t recommend this approach since it sometimes highlights the HTML of the surrounding (parent) element - The second way is by pressing CMD+F (CTRL+F on Windows) which will invoke a searchbar that allows you to search for HTML. Simply type
<videoorclass="btn"and you will see all the results that match your query, while simultaneously seeing the corresponding visual element(s) highlighted.
DOM Manipulation & Inspection
Now that we can search for a particular element, let’s see what we can do with it.
Edit Element
Firstly, you have the option to fully manipulate it, as if you were editing it in your local .html file. Simply right click on the element that you’re interested and click on the option Edit as HTML. This will open a textarea box with all the full HTML of the element, including its children, that you can edit in any way you want. You can change a class, add an attribute, add an extra <span /> as a child of the element etc. Should you wish to only change a particular attribute, then you can simply click on the add (or edit) attribute shortcut instead.
Delete Element
In order to delete an element from the screen you can simply press the Delete button in your keyboard, while having its HTML line selected (The same can be achieved by right clicking it and selecting Delete Element). This is something incredibly useful whenever you want to isolate an element in the screen (or whenever you see an annoying ad in a website).
Trigger Element State
Another nifty tool that can be quite useful, is to force an element to appear as if it’s hovered, active, focused etc. This will allow you to see the way the element looks as if you were hovering or focusing it. This is helpful whenever you want to debug the hovered-state CSS rules, without requiring you to actually hover or focus on an element.
Inspect Element Tree
Whenever you are debugging an element that’s very high in the hierarchy of the DOM, then it will be wrapping a lot of children elements. Instead of clicking on them one-by-one to inspect them, you can expand and collapse them using the corresponding options shown in the popup in the screenshot below. This quickly shows you the whole tree of elements, allowing you to easily identify the element that’s causing the visual bug that you might be seeing in the screen.
Element Breakpoints
One of the most interesting features is the ability to add breakpoints automatically on DOM modifications. By right clicking on an element and selecting Break on you can tell the main Javascript thread to pause the execution whenever one (or more) of the following events occurs:
- A modification to the element (and its related children) occurs.
- The element gets deleted.
- One of the attributes of this element (class, id, etc.) changes
Whenever this happens, the code will pause at the piece of code that modifies the element. This can be useful in situations where you want to identify the function responsible for tweaking the DOM, since you will be able to traverse the Call Stack and identify this particular piece of code.
You can disable that at any point by re-clicking on the same option, or by visiting the Dom Breakpoints section in top right corner of the elements tab
Style Inspection & Manipulation
On the right part of the Elements tab you are able to see every CSS rule applied to the DOM element that you have selected, regardless of the file(s) that they exist in (there’s always a link to the right of each CSS rule, pointing to the file it exists in).
Scrolling to the very bottom will reveal a rectangle with four (4) colours: blue, green, yellow and orange. Blue is the pure dimensions of your highlighted element, green is its padding, yellow its border and orange its margin. By hovering on any of them you are also able to visually see their outline on your screen.
The filtering input at the top of the tab (marked with green in the screenshot below) allows you to filter the CSS rules you see. For example, if you simply want to see why the hell your element has 0px in height, you could type in “height” and all the results you would be seeing would have to do with height-related rules.
A nice thing that most Devtools allow you to do, is to run custom CSS on the fly by using the elements.style section (highlighted with blue at the screenshot). Whatever you write there would automatically be inlined to the selected DOM element via an HTML style tag. This works vice versa, so if this area is already populated with some CSS rules, then that means that this element has some inline styles by default. Clicking the “plus” icon (highlighted with orange) will create a CSS selector that targets the element you have highlighted (by utilising the id and/or the classes that this element has). A nice trick with that is that you can append the word :after or :before in this CSS-selector and thus create CSS pseudoelements for this element without any hassle.
While we are on the subject, although not directly related to this article, it’s good to know that CSS rule priority is as follows:
- rules with
!importantat the end of them - inlined rules (using the style HTML tag)
- complexity of selector (more complex selectors override simpler ones)
- last encountered CSS rule (rules that were loaded last)
For example, if two rules have !important at the end of them, then the one that is inlined “wins”.
Not important at all: One nice trick that this section allows you to do is to have access to a colour-picker. Simply add or find an existing CSS rule that has a colour as a value (for example color: black) and click on the little “coloured square” that always appears to the left of the colour’s value. Now you can click anywhere in the page and the colour of the CSS rule (whose square you clicked) will change to match the colour of the item that you clicked. This can be helpful when wanting to compare colours or to find out “what the hell is the colour of this stupid element”.
Device Toolbar
When developing for devices, chrome provides some helpers to stop you from resizing your browser window to mock a smaller screen width. By clicking on the “mobile-and-tablet” icon to the left of the Elements tab, you gain access to the device toolbar. This allows you to essentially mock a device screen in order to see how your website would look in a device.
You can select a device among the most popular ones and tilt them using the tilt button (marked with blue in the screenshot below). You also have the option to define your own width & height by choosing the “Responsive” option (marked with orange) and either filling the corresponding input fields (marked with purple) or dragging the edges of the emulated device window.
What is interesting when mocking an android or iOS device, is that the global variables of Chrome change accordingly to emulate a real environment. Thus, what you see is what you would be seeing if your website was actually running in an android or iOS device. That’s incredibly helpful, since different operating systems handle a page differently (for example, URL bar transformation when scrolling).
One last feature that i will briefly mention here (since it’s also gonna be mentioned in the “Network” part of the series) is that you also have the ability to modify the speed of the network to see how your application would perform under 2G, 3G & 4G networks. You can even make it go offline for checking the offline experience when developing a PWA (Progressive Web App). All that, is also available on the Network tab, but cloning the functionality in the Device toolbar is also a nice thing to have. You can see this feature to the right of the tilt button (blue) in the screenshot below.
Closing notes
This article briefly scratched the surface of the Elements tab’s capabilities, since by its nature, it’s a tab where you simply delve in and start messing stuff around. It’s also a nice way to learn and test out CSS rules.
In the following article, we will explore Networking and how you can effectively monitor your requests & responses.
Thanks for reading :)
P.S. 👋 Hi, I’m Aggelos! If you liked this, consider following me on twitter and sharing the story with your developer friends 😀
