10694 2010-09-23 09:49:49 +0000 Specify window.console 2016-02-12 16:50:55 +0000 1 1 1 Unclassified Browser Test/Tools WG Console unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#the-window-object whatwg-resolved P3 normal --- 1 contributor mike d eoconnor ian Kathysoto411a kennyluck mike mjs Ms2ger nazrmed pastith philipj pixelparty public-browser-tools-testing public-html-admin public-html-wg-issue-tracking rayrayray111 sroussey www-dom dave.null oldest_to_newest 39197 0 contributor 2010-09-23 09:49:49 +0000 Section: http://www.whatwg.org/specs/web-apps/current-work/#the-window-object Comment: Specify window.console. Without it scripts around the web break because the author left in a console.something. Not sure which members are required; Opera has log, warn, error, info. They should be defined to either do nothing or show the arguments converted to DOMString and joined with a U+0020 space as a message to the user in a UA-defined way. Posted from: 85.227.159.236 39198 1 zcorpan 2010-09-23 09:59:48 +0000 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. 39202 2 w3c 2010-09-23 14:05:54 +0000 +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. 39205 3 pixelparty 2010-09-23 14:40:30 +0000 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. 39209 4 shelleyp 2010-09-23 16:44:53 +0000 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. 39211 5 mjs 2010-09-23 16:53:54 +0000 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. 39871 6 ian 2010-09-29 06:23:27 +0000 Yeah, this doesn't seem HTML-specific. Any takers for speccing this? 39984 7 hober0 2010-09-29 17:39:28 +0000 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 39986 8 mjs 2010-09-29 18:05:29 +0000 (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. 39988 9 shelleyp 2010-09-29 18:42:47 +0000 (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? 39995 10 hober0 2010-09-29 18:53:53 +0000 (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. 43819 11 Ms2ger 2011-01-05 11:55:12 +0000 For reference: https://github.com/sideshowbarker/console-object 59549 12 zcorpan 2011-11-03 10:15:25 +0000 Moving this to webapps and reopening. 59574 13 Ms2ger 2011-11-03 17:49:46 +0000 Mike, anything happening with your spec? 59679 14 mike 2011-11-07 08:09:12 +0000 (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. 124821 15 philipj 2016-02-04 06:51:37 +0000 https://console.spec.whatwg.org/ 125002 16 1636 seancrayton81 2016-02-12 11:58:02 +0000 Created attachment 1636 www.google.com 1636 2016-02-12 11:58:02 +0000 2016-02-12 11:58:02 +0000 www.google.com file_10694.txt text/plain 6 seancrayton81 R29vZ2xl