Why highlighting by inverting colors is a bad idea

Date:October 31, 2003 / year-entry #114
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.

One Two

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)
  1. Ross says:

    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

  2. Kevin says:

    Wouldn’t the truly inverted text have white text at least, and provide at least a slight indication to the user?

  3. Raymond Chen says:

    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.

  4. Tjipke says:

    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!

  5. Timwi says:

    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.)

  6. Anonymous says:

    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.

  7. Anonymous says:

    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.

  8. Shane King says:

    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! ;)

  9. Centaur says:

    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.

  10. TLKH says:

    The solution may be:
    1. If the color is close to #808080, use white or black.
    2. Otherwise, invert.

  11. James says:

    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.

  12. chaboud says:

    highlightVal = (inputVal + 128) % 255;

    (Assuming 0-255, and appropriate head-room).

    It’s really quite workable, and produces predictable, though not continuous, results.

  13. Delf says:

    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

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index