Dueling DOM Inspectors

The "DOM", in web page speak, is the Document Object Model. The W3C explains it: What is the Document Object Model?:

The Document Object Model is a platform- and language-neutral
interface that will allow programs and scripts to dynamically access
and update the content, structure and style of documents. The
document can be further processed and the results of that processing
can be incorporated back into the presented page.
 

In other words, it's what lets web pages change fonts, styles, and even add new elements to the page. Without this, we wouldn't have Javascript menus, css styles.. and writing cross-platform web pages would be much more difficult.

But all this power can be complicated. That's why we have DOM inspectors: Firefox has it under its Tools menu and there are add-ons that give you even more inspection capabilities. Even Microsoft has one for IE: Internet Explorer Developer Toolbar. But Safari does not..

Well, no, that's not true. Safari does have a DOM inspector, but you have to enable it. Open up a Terminal Window and type:

defaults write com.apple.Safari WebKitDeveloperExtras -bool true
 

(I suspect you might need to have installed the Developer Tools also, but I can't imagine why you wouldn't have done that already anyway)

Restart Safari, and right click anywhere on your page - you'll see "Inspect Element" as a menu choice, and selecting that starts up the DOM inspector.

What's it good for?

Regular readers of this site know that I like my pages to validate (http://validator.w3.org/). I'm not completely compulsive: I know there are still broken pages here and there on this site, but I do like to fix them when and where I can. The single most common problem I have is leaving off closing tags. These are usually trivially easy to find: if I leave off a </p> tag, I can quickly find it. Tables, lists, piece of cake. But <div> tags.. oh boy, those can be tough, and unfortunately all too common to screw up either by missing the close entirely, accidentally putting in too many closing tags (which of course prematurely closes another "div" you didn't want closed) or by incorrect nesting. So for me, tracking down "div's" is the biggest reason for using a DOM inspector. Of course there are other reasons, but for me, this is the meat of it.

Stop. Right now, somebody is saying something like this:

"Are you nuts? You should be using Typepad, Wordpress, Blogger, Dreamweaver.. you shouldn't be writing raw HTML!"

Ahem. I write very little raw HTML. The articles I write here are mostly plain text that is turned into HTML by scripts, I write the scripts, and it is within there that I usually make mistakes. Because the scripts get complicated, a simple mistake there can be very hard to spot, and that's why a DOM inspector is so useful to me. OK, we can continue now.

Let's take a look at these inspectors. From a raw visual perspective, the Microsoft is the worst of the lot: it opens in the same window as your page (as you might expect, given that they tell you it is a "toolbar"):

The others open in separate windows. Here's Firefox:

And here is Safari:

The Microsoft positioning is not as bad as you might think: when you click on an element in its window, the upper window will scroll to it if no part of the element is currently visible. Both Microsoft and Firefox do that, and both outline and briefly flash around the element you chose.

Safari does something similar, but it took me a while to figure out what. Basically, it darkens the screen and displays the selected element undarkened. Here it is after I selected a small div near the top of the screen:

That's much more visible than the others, but less useful when divisions are large and overlap. However, if you choose "Metrics" in the right hand column of Safari's inspector, you can see the actual size of the element you are inspecting. That can help you if it is bigger or smaller than you thought it should be. In Firefox, that's under Object - Box Model -> Dimensions; if you can get that from the IE tool, I could not find it.

These tools differ greatly when showing you style information about the element you are looking at. Safari and IE take a minimalist approach, while Firefox shows all inherited styles. Safari will show all if you click the "Implicit Styles" box; I could not find anything in the IE tool that would do that. Even with all styling shown, Safari thoughtfully dims the inherited styles so you always know what was explicit. Safari also "crosses" out styles that have been over-ridden - look at the "padding" in this shot:

Firefox will also tell you the x/y position of an element - again, very helpful when you've screwed something up. If the Safari or IE inspectors have that, I did not see it.

With all of these, it's fairly easy to see if one element is inside another by collapsing and expanding the detail views. Obviously your element disappears when you close its parent, and that alone can be very helpful when you have closed something off accidentally.

One feature I'd like seems so obvious that I'm surprised that I could not find it: In a source view, I'd like to click on the opening or closing tag of any element and have it jump to the matching partner. That doesn't seem to be an item any of these considered useful, but in most cases that feature alone would let me fix probems almost instantly.

I can't say that any of these is absoluely better than another, at least for my typical use. I'm not apt to use the IE inspector just because I don't use IE itself very often, but that's also true for Safari. I expect that if my problems were CSS related, Safari's CSS views would be very handy. In some cases, Safari's highlighting of elements is better than that of Firefox, but very often overlapping divs are far too confusing anyway. I'd like to see the ability to assign background colors or patterns to specific elements and perhaps to cycle through them for a more visual view of how the document is built. It can be confusing enough with web pages you created yourself; imagine how confusing it is to look at someone else's pages (especially when they have been created by Word, Dreamweaver or other HTML tools that spit out very bloated code).

Still, these tools are a lot better than having nothing at all. I suspect that their designers are more concerned with CSS inheritance than screwups like I make, so what I see as missing functionality really is not. I usually don't even try to debug CSS problems, but then again I don't demand much from CSS either, so seldom have problems or issues. Probably I'm using a perfectly good chisel as a screwdriver and complaining about how badly it works..

Well, sometimes a chisel is better than your fingernails, right?

Click here to add your comments


Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Why no "Digg this!" etc.?

Take Control of Your Domain Names

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here