Some of these signals are "active low," which are traditionally written with a overbar over the signal name.
That is just one convention. There are many more, and they are as well traditional ones. even in fact more traditional than an overbar. Using an overbar in traditional documentation was only possible when typeseted. Or added manually when it got printed by photographic means.
Currently the best alternative convention supported here (which I'm using where I can) is to use a slash before the signal name, e.g., /CS for active-low chip select.
Which is exactly the way such a signal is named in classic documentation or (most) tools using textual input (like PALASM).
But that runs into problems for signals that already have a slash in them, such as "read/not-write" where R//W is not really clear that one slash separates the two components and the second slash is negating the second component.
Well, only if the slash is interpreted as 'or'. But the signal is not the combination of two signals at different times, but two meanings when used. It's therefore not named "Read or Write" but reads correctly "R (not W)", or short is R/W. Adding here an overbar is just stating the obvious. If at all, the signal must be written RW with an overbar only above the W (RW̅)
Having said that, there are systems where different signals are transported over the same line at different situations. A good example would be the 8086es /RQ, /GT0 (on pin 31), which transports different signal at different times during a bus request cycle. It's a bidirectional line in addition. They are two independant signals and either signal is active-low. The name is often a concatenation of both for a pinout, but thurout all documentation described seperate. For a clear naming, this line should have had it's own name, but Intel went with a list - and using
/ as list seperator.
This 8086 pin is even more revealing, as in Minimum mode it becomes the active-high signal HOLD :)) Something that again gets handled during documentation seperate and marked on pinouts in many different ways.
Facit, as soon as something gets more sophisticated, notation isn't as clear anyway.
And then there is the even more important issue of copying text, which usually looses most of such eye candy, much depending on the readers system and the target application. While some charset based games may work out to some degree, everything HTML will result in a complete loss of information, even screwing it up big time (*1)
Bottom line: If we want to get readable and long time stable (*2) questions and answers it's best to stay with basic 7 bit encoding and well proven notations within this codeset. Adding eye candy is adding another point of failure.
*1 - Like 27 (2<SUP>7</SUP>) ending up as 27 ... doesn't look right, does it?
*2 - I don't think anyone can predict waht future environments will do with all these 'tricks' - just remember what features have already droped out of HTML (and SUP is one of the things they always want to get rid of, as it describes rendering, not content and rendering is meant to be done by CSS - right?)