Improved WYSIWYG?

[BartVB]

There have been previous discussions about this subject like:
https://community.nodebb.org/topic/1942/any-reason-why-the-dual-composer-view-was-chosen-over-wysiwyg
and
https://community.nodebb.org/topic/4380/wysiwyg-editor/

Apparently the main problem is that an easy to use WYSIWYG editor hasn't been found that outputs Markdown.

I think this is fairly easy to solve by storing (sanitized) HTML in the database instead of raw Markdown. It should be trivial to convert between these two, that way the current composer/Markdown can still be used on sites that want this. Other sites are free to use BBcode (if they convert to/from HTML) or plain HTML.
But this is a rather fundamental/ideological change.

The main problem with the current editor (for me at least) is that it takes up a lot of space, it's pretty ugly from a usability point of view. I found a really nice (IMO) solution on Flarum.org:

The preview is shown inline at the point where the post is going to be when you hit 'Post Reply'. This gets rid of the split screen, it's easier to see what will happen when you scroll/navigate away, and it doesn't take up extra space.

[julian]

As mentioned in the other topics -- the main problem is that HTML and Markdown are not one-to-one convertible. Saving sanitized HTML into the database is a bad idea because you cannot guarantee that the reverse process will work 100% of the time (that is, if you want to edit the post a second time). Even if you can get Markdown to HTML conversions working both ways, plugins introduce another issue.

e.g.

Typing NodeBB/NodeBB#1234 turns into a GitHub issue (see the bottom of this post). Saving that HTML in the database means the GitHub plugin has to handle the reverse, which it does not.

Extend this to every single plugin out there that listens to the filter:parse.post hook, and you see why it is impractical.

Yet, let's also assume this is possible... that the GitHub plugin (among others) does handle the reverse process.

What if a theme also changes a post content... let's say it takes that GitHub rendered onebox and adds some pretty borders to it... now the GitHub plugin won't recognize the HTML anymore, unless it is modified to work with both the custom theme and Persona and Vanilla... and Lavender... and Slick... and Material... get my drift?

[julian]

Redactor v3, by the way... is coming along quite nicely....

[BartVB]

I get your drift But that's not quite what I meant.
My proposal would be to save approximately what a user enters in a textbox on the site. I.e. the same that happens now. So you'll save <b>blabla</b> instead of **blabla**, but you'll just keep NodeBB/NodeBB# 1234 as it is.

When you edit the post <em> is converted back to * if the composer you use accepts Markdown. If the site uses a a WYSIWGY editor you can just keep the HTML and work with that.

Plugins can still hook into all that, just make sure that they don't put presentation HTML in the DB. I can imagine that they do add something like <widget=github>NodeBB/NodeBB#1234</widget> to the text that goes in the DB (and deal with this appropriately when editing). This would make it easier to build more complex widgets I guess. But that's all optional.

My main point is that saving (really basic) HTML in the DB is much more universal and more extendable than saving Markdown.

Well, actually my main point is that I found a different (better?) way to deal with the realtime preview of the MarkDown