`fig-alt` attributes is not correctly processed on image for gfm output.

[cderv]

I think we are just not handling fig-alt (which is a quarto image attribute https://quarto.org/docs/authoring/figures.html#alt-text) for gfm format. 🤔

---
title: "Untitled"
format: gfm
---

![](surus.png){fig-alt='A placeholder image'}

gives

# Untitled


<img src="surus.png" data-fig-alt="A placeholder image" />

which seems unexpected to me

Originally posted by @cderv in #12443 (reply in thread)

[mcanouil]

If there is no other attributes, there is no reason to output HTML.
The alternative text in GFM is the fig-cap in Quarto.

[cderv]

We currently transform fig-alt to alt in post-render-html-fixup

quarto-cli/src/resources/filters/quarto-post/html.lua

Lines 63 to 79 in d9f1872

	Image = function(el)
	-- FIXME we're not validating here, but we can't use figAlignAttribute because
	-- it picks up the default value from the document metadata, which is not
	-- what we want here.
	local align = attribute(el, kFigAlign, nil)
	if align ~= nil then
	el.attributes[kFigAlign] = nil
	el.classes:insert("quarto-figure")
	el.classes:insert("quarto-figure-" .. align)
	end
	local alt_text = attribute(el, kFigAlt, nil)
	if alt_text ~= nil then
	el.attributes["alt"] = alt_text
	el.attributes[kFigAlt] = nil
	end
	return el
	end,

I think we need to do this fixup for any format that supports HTML

quarto-cli/src/resources/pandoc/datadir/_format.lua

Lines 144 to 147 in d9f1872

	-- check for markdown with raw_html enabled
	local function isMarkdownWithHtmlOutput()
	return (isMarkdownOutput() and tcontains(PANDOC_WRITER_OPTIONS.extensions, "raw_html")) or isDocusaurusOutput()
	end

If there is no other attributes, there is no reason to output HTML.
The alternative text in GFM is the fig-cap in Quarto.

But we could also modify the feature and move fig-alt in the correct place for markdown writer output 🤔

[cderv]

Fun fact: alt is processed correctly when it is an attribute by Pandoc

❯ pandoc --to gfm
![](surus.png){alt='A placeholder image'}    
^Z
<img src="surus.png" alt="A placeholder image" />

❯ pandoc --to gfm
![Caption](surus.png){alt='A placeholder image'}
^Z
<figure>
<img src="surus.png" alt="A placeholder image" />
<figcaption>Caption</figcaption>
</figure>

No alt

![Caption](surus.png)
^Z
<figure>
<img src="surus.png" alt="Caption" />
<figcaption aria-hidden="true">Caption</figcaption>
</figure>

which is because of implicit figures

❯ pandoc --to gfm --from markdown-implicit_figures
![Caption](surus.png)
^Z
![Caption](surus.png)

Quarto does not use Figure from Pandoc I think. So we need to check the different results too

--- format: gfm --- {alt='A placeholder image'}	<img src="surus.png" alt="A placeholder image" />
--- format: gfm --- {alt='A placeholder image'}	
--- format: gfm --- 	

The second result does not seem right. And our doc state clearly that it should be possible to set caption and fig-alt. 🤔

Something to look into IMO.

[cderv]

Other fun fact: for HTML, we don't keep alt (but this is probably why fig-alt to match other figure attributes)

--- format: html --- {alt='A placeholder image'}	<div class="quarto-figure quarto-figure-center"> <figure class="figure"> <p><img src="surus.png" class="img-fluid figure-img"></p> <figcaption>Caption</figcaption> </figure> </div>
--- format: html --- {alt='A placeholder image'}	<div class="quarto-figure quarto-figure-center"> <figure class="figure"> <p><img src="surus.png" class="img-fluid figure-img" alt="A placeholder image"></p> <figcaption>Caption</figcaption> </figure> </div>

unless there is no caption meaning this is not a figure

--- format: html --- {alt='A placeholder image'}

<p><img src="surus.png" class="img-fluid" alt="A placeholder image"></p>

[cscheid]

If you use our trace viewer, I think you'll notice that the Figure Pandoc node is not getting processed appropriately. It's a recurring source of bugs for us, unfortunately. We move much of the AST as we can to FloatRefTarget nodes but we decided to preserve some Figure nodes.

At the time, we decided to do it in this way because users might expect Figure to work (especially if they choose to emit pandoc.Figure nodes in their filters). I now regret the decision, but we're sort of stuck with it.

Ideally, we need a proper code review and more extensive regression tests for Figure nodes in our Lua filters.

[cderv]

If you use our trace viewer, I think you'll notice that the Figure Pandoc node is not getting processed appropriately. It's a recurring source of bugs for us, unfortunately. We move much of the AST as we can to FloatRefTarget nodes but we decided to preserve some Figure nodes.

Yes I am aware of that. This explains the difference between Pandoc processing and Quarto processing.

But still, even if we don't process Figure node, then the handling should be similar between HTML and Markdown that supports +raw_html, like gfm.

It feels to me that without changing how we process Images and Figure, we can do better for gfm output.

[david-hodge]

Only a small part of what you've observed, but your first example above in #12456 (comment) might possibly be this issue I raised last year and was briefly broken and then fixed between versions 1.3, 1.4 and 1.5. I think you may even have diagnosed the source back then. Of the alt tag being eaten in the context of a caption being provided.

This was the issue: #9535 (#9535 (comment))