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

Re: Standardizing console APIs: Where?

From: Alex Russell <slightlyoff@google.com>
Date: Wed, 27 Feb 2013 08:36:54 +0000
Message-ID: <CANr5HFUcbgBrZgqYmCRn70AsmqKqH3nX7+U+GzLLgHRhe93ebw@mail.gmail.com>
To: "Mark S. Miller" <erights@google.com>
Cc: Domenic Denicola <domenic@domenicdenicola.com>, Marcos Caceres <w3c@marcosc.com>, Brian Kardell <bkardell@gmail.com>, "Hill, Clint" <clint.hill@goaaa.com>, Jorge Chamorro <jorge@jorgechamorro.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
I would also like to see this added to ES, likely for ES7.
On Feb 27, 2013 12:43 AM, "Mark S. Miller" <erights@google.com> wrote:

> On Tue, Feb 26, 2013 at 2:06 PM, Brian Kardell <bkardell@gmail.com> wrote:
>
>> It seems that I may have mixed a few assumptions from side conversations
>> on twitter/chat and been less clear than I could have been.
>>
>> My question here was really a few fold:
>>
>> 1. Does anyone else feel like we _should_ have a standard
>>
>
> I feel strongly that console should be standardized.
>
>
>
>> 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 agree.
>
>
>
>> 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
>>
>> Those are my merely opinions and rationale - I am happy to be wrong on
>> any of them :)
>>
>
> Both could work. My first reaction is that it makes more sense to propose
> this for ES7, rather than create a separate track. But I don't have any
> strong basis for this. It does meet the same enabling criteria as i18n: It
> is largely orthogonal from the rest of ES7 and so need not be synchronized
> with it.
>
>
>
>
>>
>> -Brian
>>
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
Received on Wednesday, 27 February 2013 08:37:23 UTC

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