Programming

17299 readers

667 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago

MODERATORS

[email protected]

It must a pain to make a Rich Textbox (lemmy.ml)

submitted 3 months ago by [email protected] to c/[email protected]

26 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 60 points 3 months ago (9 children)

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.

[–] [email protected] -4 points 3 months ago (2 children)

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?!

[–] [email protected] 10 points 3 months ago* (last edited 3 months ago) (1 children)

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. Markdown is just simple and has ten billion implementations out there.

[–] [email protected] 4 points 3 months ago* (last edited 3 months ago)

Probably not. Having actually played with making a WYSIWYG editor as a learning project markdown is too simplistic for the formatting needs of any non-trivial text editing, as a serialized storage format.

You almost always end up back with your own data structure that you serialize into something like XML for storage. Or you end up supporting HTML or non-spec compliant syntax in your markdown.

And if you care about performance, you're not actually working with XML, HTML, or Markdown in memory. You're working with a data structure that you have to serialize/deserialize from your storage format. This is where markdown becomes a bit more tedious since it's not as easy to work with in this manner, and you end up with a weird parsing layer in-between the markdown and your runtime data structures.

The commenter that's downvoted is more correct than not IMHO (Also why are we downloading discussions??). Markdown is ill suited for "most WYSIWYG needs". It tends to get augmented with XML or custom non-spec compliant syntax. The spec poorly supports layout (columns, image & media positioning, sizing...etc) and styling (font color, size, family, backgrounds...etc)

load more comments (6 replies)