Bold Text inside of a word with trailing punctuation character inside of bold is not rendered #582

New Issue

claunia · 2026-01-29T14:40:23Z

claunia commented

2026-01-29 14:40:23 +00:00

Originally created by @RickStrahl on GitHub (Dec 8, 2022).

There's a rendering issue with bold text when bold is selected without a trailing space after teh bold text (ie. inside of a word boundary) and the bold text ends in a puntuation or sign character.

GOOD: **bold text ending with slash/** followed by non-blank

BAD: **bold text ending with slash/**followed by non-blank

BAD: **bold text ending with slash=**followed by non-blank

<!-- workaround -->
GOOD: <b>bold text ending with slash/</b>followed by non-blank

Here's that rendered on GitHub which exhibts the same behavior actually:

GOOD: bold text ending with slash/ followed by non-blank

BAD: **bold text ending with slash/**followed by non-blank

BAD: **bold text ending with slash=**followed by non-blank

GOOD: bold text ending with slash/followed by non-blank

I've tried escaping the text with \ and none of that seems to help. The only workaround seems to be using raw HTML as long as the target parser supports that (and MarkDig and Github appear to both).

The following Babelmark demonstrates - although it behaves differently yet (even for MarkDig and GitHub which obviously behave slightly differently):

Babelmark for bold issue

(hmmm... babelmark seems to inject an extra space regardless, but GitHub here or MarkDig seem to do the right thing)

This is an edge case for sure, so probably low priority and apparently MarkDig isn't the only parser handling it this way. Not sure if this even should be fixed because it would give different behavior than GitHub which is the most common use case for Markdown to end up on.

Anybody know why the /**moreText would cause this behavior in the parser?

Originally created by @RickStrahl on GitHub (Dec 8, 2022). There's a rendering issue with bold text when bold is selected without a trailing space after teh bold text (ie. inside of a word boundary) **and** the bold text ends in a puntuation or sign character. ```markdown GOOD: **bold text ending with slash/** followed by non-blank BAD: **bold text ending with slash/**followed by non-blank BAD: **bold text ending with slash=**followed by non-blank  GOOD: bold text ending with slash/followed by non-blank ``` Here's that rendered on GitHub which exhibts the same behavior actually: --- GOOD: **bold text ending with slash/** followed by non-blank BAD: **bold text ending with slash/**followed by non-blank BAD: **bold text ending with slash=**followed by non-blank GOOD: bold text ending with slash/followed by non-blank --- I've tried escaping the text with `\` and none of that seems to help. The only workaround seems to be using raw HTML as long as the target parser supports that (and MarkDig and Github appear to both). The following Babelmark demonstrates - although it behaves differently yet (even for MarkDig and GitHub which obviously behave slightly differently): [Babelmark for bold issue](https://babelmark.github.io/?text=BAD%3A+**bold+text+ending+with+slash%2F**followed+by+non-blank%0A%0AGOOD%3A+%3Cb%3Ebold+text+ending+with+slash%2F%3C%2Fb%3Efollowed+by+non-blank%0A%0ABAD%3A+**bold+text+ending+with+slash%3D**followed+by+non-blank) (hmmm... babelmark seems to inject an extra space regardless, but GitHub here or MarkDig seem to do the right thing) This is an edge case for sure, so probably low priority and apparently MarkDig isn't the only parser handling it this way. Not sure if this even should be fixed because it would give different behavior than GitHub which is the most common use case for Markdown to end up on. Anybody know why the `/**moreText` would cause this behavior in the parser?

claunia added the question label 2026-01-29 14:40:23 +00:00

claunia commented

2026-01-29 14:40:24 +00:00

@MihaZupan commented on GitHub (Dec 8, 2022):

This behavior comes from CommonMark's right-flanking delimiter run definition:

A right-flanking delimiter run is a delimiter run that is (1) not preceded by Unicode whitespace, and either (2a) not preceded by a Unicode punctuation character, or (2b) preceded by a Unicode punctuation character and followed by Unicode whitespace or a Unicode punctuation character. For purposes of this definition, the beginning and the end of the line count as Unicode whitespace.

Specifically, **bold with slash/**f doesn't match either of the 2a/2b conditions as the closing ** are preceded by punctuation (/) but not followed by a whitespace/punctuation.

Examples 391 and 392 represent this case.

@MihaZupan commented on GitHub (Dec 8, 2022): This behavior comes from CommonMark's [right-flanking delimiter run](https://spec.commonmark.org/0.30/#right-flanking-delimiter-run) definition: > A [right-flanking delimiter run](https://spec.commonmark.org/0.30/#right-flanking-delimiter-run) is a [delimiter run](https://spec.commonmark.org/0.30/#delimiter-run) that is (1) not preceded by [Unicode whitespace](https://spec.commonmark.org/0.30/#unicode-whitespace), and either (2a) not preceded by a [Unicode punctuation character](https://spec.commonmark.org/0.30/#unicode-punctuation-character), or (2b) preceded by a [Unicode punctuation character](https://spec.commonmark.org/0.30/#unicode-punctuation-character) and followed by [Unicode whitespace](https://spec.commonmark.org/0.30/#unicode-whitespace) or a [Unicode punctuation character](https://spec.commonmark.org/0.30/#unicode-punctuation-character). For purposes of this definition, the beginning and the end of the line count as Unicode whitespace. Specifically, `**bold with slash/**f` doesn't match either of the 2a/2b conditions as the closing `**` are preceded by punctuation (`/`) but not followed by a whitespace/punctuation. Examples [391](https://spec.commonmark.org/0.30/#example-391) and 392 represent this case.

claunia commented

2026-01-29 14:40:25 +00:00

@RickStrahl commented on GitHub (Dec 9, 2022):

Thanks for the pointer Miha...

So I don't see that there's any workaround short of using raw HTML

<b>bold text ending with slash/</b>followed by non-blank

Is there any other way that this can be bypassed? Looks like escaping doesn't work.

@RickStrahl commented on GitHub (Dec 9, 2022): Thanks for the pointer Miha... So I don't see that there's any workaround short of using raw HTML ```markdown bold text ending with slash/followed by non-blank ``` Is there any other way that this can be bypassed? Looks like escaping doesn't work.

claunia commented

2026-01-29 14:40:25 +00:00

@xoofx commented on GitHub (Dec 9, 2022):

Thanks for the pointer Miha...

So I don't see that there's any workaround short of using raw HTML
bold text ending with slash/followed by non-blank
Is there any other way that this can be bypassed? Looks like escaping doesn't work.

Don't think that there is any workaround than to use raw HTML.

@xoofx commented on GitHub (Dec 9, 2022): > Thanks for the pointer Miha... > > So I don't see that there's any workaround short of using raw HTML > > ```gfm > bold text ending with slash/followed by non-blank > ``` > > Is there any other way that this can be bypassed? Looks like escaping doesn't work. Don't think that there is any workaround than to use raw HTML.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/markdig#582