better rich text and more of it

we deserve rich text

It's hard to believe that Unicode exists. The fact that there is one single standard that is used for pretty much all plain text interchange is amazing—imagine if you couldn't copy non-English text from one file to another without it getting mangled beyond repair, or if every application supported a different, mutually incompatible subset of your language that you had to input in a totally different way. But that's precisely the situation that we are in right now with rich text. In fact, most people don't even have a conception of rich text as a category, instead conceiving of it only in terms of the patchwork of ad-hoc formats that are used in day-to-day life. Those who do think it is essentially about formatting—bolding, italics, etc. But rich text is not just formatting—rich text is any aspect of layout not supported by Unicode, which can include such essential things as signalling the language a text is written in (required to display the correct glyphs for unified Han characters[1]) and support for any decent looking mathematics[2]. Also covered (at least in my definition of rich text), though less essential, is everything from embedded images to hyperlinking.

Now, obviously some aspects of rich text are not appropriate for every scenario. For example, you probably don't want users to have total creative control over the layout of their instant messages/tweets.[3] One can categorise the usages of rich text into two main categories—inline, and as a document. Inline usage would encompass things like bolding, italicising, language indication, font selection, lists, etc., whereas rich text in a document could include embedded images, pull quotes, several columns, tables, etc. In addition to these two categories, applications may want to include and exclude certain features on a case-by-case basis—e.g. Reddit (and Markdown in general) allows tables in addition to the normal inline features.

That being said, in general rich text is an unalloyed good. After all, as you might have seen in a footnote already, why should one give up things that are easily achievable with handwriting on a computer? A computer is meant to open up more possibilities, not less! And the public agrees—on platforms that don't allow rich text the misuse of Unicode text to convey italics, or superscripts, or small text, and so on is rife. Instead of upbraiding them for using these characters in an inaccessible way, the correct answer is to allow rich text.

we aren't getting it

But many social media platforms—and no matter what we may think of it[4] social media platforms are where the majority of online writing is found today—will not allow rich text. Facebook, the all-consuming platform that wants to replace all human interaction with a "Metaverse"[4], doesn't allow it. Twitter doesn't allow it. Youtube doesn't allow it.

what we are getting isn't good enough

Some social media platforms do allow rich text, those being Tumblr, Reddit and most instant message platforms. But the rich text support is, at best, lacklustre. In fact, it would be impossible for it to not to be, since the amount of effort that is needed to support rich text fully is probably beyond what is profitable for Reddit or whoever to implement.

features

There are some truly baffling[5] omissions in most of these platforms. For example, Discord does not support inline links, neither Discord nor Reddit support changing font sizes, and nothing supports setting fonts—not even from the 5 CSS generic font families[6]—which is only not a completely outrageous exclusion because everyone excludes it.

In fact, there's a lot (a lot lot) of rich text features that aren't used very much in aggregate. This is the "long tail", and it's perfectly understandable that vendors wouldn't support it—as understandable as it was for the "long tail" of plain text. But the long tail of plain text includes thousands of languages, which wouldn't be implemented at all if it weren't for Unicode—and the long tail of rich text is the same, including above-text annotation (implemented by the HTML <ruby> tag) which is essential for Japanese 振(fu)り(ri)仮(ga)名(na), vertical text orientation (necessary for the Mongolian language) ... and let's not forget the most populated member of this long tail, mathematical notation!

interoperability

There isn't any.

the options right now

Unicode

Unicode is one of the more widely-used solutions for rich text, which is impressive considering it doesn't encode rich text at all. The "rich text" (italics, bold, etc) that it encodes are actually mathematical symbols, which are unfriendly to screenreaders and unsupported on many mobile devices. This is not a viable way forward, but its use does indicate a need for rich text.

DOCX &c.[7]

DOCX is probably the most used rich text format. It is very capable, as befits its status as the format of Microsoft's flagship office suite. However, it is oriented towards the page, not the screen. What this means is that it usually assumes the document is being viewed as a series of fixed-aspect-ratio pages, of which the user has full control. This isn't (in my opinion) within the scope of rich text, since it makes reflowable text impossible. More will be said on this subject later.

In addition, the formatting in DOCX is presentational, not semantic. More, again, will be said on this subject later.

TeX and LaTeX

TeX and its brethren are not widely used among the general public, but are ubiquitous within academia. TeX is extremely flexible, and can produce fixed-page documents or reflowable documents (though its main target is the fixed-page PDF). It has very good support for mathematics, which is in my opinion essential for any truly rich text. However, TeX is somewhat more than a rich text format, and it has support for macros—which are Turing-complete! This means that while one can create a WYSIWYG (What You See Is What You Get) editor that outputs TeX, one cannot create a WYSIWYG editor that can take as input any arbitrary TeX document, or one that can output a document that uses the full features of TeX. And any rich text solution which aspires to generality needs a WYSIWYG editor.

Markdown &c.

Markdown is widely-used, and seems to be the "format of choice" for platforms that want to offer rich text.[8] Unlike the previous rich text formats (excluding Unicode, which isn't really a rich text format), it only offers inline rich text, rather than document rich text. Unfortunately, it seems like every platform that wants to include Markdown extends it in their own incompatible way—are spoilers represented ||like this|| or >!like this!<? In addition, it is not really adequate even for inline rich text - no furigana or mathematics, for instance.

Markdown is optimised to be nice to read as plaintext. For the original goal of highly limited inline rich text, this was OK. But when features like tables were added, the attribute of being nice to read has now made it hard to write—after all, who wants to write out an ASCII art table? This prompts the question—is it really a valuable attribute of a rich text format to be nice to read as plaintext? I don't really think so; after all, if one wants to read rich text as plaintext, then it should be fairly trivial to have a simple postprocessing step that does this.

HTML

HTML is the nexus of essentially all the effort that has been put into nice text layout on the computer over the past 15 years. 99% of the text viewed on a computer is in HTML - even eBooks are in HTML, since the ePub format is just a zip file containing HTML. As a result of all the effort that has been put into HTML and CSS, it is actually a very nice format to write documents with rich text. It has a totally different model to that of DOCX and TeX—if DOCX and TeX use the "presentational" model, HTML uses the "semantic" model.

However, HTML is much more than rich text. The ability to embed JS in HTML[4] means that it's not safe to use the entirety of HTML as a rich text format. Any rich text format that uses HTML would need to be a subset.

presentational or semantic

I have promised to explain this, so I shall. There are two forms of rich text: that which is formatted in a presentational way, and that which is formatted semantically. This is perhaps best explained with an example. HTML is formatted semantically. This means that the details of formatting, like font, colour, and layout are not exposed in the HTML but are separated into the CSS.[9] With presentational formats, the formatting information is interleaved with the text, such that if you (for example) wanted to make every headline red you would have to manually set the colour to red on each and every one.[10]

Presentational formatting is, in the short run, simpler to use, and is probably what most people (who know what rich text is) think about when they think of rich text. It is also what most WYSIWYG editors presently produce and edit, though I don't see any theoretical reason why one shouldn't be able to edit semantic formatting in a WYSIWYG manner. However, semantic formatting is a much more flexible alternative. It allows, by separating formatting from content, the style of entire documents to be changed easily. In addition, it allows readers to restyle your document easily if e.g. they have bad eyesight, and require larger text, or if they prefer a dark mode, or if they are dyslexic and can read special fonts much more easily than the one you chose, etc.

why not PDF

PDF is good.

However, PDF solves a different problem to rich text. PDF is designed such that the same PDF document will always render in precisely the same way on everyone's screen. This necessitates design choices such as making it fixed-page, and storing the fonts used within the document. This is not how rich text should work. Rich text should be reflowable, such that it can fit on any screen size. Further, it should allow for the possibility that, e.g. people read it with different fonts, the default font size may be different, etc. The only format that really allows this today is HTML.

where from here

If you can't already tell, I think that HTML is the best way to write and interchange rich text today. But simultaneously, HTML is very inadequate. HTML has too many features for safety, there is no WYSIWYG editor for semantic HTML, and it currently has no adoption for user-generated content on commercial platforms, which are[4] the main platform for content on the World Wide Web today. Still, I think that any rich text format that has any pretensions to universality should follow the examples set by HTML+CSS, and more specifically modern HTML5+CSS3, since each successive version has moved further from presentational formatting to semantic formatting. Whether this means using a subset of HTML, or using a new format inspired by HTML, or something entirely different is up to time to tell.