The fact that the DOM Inspector has different views of a node/stylesheet (DOM Node, Javascript Object, etc.) isn't noticable enough. I didn't even realize that those views were there until a short time ago after a couple years of using the inspector. I propose to change to a tabbed interface, which also would be more consistent with everything else everywhere. I'd be willing to try to implement this if someone higher up says this would be good to have.

I'm not so sure about this... given that there are up to six panels (what you are calling views) in a pane at a time. Even with a maximized window, that could be troublesome.

I don't know about other people, but my standard DOM inspector window size could accomodate a lot more than 6 tabs. I definitely think this would be worthwhile, drop down menus make it harder to go to where you want quickly.

mine wouldn't handle more than 2 tabs.

Ccing some UI design folks.

The drop-down isn't discoverable, we need to improve on that. If not tabs, then what? To do this right with tabs, we need to fix the remaining issues with hidden and/or disabled tabs in tabbox, but I already have that on radar.

Typical DOM inspector window has no more than 150px of horizontal space in the right panel when maximized on a high-res screen. That's not really enough space for more than 2 tabs. In the main view things are a little better, but the default size in Firefox for this window is 640x480, so that would be about 500-ish px of space. That could fit about 5 tabs.... mconnor suggested that a more thorough UI redesign is in order here.

What about vertical tabs along the side? I'm not even sure if we can do that easily, but I know that many people don't realize that you can change the views (I've had people who helped me develop an extension and they used it all the time but didn't know you could change the views). It at least needs to be a bit more discoverable.

I'm glad to know that not realizing you can change views is not just a problem for accessibility! I've been trying to think how a panelset could be made to make this accessible. I've thought of the following, not knowing how it would affect the visual appearance: 1. Add the choices under the dropdown as a submenu of the view menu; either a submenu for the current pane, which would change when focus switched to the other pane, or one submenu for each pane. 2. Add a submenu to every context menu in the pane. 3. Add a button in the focus ring that would open the menu. Re: method 1: Would having a View menu change based on the focused pane be acceptable UI behavior? Re: method 2: The only way I see to do this is to have the logic that handles panel changes add/remove items from all context menus in the panel and a context menu when there isn't one. Is this reasonable/practical? Re: method 3: I tried to make the toolbar button focusable-- I added -moz-user-focus:normal style to it. (You definitely want to use -moz-user-focus rather than tabindex because with tabindex the buttons in both panes appear in the focus ring in either pane.) Toolbarbutton type=menu would not be activated with the keyboard (spacebar) by default. I got the keyboard to sort of access it by placing onkeypress="if (event.charCode == ' ') event.target.firstChild.showPopup();" on the toolbarbutton. It seemed to activate the button but there was no indication via the screenreader that anything happened (like there is if you simulate a click) until you arrowed. Also, pressing TAB or Shift+TAB would activate the menu, but JAWS seemed to read the name of the following field or something, it was very strange. I gave up on that for now.

For toolbarbutton type=menu try F4 or Alt+Down to open it.

I'd say to use scrollable tabs and make sure tab names are short as possible

DOMi has been decomissioned, closing as WONTFIX.