This sample has a lot of markdown syntax that shouldn't be supported according to the docs.
{
"$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
"type": "AdaptiveCard",
"version": "1.0",
"body": [
{
"type": "TextBlock",
"text": "## Markdown Headers should not be supported"
},
{
"type": "TextBlock",
"text": "___"
},
{
"type": "TextBlock",
"text": "Neither should horizontal rules"
},
{
"type": "TextBlock",
"text": "Some of my spaces are being eaten up by the markdown parser"
},
{
"type": "TextBlock",
"text": "~~Strikethrough should not be supported.~~"
},
{
"type": "TextBlock",
"text": ">Quote blocks should be ignored"
},
{
"type": "TextBlock",
"text": "Markdown | Tables | Work\n:--- | :---: | ---:\n*And* | change | **horizontal alignment**\n1 | 2 | 3"
},
{
"type": "TextBlock",
"text": " This one I don't really understand"
},
{
"type": "TextBlock",
"text": "````\nBut Seems to be a shortcut for code blocks, which should be ignored."
}
]
}
Renders as:

Inline images also work via markdown:
{
"$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
"type": "AdaptiveCard",
"version": "1.0",
"body": [
{
"type": "TextBlock",
"text": ""
}
]
}
renders as

This one is interesting:
So, how can we address this?
For .NET we forked a library and customized it. For the iOS/Android/UWP we are working through options, including writing a shared parser/implementation in our C++ layer. There are plenty of references out there, it seems like rolling our own given the very limited set of markdown options might be the best way to go?
we've found implementing markdown subset is not easy work :tired_face:
even if the spec becomes clear, it is difficult to use existing library as is.
I think adaptivecards is expressive enough even without markdown support
e.g.
selectAction instead of markdown hyperlinkfacts and columns instead of markdown liston the other hand, i hope auto linebreak and inline text emphasis feature since these are most wanted features by our developers.
but other markdown features can be replaced by adaptivecards itself.
@andrewleader / @matthidinger / @paulcam206/ @dclaux is this addressed with 1.2 changes all up across all platforms? What should be the expected behavior wrt markdown in textblocks and richtextblocks resp with 1.2?
No, this isn't addressed, but it's something we need to do. This inconsistent behavior leads to confusion. Users expect that what you see in the designer is what you get everywhere else.
Problem is we may not be able to control it unless we provide a built-in Markdown processor. We don't load markdown-it, and I'm not sure we can reconfigure it after it's been loaded by the host application. Plus, using Markdown-it isn't a requirement.
I'll table this in that case for 1.3 addressing. @andrewleader what are teh next steps here for this to result in a Markdown-related requierments spec for 1.3 ? THanks!
Working with @andrewleader to create a "parent" "Markdown support in TextBox" task/issue for 1.3
@dclaux FYI likely moving this to 1.3 (adding a checkbox that lets textbox element have the option to "opt-out" of markdown
FYI the ReactNative team did in fact implement their own markdown processor. @vasanth-s can provide details. Ideally we could use the same or similar code in the plain JS renderer to bundle official AC markdown support in the renderer
@Vasanth-S / @matthidinger This is the markdown parser we are using for our react-native implementation. Currently, it supports the below 5 types:
You can refer the same to support web-based markdown processor. In case, if you need any help, we are happy to work on that.
No immediate requirement to do this at this point. Chatted with @dclaux ; moving this out to our backlog to revisit.
Most helpful comment
@Vasanth-S / @matthidinger This is the markdown parser we are using for our react-native implementation. Currently, it supports the below 5 types:
You can refer the same to support web-based markdown processor. In case, if you need any help, we are happy to work on that.