Programming

That is a very unlikely approach.

Rich text in the modern world is almost exclusively solved by using markdown because it's such a trivial solution.

In previous words it was usually solved either using range tags (similar to HTML, sometimes literally HTML, more often custom stuff) or embedded boundary markers (something that marked a new boundary and then had a full definition of the styles to follow, sometimes omitting styles that didn't change, often times in some insanely dense binary format for predictable scanning).

Usually, it's more sane to embed formatting in the string itself rather than having styling separately defined (i.e. CSS, kinda). Because otherwise storage would be a huge pain and reading would require a lot of non-consecutive disk scans.

There are markup languages for this purpose. And you store the rich text as normal text in that markup language. For the most part.

It's typically an XML or XML-like language, or bb-codes. MS Word for example uses XML to store the markup data for the rich text.

Simpler and more limited text needs tend to use markdown these days, like Lemmy, or most text fields on GitHub.

There's no need to include complex technology stacks into it!

Now the real hard part is the rendering engine for WYSIWYG. That's a nightmare.

All the bold text, italics, and headings would need to be saved in a database column to be retrieved later in their correct positions.

Nobody does that. People simply store HTML, Markdown or BB code. Check out TinyMCE, Milkdown, tui-editor, stackedit... all of them have a "see source" button and you'll see the text with the formatting code right there.

You'd save it to the database in the same field as the rest of the text. You don't store the positions or anything like that - you'd store the text with HTML and have the front end render it as expected.

For instance, the database could have the following text:

Hello <strong>World</strong>

And the front end just renders HTML.

Alternatively, you could store Markdown syntax if you're hesitant to allow HTML.

EDIT: as always, if you store raw HTML, don't forget to sanitize it.

I came across something like that in a proprietary "epub" format. Not because of formatting/styling but because of crossreferencing and footnotes it stored every word in a database with its position.

Just make a normal text box and enter a wallet address containing a bitcoin. Tadaaa

Yes, it is a huge pain, especially if you want to have round-trip interoperability with humans using markup. Wikipedia had a major challenge with this when they decided to add a rich text editor alongside wiki markup.

You mean like the comment fields we're using right here on lemmy?

As others have pointed out, it's usually some markdown that's embedded within the text. Lemmy is using a format that's actually called "markdown" if I'm not mistaken, or a slight variation/subset thereof.

I've gotten used to the double-star for bold and what not to the point that it annoys me when some message client or whatever doesn't support it. I share code snippets with people fairly often, and the code markdown is particularly useful to maintain its legibility.

*Vietnam flashback from dealing with RTF*

Now also write the font rendering engine and you're all set!

You can always take a look how for example Windows 3.11 and earlier did it for their *.rtf file format and their "write.exe" editor / viewer / renderer (if you want to call it that way).