Markup for Overbars

Question

In answers such as this and this I mention signals on chip pins and buses. Some of these signals are "active low," which are traditionally written with a overbar over the signal name. I'd like to be able to do that here.

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. 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. Being able to write this as R/W with an overbar over the W would be a lot more clear.

This would also be handy on various other SE sites. Some SE sites, such as the EE StackExchange, allow LaTeX/math markup, which offers a way of doing this, but the markup is pretty awkward ($\small \overline{\text{CS}}\$). (Other sites where signal names are likely to be used are the Arduino and Raspberry Pi exchanges.)

There's easy HTML markup for an overbar: <span style=text-decoration:overline>CS</span> so I don't think that there's any issue on the display side, but there is the question of how to mark it up in the editor. What would it take to add this?

Answer 1

You can sort of do this with the following HTML markup:

C̅S̅

This renders like so:

C̅S̅

It doesn't really work on every browser (e.g. it completely fails on most Androids, and it displays funny on my machine) but it's perhaps the best we can do without MathJax. (A custom markup is almost certainly out of the question, but I haven't asked about it yet.)

This isn't enough on its own to justify getting MathJax, since it slows down the loading of every page and the rendering of many. However, these things build up, and we might've become a technical enough site to justify it now. Post another question with reasons and, if the rest of the community agrees, we can use that justification to convince SO to add it.

Answer 2

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 2⁷ (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?)