Re: Standardizing console APIs: Where?

On Feb 25, 2013 10:02 AM, "Clint Hill" <clint.hill@gmail.com> wrote:
>
> I would argue that there has been developer pain with console in
> particular. I provide IE 8 & 9 as clear examples of the console host
> object being inconveniently non-standardized.
>
>
> On 2/25/13 7:54 AM, "Marcos Caceres" <w3c@marcosc.com> wrote:
>
> >
> >
> >
> >On Monday, 25 February 2013 at 14:47, Robin Berjon wrote:
> >
> >> To reinforce what Marcos was saying: this isn't about not doing it.
> >> We're simply asking the question of whether it's worth spending time
on.
> >>
> >> Building a standard is expensive. A lot of the time, that cost is small
> >> compared to the savings it brings to developers (and users, but that's
> >> less obvious here) and so we just do it. But here, a few of us are
> >> wondering if there really is that much pain on the developer side.
> >>
> >> I've never noticed much in the way of problems with the console API,
but
> >> I'll readily admit that I'm quite unsophisticated in my usage of it,
and
> >> while I use it every day it's pretty much just for console.log().
> >>
> >> If there's a clear case of developer pain (as opposed to making a
> >> standard because it's neater) then I'm certainly happy to see it
happen.
> >>
> >> If that happens, I don't know if TC39 wants it or not, but in case it's
> >> rather not then I can think of at least two groups in W3C that we could
> >> likely bring this work to speedily (i.e. without having to worry about
> >> chartering and such issues).
> >
> >I'll add that if this is about authoritative access to developer
> >documentation, then this should be done on webplatform.org. That's now
> >the authoritative place to document the Web platform for developers,
> >AFAIK.
> >
> >_However_, if evidence of interoperability issues can be presented, and
> >those are causing developer pain, then that makes for a stronger case for
> >standardisation.
> >
> >--
> >Marcos Caceres
> >http://datadriven.com.au
> >
> >
> >
> >
> >
>
>
If we are talking ecma beyond browsers, other engines are much more sparse
in implementation as noted in my strawman.