The problem with wrapping console.log is that you lose the ability to know what line number initiated the log entry. The line number Chrome gives for the log line will always be where you call console.log inside the wrapper, not the line where you call the wrapper. Since there's no way to grab the line number of a caller in JS (Chrome's dev console uses browser hooks unavailable in JS), you can't even emulate the line number reporting yourself as a suffix to the log entry.
Using straight console.log statements seems to be non-negotiable for effective debugging, at least until a good workaround for the above is found.
For using Chrome's logging styles, we define a few short helper functions — l1(), l2(), l3(), etc. — that return predefined CSS strings, then doing our logging like
console.log("%cThis is a heading", l1())
console.log("%cLess important stuff", l2())
This means you're only adding 6 or so characters to get nice styled console messages that also maintain the nice line numbers and links to the source. Plus, it's similar enough to h1, h2, etc. that it's easy to remember.
We found that varying the font color (black vs. gray) and margin-left (2em, 4em) were most helpful in differentiating more and less important log messages.
After looking at the code in more depth, I feel I should point out that it looks like `arguments.callee` is only the last-ditch fallback for generating a trace. I see baked-in support for Chrome, IE, FF, Safari, and Opera, and so unless your preferred browser is something else (or you want to target every possible browser) then you could change just a few lines to make it strict mode compliant.
This will severely degrade performance in almost every scenario. I don't recommend doing it by default, though it is a nice feature to have. Sometimes you want to be able to call console.log a few times per frame in a game without your framerate dropping into the single digits.
I'm on OS X with an external keyboard, and I gave up after trying 3 or 4 keyboard combinations. I literally don't know for sure what key any of the three symbols is referring to.
YUI has a pretty nice console.log wrapper with tons of extra functionality. I don't use all of its functionality, but it does have the nice feature of not breaking IE when calling console.log without first having the Developer Tools window open.
I don't want to sound nitpicky buuuuuut in text based emails folks have been using bold, /italics/, _underlining_, and {{{ preformatted }}} text for a long time with slightly different syntax. How attached are you to the one you chose? Would you be open to accepting a patch to use the older syntax?
I once tried to write a markup parser with slashes for italics, then I understood why no parser seems to use them. It interferes with URLs, dates, slashes as "or", etc.
