There are plenty of text and Rich Text editors around, but there’s only one which is installed on (almost) every Mac: TextEdit. Direct descendant of the editor of the same name on NeXTSTEP, and god-daughter to Mac OS’s SimpleText, it was part programming demonstration and part basic utility.

TextEdit has never been sexy, bohemian, or even vaguely exciting. It has been an excellent example of a staple tool which has just got on with the job. And it’s a better-than-even bet that it’s still the default app to open all your text and Rich Text documents.

Then came macOS Mojave 10.14.2.

Apple didn’t bother to mention in its release notes that TextEdit had changed. Neither did it increment its version number, which remains at 1.14, although if you open the app you may spot that its build number has gone from 340 to 341. Given that few users will have simultaneous access to both versions, it’s hardly going to attract your attention.

As far as I can tell, build 341 contains a single change: the addition of a new command to its View menu, Use Dark Background for Windows.

There are several curious facts about that too. First, you’ll only see this command when you’re running in Dark Mode, but the menu item doesn’t mention that mode by name. It’s also the only command in the View menu which applies to all TextEdit’s windows, not just the front one. By any convention, it’s in the wrong menu, as it’s an app-wide setting, not per-view.

Look in TextEdit’s Help book, and you’ll not see any mention of this command, nor can I find anything there when searching for ‘dark’. Neither does this command do just what it claims (although I really wish it was for Windows and not macOS). Enable this Dark Background, and TextEdit changes most of the colours shown in its windows.

The most obvious thing that it does is swap white for black, and black for white, in both foreground and background colours: simple colour inversion. Even when you have painstakingly set a black background for a section of white text, it inverts the colours you have chosen. Worse still, it alters the lightness values in most if not all other colours you might use, apparently to maintain the same level of contrast with its inverted background.

The two overlapping windows above show the same section of coloured symbols in two different apps, having been copied from TextEdit and pasted into DelightEd.

That’s just like an image editor changing the lightness of your photos when it switches to Dark Mode.

These changes are only shown when using Dark Background, and they don’t alter what is saved to Rich Text files or copied and pasted into other apps. Because this Dark Background mode is peculiar to TextEdit (thank God), you’ll never see those colours in any other Rich Text editor or word processor. They are figments of TextEdit’s twisted imagination.

There’s another more general problem which becomes painfully apparent in this new unannounced version of TextEdit, which affects my DelightEd and other apps which use Apple’s Cocoa AppKit too: the background and foreground colour selectors have a mind of their own. This is easily demonstrated by typing in some text, selecting it all, and changing its foreground (text) colour to blue before setting its background colour to red. You’ll then see the foreground colour also change to red, even though the text is displayed correctly in blue.

At the start of the Introducing Dark Mode presentation at WWDC last June, Apple’s experts impressed upon us three principles:

• Dark interfaces are cool
• Dark interfaces are not just inverted
• Dark mode is content-focused.

In breaking the second and third of those, this new version of TextEdit demonstrates how readily it can shatter the first.

If this were only to affect TextEdit, it perhaps wouldn’t be so catastrophic. Unfortunately the rot has set in, and Mojave’s handling of Rich Text in Dark Mode is now broken in several places. Apparently unknown to the engineers who have updated TextEdit, macOS already has a standard solution. It involves adding an expanded colour table (\expandedcolortbl) to the Rich Text encoding the document which earmarks bi-modal text, which should change colour according to the prevailing appearance mode. This is built into macOS Mojave, and was alluded to at WWDC last June.

Currently, macOS and apps which claim to be compatible with, or even support, Dark Mode don’t handle Rich Text consistently in Dark and Light Modes. The best way to demonstrate this is by generating some sample Rich Text and showing how it is displayed by macOS and some important Rich Text editors.

This is my original Rich Text document, written in TextEdit set with a Dark Background. Because TextEdit doesn’t natively add the expanded colour table to support bimodal text, the final para has been pasted in from a window in DelightEd, which does. Note the sequence of paras here:

1. TextEdit default composed in default white text on the default background;
2. TextEdit set black text on a set white background;
3. TextEdit set white text on a set black background, but note that the background is actually displayed as a very dark grey;
4. DelightEd textColor text on a default background (pasted in), displayed identically to the first para.

Turn Dark Background off in TextEdit, and every para is now inverted in colour, despite the fixed colours set originally.

The Finder QuickLook thumbnail of the same file (system in Dark Mode) is essentially the same as TextEdit with Dark Background turned off, except for the last para which vanishes completely, presumably because its text is being erroneously rendered in white on white.

QuickLook preview of the file with the system in Dark Mode is the same as the thumbnail, with the last para lost in white.

Opened in Pages 7.3, also in Dark Mode, the document is rendered the same as by QuickLook. The fact that the last para is actually present is confirmed by the underlined spelling exception for the word textColor.

Previewed in Microsoft Word’s Open File dialog (16.19), in Dark Mode again, the last para reappears rendered in black on white.

However, when the file is opened in Word 16.19, the background of the second para isn’t set to fixed black, so its white text vanishes; Word doesn’t appear to be complying with the RTF standard in this respect. The bimodal text of para four is shown correctly.

In DelightEd 1.0, which uses the Rich Text support provided in Cocoa’s AppKit, with the window in Dark Mode shows the file strictly according to its intent. The black text of the first para is shown on its very dark grey default background, rather than pure black (as in TextEdit). This demonstrates that TextEdit writes RTF which sets the foreground colour to a fixed black, and doesn’t specify a background colour at all.

When DelightEd’s window is switched to Light Mode, all colour settings are preserved, although the unspecified background of the first para is now rendered in white, and the bi-modal textColor of the last para is now shown in the black on white of that mode.

Previewed in Nisus Writer Pro’s Open File dialog (3.0), in Dark Mode, it is shown the same as in Word’s preview, which differs from the QuickLook thumbnail shown in the Finder in rendering the last para correctly.

Nisus Writer Pro renders the document in accordance with Rich Text support in Cocoa’s AppKit, and is the only ‘word processor’ of the three shown here to render all four paras ‘correctly’.

This is a real mess, which this new version of TextEdit only makes worse. There needs to be a consensus so that macOS and its apps can deliver a consistent result to users, otherwise Dark Mode and TextEdit will be no-go areas for the editing of Rich Text. That would be a damning failure for macOS Mojave.

Tomorrow, I will propose a detailed solution.