APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

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: www.microsoft.com/downloads/details.aspx?FamilyID=E59C3964-672D-4511-BB3E-2D5E1DB91038&displaylang=en (link dead, sorry) 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"):

Internet Explorer DOM inspector

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

Firefox DOM inspector

And here is Safari:

Safari DOM inspector

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:

Safari DOM inspector showing div

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:

Safari DOM inspector showng styles

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 absolutely 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?



Got something to add? Send me email.





Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence



Kerio Samepage


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.

Contact us





Software and cathedrals are much the same – first we build them, then we pray. (Sam Redwine)

Computers make it easier to do a lot of things, but most of the things they make it easier to do don't need to be done. (Andy Rooney)












This post tagged: