WYSIWYG and Dark Mode
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.
[…]
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.
2 Comments RSS · Twitter
I hit this issue a lot with figuring out how to handle styled text in Keyboard Maestro in dark mode. In the end, I pretty much punted - if the text is colored and has a background included in the text, then I accept that, otherwise I force a white background behind the text.
The fact that Apple has not (as far as I am aware) got any API for any of this on how to deal with color styled text when dark mode changes is an indication that it is both really hard and not all that well thought out.
But hey, dark mode looks spiffy, right?
Regarding Peter Lewis' comment about a lack of API support, Apple did implement support for bi-modal text in Mojave (text responsive to dark mode). It was briefly referenced in a presentation at WWDC that year, but documentation is almost impossible to find. You need to add \expandedcolortbl to the RTF encoding. Basically this allows you to give text one style for regular mode and one style for dark mode. TextEdit will actually use this if you paste it in from one of the few apps that support it, which alleviates the color-overriding problem, but doesn't have any user-facing features that access it by default.
