Why were CLIs typically light text on dark background, whereas GUIs typically use(d) dark text on light background?

My experience is that CLIs were typically shown with light text on a darker background. For example, the IBM PC would use white/light gray (depending on your point of view), amber or green (the latter two for monochrome monitors) on black unless the software did something to change that, and the Commodore 64 IIRC used white on blue, and the original Amiga Workbench used white on blue for the CLI.

Yet once GUIs started taking off, the typical color scheme seems to have been dark text on a light background. For example, even early versions of Microsoft Windows used black on white; apparently, so did GEOS on both the C64 and on the Apple II; as well as Digital Research's GEM. The Amiga soon switched to a black on grey color scheme. One major exception seems to have been Visi On using a white on black color scheme for much of the UI, including the bundled applications.

I do remember some time in the mid-1990s using a PC compatible which used black text on a white (or at least light) background for the MS-DOS CLI, and that really was the odd one out.

Why did early CLIs seemingly so predominantly use light on dark color schemes, and what drove the shift to GUIs using dark on light color schemes instead?

9 Answers
9

Why did early CLIs seemingly so predominantly use light on dark color schemes, and what drove the shift to GUIs using dark on light color schemes instead?

Simple: CRT technology (and, as so often, missing need to do otehrwise)

Early CRT technology was not able to deliver black on white. Further it was more important to make a readable display early on, than a paper like one – an idea that only became a topic many years later.

On a CRT the 'lightened' parts are the ones drawn by the electron gun. Writing the few strokes of a letter can be done with a beam whose focus is wider than a pixel, as the large dark areas will give a good contrast. In fact, this will even improve quality, as adjacent pixels will form a coherent line when spilling.

Changing between off and on and back didn't need to happen exactly at the border of a pixel and as instantly as possible. If ramping up voltage to draw a pixel left a blur, it didn't matter, as long as the sufficient intense part was at least as wide as a pixel and (hopefully) smaller than two of them. CRTs, CRT controllers and analogue parts in between got thus a rather low requirement for exact justification and maximum switch frequency. And that's what the emerging technology could deliver. As a result, all early screens were white (or whatever the light emitting surface was) on black.

Illuminating the 'background' to produce black on white, on the other hand, does need a way faster ramp up (and down) time for the electron cannon to allow sharp borders, as well as way more exact focusing, as now a lighted pixel should not spill over (which would have made the black letters unreadable), but at the same time no black gap between pixels should be visible/produced. Last but not least, the gun, as well as the power electronics for the CRT, need to be sufficient sized to supply a screen that is mostly while (*1).

One of the basic ideas of a GUI is the paper metaphor, presenting documents to the user that look as much as possible like the paper on his desk. And we're used to writing dark on white (or at least light coloured) paper. Thus the requirement for high quality screens came to satisfy this.

For a ~1980, GUI based workstation, the CRT did cost almost as much as the whole computer – but was necessary to provide an acceptable picture for daily professional use.

Screens sold for early desktop computers, from Apple II to the PC, were not really made to satisfy the needs – even if the computer could supply a 'sharp' image (high switching frequency), the CRT couldn't display it. Trying black on white (or green) on an Apple II with an early 80s '80 column' display was quite hurtful. This screenshot of Mousepaint on a contemporary CRT gives a hint. Similar to doing so on a MDA/Hercules PC. Sure, it could be done, just not acceptably for a professional environment (*2).

That's also the reason why not only Visi-On used a white on black output in their windowing, but also Apple for their GUI-ish programs on the Apple II (Mousetext). Heck, even Microsoft offered a (mostly) white on black screen layout for Windows. The colour pictures we get shown today were only that good on high end graphics cards and really good screens.

The default white on blue colour scheme for the Amiga was not at least due to the need to look good on affordable screens. Atari flunked out by using a specially designed b&w screen. It took some time until higher resolution CRT controllers, together with better screens, became available for mainstream computers.

... and no time in the world can change deep rooted habits, like wanting your CLI as white on black :))

*1 - I guess everyone remembers pumping screens when content changed - and worse, such with not enough 'light' to really fill large areas resulting in a sludgy grey in grey display.

*2 - No, just because we did endure it out of coolness doesn't mean it was acceptable.

From the Macintosh Folklore Site:

The Apple II displayed white text on a black background. I [Bill Atkinson] argued that
to do graphics properly we had to switch to a white background like
paper. It works fine to invert text when printing, but it would not
work for a photo to be printed in negative. The Lisa hardware team
complained the screen would flicker too much, and they would need
faster refresh with more expensive RAM to prevent smearing when
scrolling. Steve listened to all the pros and cons then sided with a
white background for the sake of graphics.

As white filled the screen (or green, or amber), any flicker became more obvious and annoying, and the inexpensive workarounds usually weren't much better. It was easier to just stick with white/green/amber letters on a black background. So black-on-white was an expense that wasn't justified in the era of the CLI but later became necessary for GUIs.

Since nearly all early computers used TV quality CRT screens, they suffered from phosphor burn in so the more you limited visible areas the longer your CRT would last. More expensive higher quality monitors had less of a problem but the price tag did not appeal to the mass market.

The early TV quality monitors had pronounced flicker and many video card refresh rates were slow enough to be seen. Using a black screen helped hide these deficiencies. When graphics became more popular the switch was mandatory. With the exception of Apple, the first white on black screens I saw where X11 terminals the latter part of 1980's.

I won't get into details of why white on black, as others have explained that this mostly due to limitations of CRT technology at the time.

One of the main reasons for the switch to black on white in GUIs, though, is skeuomorphism: GUIs (especially the early ones) tried very hard to emulate real-life, and have lots of things like folders, trash bins, and more that come from the original tools they're trying to replicate/replace, which obviously includes the existing (white) paper with (usually) black text printed on it.

One of the big keywords at the time was also WYSIWYG: What You See Is What You Get, which was the big difference with text-based interfaces available till then. You had actual fonts, sizes, styles, etc, and it should look the same on screen and when printed. That meant black on white.

Once you have most of the interface that is black on white (word processing windows, spreadsheets, technical drawings...), then it's quite natural that the rest of the GUI (menus, dialogs...) should be the same.

Of course there's a bit of a tendency to go back to white-on-black nowadays. Makes you look cool™.

The Raffzahn's answer perfectly desribed why white on black CLI was result of technical limitations, and better technology together with GUI went for black on white.

I would like say more about, why even now is CLI white on black.

The main aspect of GUI is, that it is designed mainly (mainly) for content consumers. The screen should look "nice" and many times there are tone-in-tone colors used

Look at this site:

Web pages, GUI tools and such today looks decent, professional and all (but some people with bad seeing have problems to read those so much decent shades), they also use the bonus of having 24-bits colors and would not fit to old 16, or 256 colors paletes as good.

All of it is mainly supposed to be processed by human eyes, so it prefere "niceness", knowing, that humans have extra strong "autocorrection ability" for reading, and that there is not problem, if some of similar characters (like .,;: or l1I|) looks nearly the same. Consumer will probably read the right version, even if actually wrong is used. The same goes for typos - many of them are just ignored or not recognized at first reading and it is not a problem - the right message will go thru anyway. Even if there are some elements to manipulate, they are typically big buttons or full words/phrases in different color (hyperlinks) and the consumer have just to choose from this selection offered and hit with mouse relatively big rectangle - somewhere.

And majority of text (if not all) is ment to be read fast, not preciselly deciphered to last character. Well, for exact copy there are Copy-Paste shortcuts, no need to make sure each character fits - just make sure, that the begin and end is right.

On the other hand CLI is maily used by programmers to be read by computer.

And computers do not have good autocorrection (and it would not be typically used in CLI commands/programs anyway, as the each character counts and using other, just visually similar, would probably make an error in the best case, unwanted (but legal) difference in worse case.

(Old good

rm -rf test *

shows how one more space give totally different and harmfull (but syntactically correct) effect. )

So CLI prefere exact results and correctness over nice look. And usually is even set to bigger font and syntax highliting and just few bright, distintive colors on black (or dark) background. All for making harder to any mistake slips. The small number of bright colors on black backgroud makes everything highlited to really stand out and be totally distinctive from any other kind of highlites.

Those texts are supposed to be correct to last character and to be deciphered and weighted with extra care.

At least me and every other programmer, who I know have its programming evironment set it similar high-contrast scheme, while "normal web pages" are in "nice, decent tone" at the same time.

The dark background makes the bright collors (white, magenta, red, cyan ...) stand out more, then white backgroud, or even "old sepia picture with hint of light blue here and light pink there" background, which is to be seen an many webpages.

The relative small number of colors (and only few cases of inverted background on the most critical spots) make it easier to distinguish exact meaning of such marked phrases, words or even single characters.

So the result for "darker gray on lighter gray" GUI and "bright on black" CLI is not only result of nostalgia, but also (and mainly) result of different use (reading vs. programming) and different targets (readers vs. computer programs)

BTW, if I remember correctly, than Spectrum BASIC was black on white (and bad readable too) as well as some other examples and lot of old BIOS screens. TurboPascal used Yellow on Blue for text and Black on White for menus in days, where Hercules cards was common here and lot of PCs had CGA graphic cards, just few had VGA one. So other approaches also existed in old good times :)

As soon as multi colour printers became available the WYSIWYG paradigm required the background to be white.

It was not possible to view white text and red borders that would later print as black text and red borders in a consumer market.

Typesetters had suffered with whatever was available for a long time and did not wait for WYSIWYG before using computer typesetting.

Well, they weren't. Command-line interpreters typically dealt in characters - they'd send a character to the output device, and the output device displayed it. This might be an inky mark on paper, or a pattern of lit-up phosphor dots.

So it really turns into asking why the display component of a terminal is light-on-dark, and to my way of thinking, it's "obviously" because the screen is naturally dark. The hardware would light up some dots corresponding to the character being drawn.

The new-fangled VT100 did have a dark chars on light background mode, but to my eyes, it looked much less crisp.

Exceptions:

Tandy CoCo / Dragon 32:

ZX Spectrum:

I wanted to reinforce jcaron's excellent answer pointing to skeumorphism with its specific origin: the first commercial desktop system to offer a graphical interface was the Xerox Star, and its development and design were tightly focused around the desktop metaphor, from folders for directories to sheets of paper for documents themselves. Indeed, there's an argument to be made that it was so effective in that regard that it served to 'lock in' the dominant metaphor for interacting with digital data for a generation and more. Apple's decision to xerox the Star's UI for their Lisa and then Macintosh UIs brought the metaphor into public prominence, and then Microsoft's own cloning put it on every desktop, further reinforcing that paradigm. And of course, as noted text printed on paper is for numerous reasons almost entirely black on white, so using the same visual style in the desktop metaphor was the natural choice.

Thanks for contributing an answer to Retrocomputing Stack Exchange!

But avoid …

To learn more, see our tips on writing great answers.

Required, but never shown

Required, but never shown

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.