Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

I still don't understand why it isn't. We have wide screens and we use more and more tabs.

Why do both Firebug and the built in tools exist, if you guys are committing to both? Why not just put everything behind Firebug?

One thing I don't like about the Firefox debug tools is that they are split up into different tools. Developer Toolbar, Web Console, Debugger, Error Console. Why do we need all these to be separate?

I'm not being pedantic.

Implement the same toolset, layout(UI), and keyboard shortcuts as Chrome/Safari. The underlying code would obviously be different, but as a developer one of my biggest problems with Firefox is having to do a mental context switch every time I have to debug something. Things that bother me is the dev tools defaulting to the top instead of bottom and having to click little buttons instead of fat tabs to choose what shows up in the console. Make each its own tab.

On the good side, the FF dev tools are a lot faster than Firebug was. That's much appreciated.

Chrome and Safari should do this as well. My point is that they are more similar to each other than Firefox is.

I tried searching, but I couldn’t find a single thing about accessibility on this page.

As someone who does not rely on accessibility tools, I have a lot of problems writing and debugging accessibility-compatible services, though I do try. I have a blog and a project that I am trying to make aide the experience for people with accessibility tools, but I still have no idea how it “renders” on their end. Nor do I know if I make a typo or write something that would not get validated by a test suite.

Here are some of the measures I include that Firefox does not appear to assist with:

    1. rel="next" and rel="prev"

It is actually incredibly sad that only Opera supports this—from what I can tell. Even Google seems to screw up the "next" and "prev" articles in search results for my blog.

On a personal note, being able to browse through a catalogue of blog posts, forum posts, etc. with just my Space bar, as Opera allows you, is amazing and something I am surprised others haven’t copied.

If you want to try it, you can check out my blog linked in my profile on Opera; you can use it either from the pages with several posts displayed or on individual permapages. This kind of navigation creates an entirely new experience, and in some cases it also defeats a lot of tedium, such as when I am reading through fifty pages of forum posts—especially if it is a high-activity thread for, say, a live event where I have to keep up with new posts.

    2. WAI-ARIA

In other words, the `role` attribute.

    3. .link-skip 

How, if at all, does my HTML/CSS actually work on accessibility software? Maybe my implementation is a completely rotten experience, but I wouldn’t know.

    4. Testing for colours

Be it colour-blind people or people with poor vision. One functionality could be contrast inspection where a font `color` is compared to the colour of its background. Since you already have the requisite tools for modelling element-layering, this should be fairly trivial to automate as a test.

Another functionality could flip the colour scheme to show what the site would look like with different types of colour-blindness.

There is much more to be done in accessibility, but I don’t really feel anything has changed in web-base accessibility in the last five or maybe ten years. I guess I wouldn’t know, because the tools available aren’t that great at the moment.

    5. Noscript testing

+++++

I really love the continuous integration that Travis CI provides (when I can get it to work, which isn’t right now). I would love to be able to automate this process to the extent possible.

Perhaps I could provide some kind of testing recipe that is either automated or provides the tools I need for a certain task—and only those tools—so I have, say, an accessibility-specific testing environment.

Webkit?