Closed djwebsystems closed 4 years ago
The best way to handle this is to add an option for "no html in markdown on import". It looks like it's getting confused due to all the unnecessary HTML that's added.
@mdchaney the default sanitizer is always on. The issues are about TUI editor itself. I have similar issues, though they appear differently.
<br>
Random <br>
tags are not that much about HTML but about crappy whitespace handling.
Consider this HTML code placed on a random web page:
<p>
I am a regular
html paragraph.
</p>
When copied to WYSIWYG mode, TUI Editor will paste these line breaks inside the text node, too. The problem is markdown code will have convert line breaks into <br>
tags (because it uses GitHub-style line breaks and paragraphs). But WYSIWYG will show a regular text node without any visual issues until you reimport this content or switch to MD mode and back.
This is simple, if you occasionally mark a word with a surrounding whitespace as bold/italic/whatever, it will break after reimporting or switching modes.
**this is a valid bold text**
**and this**
** this is an invalid bold text, but TUI Editor WYSIWYG mode doesn't care **
**meh **
In short, it all is a result of the poor architecture of TUI Editor that naively converts markdown and HTML back and forth, resulting in two weakly synced data sources. Because of that, and a tail of other quirks and poor API, I can't use this editor in production as these inconsistencies appear 100% of the time when used in real environments.
It also seems that when adding extra lines in WYSWIG mode, when you change to markdown mode, the
tags are shown which is not ideal.
WYSIWG mode:
Test
Test
Produces markdown:
Test
<br>
Test
In markdown, line break is <br>
so when change to Markdown from Wysiwyg, <br>
could be inserted in Markdown. So the appearance <br>
is the right thing.
We need more investigate for formatting issue when word with a surrounding whitespace.
This issue has been automatically marked as inactive because there hasn’t been much going on it lately. It is going to be closed after 7 days. Thanks!
This issue will be closed due to inactivity. Thanks for your contribution!
I am still facing this problem (with version 2.1.1) when hitting return
twice, or hitting return after a heading. Is there any workaround I could use? editing the generated markdown solves the problem, but is not an optimal solution for the end-users.
Thanks for the help!
I hit this problem too. :/ on the other end, when we generate HTML again out of the markdown, we disallow all HTML blocks for safety. This makes it a bit difficult, as that removes all the <br>
s
Oh I got the actual issue
it's because in wysiwyg, you allow multiple newlines, which is not possible to model with "pure" markdow.
so you add <br>
s to model that.
That's nice; but I would love to turn it off somehow :D
Same problem here. HTML is not part of Markdown. It’d be very nice if there was an option to disable this altogether.
Version
1.2.6
Test Environment
Google Chrome (latest version), Windows 10.
Current Behavior
When creating multiple line feeds (pressing ENTER twice or more) in the WYSIWYG editor, the editor creates
<br>
tags. These tags aren't a huge issue, but when removing one of them in the markdown editor, it seems to remove both of them -- making line editing incredibly cumbersome.Also and probably more importantly, we've noticed that the above behavior will cause bold formatting to be escaped displaying **Some Bold Text** as opposed to Some Bold Text.
This is most noticeable when copying and pasting from Word docs, but the issue can also be created by hand just by using the WYSIWYG editor in this way.
Since the company I am working for expects its clients to not be markdown or HTML savvy, we would like them to be able to use the WYSIWYG editor without need for the mark down editor, but as it stands we need both so customers can do surgery on the markdown to fix any of these bizarre issues.
Expected Behavior
The expected behavior is to add normal line feeds (as per markdown specification) and not
<br>
tags and also to respect any formatting after the line feeds without removing the formatting.