Actually Chrome doesn't convert the arguments to DOMString, so strike that part.

In Opera and Chrome window.console returns a Console object, but there's no Console interface object.

We should probably also make console available to workers.

+1 on standardizing the console object, or at least having dummy no-op versions of the API functions standard-included in the browser.

Look at the hoops we have to jump through to normalize `console` across browsers and also for browsers without it defined:  http://blog.getify.com/2010/06/console-log-in-the-wild/

It would greatly simplify web development to have `console` standardized.

I would love to see this happen. I often hear "Hey J, it's not working in IE" during the build/testing.  The first thing I check is for any calls to the console that I've left behind.

I've even seen people add their own functionality to assign console functions to do-nothing functions just to get around browsers that don't support it.

Disagree with having this standardized. This has nothing to do with HTML, and everything to do with web application development and JavaScript.

More importantly, saying we need this because some sloppy developer left it in a production site, and it "broke", is saying that we need to codify sloppy behavior.

This is part of debugging. Chances are, you debug in one browser. Let each browser determine what is best for debugging within its own environment. By the time cross-browser testing happens, the console statements should be removed, because testing with debugging implemented is not "true" testing.

We added console.log and a few related calls in Safari in part because sites broke occasionally due to a stray console.log. Realistically, a new browser would have to include the console object to achieve a competitive level of compatibility.

It would be useful to spec this, but it could plausibly go in a separate spec (perhaps in Web Apps WG) since there is almost no tie-in to other things in the HTML5 spec.

Yeah, this doesn't seem HTML-specific. Any takers for speccing this?

I think I'll take a stab at speccing window.console.

Maciej, you wrote:
> We added console.log and a few related calls in Safari in part because
> sites broke occasionally due to a stray console.log. Realistically, a
> new browser would have to include the console object to achieve a
> competitive level of compatibility.

I went looking for what the few related calls might be: when
window.console was originally added to WebKit[1], its error, info, log,
and warn methods were added. Since then, WebKit has added a bunch more
to its Console object[2]; do you have a sense for how much of that is
needed for interop with web content?


Ted

1. http://trac.webkit.org/changeset/27161
2. http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/Window/window-properties-expected.txt#L2171

(In reply to comment #7)
> I think I'll take a stab at speccing window.console.
> 
> Maciej, you wrote:
> > We added console.log and a few related calls in Safari in part because
> > sites broke occasionally due to a stray console.log. Realistically, a
> > new browser would have to include the console object to achieve a
> > competitive level of compatibility.
> 
> I went looking for what the few related calls might be: when
> window.console was originally added to WebKit[1], its error, info, log,
> and warn methods were added. Since then, WebKit has added a bunch more
> to its Console object[2]; do you have a sense for how much of that is
> needed for interop with web content?
> 
> 
> Ted
> 
> 1. http://trac.webkit.org/changeset/27161
> 2.
> http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/Window/window-properties-expected.txt#L2171

The first round was driven in part by the desire to keep sites working. Most of the subsequent additions were to enable debugging compatibility between the Web Inspector and Firebug, not for stray calls left on sites.

(In reply to comment #7)
> I think I'll take a stab at speccing window.console.
> 
> Maciej, you wrote:
> > We added console.log and a few related calls in Safari in part because
> > sites broke occasionally due to a stray console.log. Realistically, a
> > new browser would have to include the console object to achieve a
> > competitive level of compatibility.
> 
> I went looking for what the few related calls might be: when
> window.console was originally added to WebKit[1], its error, info, log,
> and warn methods were added. Since then, WebKit has added a bunch more
> to its Console object[2]; do you have a sense for how much of that is
> needed for interop with web content?
> 
> 
> Ted
> 
> 1. http://trac.webkit.org/changeset/27161
> 2.
> http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/Window/window-properties-expected.txt#L2171

I'm assuming that you'll submit your spec to WebApps or another group? 

If so, since this won't be in HTML, or is considered not relevant to the HTML5 spec, can we close this bug out?

(In reply to comment #9)
> I'm assuming that you'll submit your spec to WebApps or another group? 

Most probably, yes.

> If so, since this won't be in HTML, or is considered not relevant to the HTML5
> spec, can we close this bug out?

Fine by me! Resolving as WONTFIX as the HTML WG won't be addressing this.

For reference:

https://github.com/sideshowbarker/console-object

Moving this to webapps and reopening.

Mike, anything happening with your spec?

(In reply to comment #13)
> Mike, anything happening with your spec?

Nothing new except that we made it a deliverable of the Browser Testing and Tools WG.

https://console.spec.whatwg.org/

Created attachment 1636 [details]
www.google.com