Making Internet Explorer Better for Developers

Here’s what my Start Bar looks like:

Screenshot of my start bar: Outlook, IE9, IE6, Firefox, Chrome, Safari, Opera, Visual Studio, Photoshop, Excel, MetroTwit, Communciator, Skype, Live Messenger

Specifically, you’ll notice that I have all the major browsers there as first class citizens. When I want to launch a browser, I just randomly move my mouse towards the bottom left of my screen and click which ever browser I hit first. As I write this post, I’m using four of them to browse the web. LastPass deals with my passwords and I don’t use bookmarks anyway.

I do this to maintain my knowledge of all the browsers, to help me be a better web developer.

For day-to-day browsing, this works fine. For development though, I find myself actively switching to Firefox just so I can use Firebug. On paper, Internet Explorer’s developer tools do everything Firebug does. In practice, I’ve just never liked them as much. Even with the current progress on consistent rendering, we need good development tools in all the browsers.

Over the last few days, I’ve been exclusively using the Internet Explorer 9 developer tools. I’ve noted each feature that I think needs work. Now, I want to add your feedback so that we can build a cohesive set of requests for the IE team. None of these suggestions will make it into the IE9 release, but now is a good time to get our feedback in before they commence planning for IE10.

General Browser

  • JS error dialog is annoying as hell – would be good to say “stop showing error dialogs” after the first one, and route the rest of the text to the console
  • Would be nice to be able to view JSON responses in the browser instead of getting a download prompt, just like XML

Console tab

HTML tab

  • Minor, but the HTML should really get renamed to DOM. It feels a bit silly telling people to go to the HTML tab when they want to see how an SVG is structured
  • Selecting an element in the DOM should outline it on the page
  • Can’t delete an element
  • Adding CSS properties in dev tools (should be able to do it from trace styles, not via attributes)
  • "Edit" button in DOM always seems to edit the wrong node
  • Typing style=" to add an attribute results in style="" which works against the habit
  • Rename "Trace Styles" to "Applied Styles" and make it the default
  • Rename "Style" to “Trace Styles” and make it second
  • Layout pane is too chunky – always have to make the dev tools bigger just to see it
  • With an active node in the DOM, need a way to get into the attribute editing via the keyboard only F2

Script tab

  • Whenever I hit “Start Debugging”, the dev tools undock and docking gets disabled. Seems unrelated and certainly annoying.

CSS tab

  • "This stylesheet cannot be viewed because its source is in a different domain than the page."

General dev tools

  • Why is there a "Clear Browser Cache" button in the HTML + CSS tabs? It’s already in the menu.
  • Why is Disable > Script not available? (It’s there, but greyed out.)
  • Consolas over Courier please.

What are you suggestions? Comment on this post.

I’m on the Microsoft campus in Seattle this week so I’ll be championing as many of these issues with the IE team as I can.

5 comments

  1. Honestly, the entire dev tools need major revamping, the UI is especially hard to use. I find that I can never have the dev toolbar docked inside IE because it feels too big, and not compact enough, maybe it’s the font choice and font size choice? Maybe it’s that stupid Menu as well, that makes you feel like there’s a gazillion (useless) options.

    Here are my gripes when compared to Chrome’s dev tools and Firebug:

    HTML Tab:

    When I debug in Firebug, I love deleting, it’s a great feature, being able to delete chunks and slowly cull away things to see what’s impacting my layout or what’s causing obscure bugs, it’s a fast and dirty way of isolating and eliminating.
    Yes, I know i can click on the edit button, but I hate going back into plain text mode and selecting a chunk of text to delete, I want to be able to select on a node and delete.

    Would be good to see the breadcrumb trail like how Firebug has it, so once I get deep down into my HTML I still know where I am.

    IE is really lacking the Computed styles tab as well, sometimes I like a nice categorized summary of the computed CSS values.

    Look at the Firebug DOM tab, now that’s what I call comprehensive details of everything, whether it’s used by everyone or not, it’s extremely useful at times when I need to dig deep into it, not only that I can edit most of it. So ditch that stupid plain Attributes grid and replace with the DOM tab.

    Console:

    I use this quite a bit, to execute javascript functions or jquery crap on the fly, it’s fast and simple, but the IE one just sucks and goes way too simple, when I execute a block of JS, that may return a new object, I’d like to be to see the breakdown of the object and other things related to it, check out Firebug’s doing of it, much better and informative when you execute some comprehensive blocks, but IE seems to show me nice ellipsis only.

    NET:

    There is no doubt I’ve wanted the Net tab all along, it’s really handy to track resources and requests made. It’s extremely handy to visualize as well, and being able to see all the response and headers.

    Currently, I can’t (or I’m not aware of) how to view response payloads, especially when I’m fiddling with stuff with JSON, I’d either do it in Firebug or whip up Fiddler.

  2. <>

    I believe the story is that JavaScript runs on the UI thread. Docked devtools also run on the UI thread. If the tools weren’t undocked and run on another thread, you’d deadlock the first time Script hit a breakpoint.

    1. If that’s the case, then maybe that should be made no longer be the case.

      This undocking mayhem is a huge usability problem, IMHO, and it’s bugging me at this very moment (2013, you’ll notice).

      Web developers should be able to choose whether the F12 window is docked in the same window or detached. That choice is snatched away in a very common scenario, and it looks very bad when compared to the competition (I’m glancing in Chrome’s DevTool’s direction).

Comments are closed.