Standardizing console APIs: Where?
On Fri, Feb 22, 2013 at 11:13 AM, Brian Kardell <bkardell at gmail.com> wrote:
Recently I read a post about Chrome adding a console.table API which mentioned some things in other browsers. My immediate reaction was "is this a new proposal for addition to console standard API, because that could be pretty handy actually" but then after a moments pause and about an hour search, I realized: There is no codified standard for console API. Turns out that public-browser-tools-testing at w3.org has sort of agreed to take it up, but it doesn't seem like anything much has happened yet and I'm wondering why that should be bound to anything with the browser since console is a pretty universal thing in implementations. Not saying it should or shouldn't be ECMA, just that it seems to be in the wrong place now if, indeed, anything is happening there.
A very smart addition to the future standard library modules—which are dependent on a Module spec of course. Write a strawman?
On Fri, Feb 22, 2013 at 5:31 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
On Fri, Feb 22, 2013 at 11:13 AM, Brian Kardell <bkardell at gmail.com> wrote:
Recently I read a post about Chrome adding a console.table API which mentioned some things in other browsers. My immediate reaction was "is this a new proposal for addition to console standard API, because that could be pretty handy actually" but then after a moments pause and about an hour search, I realized: There is no codified standard for console API. Turns out that public-browser-tools-testing at w3.org has sort of agreed to take it up, but it doesn't seem like anything much has happened yet and I'm wondering why that should be bound to anything with the browser since console is a pretty universal thing in implementations. Not saying it should or shouldn't be ECMA, just that it seems to be in the wrong place now if, indeed, anything is happening there.
A very smart addition to the future standard library modules—which are dependent on a Module spec of course. Write a strawman?
I beg to differ.
The standard for console APIs is at getfirebug.com/wiki/index.php/Command_Line_API, along with
other devtools-related standards. It is very functional (changes happen regularly by cross-browser consensus, and suggestions are welcome from anyone). Sure, not all devtools support it all, and they may have bugs, but they each strive to fix their implementation. Duplicating standards will only duplicate efforts.
You may notice that console.table is defined there now (and has been for some time).
On Monday, 25 February 2013 at 10:50, Thaddee Tyl wrote:
On Fri, Feb 22, 2013 at 5:31 PM, Rick Waldron <waldron.rick at gmail.com (mailto:waldron.rick at gmail.com)> wrote:
On Fri, Feb 22, 2013 at 11:13 AM, Brian Kardell <bkardell at gmail.com (mailto:bkardell at gmail.com)> wrote:
Recently I read a post about Chrome adding a console.table API which mentioned some things in other browsers. My immediate reaction was "is this a new proposal for addition to console standard API, because that could be pretty handy actually" but then after a moments pause and about an hour search, I realized: There is no codified standard for console API. Turns out that public-browser-tools-testing at w3.org (mailto:public-browser-tools-testing at w3.org) has sort of agreed to take it up, but it doesn't seem like anything much has happened yet and I'm wondering why that should be bound to anything with the browser since console is a pretty universal thing in implementations. Not saying it should or shouldn't be ECMA, just that it seems to be in the wrong place now if, indeed, anything is happening there.
A very smart addition to the future standard library modules—which are dependent on a Module spec of course. Write a strawman?
I beg to differ.
The standard for console APIs is at getfirebug.com/wiki/index.php/Command_Line_API, along with other devtools-related standards.
there is also the CommonJS one: wiki.commonjs.org/wiki/Console
It is very functional (changes happen regularly by cross-browser consensus, and suggestions are welcome from anyone).
Sure, but that's the same for most Web tech.
Sure, not all devtools support it all, and they may have bugs, but they each strive to fix their implementation. Duplicating standards will only duplicate efforts.
You may notice that console.table is defined there now (and has been for some time).
I guess the question is, what is the benefit to the developer community in formally standardising this API at either the W3C or ECMA (as opposed to the de facto standard processes above)? Is there something we can do better that the other communities are not already doing?
Kind , Marcos
I must admit i am a bit surprised that anyone would appear to be opposed to formalizing something through one of the two groups... It seems to me the goal of all of these other groups here is to pick up something that is lacking and people wish that we had a standard for.
Regardless of history or agreement by vendors, no dev i know of looks to any of those as sources of standards and they give no indication themselves otherwise.
I sent Rick the following link Friday evening and was hoping for a little tweaking before it was shared with a much wider audience. It contains explanation/goals/non-goals bkardell/logging
Essentially though, some logging concept (usually console based) is supported by all engines, but the actual almost universally shared API has actually been pretty small. There is really no good reason i can see for that, logging really has nothing to do with dom or even console inherently
- so why not get an actual standardized API effort to make the code at least universally portable with a source people can look up and recognize as standard?
That said, i'm not interested in charging at windmills here, so if no one is interested, that's fine too.
I maybe missing what you're saying. But I went to the link you supplied and that is for the Command Line API. Further it seems to be specific to Firebug (which doesn't IMO sound like a place to hang a standard like this). I did however find getfirebug.com/wiki/index.php/Console_API to which I think is what this thread is targeting.
The interesting bit in that standard is that it is in fact very specific to Firebug. Reading the implementation notes clearly shows that if an existing console object exists on window - this API is not guaranteed to be implemented. And likewise if it's not Firefox. Seems to be vendor specific and then even plugin specific.
These things alone tell me that a standard (w3c vs. ecma I care little) is necessary.
Somehow this thread wound up forking only to public-script-coord at some point - not sure where. See comments from awb, alex russell, mark miller and others: lists.w3.org/Archives/Public/public-script-coord/2013JanMar/thread.html
-Brian
---------- Forwarded message ---------- From: Robin Berjon <robin at w3.org>
Date: Wed, Feb 27, 2013 at 5:35 AM Subject: Re: Standardizing console APIs: Where? To: Brian Kardell <bkardell at gmail.com>
Cc: "public-script-coord at w3.org" <public-script-coord at w3.org>
On 26/02/2013 23:06 , Brian Kardell wrote:
- Does anyone else feel like we should have a standard
I think that this thread has shown that there are interoperability issues. Given that this is a debugging tool, you really want it to have predictable behaviour so as not to waste time looking for a problem that in fact comes from the console API.
- Given that this goes beyond the browser, where should that standard
live? I feel like its proper home is ECMA since the API, again, has not really anything to do with browser necessarily.
I think that it makes more sense in ECMA, but if for whatever reason that doesn't work out you're welcome to bring it to W3C.
- If ECMA, is it part of the language (ES7?) or is it separate like
i18n? I was actually suggesting that my opinion is the later, this feels like an ECMA module that could use standardization and is commonly imported in browsers and many engines for back-compat as 'console' (though I suggesting 'logging' is a better API term). I also suggested (in the strawman) that it could start very small with the abstract APIs that are at least universally non-breaking (even if they might do something slightly different) and have been fermented for years and years - thus it should mostly be an easy approval to find a home and basis on which to gather proposals and consensus
I don't have a specific opinion on how ECMA organises work, but I strongly agree with the idea of starting very small and iterating, even if it means that you release several version in a relatively short period of time.
On Wed, Feb 27, 2013 at 5:07 PM, Brian Kardell <bkardell at gmail.com> wrote:
On 26/02/2013 23:06 , Brian Kardell wrote:
- Does anyone else feel like we should have a standard
I think that this thread has shown that there are interoperability issues. Given that this is a debugging tool, you really want it to have predictable behaviour so as not to waste time looking for a problem that in fact comes from the console API.
If I'm not mistaken, the only interoperability issue that was raised
is that the display of logging data at high frequency (using console.log)
has a delay which may cause it to show a newer representation of the memory slot
than was passed to console.log.
If there was a standard, I do not believe that it should forbid this buffering. Doing otherwise may greatly impact performance. Remember, this issue only happens on high frequency logging; having the logging block for immediate string conversion will make something that happens very often take a lot more time!
How much time? 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.
That being said, the standard shouldn't forbid blocking behavior either. If it can afford to be precise, let it be!
Right now, displaying data through console.log is "best effort".
In order to get better information, you should set a conditional breakpoint.
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.
On Wed, Feb 27, 2013 at 1:55 PM, François REMY < francois.remy.dev at 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 :)
The script engine does not relate to clicking on things -- that happens in a browser. So do you feel that script engines must ship with a console? Or does that apply to web browsers? And if so, why?
As Brian said, the UI itself should not be defined in the spec. However, I feel like the object-to-string behavior should be standardized so that any JS engine could be used reliably in a command-line environment (ie console.log outputs the same string in the console in all browsers/engines).
The browsers may still ship with a custom interface that wraps around the text APIs of console and that allows more fancy things, the point is that the basic functionalities should be interoperable.
Is an informative draft a fair start or does it need to be normative from the get-go?
I don't feel strongly about that, but there are informative standards already, maybe something normative would be better to reach standardization.
On Wed, Feb 27, 2013 at 7:55 PM, François REMY <francois.remy.dev at 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.
Immediate string conversion can still be costly (which is why Firefox and Safari use a cache). It is a matter of tradeoff. Paste this in the developer console:
(a=[], function() { for (var i=0 ; i<100000 ; i++) { a[0]=i;
console.log(a); } })()
When Chrome does console.log in a huge loop (which can happen by accident), the tab and the whole DevTools are unresponsive. When Firefox' DevTools does the same, you can interact with the page (and the rest of the DevTools) quite fine. (I'm running it in gmail right now, fwiw.) I tried to make something as fast in Firefox' JSTerm add-on, but it isn't as resilient.
The clickable behavior is an extension to the Console API (which is text-only). I agree that this part should not be standardized.
What subset of getfirebug.com/wiki/index.php/Console_API do
you wish to standardize? How would the standard require to process the following?
console.log('%cThis is red text on a green background', 'color:red; background-color:green');
Where do we draw the line? Can the standard compete with Firebug's ad hoc description, if it is but a subset?
Also, testing this standard is… hard.
However, IE has a console.clear() function that I find useful, it should probably be standardized.
That, too, is in getfirebug.com/wiki/index.php/Console_API.
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.
Best effort. That's the spirit.
Recently I read a post about Chrome adding a console.table API which mentioned some things in other browsers. My immediate reaction was "is this a new proposal for addition to console standard API, because that could be pretty handy actually" but then after a moments pause and about an hour search, I realized: There is no codified standard for console API. Turns out that public-browser-tools-testing at w3.org has sort of agreed to take it up, but it doesn't seem like anything much has happened yet and I'm wondering why that should be bound to anything with the browser since console is a pretty universal thing in implementations. Not saying it should or shouldn't be ECMA, just that it seems to be in the wrong place now if, indeed, anything is happening there.
So what does everybody think?
It seems that there is already a subset of what's implemented out there as a de-facto standard and could be some low-hanging fruit to create a base standard on which others could propose against, provide prollyfills for, etc - and that would be a pretty good thing IMO. Over the years, just a couple of anomalies in browsers have caused some pain - let's write it down somewhere :)