Handling of <figure> links in Markdown

[alhirzel]

I wanted to bring to our attention a peculiarity of Pandoc's behavior wrt links in figure captions. When interpreting the following HTML (-f html -t markdown), the following results (<!-- in comments -->) are produced:

<figure>
	<img src="one.png" />
	<figcaption>One</figcaption>
</figure>
<!-- produces: ![One](one.png) -->

<figure>
	<a href="https://google.com/">
		<img src="two.png" />
	</a>
	<figcaption>Two</figcaption>
</figure>
<!-- produces: ![Two](two.png) -->

<a href="https://google.com/">
	<figure>
		<img src="three.png" />
		<figcaption>Three</figcaption>
	</figure>
</a>
<!-- produces:
[](https://google.com/]

![Three](three.png)
-->

Describe your proposed improvement and the problem it solves.

I think it may be worthwhile to make example Two or Three produce the following results:

[![Two](two.png)](https://google.com/)
[![Three](three.png)](https://google.com/)

and then to have these round-trip properly back to the original HTML. Right now, they convert (-f markdown -t html) to:

<p><a href="https://google.com/"><img src="two.png" alt="Two" /></a></p>
<p><a href="https://google.com/"><img src="three.png" alt="Three" /></a></p>

Describe alternatives you've considered.

I am not sure how to reconcile the two ways of expressing figures in HTML, as well as the multiple representations in Markdown. I bring this up for discussion and to elicit other ideas on how <figure> may be handled.

[jgm]

With the implicit_figures extension, a markdown image that is alone in its paragraph is parsed as a figure. If we included the surrounding link, we wouldn't have an image alone in its paragraph, and no figure would be produced.

[alhirzel]

Ah, I understand, so this behavior is expected based on how the extension is defined. (I didn't even realize this was an extension and that I had this extension enabled.)

I am not sure what the use cases are for the extension, so I am going to back-pedal and close this issue. I have worked around it by switching toward the <p><a><img> markup format in a pre-processing step. This particular application of pandoc is already wading in a swamp, so the stated workaround is not onerous. I appreciate your insight, John!

[tarleb]

Just fyi: we're working on fixing this. See #3177 and related issues.

[alhirzel]

@tarleb - thanks for the reference, I see there is a much deeper multi-format rabbit hole than I initially perceived (but should have expected, given how many facets Pandoc has).