W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

Re: Standardizing console APIs: Where?

From: Jorge Chamorro <jorge@jorgechamorro.com>
Date: Thu, 28 Feb 2013 19:31:48 +0100
Cc: public-script-coord@w3.org
Message-Id: <72DB02D8-CEF5-43BD-9E2E-76788BD89C70@jorgechamorro.com>
To: Marcos Caceres <w3c@marcosc.com>, Boris Zbarsky <bzbarsky@MIT.EDU>, Thaddee Tyl <thaddee.tyl@gmail.com>, François REMY <francois.remy.dev@outlook.com>, Brian Kardell <bkardell@gmail.com>, public-script-coord@w3.org
On 27/02/2013, at 22:46, Marcos Caceres wrote:
> On Wednesday, 27 February 2013 at 21:24, Boris Zbarsky wrote:
>> On 2/27/13 3:47 PM, François REMY wrote:
>>> However, I feel like the object-to-string behavior should be standardized
>> This assumes there is a conversion to string at all. The point of the  
>> discussion about clickable stuff is that some log() implementations show  
>> objects as trees or whatnot, not as strings.
> I was going to say exactly the same thing. 

@Zbarsky: I think that those clickable interactive trees and whatnots are über awesome when in interactive mode, when one's typing at the console, but to get them programatically perhaps one should have to call .dir() [1] not .log(), don't you think so?

If .log() -as it seems- is the printf() [2], that means ~ === print to "stdout" with formatting, and then it should output plain text.

When you do a console.log(obj) in a loop as in that example, to observe obj changing, delaying the serialization obviously won't work... unless we want to have to .log(serialize it upfront)

> Different browsers display these things in wildly different (and wonderfully useful) ways. It's a competitive differentiator. 

That every browser "displays these things in wildly different (and wonderfully useful) ways" might be fine for .dir() but not so much for .log().

[1] <https://developer.mozilla.org/en-US/docs/DOM/console.dir>
[2] <https://developer.mozilla.org/en-US/docs/DOM/console.log>
Received on Thursday, 28 February 2013 18:32:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC