There aren't really intense and faint palettes. The conventional indexed colour mapping has 16 "standard" colours in entries 0 to 15, but those aren't really anything to do with either bold or faint attributes. They are not even standard. ITU T.416 does not specify them.
There are only eight standard colours in ECMA-48, set by SGR 30 to 37 and 40 to 47. Some emulators substitute a colour modifier for boldface. But not all of them even do that, with several terminal emulators rendering boldface as actual boldface, meaning that that is not a route to a colour change in the first place. As for faint, my terminal emulator is one of the very few that even takes any notice at all of the faint attribute.
SGR 90 to 97 and 100 to 107 are not standardized by ECMA-48. They are an extension from aixterm.
Bold and intense are two completely different things in terms of SGR codes, so let's just strike bold from the conversation now.
The intence and faint codes are the same SGR ranges as the standard 8 colours but have their additional property encoded in their escape sequence (separated by a semi-colon, as is common with terminal escape sequences).
Arguements about whether it is standard or not aside (because there are dozens of standards and no terminal emulator follows any of those standards strictly anyway - instead picking and choosing parts from different standards based on whatever gets the best results the easiest), most terminals do support it. In fact faint and intense are more widely supported than the 8 bit and 24 bit SGR sequences. However if you're really going to get hung up on compatibility and standards then the only safe route is not to use colour at all.
You have the wrong model for how this works. SGR control sequences do not work this way.
There is no "additional property". The "additional property" is the very boldface and faint attribute that you erroneously want to "strike from the conversation". It is a standalone attribute, separate from the foreground/background colour setting. And as I said: Some, but not all, terminal emulators treat the bold attribute as a colour modifier, with several conversely now rendering it as true boldface, sometimes to the surprise of users; and the majority simply ignore the faint attribute completely.
And no, you don't get to set aside whether this is a standard, since you brought up the argument that there were "standard colour ANSI escapes" in the first place. (These are not ANSI, by the way. You have the wrong standards body, on the wrong continent.)
To which you then added this erroneous notion that there are "faint and intense palettes", based as we now see on an incorrect understanding of the ECMA-48 SGR control sequence.
No, not using colour is not the only safe route, as ECMA-48 standardizes eight colours with a mapping from ordinal to colour, the use of which is very safely within standard-defined areas. Indexed colour, standardized by ITU T.416, in contrast does not have a similar defined map for the various indices. The "standard 16 colours" in indices 0 to 15, so often talked about, are not in fact standardized.
And indexed colour control sequences properly use colon, not semi-colon, as a separator. Ironically, that is the way that "additional properties", more properly termed sub-parameters, are encoded in ECMA control sequences. You are not alone in making this mistake. It was widely made based upon samizdat, rather than reading the actual standards, and has some historical inertia behind it; although by my observations a fair number of terminal emulator authors have nowadays come around to supporting the proper, standard, mechanism. But you are nonetheless making another mistake.
No, there are not "dozens of standards". There's ECMA-48, ECMA-35, ITU T.416, the Unicode standard (for UTF-8), and the de facto standard of what the VT520 doco says about all of the DEC private stuff. One can nowadays get away with, as I and the mosh people do, not implementing any of the ECMA-35 8-bit character set switching mechanisms and ignoring that standard. The mosh people tout this as a feature. That leaves just four.
Nor are terminal emulator people flippant about them, as you claim, in my direct experience of dealing with them.
I've spent a great many hours of my life implementing terminal escape codes into various $SHELLs and $TERMs (and I don't mean some Electron crap), so I have read the specs and I'm not just making this stuff up nor talking purely from the perspective of throwing some colour in a personal CLI tool.
> There is no "additional property". The "additional property" is the very boldface and faint attribute that you erroneously want to "strike from the conversation".
I think you're more hung up on my wording than anything.
ESC[31m -- red
ESC[1;31m -- intense red
ESC[2;31m -- faint red
Granted you can make whole segments of colours bold or faint via:
ESC[1m -- bold
ESC[2m -- faint
However I was talking specifically about the former point rather than the latter but I'll concede that I was being pedantic on that particular point.
> And no, you don't get to set aside whether this is a standard, since you brought up the argument that there were "standard colour ANSI escapes" in the first place. (These are not ANSI, by the way. You have the wrong standards body, on the wrong continent.)
Again, you're arguing semantics rather than trying to understand the point I was making (maybe that was my fault for trying to discuss complex thing on a phone with a broken touch screen?). But in any case you later went on to reiterate my original arguments when you said devs should use 3/4 bit.
> No, not using colour is not the only safe route, as ECMA-48 standardizes eight colours with a mapping from ordinal to colour, the use of which is very safely within standard-defined areas.
Not all terms honour those SGR sequences. If portability is a concern then you cannot rely on colour - period.
However it's interesting to see you're basically reiterating my primary point now :)
> And indexed colour control sequences properly use colon, not semi-colon, as a separator.
Some do, some don't (as I demonstrated above). Semi-colon is more commonly used as a separator in terminal escape sequences though (not just with SGR codes either, I could list dozens of CSI sequences which use semi-colon as a separator).
Not all standards have been enshrined by a standards body but there are indeed multiple vendor specific standards and de facto standards as well. Working with vendor specific standards is "fun".
> Nor are terminal emulator people flippant about them, as you claim, in my direct experience of dealing with them.
Then I question you're experience because my direct experience has been that you cannot count on a $TERM following any specification to the letter (unless of course that specification was written for that term). This is a particularly potent problem when you start dealing with CSI and other sequences. Heck, $TERMs don't even agree on backspace all of the time (^? vs ^H) so god help them when it comes to anything more complex.
But I guess if it was as simple as you claim then termcap et al wouldn't be a thing ;)
There are only eight standard colours in ECMA-48, set by SGR 30 to 37 and 40 to 47. Some emulators substitute a colour modifier for boldface. But not all of them even do that, with several terminal emulators rendering boldface as actual boldface, meaning that that is not a route to a colour change in the first place. As for faint, my terminal emulator is one of the very few that even takes any notice at all of the faint attribute.
SGR 90 to 97 and 100 to 107 are not standardized by ECMA-48. They are an extension from aixterm.