The Mac survived because it was the first thorough attempt in a low-cost computer to accomplish WYSIWYG. Sales soared when the Desktop Publishing Revolution came, and designers could see pages on their displays which were very close in appearance to those that would emerge from the printers. Gone was that horrendous experience when you discovered that page proofs of your twenty-page brochure were actually twenty-two pages redesigned by a gremlin.

Without WYSIWYG, macOS would be long dead, and it’s still at the core of every user’s assumptions about what they see on screen. We’ve survived HTML font substitution and other attempts to shatter the illusion, but when it comes down to it, we expect high fidelity.

Dark Mode has been a challenge to this, and it’s a challenge which Apple still hasn’t addressed properly. Those of us who work fairly constantly in Dark Mode have come to understand that white is black and the reverse when working with text, but we continue to rely on colour. Any image editor which inverted its colours or their lightness values just because you switched from one Mode to the other would be laughed out of court. Yet that’s pretty well what Apple’s standard rich text editor does, and without your even having to change Mode.

To experience this, switch to Dark Mode, open TextEdit in Mojave 10.14.6, and enable its dark window background (View menu, Use Dark Background for Windows ticked). Find some nice solid characters in the Emoji & Symbols pane, and make a rectangle of them in your document. Select them all, and change their colour to a deep purple, in the row next to the top of the colour table.

Then untick that menu command to use a regular white window background. What happens to the colours in your document?

Yes, they change from dark purple to light lilac. And so they remain in Light Mode, where the option for a dark window background is removed altogether from TextEdit’s menu.

A little experimentation demonstrates that, rather than TextEdit using the colour you selected, it chose the light lilac instead, but just to fool you, when a dark background is enabled, it changed the display colour to what you thought you were using. Try printing to PDF, for instance, or copy and paste into another app.

Compare any other rich text editor, such as Nisus Writer Pro or my own free DelightEd, and the colours you choose remain constant whatever the Mode.

Look inside the rich text code, and you’ll see that your original colour wasn’t dark purple as shown on the display, but light lilac instead. The prefatory colour and expanded colour tables set the dark purple as light lilac:
{\colortbl;\red255\green255\blue255;\red254\green204\blue255;}
{\*\expandedcolortbl;;\cssrgb\c100000\c84540\c100000;}
and that’s the colour all those characters were set in:
\cf2 \uc0\u9751
and so on.

There are only two reasonable ways of displaying colour like this, irrespective of Mode or background window colour: faithful to the colour, or to expected human perception. TextEdit has neither intent. It simply inverts the lightness of each colour when the window background is switched between light and dark. That deliberately flouts WYSIWYG for no good reason.

TextEdit has behaved in this way since macOS 10.14.2 was released on 5 December 2018, more than six months ago. Someone in Apple clearly thinks that this is the way to go, and it’s fine and dandy. If that’s the case, please keep them away from macOS altogether, because they don’t understand what makes a Mac a Mac, or why we so willingly pay Apple for our systems. If we wanted apps to do confusing things like this behind our backs, then we’d all go off and use Windows.