Improved Productivity Through Internet Explorer 8 Developer Tools
Over the past year, I’ve written about different tools 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:
- Internet Explorer 8 Beta 1 – download the beta, try the tools, and tell us what you think!
- Developer Tools whitepaper
- Developer Tools SDK page
- Demo video: overview (video version of this post)
- Demo video: debugging (~6min)
- Internet Explorer 8 Beta 1 Release Notes
Thanks!
John Hrvatin
Program Manager
Internet Explorer
Edit: Updated "Compatibility Modes" image
Comments
Anonymous
March 07, 2008
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.Anonymous
March 07, 2008
Good work on the developer toolbar. It sure beats having to wait an extra minute for Script Debugger to fire up and then a bunch of "OK" button-hitting. One thing I really miss is the ability to search through the code, though. hint hintAnonymous
March 07, 2008
The comment has been removedAnonymous
March 07, 2008
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?Anonymous
March 07, 2008
Kudos on the new Developer Tools, and thank you for them. I only have a few things to request about them.
- 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.
- 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!
Anonymous
March 07, 2008
You can have IE8 emulate IE7, then user the IE8 development tools to debug your IE7-supporting site. I love it.Anonymous
March 07, 2008
Have you ever seen Firebug? Firebug is great tool for Web site debugging/building. Just copy it functionality and this would be great.Anonymous
March 07, 2008
@Johan : To get download time for each element in a page, you can use DebugBar (http://www.debugbar.com). It gives all the HTTP requests of a page, connecting time, headers exchange time, keep alive sockets, download time, and ajax requests. Hope this helps. JFRAnonymous
March 07, 2008
Morten: This toolbar is new code, so we have to port the old features over (which we plan to do as John mentioned.) Vitaly: We've definitely seen Firebug... TheRabbi: Feel free to post ideas about how to better display the info.Anonymous
March 07, 2008
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.Anonymous
March 07, 2008
Puh-leeze. Why didn't you deal it years ago? "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."Anonymous
March 07, 2008
@Jeremy -- the "Puh-leeze" comment in reply to multiple blog posts is pointless and immature. I'd hate to see how you interact with people in person.Anonymous
March 07, 2008
The comment has been removedAnonymous
March 07, 2008
I do like it, but Safari 3.1 has better tools. Overall, though, IE is looking good in the developer sphereAnonymous
March 07, 2008
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.Anonymous
March 07, 2008
Love the new toolbar button options/commands.Anonymous
March 07, 2008
The comment has been removedAnonymous
March 07, 2008
The comment has been removedAnonymous
March 07, 2008
@J Berrendonner: If you haven't already, you might want to give Fiddler a try: http://www.fiddler2.com 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. You can learn more about Fiddler by checking out the demo videos: http://www.fiddler2.com/fiddler/help/video/Anonymous
March 07, 2008
The comment has been removedAnonymous
March 07, 2008
@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.Anonymous
March 07, 2008
The comment has been removedAnonymous
March 07, 2008
-toolbar and script- The scriptdebugger is missing something or I can't find it. Looks to me like you can only debug the code IN the page. Not in referenced javascript files. -toolbar and http- Nikhil Kothari also had a great Toolbar called Development Helpder Toolbar, but it doesn't seem to be online anymore. It had HTTP logging, very good for AJAX development.Anonymous
March 07, 2008
I suggest the inclusion of a source viewer with automatic reformatting of code, syntax coloring and inline search to finally replace Notepad.Anonymous
March 07, 2008
@LorenzoDV : DebugBar (http://www.debugbar.com) has a source viewer with syntax coloring, showing both original source code and IE parsed source code, and an inline search feature. @Berrendonner : You also have an http request viewer integrated into DebugBar with timing for each request and AJAX requests displayed with a special icon. Hope this helps. JFRAnonymous
March 07, 2008
How do I display the developer tool in a panel at the bottom of the browser instead of in a new window? Kind of stupid that the "inpect element" button can't do squat with the browser obscured by the tool window.Anonymous
March 08, 2008
@JFR : Thanks for the tip. @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).Anonymous
March 08, 2008
The comment has been removedAnonymous
March 08, 2008
As IE 8 is focusing on standard compliant, could you also consider implementing W3 DOM2 Range API along side with the current IE selection/range API? The W3 Range API can support more advanced and accurate selection of partial dom tree than the current IE range API. more info on W3 DOM2 Range API: http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html Thanks for the great work for IE8 beta1Anonymous
March 08, 2008
The comment has been removedAnonymous
March 08, 2008
forgot about bgColor ;) http://www.siteparser.com/temp/bgColorErrorIE8.pngAnonymous
March 08, 2008
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. Keep it up, IE. I'm rooting for you.Anonymous
March 09, 2008
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.Anonymous
March 09, 2008
@Joe Brinkman: DebugBar shows original source code as well as interpreted source code, both with an inline search feature. It also provides color picker, resizing and other features. JFRAnonymous
March 09, 2008
I onsdags under MIX08-keynoten presenterades den första beta-versionen av Internet Explorer 8. Den innehållerAnonymous
March 09, 2008
I onsdags under MIX08-keynoten presenterades den första beta-versionen av Internet Explorer 8. Den innehållerAnonymous
March 09, 2008
Micro$oft sux LINUX PWNS!!!!!!!!!!!!!!Anonymous
March 09, 2008
ASP.NET, ASP.NET AJAX New ASP.NET Technologies Released around MIX08 . Lista de recursos liberados despuésAnonymous
March 10, 2008
Thanks a lot for all your hard work! I'll join other people by saying, that firebug for IE would make our lives much easier.. Maybe it would be better if you would expose information to plugins developers... then we would have more useful plugins (just like firebu) anyway, too good to be true for beta! thanks!Anonymous
March 10, 2008
The comment has been removedAnonymous
March 10, 2008
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.Anonymous
March 10, 2008
@Tony Chor: You asked for better ways to display the data; here are my thoughts.
- 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.)
- 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.
- 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.
Anonymous
March 10, 2008
The new toolbar is great. I love the call stack stuff that FireBug doesn't provide. Can I have VS-style keyboard shortcut for step in, step out, etc?Anonymous
March 10, 2008
For the Internet Explorer 8 Beta, we’ve added an Emulate IE7 button to the command bar. It will helpAnonymous
March 10, 2008
Good to see firefox 3 , firebug and standards compliance are pushing IE. It would be nice to write code in several browsers and find that in IE it also works.Anonymous
March 11, 2008
It's good you guys are doing this, Firebug was the main reason I switched to Firefox. And right now debugging IE is a major downer!Anonymous
March 12, 2008
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?Anonymous
March 12, 2008
ASP.NET, ASP.NET AJAX New ASP.NET Technologies Released around MIX08 . Lista de recursos liberados despuésAnonymous
March 12, 2008
JScript Debugger in Internet Explorer 8 As Shreesh mentioned in his blog , Internet Explorer 8 has aAnonymous
March 12, 2008
As Shreesh mentioned in his blog , Internet Explorer 8 has a built-in JScript debugger. With InternetAnonymous
March 13, 2008
@mov__ax: You can debug eval code in the Developer Tools debugger. Although you can't put a breakpoint in there but if you are single stepping or use break all functionality, you can debug eval code. Check out my post at http://blogs.msdn.com/jscript/archive/2008/03/13/jscript-debugger-in-internet-explorer-8.aspx to see a screenshot of eval debugging. @Deef: You can browse the included files once you start debugging. @ 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.Anonymous
March 13, 2008
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.Anonymous
March 13, 2008
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.Anonymous
March 13, 2008
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.Anonymous
March 15, 2008
Ehkki IEBlog teatas juba möödunud nädala kolmapäeval, et IE8 esimene beta on väljas, polnud mul mahti sellega enne tänast tegeleda. Põhjuseks CeBIT 2008 ja sinna järgi kevadiste projektidega alustamine. Internet Explorer 8 esimene beta on mõ...Anonymous
March 19, 2008
This is the first on an n part post series about my personal thoughts on this year's MIX based on notesAnonymous
March 28, 2008
Our friends over in the Internet Explorer building recently released a developer preview version of IE8.Anonymous
June 03, 2008
In addition to the features for developers we showed in IE8 Beta 1 , we’ve been working on great newAnonymous
June 04, 2008
The IE blog whittles down the IE 8 Beta 2 date a bit further: In addition to the features for developersAnonymous
June 06, 2008
Internet Explorer 8 Beta 2 Coming in AugustAnonymous
August 05, 2008
The dev.toolbar is included in IE 8, so don't expect any stand-alone releases. Read more of the featuresAnonymous
September 03, 2008
In March I wrote about the Developer Tools in Internet Explorer 8 Beta 1 and outlined three key benefits:Anonymous
December 09, 2008
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 ...Anonymous
March 19, 2009
    Internet Explorer 8 Beta 1에서 주소 표시줄에 대해서 실시한 몇가지  기술적인 안내 (도메인 하이라이트 기능, 여러 행 붙이기Anonymous
March 19, 2009
    지난  1 년간, Internet Explorer 개발시에 웹 개발자의 생산성 향상을 도모하기 위한 다양한 도구 ( Web Development Tools