How about (asterisks before space)

* **Brand & Model:** NEONOS HOLLAND //01
* **Price:** Earlybird pricing starts at $500

That functions as expected, but I still believe it to be an issue that it can't handle the space before the closing tag.

Thank you for showing me a workaround!

In fact, **foo ** should not be rendered into <strong>foo </strong> according to CommonMark, since it does not count as right flanking delimiter run.

CommonMark is not Markdown.

If I use John Gruber's document on Markdown and his 'dingus' HTML converter, it shows the behavior I expect is correct. Try **foo ** in http://daringfireball.net/projects/markdown/dingus and you'll see it works the way I think it should.

**foo ** absolutely should be rendered into foo and MouApp (the inspiration for MacDown) did this as I expect.

Yes, CommonMark is not the canonical Markdown, which is created by John Gruber. However, I prefer CommonMark instead of Markdown because the canonical "standard" misses a lot of corner cases. You can see from Babelmark that there are a lot of implementations behaving differently with this input. If we adapt one, it would still confuse users coming from other implementations, so it might be a better idea to conform to a standard, instead of just a specific implementation.

One may still argue that every implementation should just behave exactly like the canonical one. This seems to suggest that they should copy even the bugs. It is sometimes difficult to tell bugs from features, and that's why many non-canonical implementations tried to "fix" the bugs. Actually, the canonical implementations should be John's Markdown.pl, which interprets **foo ** as

<p><em>*foo *</em></p>

Yes, even his two implementations are not consistent with each other. I don't think this is what you intended. And I notice that his canonical Perl script was last updated 12 years ago, when the latest web browser from Microsoft was still IE 6.

Finally, the Hoedown engine used by MacDown is responsible for the behavior, since I reproduced it with the engine alone (with the command-line tool they provide, of course). So you may want to file an issue with them as well; MacDown would probably just conform to their decision (since it is easier than trying to hack their library).

Thanks for reproducing it with the engine alone.

What misled me here, is that the unexpected behavior does not appear in the preview pane. There, it shows the formatting as I'd expect.

Why does the engine do it wrong if the preview pane shows it correct (the way I expect)?

If the preview pane shows something inconsistent with the HTML output, then it must be a bug. I did not reproduce it though; **foo ** just previews as "**foo **" on the right on my El Capitan. May I have your MacDown and system version?

Mac OS version 10.12 16a319
MacDown Version 0.7d18 (766.1)

Nevermind. I retract my comment that it appeared correctly in the preview pane. Still frustrating, MouApp got this right, and Gruber's dingus does it correctly.

Talking about Mou:

I do not claim MacDown as the “spiritual successor” of Mou, and do not encourage such impression. MacDown is more like a Mou replacement if you must compare the two projects with each other.

Plus, Mou 1.0 has been a bad check for years, and Mou beta has not been updated for long, so I don't think it is a good role model, even though MacDown "stole the idea from it".

That's one way to think of it.

The other is, I found MacDown because Mou no longer works in Mac OS 10.12, and I was able to find it because of the strong association between the two. I opened documents I had been working on before Mou stopped functioning, and things which formatted correctly for years now do not. I was not inclined to place the blame at the hands of the tool that formerly worked.

Additionally, one of the characteristics of Markdown is that it allows the author to be a little lazy, and still work. This doesn't live up to that trait. It's weird, especially since you can do <strong>foo </strong>, it seems to follow you should be able to **foo ** just fine. And I used to be able to.

The strong and emphasis markers have always been difficult to get right. The rules are ambiguous, the (perceived reference) implementation spotty, and the logic simply does not work intra-word and with CJK languages (plus many more others without word delimiters). Gruber’s dingus works well in this case, but does not in many more, which is exactly why CommonMark came out with a new set of rules. If we are to explicitly conform to anything in the future, it will probably be CommonMark because it is the (only?) one that makes sense, not Gruber’s original spec.

I’m sorry for the situation, but I will have to mark this as not fix. It is impossible to satisfy everyone. That’s what Markdown is. Fortunately there are more than enough implementations for you to choose, and I have every believe you will find the one that suits you best.