It must be a pain to make a text box with the ability to add bold, italic, heading, etc. you know? All the bold text, italics, and headings would need to be saved in a database column to be retrieved later in their correct positions.
I don't know, I am doing internship learning C# ASP (started 2 months ago), and just got a "Shower Thought" while making an edit post function.
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.
Yes, but usually not actual HTML because then there are a lot of security issues to address. BBCode might even be a better choice, i.e. [b]Bold Text[/b]
Rich text in the modern world is almost exclusively solved by using markdown because it’s such a trivial solution.
citation needed
markdown is not a trivial solution: there are many different implementations, it's a barrier for non technical people and it allows you to embed any html, so you need an additional html sanitizer.
my definition of a "rich textbox" is a WYSIWYG field, and markdown does not help you with this?!
yes, you probably would not save the formatted text normalized over multiple database columns, and only use a single field for a the text with formatting embedded in html or another format, and another one with the text without formatting for possible full text search. but even if you would solve this using markdown (which limits you to a quite small subset of text formatting and bad extensibility) you would still need a good data format to store the formatted text in memory that allows you to render the text. and markdown does not help you with this either?!
If I wanted a WYSIWYG field I'd probably still use markdown. I could add the buttons to properly inject markdown symbol and use a JS markdown renderer for the text field. Tbh I'd be amazed if there weren't at least a dozen out-of-the-box packages that included a live rendered text area with a widget array.
In this instance I'm not advocating for markdown as a user interface but just using it as a quick and dirty markup language. Be aware that if you turn to HTML, you'd be adopting responsibility for a lot of non-trivial security issues. If the customization went beyond markdown (into, for instance, fonts) you'd need a more complex solution so you'd likely want to investigate other tag or boundary marker based markup languages out there. Markup is just simple and has ten billion implementations out there.
Markdown has one huge adventage, if you remember bit of syntax you can type it right from your finger, it's a great speedup for me. I personally prefer orgmode but noone uses that in XXI century.
Yeah, but that's not what we're talking about here.
RTF has many more features than markdown can reasonably support, even with your personal, custom, syntaxes that no one else knows :/
I use markdown for everything, as much as possible, but in the context of creating a RTF WYSIWYG editor with non-trivial layout & styling needs it's a no go.
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.
Of course not lol. The CMS I usually use stores it as HTML in the database, so I have a go-to HTML sanitization plugin with a tag whitelist. I wish it used markdown or something similar under the hood instead, but it is what it is.
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.
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.
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.
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).