Classes instead of colours? about ansi-to-html

[amatiasq]

Actually I don't have this issue no more, used your code as base for a new ANSI parser using CSS classes, I just leave it here because it may be an improvement to your project.

I used

• ansi-fg-default
• ansi-bg-default
• ansi-fg-<color>
• ansi-bg-<color>
• ansi-underline
• ansi-inverse
• ansi-italics
• ansi-strike
• ansi-bold

@blainesch Here is the CSS I used, if you look at it you'll see it doesn't add that much complexity and adds a lot of flexibility

[rburns]

I'd be open to patches for something like that, an optional classes key in the options object that provides some mapping between ansi codes and classes, which would be used in place of a style attribute if present.

or did you have something a little different in mind?

[amatiasq]

Sounds good, I tried to patch it but I'm having troubles understanding the code ^_^U
Anyway I won't flag it as prioritary I just wanted to know if it was already implemented :)

[bayleedev]

What's the advantage of classes added to compiled html? It seems like it would add unnecessary complexity for no real benefit.

With css3 you could target these and overwrite the styling, if that's what you're aiming for.

[amatiasq]

For clearness, setting the styles to a given class is simpler, clearer and maintainable that this

http://jsfiddle.net/gLgp447s/5/

Selecting an element because of a property inside an attribute is a bad pattern for this reasons:

• you need a expensive selector [name*=value] to catch elements with other properties
• you can catch unexpected elements with the same properties
• you need to use !important
• it's more expensive that just a class selector
• the property may be defined in many ways depending on the browser (whitespaces, property value format...)
• you are forcing the library to use always the same format to style elements, if the library want's to use red or #FF000 or #f00 instead of #F00 you code won't work anymore, that's coupling.
• It's not easy to select elements with more that one property, for example .foreground-red.bold.
• the resulting CSS is a lot harder to read
• not old browsers support, you may go evergreen but if we have two options and one supports old browsers and the other doesn't I don't see why to pick the most restricted one.
• with classes you can know when the ANSI style is inverted just checking for the class

[rburns]

Would color-xxxxxx style classes work for denoting colors? I can't see using color names as working in all cases. Unless there's a standard list somewhere I've not yet found.

[bayleedev]

@amatiasq I didn't think the css would add complexity, but making the app use classes instead of colors would. Knowing if it already submitted the css or not, etc. It's all the same to me though.

[Redsandro]

This in yet? I'm looking for something like this, class-based.

Classes over colors has many benefits, theme-ability and easily matched with other projects that use css e.g. CodeMirror. Servers that serve ANSI-logs in HTML streams. Hardcoded colors are the opposite of versatile.

[TakenPilot]

There are 256 different colors that are possible from an ANSI colored terminal, and adding 256 classes probably isn't very elegant.

Not only that, but the classes wouldn't represent anything except for those colors. That is, the programs that are generating the colors are assuming they're printing to the screen in those specific colors, so changing them to something completely different might create undefined behavior.

I think it would be better to have direct access to the color map itself, so we could transform the palette as a whole.

For example, globally darkening or globally lightening all the colors is very useful. Or warping the palette to have a slightly yellow or blueish hue.

[amatiasq]

@TakenPilot The program may say a "light green" but "light green" is not the same on white background than in black background.

Most terminals have dark background and some people use green as foreground and default Mac terminal has white background.

That was my case, I had a requirement for the user to choose between white and black background and some colors were just too hard to read so I wanted to tune it a little bit for readability.

In that case having the colors hardcoded let me no choice but to build my own ANSI parser. With classes I could just create two "themes".

Also with hardcoded colors it's not possible to know when the program asked for inversed (a.k.a. negative) colors. With classes it's quite automatic.

.ansi-fg-default { color: white; }
.ansi-fg-green { color: green; }
.ansi-bg-default { background-color: black; }
.ansi-bg-red { background-color: red; }

.ansi-negative .ansi-fg-default { background-color: white; }
.ansi-negative .ansi-fg-green { background-color: green; }
.ansi-negative .ansi-bg-default { color: black; }
.ansi-negative .ansi-bg-red { color: red; }

And finally with classes we can actually add behavior on top of the colors for example:

.ansi-bold:hover {
  transform: scale(1.2) rotate(20deg);
}

[TakenPilot]

For the color example, I'm really worried about trying to theme all 256 colors available in ANSI with classes. That seems like something that should be a data structure instead. Also, using classes would mean you'd need twice as many (512 classes) because you need the foreground and the background color changes.

Having 2 or more themes with all of those color classes defined, and then maintaining all of those colors, seems like a scary exercise in data entry.

.ansi-fg-0 { color: #000; }
/* ..the rest of the foreground colors, lots of typing... */
.ansi-fg-255 { color: #FFF; }

.ansi-bg-0 { background-color: #000; }
/* ..the rest of the background colors, lots of typing... */
.ansi-bg-255 { background-color: #FFF; }

And for the bold example, this might make more sense anyway:

.ansi-terminal b:hover {
  transform: scale(1.2) rotate(20deg);
}

I think I'd rather have something that I can write a for loop over, like a palette where I can make all the colors slightly brighter, or give all the colors a yellow tint, for example.