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

Re: Standardizing console APIs: Where?

From: Robin Berjon <robin@w3.org>
Date: Wed, 27 Feb 2013 11:35:46 +0100
Message-ID: <512DE182.70404@w3.org>
To: Brian Kardell <bkardell@gmail.com>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
On 26/02/2013 23:06 , Brian Kardell wrote:
> 1. 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.

> 2. 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.

> 3. 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.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Wednesday, 27 February 2013 10:35:55 UTC

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