Why were CLIs typically light text on dark background, whereas GUIs typically use(d) dark text on light background?
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
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?
history video
add a comment |Â
up vote
3
down vote
favorite
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?
history video
Not a full answer, but the resolution of early computers did not support a good looking white background, i.e. there were too many gaps between the scanlines. Also, the desire for WYSIWIG to represent printed black ink on white paper drove GUIs to adopt dark on light color schemes.
â Glen Yates
1 hour ago
1
I have no authoritative source on this but my view of it has always been that light on dark was simulating the âÂÂgreen screenâ terminal look, and the dark on white of GUIs was simulating print/writing on paper.
â mannaggia
1 hour ago
1
The Sinclair range of computers (except the QL, maybe, that opened both types of CLIs) all had consoles black on white. You could, however, re-solder a jumper wire on the ZX-80 to invert the screen.
â tofro
1 hour ago
This doesnâÂÂt provide a general explanation, but ISTR the original CGA having issues when blanking with a non-black background...
â Stephen Kitt
1 hour ago
1
Oric Atmos and Dragon 32 had black-on-white (the latter black on light green) defaults
â tofro
1 hour ago
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
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?
history video
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?
history video
history video
asked 1 hour ago
Michael Kjörling
1,027623
1,027623
Not a full answer, but the resolution of early computers did not support a good looking white background, i.e. there were too many gaps between the scanlines. Also, the desire for WYSIWIG to represent printed black ink on white paper drove GUIs to adopt dark on light color schemes.
â Glen Yates
1 hour ago
1
I have no authoritative source on this but my view of it has always been that light on dark was simulating the âÂÂgreen screenâ terminal look, and the dark on white of GUIs was simulating print/writing on paper.
â mannaggia
1 hour ago
1
The Sinclair range of computers (except the QL, maybe, that opened both types of CLIs) all had consoles black on white. You could, however, re-solder a jumper wire on the ZX-80 to invert the screen.
â tofro
1 hour ago
This doesnâÂÂt provide a general explanation, but ISTR the original CGA having issues when blanking with a non-black background...
â Stephen Kitt
1 hour ago
1
Oric Atmos and Dragon 32 had black-on-white (the latter black on light green) defaults
â tofro
1 hour ago
add a comment |Â
Not a full answer, but the resolution of early computers did not support a good looking white background, i.e. there were too many gaps between the scanlines. Also, the desire for WYSIWIG to represent printed black ink on white paper drove GUIs to adopt dark on light color schemes.
â Glen Yates
1 hour ago
1
I have no authoritative source on this but my view of it has always been that light on dark was simulating the âÂÂgreen screenâ terminal look, and the dark on white of GUIs was simulating print/writing on paper.
â mannaggia
1 hour ago
1
The Sinclair range of computers (except the QL, maybe, that opened both types of CLIs) all had consoles black on white. You could, however, re-solder a jumper wire on the ZX-80 to invert the screen.
â tofro
1 hour ago
This doesnâÂÂt provide a general explanation, but ISTR the original CGA having issues when blanking with a non-black background...
â Stephen Kitt
1 hour ago
1
Oric Atmos and Dragon 32 had black-on-white (the latter black on light green) defaults
â tofro
1 hour ago
Not a full answer, but the resolution of early computers did not support a good looking white background, i.e. there were too many gaps between the scanlines. Also, the desire for WYSIWIG to represent printed black ink on white paper drove GUIs to adopt dark on light color schemes.
â Glen Yates
1 hour ago
Not a full answer, but the resolution of early computers did not support a good looking white background, i.e. there were too many gaps between the scanlines. Also, the desire for WYSIWIG to represent printed black ink on white paper drove GUIs to adopt dark on light color schemes.
â Glen Yates
1 hour ago
1
1
I have no authoritative source on this but my view of it has always been that light on dark was simulating the âÂÂgreen screenâ terminal look, and the dark on white of GUIs was simulating print/writing on paper.
â mannaggia
1 hour ago
I have no authoritative source on this but my view of it has always been that light on dark was simulating the âÂÂgreen screenâ terminal look, and the dark on white of GUIs was simulating print/writing on paper.
â mannaggia
1 hour ago
1
1
The Sinclair range of computers (except the QL, maybe, that opened both types of CLIs) all had consoles black on white. You could, however, re-solder a jumper wire on the ZX-80 to invert the screen.
â tofro
1 hour ago
The Sinclair range of computers (except the QL, maybe, that opened both types of CLIs) all had consoles black on white. You could, however, re-solder a jumper wire on the ZX-80 to invert the screen.
â tofro
1 hour ago
This doesnâÂÂt provide a general explanation, but ISTR the original CGA having issues when blanking with a non-black background...
â Stephen Kitt
1 hour ago
This doesnâÂÂt provide a general explanation, but ISTR the original CGA having issues when blanking with a non-black background...
â Stephen Kitt
1 hour ago
1
1
Oric Atmos and Dragon 32 had black-on-white (the latter black on light green) defaults
â tofro
1 hour ago
Oric Atmos and Dragon 32 had black-on-white (the latter black on light green) defaults
â tofro
1 hour ago
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
4
down vote
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 missing need)
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 â an idea that only became a topic may 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 pixel 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 instant as possible. If ramping up voltage to draw a pixel left a blur 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 where white (ore 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 a 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 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's used to write 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, where not really made to satisfy the needs â even if the computer could supply a 'sharp' (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 doing so on a MDA/Hercules PC. Sure, it could be done, just not acceptable 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 where only that good on high end graphics cards and real good screens.
The default white on blue colour scheme for the Amiga was not at least due 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.
*1 - I guess everyone remembers pumping screen when changing content - and worse, such with not enough 'light' to realy fill large areas.
*2 - No, just because we did endure it out of coolness doesn't mean it was acceptable.
To amplify your earlier point: if a CRT goes from 5% to 75% when drawing the vertical portions of a character, but manages to go from 5% to 100% for the horizontal portions, the contrast for the vertical part will be 15:1 versus 20:1 for the horizontal parts. Not wonderfully even, but not horrible. If the CRT goes from 100% to 25% for the vertical parts at 100% to 5% for the horizontal ones, then the contrast would be only 4:1 for the vertical parts vs. 20:1 for the horizontal parts. Much worse.
â supercat
1 hour ago
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
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 missing need)
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 â an idea that only became a topic may 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 pixel 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 instant as possible. If ramping up voltage to draw a pixel left a blur 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 where white (ore 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 a 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 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's used to write 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, where not really made to satisfy the needs â even if the computer could supply a 'sharp' (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 doing so on a MDA/Hercules PC. Sure, it could be done, just not acceptable 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 where only that good on high end graphics cards and real good screens.
The default white on blue colour scheme for the Amiga was not at least due 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.
*1 - I guess everyone remembers pumping screen when changing content - and worse, such with not enough 'light' to realy fill large areas.
*2 - No, just because we did endure it out of coolness doesn't mean it was acceptable.
To amplify your earlier point: if a CRT goes from 5% to 75% when drawing the vertical portions of a character, but manages to go from 5% to 100% for the horizontal portions, the contrast for the vertical part will be 15:1 versus 20:1 for the horizontal parts. Not wonderfully even, but not horrible. If the CRT goes from 100% to 25% for the vertical parts at 100% to 5% for the horizontal ones, then the contrast would be only 4:1 for the vertical parts vs. 20:1 for the horizontal parts. Much worse.
â supercat
1 hour ago
add a comment |Â
up vote
4
down vote
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 missing need)
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 â an idea that only became a topic may 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 pixel 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 instant as possible. If ramping up voltage to draw a pixel left a blur 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 where white (ore 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 a 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 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's used to write 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, where not really made to satisfy the needs â even if the computer could supply a 'sharp' (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 doing so on a MDA/Hercules PC. Sure, it could be done, just not acceptable 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 where only that good on high end graphics cards and real good screens.
The default white on blue colour scheme for the Amiga was not at least due 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.
*1 - I guess everyone remembers pumping screen when changing content - and worse, such with not enough 'light' to realy fill large areas.
*2 - No, just because we did endure it out of coolness doesn't mean it was acceptable.
To amplify your earlier point: if a CRT goes from 5% to 75% when drawing the vertical portions of a character, but manages to go from 5% to 100% for the horizontal portions, the contrast for the vertical part will be 15:1 versus 20:1 for the horizontal parts. Not wonderfully even, but not horrible. If the CRT goes from 100% to 25% for the vertical parts at 100% to 5% for the horizontal ones, then the contrast would be only 4:1 for the vertical parts vs. 20:1 for the horizontal parts. Much worse.
â supercat
1 hour ago
add a comment |Â
up vote
4
down vote
up vote
4
down vote
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 missing need)
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 â an idea that only became a topic may 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 pixel 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 instant as possible. If ramping up voltage to draw a pixel left a blur 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 where white (ore 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 a 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 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's used to write 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, where not really made to satisfy the needs â even if the computer could supply a 'sharp' (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 doing so on a MDA/Hercules PC. Sure, it could be done, just not acceptable 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 where only that good on high end graphics cards and real good screens.
The default white on blue colour scheme for the Amiga was not at least due 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.
*1 - I guess everyone remembers pumping screen when changing content - and worse, such with not enough 'light' to realy fill large areas.
*2 - No, just because we did endure it out of coolness doesn't mean it was acceptable.
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 missing need)
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 â an idea that only became a topic may 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 pixel 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 instant as possible. If ramping up voltage to draw a pixel left a blur 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 where white (ore 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 a 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 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's used to write 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, where not really made to satisfy the needs â even if the computer could supply a 'sharp' (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 doing so on a MDA/Hercules PC. Sure, it could be done, just not acceptable 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 where only that good on high end graphics cards and real good screens.
The default white on blue colour scheme for the Amiga was not at least due 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.
*1 - I guess everyone remembers pumping screen when changing content - and worse, such with not enough 'light' to realy fill large areas.
*2 - No, just because we did endure it out of coolness doesn't mean it was acceptable.
edited 39 mins ago
LangLangC
11316
11316
answered 1 hour ago
Raffzahn
33.3k474132
33.3k474132
To amplify your earlier point: if a CRT goes from 5% to 75% when drawing the vertical portions of a character, but manages to go from 5% to 100% for the horizontal portions, the contrast for the vertical part will be 15:1 versus 20:1 for the horizontal parts. Not wonderfully even, but not horrible. If the CRT goes from 100% to 25% for the vertical parts at 100% to 5% for the horizontal ones, then the contrast would be only 4:1 for the vertical parts vs. 20:1 for the horizontal parts. Much worse.
â supercat
1 hour ago
add a comment |Â
To amplify your earlier point: if a CRT goes from 5% to 75% when drawing the vertical portions of a character, but manages to go from 5% to 100% for the horizontal portions, the contrast for the vertical part will be 15:1 versus 20:1 for the horizontal parts. Not wonderfully even, but not horrible. If the CRT goes from 100% to 25% for the vertical parts at 100% to 5% for the horizontal ones, then the contrast would be only 4:1 for the vertical parts vs. 20:1 for the horizontal parts. Much worse.
â supercat
1 hour ago
To amplify your earlier point: if a CRT goes from 5% to 75% when drawing the vertical portions of a character, but manages to go from 5% to 100% for the horizontal portions, the contrast for the vertical part will be 15:1 versus 20:1 for the horizontal parts. Not wonderfully even, but not horrible. If the CRT goes from 100% to 25% for the vertical parts at 100% to 5% for the horizontal ones, then the contrast would be only 4:1 for the vertical parts vs. 20:1 for the horizontal parts. Much worse.
â supercat
1 hour ago
To amplify your earlier point: if a CRT goes from 5% to 75% when drawing the vertical portions of a character, but manages to go from 5% to 100% for the horizontal portions, the contrast for the vertical part will be 15:1 versus 20:1 for the horizontal parts. Not wonderfully even, but not horrible. If the CRT goes from 100% to 25% for the vertical parts at 100% to 5% for the horizontal ones, then the contrast would be only 4:1 for the vertical parts vs. 20:1 for the horizontal parts. Much worse.
â supercat
1 hour ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f7583%2fwhy-were-clis-typically-light-text-on-dark-background-whereas-guis-typically-us%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Not a full answer, but the resolution of early computers did not support a good looking white background, i.e. there were too many gaps between the scanlines. Also, the desire for WYSIWIG to represent printed black ink on white paper drove GUIs to adopt dark on light color schemes.
â Glen Yates
1 hour ago
1
I have no authoritative source on this but my view of it has always been that light on dark was simulating the âÂÂgreen screenâ terminal look, and the dark on white of GUIs was simulating print/writing on paper.
â mannaggia
1 hour ago
1
The Sinclair range of computers (except the QL, maybe, that opened both types of CLIs) all had consoles black on white. You could, however, re-solder a jumper wire on the ZX-80 to invert the screen.
â tofro
1 hour ago
This doesnâÂÂt provide a general explanation, but ISTR the original CGA having issues when blanking with a non-black background...
â Stephen Kitt
1 hour ago
1
Oric Atmos and Dragon 32 had black-on-white (the latter black on light green) defaults
â tofro
1 hour ago