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

Re: Standardizing console APIs: Where?

From: Brian Kardell <bkardell@gmail.com>
Date: Wed, 27 Feb 2013 14:09:44 -0500
Message-ID: <CADC=+jfG4yVSoCqrPEvnu9eGmeKMV+z45oJx9D2x7CYFzrEYNg@mail.gmail.com>
To: François REMY <francois.remy.dev@outlook.com>
Cc: Thaddee Tyl <thaddee.tyl@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On Wed, Feb 27, 2013 at 1:55 PM, François REMY <
francois.remy.dev@outlook.com> wrote:

> > In browsers, when logging an object, you can actually click on an arrow
> > to browse through all its properties.
> > Serializing the whole thing on every single console.log, when those
> > happen in a loop,
> > would make the debugging experience a nightmare, performance-wise.
>
> True but we may expect the string representation to be exact while the
> details are loaded when expanded only.
>
> The clickable behavior is an extension to the Console API (which is
> text-only). I agree that this part should not be standardized.
>
> However, IE has a console.clear() function that I find useful, it should
> probably be standardized. I think we should also get console functions
> bound to the console object as it was already proposed in this thread. The
> string output format should probably be better defined, too.
>
> All in all, even if we limit the scope to text functions, there's still
> room for compatibility improvement. I wonder if the people working on
> navigation timing APIs wouldn't agree to work on this since the console API
> has profiling capabilities... which probably could be improved vastly.
>
> BTW it should be noted that some browsers only enable logging on a page if
> the console window is open (or was opened at some point in the page
> lifetime). This is maybe a way to avoid the slow down that more powerful
> logging tools could cause.



All of this is why, if you look at my strawman, I proposed that it be a
generic (logging) interface and focus on creating non-breaking APIs rather
than go into too deep details about how/what it does with them since that
is variable and contains of room for art and innovation.

In other words, an API with complete noop implementations would actually be
valid (logging is disabled).  It could easily provide stricter
advice/requirements where appropriate and keep this in tact.  For example,
since the de-facto apis allow tokenization, it seems appropriate to either
suggest or even potentially require that if it does show those messages (if
it is actually logging something) it should (or should not) serialize
objects, which tokens are valid (%d, etc).

This seems to me workable and simple to start pretty basic, release early
and iterate quickly... That's all speculation on my part, of course, but it
sounds rational to me :)

-- 
Brian Kardell :: @briankardell
Received on Wednesday, 27 February 2013 19:10:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:09 UTC