jgm / djot

A light markup language
https://djot.net
MIT License
1.66k stars 43 forks source link

Syntax for block-level images #87

Open matklad opened 1 year ago

matklad commented 1 year ago
Obligatory [XKCD 927](https://xkcd.com/927/):

![xkcd 927](https://imgs.xkcd.com/comics/standards.png)

An obvious idea is to use Rust for task automation.

The intention here is for the image to be a block-level element. We however wrap it in a paragraph in this case:

doc
  para
    str s="Obligatory "
    link destination="https://xkcd.com/927/"
      str s="XKCD 927"
    str s=":"
  para
    image destination="https://imgs.xkcd.com/comics/standards.png"
      str s="xkcd 927"
  para
    str s="An obvious idea is to use Rust for task automation."

AsciiDoctor have separate sytaxes for inline-vs-block images: image:url vs image::url. But presumably we can just notice that the image stands alone and not wrap it into a paragraph?

Or maybe this already is working as intended, and it's on the converter to auto-magically treat single-image paragraphs as block images?

matklad commented 1 year ago

cc https://talk.commonmark.org/t/should-img-tag-be-placed-in-a-p-tag-in-html5-in-2020/3525/8

jgm commented 1 year ago

it's on the converter to auto-magically treat single-image paragraphs as block images

This is what pandoc currently does (and has done for a long time) -- it's the implicit_figures extension. However, we've realized (also for a long time) that it would be better to have an explicit markup for block figures. https://github.com/jgm/pandoc/issues/3177

bpj commented 1 year ago

IMO the right syntax is fairly obvious:

{width=18cm}
!!!
![Alt text](path/to/image.ext)
: Caption goes here
!!!

Of course with 3 being the minimal number of bangs in the fence.

chrisjsewell commented 1 year ago

Note this has some overlap with #28

chrisjsewell commented 1 year ago

Would something as simple as having multiple ! be ok?

!![block level image](path/to/image.ext)
uvtc commented 1 year ago

It seems like this issue is related to #31 , no? I'd assume that a figure would be a block-level element that would likely contain one or more images.