[catchclose8919]

that's because "rich text" is at odds with everyhting the web is supposed to be... like separating structure and semantics from styling with html and css etc.

sure, the "semantic web" failed, but that's the history

you were not supposed to be able to control how content looks like on the web, this was supposed to be the choice of the browser customized by the user (eg. a user could set his browser to render sci-fi topics web pages text with font X and financial news with font Y min-size Z etc.)

"web design" is something that should't have ever existed or had any reason to even be a concept...

it all went off-the rails in the real world ofc, but this was the real context and dream of the web and its tehnologies as they were designed and standardized

[egeozcan]

> that's because "rich text" is at odds with everything the web is supposed to be

I respectfully disagree. Rich text editing is more about being able to add semantics than making giant red blinking text. I want to explicitly add paragraphs, emphasis, links etc. without learning a new input method for every website.

[catchclose8919]

A paragraph is a different text box. Sure, a standard method to work with links and emphasis would help, but that's about where we should stop.

A bulleted list is [add new element] > [buleted list] -> a container with text fields for each bullet (+ add/remove buttons) appears.

Same for table, a proper grid with separate inputs for all cells (see modern Confluence).

[egeozcan]

So you are suggesting to implement more stuff with scripting (otherwise that would be horrible to use with page reloads in between, no?). Why go all the trouble when HTML can store all the semantics just fine?

I also use Confluence via plain HTML because their editor sucks, especially when copy/pasting. They have something even worse than MS Frontpage but implemented in JS, and my subconscious keeps me wanting to switch to CoffeeCup.

[catchclose8919]

I suggest accepting that we need a way to capture arbitrary structured text (lists/tree/graphs of text fields) that will then be rendable either as paragraphs or as tables or as collapsible trees or even navigable graph maps or whatever, depending on context and device and never under the full control of the content producer.

And realistically speaking, we'll never be able to standardize on inputing lists/tables/trees/graphs-of-text-cells anytime soon (ever?), so yeah, scripting is the only way.

This is why the web evolved to what it is, because the problem is always another different and more complicated problem than we thought it was, and then people never agree on solutions, so we have to say "anything goes", so it's scripting and web apps for anything about creating or inputing content.

Sure, you can have nicer standard ways for displaying context, but they'd alway need to be decoupled from the producing of content and be outside the control of the content producer ...because if you couple them you just get the heavy scripting spill out to the display side too, and that's how you get a horrbly slow and heavy javascript-only SPA frontend.

Accept heavy scripting on the content creation / input side, leave the display separate and accept that you cannot control it if you want it to stay nice and clean.

P.S. Confluence had some upgrades recently, and they're newish version is quite goo, especially table editing is dream imo :P (compared to the horror of their prev version) ...it's not Notion, but it's productively usable now :)

[zo1]

Confluence puts all of that in a single text box, AFAIK.

Speaking of which, anyone know of a library that allows that kind of control and extensibility? Specifically thinking custom render items that aren't boxes, tables and more text. Something like @mention but more complex.