Partial fix Markdown conversion issues

[Lukas W.]

Affected version

2.1.0

A few bugs/issues with the markdown conversion. I know some of them depend on the spec one uses, but from a user perspective, I'd probably expect all of them to work.

Single bullet point items are not converted to lists.

Example:
- A

Example:

• A
• B

Numeric listings are not converted to ordered lists.

Example:
1. A
2. B

Incomplete formatting results in partial/wrong conversion.

Example:
__*B*_

Example Code:
*__*B*_*

Tripple backticks on same lines break code block conversion.

Example:
```Code
A```

Square brackets in URL titles break URL conversion.

Example:
[Som[e] Text](http://google.com)

Text formatting inside URL titles remains unrendered.

Example:
Som*e* Text

Example Code:
[Som*e* Text](http://google.com)

 

[Mike]

Many of these are actually intentional. Our goal isn't full Markdown parsing, so it really is going to be our own flavor (where we don't necessarily mention Markdown or CommonMark to an end user), aiming at covering common cases while trying to avoid false positives or unexpected behavior (often based on some feedback from end user behavior).

So for example, single list item and numeric lists are intentionally not parsed.

Incomplete formatting results in partial/wrong conversion.

There is a potential bug here that I'd need to have a look at, but note that our asterisk parsing is more strict than CommonMark (in that we essentially only support using this markup for full words, not within words). That is intentional.

Tripple backticks on same lines break code block conversion.

I could go either way with this one.

Square brackets in URL titles break URL conversion.

I'm not sure if this is something we'd consider changing.

Text formatting inside URL titles remains unrendered.

That certainly fits as a bug.

 

[Chris D]

Tripple backticks on same lines break code block conversion.

Example:
```Code
A```

CommonMark wouldn't generally render this correctly either. The only difference is they attempt to and we don't.

Their attempt would look like this:

A```

Whereas we just don't bother because we generally just expect the backticks to be on their own line (with the opening ones optionally including a language).

 

[Steffen]

[...] note that our asterisk parsing is more strict than CommonMark (in that we essentially only support using this markup for full words, not within words). That is intentional.

Yesterday, one of our users asked whether it is intentional that XenForo interprets the asterisks in 2*-8*MSAA as Markdown. Is this intentional? Maybe XenForo unintentionally treats digits as "word boundaries"? Maybe it could check for leading and trailing whitespace instead?

 

[Steffen]

Another example where XenForo thinks the asterisks are Markdown:

You can use an asterisk as a wildcard: "*". For example, "xenfo*" would …

 

[Aivaras]

And when someone uses other mark-up languages such as LaTeX, Markdown becomes plain destructive. It literally would have destroyed our production website had we been on XF2. Beware!

 

[Wildcat Media]

I think @Chris D or @Mike mentioned that Markdown would be switchable forum-wide with the next release, so those of us who don't need it can easily turn it off. For many of the older members who visit some of our forums, they wouldn't understand what is happening if the text all of a sudden started formatting and their characters were lost. This is a good example of what can happen if someone started using asterisks:

You can use an asterisk as a wildcard: "*". For example, "xenfo*" would …

 

[Lukas W.]

FWIW, my Editor Manager also supports markdown disabling.

 

[Mike]

We have made a few changes here, but that's all we're planning on changing at this time. We may consider more significant changes in future releases.

Notably, we have made changes to triple backtick parsing to be somewhat less particular (and to try to be more intelligent at detecting what the first line is: a language name or actual content). We've also made some adjustments to ensure that inline tags are parsed within link text values.

As mentioned, 2.1.1 has a MD-style parsing disabler option now, so if false positives cause issues for your site, then you may wish to disable them.