[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 :)