whatwg / console

Console Standard
https://console.spec.whatwg.org/
Other
269 stars 67 forks source link

Handling of ANSI escape codes #197

Open nchevobbe opened 3 years ago

nchevobbe commented 3 years ago

A bug was filed recently about support for ANSI color codes in console.log in Firefox (Bug 1720116) where the reporter mentioned Chrome supporting ANSI color codes in console.log parameters.

For example the following call:

console.log(`\u001B[31mThis will be a red string in Chrome`);

will be rendered in red in Chrome (and Node I think), but not in Firefox nor Safari.

I took a look at the spec and I don't think there's anything about ANSI codes (sorry if I missed it). It would be particularly interesting to define how those should play with %c. At the moment Chrome seems to treat them as another "style block" as in the following snippet

console.log("%cHello \u001B[31mRED", "background-color: yellow")

Hello does have a yellow background, but RED does not.

terinjokes commented 3 years ago

This is news to me.

It would be particularly interesting to define how those should play with %c.

This is where I have concerns with supporting this, especially while %c remains unspecified. The CSS supported by %c may be far wider than terminal escapes (including font faces and sizes). Should \u001B[0m reset to the previous styles set by %c? Or should it reset back to the normal console log styles, or perhaps only those equivalent to ones a terminal know about?

bmeurer commented 2 years ago

Chromium DevTools did indeed support ANSI color codes, but not very well until recently. I've recently started to take inventory of what would be a reasonable subset to support for us (design doc) based on what's implemented in popular NPM libraries. We currently treat these ANSI escape sequences exactly like a %c style block, and I think that does indeed make a lot of sense.

TBH I do think that the use cases for %c and ANSI color codes are quite distinct and we could even expect not to see mixes of both in the vast majority of cases. It seems that ANSI color codes are most popular in CLI environments (for obvious reasons) and it's important for Web browser to offer some rudimentary level of interoperability.

So from my end, I'd be very much in favor of adding ANSI color codes to the standard, so that full-stack developers can rely on them to work in both worlds. The design doc calls out a reasonable subset of CSI SGR parameters to support.

domfarolino commented 2 years ago

Yeah, the clashing between the ANSI codes and %c is also what I'm a little concerned with about, but it certainly doesn't seem insurmountable. As demonstrated:

I didn't get a chance to check Node, but I'm not even sure if it supports %c at all?

In any case, spec'ing these as style blocks feels like the most predictable solution. Unfortunately I do not have enough time to be able to spec this myself, @bmeurer is there any chance you'd be up for contributing? Although seeing as how underspecified %c is today, maybe the step here is just adding another sad TODO box for handling the ANSI codes, and listing which ones are supported, assuming there is some cross-impl agreement on that list.

adderek commented 9 months ago

I believe that color coding depends much on the OUTPUT used (actual concrete implementation of the console and the display target). Most likely the escape is processed not by the console but rather the terminal or display window.

You could use \u001B[31mRED but also \u001B[38;5;9mRED (8-bit color) or \u001B[38;2;255;0;0mRED (24bpp true color). In addition there is underline, overline, double underline, curly underline, bolded, blink (fast or slow) and many other ANSI escape codes. Whether those could be used or not - it depends on the terminal capabilities. When injecting sequences you cannot be sure those are supported. Then only thing you could use is console.log('%cRED', 'color:red'); (though I am not a fan of the % characters formatting).