Don't remove curly braces from alt attribute of an image in MDX

[talatkuyuk]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and discussions and couldn’t find anything (or linked relevant results below)

Affected package

remark-mdx

Steps to reproduce

curly braces {} are removed from alt attribute of an image when parsed by remark-mdx.

This is related with syntax-tree/mdast-util-from-markdown#44

Actual behavior

Regarding with {},

• mdx expressions in the link (anchor) text for example [**{name}**](...) are interpolated, parsed into inline markdown, and produce a JSX like <strong>{name}</strong> equivalent, as expected in MDX, it is okey.
• however, in the image alt for example ![{name}](...) produces <img src="..." alt="name">, but should produce <img src="..." alt="{name}"> as the commonmark spec says. If I use double curly braces in alt, one curly braces appear in my tests. ![{{name}}](...) produces <img src="..." alt="{name}">, meaningly mdx parser does not remove all curly braces.

Expected behavior

At least I would expect curly braces are preserved in "alt" once remark-mdx parses since commonmark spec also keeps the curly braces in alt attribute. (see in dingus)

%100 commonmark compliance is always mentioned in the docs!

Curly braces in an image like ![{here}](...) should not be removed, especially considering that MDX is still markdown at its core, just with JSX extensions.

Whereas the title of image/link can hold {} even in MDX, why alt can not hold {} inline with commonmark ? Why I've insisted on that issue this is because of that

As a conclusion, the authors of the MDX spec should allow to appear {} in alt attribute in order to meet the commonmark compliance.

Runtime

node@22

Package manager

npm

Operating system

macos

Build and bundle tools

No response

[wooorm]

Hi again! :)

At least I would expect curly braces are preserved in "alt" once remark-mdx parses since commonmark spec also keeps the curly braces in alt attribute. (see in dingus)

This is expected with extensions to CommonMark.
Another extension is GFM. It adds support for strikethrough. [~a~]() b ![~c~]() is on the CM dingus <p><a href="">~a~</a> b <img src="" alt="~c~" /></p>, but on GH it is <p><a href=""><del>a</del></a> b <img src="" alt="c" /></p>

This all also has to do with that there is something different with how markdown as a language works, compared to how you see it.
You use the word preserve. That is something that a parser could do, when parsing. That could work if markdown saw ![ and then knew: I am in an image alt, I will not parse MDX expressions.
But that is not how the markdown parser works. It sees [, ![, and everything, and then only when it sees ] it will turn into a link or image. So it has seen the attention (syntax-tree/mdast-util-from-markdown#44) and MDX expressions (this issue) already.
Only then does it know if it can emit that <em> or <del> or has to drop them because tags don’t work in alt.

[talatkuyuk]

Thanks @wooorm, for the detailed explanation. You clarified how the parser works internally.

Just to confirm, given that the parser encounters {} before it knows it's parsing an image alt, the MDX expression is already emitted by that point, which leads to the current behavior.

I’d like to ask whether there’s any room, either in remark-mdx or in the upstream mdast-util-from-markdown, for deferring or conditionally suppressing expression parsing in contexts like image alt, where CommonMark would expect literal content.

Since the title field of images/links can contain {} as-is and is not subject to MDX expression parsing, would it be technically feasible to apply a similar constraint to the alt of images? I realize this might involve complicating the tokenizer or the phrasing content model, but I wanted to understand if such a direction has been considered or ruled out due to architectural constraints.

In short, would supporting literal {} in image alt (as per CommonMark) be theoretically possible in MDX, or is this fundamentally incompatible with the current parsing approach?

Thanks again.

[wooorm]

So, what you are asking for I see as moving further away from CommonMark. It turns:
![*a*]() -> alt="a"
![`a`]() -> alt="a"
![©]() -> alt="©"
![a [b](#) c]() -> alt="a b c"

So, with MDX, we turn: ![a {b} c]() -> alt="a b c". I see that as consistent with CM.

I provide these examples so that, if you want to look for an alternative, which may be possible, I’d first like to know what you want to happen to these 5 examples? What should the alt be?

Do you want to change all these cases? Or only the {, }s? Or do the other cases not matter?

[talatkuyuk]

I’m asking for only { and } to be preserved literally in the alt attribute as is the case in CommonMark itself. While turning ![a {b} c]() into alt="a b c" may align with the philosophy of CommonMark, it doesn’t actually comply with it.

For more clarifying, here are some examples that I am expecting:
![a {b} c]() -> alt="a {b} c"
![{a}]() -> alt="{a}"
![{{a}}]() -> alt="{{a}}"
![{a.b.c}]() -> alt="{a.b.c}"
![{a}{a.b.c}]() -> alt="{a}{a.b.c}"
![*{a}*{a.b.c}]() -> alt="{a}{a.b.c}"
![{*a*}{a.b.c}]() -> alt="{a}{a.b.c}"
![©{a}©]() -> alt="©{a}©"

I’m not proposing any broader changes to how CommonMark strips formatting in alt in general and regarding with 5 examples you pointed out. If any change were made regarding with 5 examples, in future, somebody will eventually raise an issue about non-consistency with CM.