Bold Text inside of a word with trailing punctuation character inside of bold is not rendered
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 5.3k
- Forks
- 510
- Avg merge
- 8d 5h
- Merged PRs (30d)
- 5
Description
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):
(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?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the GOOD and BAD Markdown examples from the issue, including punctuation immediately before the closing emphasis markers. Then trace the parser's handling of bold spans at a word boundary and compare its output with the expected HTML shown in the report. Done means the behavior is either corrected with regression coverage or clearly documented as intentional.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100