Detailed console logging

This is an update to the console.log wrapper; see this blog post for background and a more detailed discussion of the problems with console logging.

While logging the console can be useful during development, some browser consoles do not display logged data in a readable, useful format. These primitive consoles do not expand arrays, do not link DOM elements to the source code, print objects as [object Object] rather than listing their properties, etc.

For example, try logging the following in Internet Explorer 8 through 10:

console.log( "Here's a string",
             3.14,
             {"alpha": 5, "bravo": false},
             document.getElementById('charlie'),
             new Date()
            );

It will result in:

IE8 without detailed print

On the other hand, Firebug, WebKit’s Developer Tools, and Opera’s Dragonfly print useful, interactive items to the console. Here’s the same code as above, but this time in Firebug:

Firebug running in Firefox

Expanded details

But it is possible to eke a bit more information out of the data in primitive consoles. I’ve added a detailed print plugin to my console.log wrapper.

By including the plugin and sending the data to log(), the same call as above now looks like this:

IE8 with detailed print

It’s still not pretty, nor is it linkable like modern consoles. But now instead of [object Object] you can see that it was an array (along with its length), or a DOM element (along with its selector), and so on. This can be useful in IE 7/8/9/10, iOS 5 and older, and Opera 11 and older, among others.

Alternatives

For iOS 5 and older, if you are so inclined you may instead try installing Firebug or using a remote debugging tool like Adobe Edge Inspect or Weinre.

If you’re sticking to modern browsers, you can simply ignore the new consolelog.detailprint.js plugin and continue to use log() as usual.

Thanks to Jörn Berkefeld for pointing out that this was needed on iOS 5 and for testing.

Live Demo Github Repo

  • Maxotaurus

    Output is pretty, but (firebug) processing slow and heavy on resources, heavy output gets overwritten, and I suspect (saw lots of nulls where I’ve come to expect sane values, all unfortunately overwritten) there may be a synchronicity issue. A case for output to be switched on demand directly into the Browser window? There, I’m accustomed to seeing everything.

    • http://patik.com/ Craig Patik

      Do you mean Firebug Lite, or the full Firebug Firefox add-on? Can you provide a simple test page that demonstrates it, preferably on CodePen.io, jsFiddle.net, or similar?

  • bbfbbf

    Is there any way to continue using “console.log()” and have your script kick in only when needed?
    Reason being that we lose the original “called from line #” when using “log()”. This is useful when there are whole bunch of console.log() calls and you’re trying to figure out where one of them is coming from.

    Thanks!

    • http://patik.com/ Craig Patik

      Perhaps you could define `console.log` as `log`, like this:

      // Load log() from the script first, then:
      if (!console && !console.log) {
      console = {
      log = window.log;
      }
      }

      • bbfbbf

        Thanks! Seems simple enough, I just wanted to make sure there wasn’t something I was overlooking, I’m new to larger-scale js.

        BTW, shouldn’t line 4 be “log : window.log” (i.e. object notation) ?

      • http://patik.com/ Craig Patik

        Good catch. It’s fixed now.

  • Pingback: Complete cross-browser console.log() « console.blog()()