| Date: | October 31, 2003 / year-entry #114 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20031031-00/?p=41983 |
| Comments: | 14 |
| Summary: | Often people will say, "Oh, we can highlight by inverting the color." This may have worked great on two-color black-and-white displays, but in the world of 32-bit color this no longer is effective. Consider the following picture. See if you can guess which one is inverted. One Two Answer: The one on the... |
Often people will say, "Oh, we can highlight by inverting the color." This may have worked great on two-color black-and-white displays, but in the world of 32-bit color this no longer is effective. Consider the following picture. See if you can guess which one is inverted.
Answer: The one on the right is inverted. The background color is gray, #808080. The box labelled "two" is highlighted by inversion. The inverse of #808080 is #7F7F7F, which is practically the same color. Even if your eyes happen to be good enough to spot the difference, it's still not a very obvious difference. |
Comments (14)
Comments are closed. |
So how *do* you choose a color if you are trying to do it programmatically – or do you just not ?
For those who do think they have eyesight good enough to see the difference, you should look at http://www.optillusions.com/dp/1-67.htm …
Wouldn’t the truly inverted text have white text at least, and provide at least a slight indication to the user?
The words "one" and "two" are just labels and not part of the diagram. (I should have put them below the boxes instead of inside them. Bad diagram.) Imagine the user selected a region of the screen in order to do something to it: Crop, change brightness, etc.
As for which color to use – go ahead and choose a color but make sure to build contrast into it. For example alpha-blend with the user’s highlight color COLOR_HIGHLIGHT but put an opaque border of COLOR_HIGHLIGHTTEXT around it so it it stands out even if the region being highlighted happens to match the COLOR_HIGHLIGHT.
I guess that is the same as in a previous version of MS Word. When you had the mousecursor next to the page in the grey area, you didn’t saw the cursor!
When you have an area on the screen all in #808080, you *so* want to change its brightness! :)
Seriously, though … another reason why inverting for selection is a bad idea is demonstrated well by the Opera browser. If the text has the same colour as the background (and is thus invisible), selecting the text makes it visible in all other browsers, but not Opera because inversion preserves this invisibility. (There are cases where such invisible text is legitimate, such as solutions to a puzzle, where selecting the text is a means of revealing the solution.)
I wouldn’t exactly call that legitimate. It’s more of a hack around constraints. The same sort of hack that leads Raymond to pulling his hair out trying to work around a "badly behaving application" because it used undocumented API’s believing them to be a legitimate use.
My favorite graphics editing package uses colour inversion to show the position of the carat when adding text. On a grey background near #808080 editing or positioning text can become a really frustrating experience.
It doesn’t matter how good your eyesight is, you can never tell which one is inverted.
Say you had a white box and a black box. Now, is the white box an inversion of the black, or the black and inversion of the white? No way to tell! ;)
Actually, it is a question of why coloring anything gray is a bad idea :)
Concerning spoilers, white on white is not really an elegant solution. What would be interesting is a collapse/expand section, like a <span> that toggles its second child’s style between display: inline and display: none. Alas, it cannot be done in pure standard HTML+CSS, without resorting to client-side scripting.
The solution may be:
1. If the color is close to #808080, use white or black.
2. Otherwise, invert.
Or that the difference between the inverted color and the original is greater than some minimum threshold.
But anyway, total reliance on colors is a bad idea, since invariably you’ll run into problems with people with poor eyesight or people who are color-blind. Colors should provide visual hints, but they shouldn’t be a necessity.
highlightVal = (inputVal + 128) % 255;
(Assuming 0-255, and appropriate head-room).
It’s really quite workable, and produces predictable, though not continuous, results.
Well, do you know and remember PopPad example from
Petzold? While playing with it, I combined few other
Petzold examples into it and finally I had PopPad with a
Background menu and my own custom Caret cursor.
The point is when I change the background color
of edit control to black (and color of text to amber, ha, ha)
my caret cursor disappears. Is there a problem with my
cursor resource or should I change the code, like add
inverted version of caret cursor to my app or something
else?