Working with the Internet Explorer Developer Tools

Internet Explorer has been out for a while now, and I am very pleased with it, especially from a developer's perspective. First I am more and more appreciative of the IE team getting CSS compliant, this is making it so much easier to create a consistent design across browsers. If you want to appreciate the differences between the last three versions of Internet Explorer Smashing Magazine did a great article earlier this week. The thing that has truly changed my experience with client-side development (think jQuery and CSS) is the Internet Explorer Development Helper. In fact I can not imagine doing client-side development without it or FireBug in FireFox.

The Development Helper can either be invoked by selecting it from the Tools menu, or as I always do pressing F12. This launches a new window with all kinds of wonderful client-side development tools. The first thing that stands out are 4 tabs located below the menu (more on that later); HTML, CSS, Script and Profiler. The HTML table gives you manipulative access to the HTML. The CSS tab lets you access the CSS files loaded by the page. The Script tab lets you see and debug any JavaScript the page relies upon. The Profiler let you trace the page request and subsequent running of the scripts while the page is loaded.


When I am working on CSS issues in my pages I spend a lot of time on this tab. The reason is the ability to see how style rules are applied to a specific DOM element and change that style applications real-time. There are 4 ways to view the CSS rules for an element; Style, Trace Styles, Layout and Attributes.

The HTML Style tab simple lists all the style rules in the order they are applied to the element. The rules are displayed in a tree hierarchy, with each selector having its rules displayed as child nodes. If a rule is overridden by another selector rule, then it is displayed with a strike through. Beside each rule is a checkbox, indicating if the rule is applied to the DOM element. Unchecking a rule will automatically cause the next matching rule to be applied to all elements that match that selector. You also have the freedom to select a rule, say background-color, and change it to another value. This will cause it to be applied to all elements that implement that rule. This is so valuable because now I can make minor tweaks to rules, selectors, etc to see how a change will affect the page without having to make the change in the stylesheet, save the file and reload the page.

The Trace Styles tab works almost the same as the Style tab, but instead of a treeview of CSS selectors and rules being displayed the CSS rules are listed for the DOM element with the ability to expand the selectors that apply to the element. You can again turn them on and off and adjust values as described before. I use this view more than the Style tab because it is much easier to see what I can adjust.

The Layout tab is much different than the two CSS tabs because it visualizes the box model of the element. This means you get to see the real height, width, margin, padding and offsets of the element. This is a very useful view when you are trying to work on layout and placement issues. I find it invaluable to understanding how a form using tables actually renders for example.

Finally the Attribute tab lets you define element attributes at run-time. So you can add and set any attribute or style value at run-time. For the longest time I was very frustrated with the Developer Tools because I could not add style rules or change attributes (like table cell widths) without going back to the source, saving and reloading. So when I found I could do it here I was very happy. Working with FireBug in FireFox also allows this feature, so I was really happy learning how to do it in IE too.


If you do any AJAX development you will spend a lot of time in the Script tab. In the past few years the debugging tools seem to have finally caught up to the need to adequately work with JavaScript. This has been the primary reason I stayed away from JavaScript development over the years, but now with jQuery and the IE Developer Tool I Love JavaScript Development.

The Script tab of the Developer Tool opens up a real debugging environment that you can set break points in your JavaScript and step through the code just like we are accustomed to doing in Visual Studio. It also has additional windows for watches (both local and developer defined), a Console and a Call Stack window.

Stepping through code works just like it does in Visual Studio. However if you have included a JavaScript file that has been minimized then you are going to have a very difficult time stepping through this code. If you are not familiar with minimizing JavaScript it basically means removing the unneeded whitespace characters that are ignored by the JavaScript interpreter, making it much more compact to send down the wire. If you are developing this can be problematic because stepping through the code now is very difficult. I relate it to trying to step into one of the .NET libraries you do not have source code access, it just gives you a class view in Visual Studio.

Setting a watch is pretty easy, you can right click on a variable a selector, $('#myelement') for example, etc. and you can just add the watch from the context menu. One thing to note is once you close the Developer Tools you will loose not only the breakpoints you have set, but also the watches you have set.

The Console window is pretty nice because it allows you to execute a JavaScript statement based on the current point you have set your breakpoint. By this I mean you can execute a statement and see the result in the window based on the current state of the client-side state. So if a JS variable has a value that is set after your breakpoint it will not be available, but you can 'set' that value in the console and maybe play some what if scenarios like I described above in the CSS tabs.

Call Stack if a nice idea, but in my experience not quite as useful because I tend to only see 'anonymous JavaScript function' listed. But it does sometime actually list the functions called on the way to the point of the breakpoint execution.


The profiler is another invaluable tool, but its not obvious at first glance. The profiler monitors all the JavaScript execution during a monitoring session. To start profiling just click the 'Start Profiling' button then go back to the browser and use your web site. When you are done executing things return to the Web Development tool and click 'Stop Profiling'.

You will then be able to view the results of the profiler in one of two ways; by function call or in an execution tree. The usefulness of the profiler is allowing you to see where bottlenecks and other inefficient code is located in your JavaScript. It tells you how many times a function was called and how long those calls took. It also tells you what file the function is located and what line it is located.

The results can be exported to a CSV file by clicking the third button from the left on the Profiler toolbar. Now you can view and manipulate the data in another tool if you want. The E-Mail form I am using for this demonstration is rather boring because it does not do much outside the jQuery framework. But just glancing over it I can see some potential optimizations I can make by reducing the number of times I make jQuery use the selector syntax for example.

Menu Options

So far I have just been talking about the tabs in the Developer Tools and have not even started with the menu options!!! So wait, there's more ;) I am not going to cover them all, but want to write about the cooler features.


This menu option gives you the ability to turn off scripts the pop-up blocker and even CSS. This means the browser will not execute these items. This can be a good way to test your application for downlevel browsers (think Lynx) and to see how a search engine spider might see your site. I like to turn off the scripts so I make sure my page will work where JavaScript is turned off. Granted I do not do that very often, but it is a nice way to test it out.


The View menu option is another useful feature because it overlays information on the page for applicable elements such as the CSS class, Id, tab index and Access Keys. This is really nice because now you can just glance at your page and see what these values are from a user's perspective. So its another way to see things without having to view the source and search through the markup to find these values and make sure you are on the right element.


The Outline menu lets you turn on 'outlines' to visualize where a table, div or any other DOM element's box is actually located on the page. When working on a new layout this is very helpful in determining where containers begin and end. In the screen shot shown here (click for a larger view), the DIVs are indicated with a thin green line. Images are outlined by purple.



This menu option lets you visualize information about images or just turn them off all together. Again overlaying this information on an image is very helpful in determining the dimensions and file sizes. One problem I have is on small images it overlays the information, but only within the boundary of the image itself, which means you just get a pink box covering the image with no useable information. I hope they fix this issue and allow you to roll your mouse over the image and have the information naturally expand to a viewable tooltip type metaphor.

In the image shown here you can see it is highlighted in pink and see it trying to write out the image dimensions. This needs to be corrected in the next version of IE.


The Cache menu can be a developer's best friend at times because you can designate that all supporting files must be retrieved from the server each time the page is requested. You can also manually clear cookies and the browser cache related to the URL.


Under Tools you can Resize the browser window to different potential user dimensions. I have always targeted my sites for an 800x600 box, but that is quickly fading away with larger monitors quickly becoming the defacto standard. Uber Geeks tend to run at super high resolutions so you can set the browser dimensions to larger screens as well or a custom height and width.

The ruler is a very neat tool, but not quite obvious at first. But you can pick a point on the page and drag the mouse from it to another point. A ruler is drawn from point A to point B. The length is displayed in the Ruler window that is open above the page.

The color picker is very useful when you are trying to determine a color on a web page. This will launch a tool window over the browser with a eye dropper mouse cursor. As you pass over elements in the page the color is grabbed by the tool and displayed in tool window. Clicking over an element will lock the color for you. Now clicking the 'Copy and Close' button will place the color's HEX value in the clipboard so you can easily use it in your CSS or Paint.Net, etc.


Using valid HTML code is critical to having a good web site, in my opinion. You can get by with bad markup and CSS, but you are actually hurting yourself in the long run. The Validate menu lets you send your markup or CSS to W3C for actual validation. Additionally you can check for accessibility compliance, which is really handy. Now this is not going to be the ultimate accessibility feedback you might get from a tool like JAWs. But I highly recommend using as much validation as you can. One drawback is the tool wants to send the URL to the W3C online validation tool instead of posting the markup to the tool. So you cannot send anything from your local development machine, it has to be a public facing web site. So I hope this gets improved in future version.

Browser Modes

IE 8 is a game changer when it comes to supporting CSS standards. Prior to IE 8 Internet Explorer was known for doing things its own way as far as how it implemented CSS standards. This causes many web developers and designers to pull out their hair every time they build a user interface. Now the real problem is there are so many web sites out there that only conform to IE 6 or 7 standards. Microsoft has even been offering bribes to get folks to upgrade from IE 6, and as a web developer let me say PLEASE STOP USING INTERNET EXPLORER 6!!!

Rather than allowing these poorly developed sites just not work in IE 8, they opted to let users click a button to the right of the address bar to have IE 8 use the IE 7 rendering engine to display the URL. The Web Developer takes this a step further because it allows you to select the browser and the browser mode you want the page rendered. It even offers Quirks Mode, which is used by browsers when it cannot determine what if any DOCTYPE the page uses.


The Internet Explorer 8 Developer Tools are an invaluable tool that every web developer should leverage in their day to day development tasks to make high value modern web sites. Understanding all the features available in the tool is very important because once you understand how to use the tools you will start seeing how to make your web sites' user interface better. With the popularity of FireBug, this is a much needed tool for Internet Explorer that will help all of us develop better front-ends.

Share This Article With Your Friends!