Browsers - Developer tools

Go beyond console.log with the Firefox Debugger

Promo art for the Firefox Debugger Playground: a styled insect with the words "go beyond console.log" below it.

console.log is no debugger. It’s great for figuring out what your JavaScript app is up to, but it’s limited to spitting out a minimal amount of information. If your code is complex, you’ll need a proper debugger. That’s why we’ve added a new section to the Firefox Devtools Playground that’s all about debugging. We’ve built four basic lessons that use the Firefox Debugger to examine and repair a simple JavaScript to-do app.


Developer-facing implementation errors

This is a great way to guide other developers who may use your code or components to use the correct elements for accessibility and other reasons:

In our script, we can detect the element nodeName and return an error message if it is not BUTTON. We use return to stop the remainder of the IIFE (Immediately Invoked Function Expression) from executing.


if (toggletip.nodeName !== 'BUTTON') {  
  console.error('Toggletip buttons need to be <button> elements.')
A screenshot of a browser's developer console with the error message 'Toggletip buttons need to be button elements.' shown.

CSS tests and error messages

In Inclusive Design Patterns I write about creating deliberate visual regressions to highlight code errors, and providing error messages in the developer tools CSS inspector.

The error we caught with JavaScript earlier can be caught using the CSS selector [data-tooltip]:not(button). We can highlight the erroneous element with a red outline, and provide an error message using the made-up ERROR property:


[data-tooltip]:not(button) {
  outline: red solid 0.5em;
  ERROR: Toggletip buttons need to be <button> elements.

Despite being an invalid property, the ERROR will appear in dev tools when the element is inspected.