Adaptivecards: Unable to put a literal * into visualizer

[matthidinger]

Depending on the number of * it behaves differently. Escaping it doesn't seem to help either

{
  "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
  "type": "AdaptiveCard",
  "version": "0.5",
  "body": [
    {
      "type": "TextBlock",
      "text": "**********",
      "wrap": true,
      "maxLines": 2
    }
  ]
}

[dclaux]

It functions per markdown spec. Every line of text is processed with markdown. The only thing I can think of would be to have an explicit property on TextBlock to bypass Markdown processing.

[dclaux]

The official solution is this:

<pre>*********</pre>

But that won't work in the visualizer.

[matthidinger]

<pre> seems like a very HTML-specific fix doesn't it? It seems weird to have to put an HTML tag in a general card, especially if you are only sending things to iOS or Windows, etc. I wonder if we need to consider either a better escape mechanism, if possible, or have a property to disable markdown processing as you suggested.

[riarenas]

I think there's a few things to consider. Do we want to support full markdown syntax in Textblocks, or limit it to what we have in the spec right now? ie. Bold, italics, possibly links.

[matthidinger]

We should kickup another topic on what specific markdown features we want to support.

For this particular issue, I was thinking maybe we introduce a LITERAL() function similar to our DATE and TIME functions.

"text": "Hello LITERAL(***)"

Would output Hello ***

[andrewleader]

My quick thoughts on this is that by default, markdown should NOT be enabled. Otherwise you're going to get devs passing in plain text from users (like an IM message) which potentially has things like ** and it'll get stripped away or changed due to markdown.

I don't believe most devs are going to understand/think that the text blocks use markdown by default, and therefore they won't know they need to pre-process and escape their text before inserting it into the card they're generating.

Therefore, opt-in for markdown would make more sense. Those that are explicitly using markdown can enable support for it on a per-textblock basis.

[shalinijoshi19]

@andrewleader / @matthidinger / @dclaux is this still relevant today and would using RichTextBlocks with the markdown support solve this ?

[dclaux]

Still relevant today. My preferred solution is to allow opting out of Markdown. Like Andrew I would rather make it an opt-in thing, but we have shipped with Markdown processing always applied. We can't remove that.

[andrewleader]

would using RichTextBlocks with the markdown support solve this ?

You mean RichTextBlocks without markdown support, and yes that would solve it, but that's a less-ideal way of solving it. We simply need to have a property on TextBlock that lets you disable markdown.

[shalinijoshi19]

Thanks this helps with context and i also tried it in the designer and noticed the irregularity Matt had been noticing where text is being interpreted as markdown by default! Which is not intuitive.
So we definitely should provide for a way to not have text interpreted as markdown (correct @andrewleader ).. That should be straightforward i hope - @andrewleader am assuming we can go ahead and annotate this issue so we can get the right number of platform-specific bugs filed? Could you let me know the worfklow (offline fine)? thanks!

[shalinijoshi19]

@andrewleader assigning to you temporarily to help create the platform-specific bugs; please reassign to me once we have teh platform-specific bugs are created! Thanks

[matthidinger]

We have another issue where we discuss possible designs for this, and should revisit them. There are at least 3 decent ways to solve this which have been proposed. Searching open markdown issues should hopefully find it

[msftbot[bot]]

Hi @matthidinger. We have acknowledged this issue report. Please continue to follow this issue for updates/progress/questions.