Improved Productivity Through Internet Explorer 8 Developer Tools

Over the past year, I’ve written about differenttools to help web developers become more productive when developing in Internet Explorer. These tools came from partners inside and outside Microsoft. One – the IE Developer Toolbar – came from the IE team in response to your requests for a free, lightweight tool to help debug your site in IE.

The IE8 Developer Tools are the next step in helping make developers more productive in Internet Explorer. In this post I’ll introduce you to what’s available in IE8 Beta 1 and point you to more detailed information about the tools.

Integrated, Simple-to-use Developer Tools

Internet Explorer 8 simplifies the process of debugging by including developer tools out of the box and making those tools easy to use. Instead of having to find, download, and install a separate debugging application, just press SHIFT+F12, or click the developer tools icon in the command bar.

And if you want to debug JScript, switch to the script tab and press ‘Start Debugging’. Even if script debugging is disabled, Internet Explorer 8 will remind you that it will refresh the page and enable debugging for only the current IE instance so you won’t see script error dialogs as you browse the web. Or, if you prefer to avoid the page refresh and dialog, just enable script debugging for Internet Explorer in the ‘Advanced’ tab of the Internet Options Control Panel.

Here’s a view of the debugger:

We also heard your feedback about the IE Developer Toolbar’s impact on performance even without the tool open, so we created a more robust design that resolves the problem. As we built on this new design for beta 1, we focused on new scenarios rather than putting back all features from the IE Developer Toolbar. As a result, you’ll notice many features from the IE Developer Toolbar aren’t available in IE8 Beta 1. In future betas, however, we’ll continue to add new features while bringing back the functionality of the Developer Toolbar so you can continue using the features you’re already familiar with.

A Visual Interface to the Platform

In addition to simplifying the debugging process, IE8 Developer Tools offer a new perspective on your site. Instead of just a source view, the tool provides visibility into Internet Explorer’s internal representation of the site. For example, the DOM tree in the tool is built from the tree IE builds internally to display the page, not from your source. So if script changes the tree, IE8 shows you the updated tree. You can also view style information for an element to better understand what rules apply or what rules specify a given style property, as show below.

Fast Experimentation

The Internet Explorer 8 Developer Tools also provide the ability to experiment and iterate rapidly by letting you edit a site within IE. For example, once you’ve found a style rule or property you’re interested in, click a checkbox to enable or disable it, or click an attributes in the DOM tree to edit it in-place.

The tools also provide easy access to all available rendering modes so you can test different modes quickly:

By removing the need to save changes, switch between applications, and refresh the page, the tools make it faster and easier to test, debug, or just experiment.

More Information

For more information about the Internet Explorer Developer Tools, check out these resources:

Wow, totally missed that button before now on the beta. Have not had time to try out the tools yet, but it looks good on this post. It’s nice to see so many new changes to IE8 that show you have been listening, so thanks for listening and working on including what we want and need into IE8.

I hope the requirements for IE 8 Development support comes from matching what Firebug does and not what IE Dev toolbar did. One of the most interesting part of of Firebug is to be able to see load times of different components. Hoping these type of features will be included also. IE Dev toolbar was so limited that many web developers switched to Firefox with Firebug.

Removing the property table, the read-only list and inherited style properties table is not increased productivity.

Yeah I like that you see the style tags in the tree-view but this is NOT user-friendly. Its tedious work looking at all the style properties, you cannot see the read-only properties nor got an overview of the inherited properties.

Don’t get me wrong… I LOVE the new features, but why did you have to remove the very useful ones that were already there?

Kudos on the new Developer Tools, and thank you for them. I only have a few things to request about them.

1) Their user interface is very clunky. I realize this is Beta 1, so this may not be the final UI, but please take this into account. There are much better ways to display this information and make it accessible to people easily.

2) It would be nice to have the ability to edit tags, styles, the DOM, etc. in-place. If I remember correctly, IE7’s dev tools have this feature. Even more powerful is something like Firebug for Firefox. In fact, if the IE8 dev tools were to become like Firebug, my life would become much, much easier.

Still, I’m looking forward to seeing what IE8’s final release will shape up to be. This has given me a lot of hope; good job and don’t let us down!

I’ve found a bug in DevTools that reports the wrong CSS rules as overridden in contradiction with the (correct) rendering by the IE8 layout engine. This is strange: aren’t DevTools supposed to look into the layout engine?

Note: i posted this bug with a test case in the IE8 beta newsgroup and didn’t get a single reply. I’m not one of the "bleesed ones" that are able to report bugs on Connect so THAT’S WHY A ***PUBLIC*** BUG TRACKER IS NEEDED.

About the interface I agree that there is a lot of room for improvement. The CSS view in particular seems a bit messy with all that checkboxes and without syntax coloring. Again look at Firebug: the interface its simply better and nicer.

Thanks for finally coming with such nice tool. It takes much of the features previously present on VS, but you should really consider a profiling tool (see Firebug). This has always been a big missing when developing to IE.

Any change to get some times an http debugger (well I mean really a simple log of http requests would be a very good basis, especially for Ajax !!!). And what about the "view source" option of the "page" menu : any chance to get a better visualizer (colored, auto reformatted text, …) ?

Any change to get some times an http debugger (well I mean really a simple log of http requests would be a very good basis, especially for Ajax !!!). And what about the "view source" option of the "page" menu : any chance to get a better visualizer (colored, auto reformatted text, …) ?

Fiddler is powerful, simple to use Web Traffic debugger that supports a rich extension model, breakpoints, content-rewriting, autoresponses, performance analysis, log capture, and a great many more features. Fiddler works for all versions of all browsers and is available free of charge.

@EricLaw : Thanks for the link, I didn’t know that one. I was just thinking that an integrated tool would be even easier to use in addition to the debugger. But congrats anyway for the work already done. Integrating developper tools in IE8 was really a "must do", especially for occasional developers that sometimes do not know what they are doing and make things "that just work". I’m also thinking about developpers of devices such as embedded network devices who are not especially skilled in web development but whose web pages will be used by thousands or millions of people around the world (I have some experience in that domain). If they have the tools in the hands, they will start to use them and better understand what they are doing. Thanks for integrating the IE developers toolbar into IE.

I hope the requirements for IE 8 Development support comes from matching what Firebug does and not what IE Dev toolbar did. One of the most interesting part of of Firebug is to be able to see load times of different components. Hoping these type of features will be included also. IE Dev toolbar was so limited that many web developers switched to Firefox with Firebug.

@EricLaw : This is kind of stange that now that there is a JScript debugger in IE, the same old popup window still shows : it would be much nicer to pop-up directly in the JScript debugger (or kind of). Moreover, when clicking the "Yes" button to the question "Do you want to debug ?" in this popup, currently displays a list of available debuggers which doesn’t even contains IE built-in debugger. Wouldn’t it be more user friendly to directly jump to a user chosen debugger configured through the "programs" tab of the "internet options" ? ( you can eventually keep a "first time" popup, but there again, in order to see the popup window, people have to enable the debugger in the internet options to be able to debug, so would a "first-time" popup be really useful? I suppose this was made for softwares embedding IE, but now that you have a full JScript debugger, I think this popup could be removed).

Kudos for your attention of more effective developer tools. This is a large leap in the right direction. Most developers who abandoned IE for Firefox over did so as they read Zeldman and became standards wonks. I parted ways in part for rendering, which has greatly improved in IE 7 and 8, but perhaps more so because of the excellent Firefox add-on developer tools (Firebug, Web Developer Toolbar, Color Picker). It was easier to develop in Firefox and the rendering was more accurate. That was enough to make me switch. Then I discovered the host of other quality add-on that made my browser what I wanted it to be (Drag and Drop Upload, Sage, Google Browser Sync, and many more). I wouldn’t want to develop and browse now without many of these.

But the ability to inspect and manipulate the DOM and track down and debug Javascript errors will make it tolerable to develop for IE again. Who knows, this might be the first step in winning back influential developers, the people to who convinced their friends and family in droves they should be using Firefox.

For a Beta, this is excellent. The most glaring omission from my perspective is the inability to interactively change the values of CSS properties and add CSS properties to existing rules (a la Firebug). Seeing the effect of enabling/disabling is a helpful start.

While I applaud the many changes I would like to see you include both the "original" html dom and the "current" dom. When troubleshooting it is good to know if it was the initial state that was buggy or the result of some javascript changing the DOM. There are plenty of cases where I need to see both. Also, just so it is not lost, the resizing, measuring and color picker tools are all much needed tools. Overall though, it is a good first BETA.

The javascript debugger doesn’t seem to want to break on any breakpoints within an AJAX onComplete function.

The interface, as mentioned, is a bit clunky. Especially not being able to find a way to get the dev tools window into it’s own frame so I don’t have to keep dragging it all over the screen to see what’s happening underneath. I unfortunately don’t have two displays to do development work.

The CSS tab doesn’t seem very useful in it’s current state. It’s easier for me to find id’s and classes in my own editor where they’re color coded, not in reverse order, and include comments I may have stuck in there to help me during development.

Seeing IE interpreted code in the HTML tab wasn’t what I was expecting, but it’s manageable. Perhaps having the ability to view the code in a more native format would be better, since that’s what web dev’s are used to seeing all day long. My initial reaction was, ‘Hey, how do I read this? There’s no quotes’.

I’d love to see the layout tab show the borders, margins and padding on the screen when mousing over each area, a la firebug.

The trace layout tab would work better in a tree format in my opinion, showing how each style cascaded down to the selected node. Although, I can see how the more flat format is useful if you’re searching for a specific style property.

Overall, it’s a good start, and development is a bit easier than it used to be in IE. But there’s still a ways to go before it’ll be as easy as in some of your competitions browsers. You’re on the right track though. Keep at it.

1. The HTML source viewer displays elements whose end tags are on different lines as closed tags (see any page’s <body> tag for an example: it shows up as <body />). I think it would be more natural to see the contents as one would opening the source in a text editor. That is, display the end tag after the content nested inside it. (Incidentally, I recall that the xml spec indicates that all tags are to be in lowercase. If this is in fact true, stop capitalizing the tags displayed. That capitalization adds noise to the display.)

2. In the style tab of the HTML viewer, the tree view used is clunky. I appreciate that this is a textbook tree view control, but the design has to be stepped up a bit. For example, the nodes at the top of the tree view should already be open. Better yet, make their status as roots of trees less obvious (because it doesn’t make sense to think of them that way) and try using them as headers instead. Stretch them across the area and use that visual disconnect to separate the ares. I hate to keep pointing to Firebug as an example, but it does this particularly well.

In addition, rethink the display of these tree structures in total. What can you use to make the information we need to see come across better? Colors, weight, and spacing are all neglected in the current design. A tree control is a great place to start, but you need to start thinking in a less constrained manner to convey this information in a truly superb manner.

I know that there are tons of web developers there – and I’m not talking about the Silverlight guys (though that stuff looks great) or your fancy-schmancy JScript XmlHttpRequest-heavy coders (though some amazing things get done there), I’m talking about the people that lay out the base work for the sites – so go ask them, no strings attached, what they’d like to see in developer tools. What information is important to them? What do they need to access side-by-side? I know one thing for me would be the ability to have the dev tools ‘docked’ in much the same way IE7’s were (or Firebug is) and see live changes take place on the webpage as I use the tools.

3. In the CSS viewer, it is not apparent what to do to access the hidden information. These trees should be expanded by default. The selectors should be highlighted somehow (bigger font size?), the properties should be lowercase (as specified in the spec), and the other files are hard to get to. Perhaps a tabbed approach for accessing the other files would work better?

I’m not sure what this would entail, but it also seems like there’s an awful lot of wasted space on the right side of the CSS viewer.

That’s all I have for now, I think. I haven’t gotten a real good chance to check out the Javascript debugger, and I probably won’t. But I hope that my suggestions get taken into account on the other tabs.

﻿Another important problem regarding the Built-in Developer Tool is that it doesnt allow debug of eval-code. When working with complex JSON objects, I need to inspect, place break points etc. Also, scripts which are added dynamically are not discovered in the Developer Tool’s script tab. Can anything be done about these things?

@ J. Berrendonner: You can avoid the script error dialogs by disabling debugging from Internet Options control panel. Devtoolbar JScript debugger will enable debugging only for the instance of IE in which you are debugging.

Deepak, you may be mistaken, with an ajax call, try getting a complex JSON object or even a simple file containing a function of about 300 lines, eval it, select one of the "eval code" items in the dropdown of the script tab. You will notice that the code is truncated, and as well, you can not place break points, etc. I find this extremely debilitating. Seeing code is different from debugging it, and in this case, i can’t even see all the code. You also did not address my concern regarding dynamically loaded scripts; scripts which are added dynamically are not discovered in the Developer Tool’s script tab.

Deepak, you may be mistaken, with an ajax call, try getting a complex JSON object or even a simple file containing a function of about 300 lines, eval it, select one of the "eval code" items in the dropdown of the script tab. You will notice that the code is truncated, and as well, you can not place break points, etc. I find this extremely debilitating. Seeing code is different from debugging it, and in this case, i can’t even see all the code. You also did not address my concern regarding dynamically loaded scripts; scripts which are added dynamically are not discovered in the Developer Tool’s script tab.

Deepak, you may be mistaken, with an ajax call, try getting a complex JSON object or even a simple file containing a function of about 300 lines, eval it, select one of the "eval code" items in the dropdown of the script tab. You will notice that the code is truncated, and as well, you can not place break points, etc. I find this extremely debilitating. Seeing code is different from debugging it, and in this case, i can’t even see all the code. You also did not address my concern regarding dynamically loaded scripts; scripts which are added dynamically are not discovered in the Developer Tool’s script tab.

FireFox users have a wealth of free browser addons that really help make the browser a strong development and debugging tool. Unbfortunately those nifty FireFox addons aren’t always helpful when a pa …