More changes here, there's now NodeBB/NodeBB#3807, which replaces utils.findBootstrapEnvironment to make it much faster. Also made another branch with-css which uses CSS for the .write-preview-container positioning.pitaj created this issue in NodeBB/NodeBB closed A much faster findBootstrapEnvironment method #3807
BartVB last edited by
There have been previous discussions about this subject like:
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.
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.
NodeBB/NodeBB#1234turns 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.posthook, 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?
Redactor v3, by the way... is coming along quite nicely....
BartVB last edited by
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
**blabla**, but you'll just keep
NodeBB/NodeBB# 1234as 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