Should IMG tag be placed in a P tag... in HTML5... in 2020

[SubhashBrowser]

The image element, being an inline tag, used to be placed inside a P tag, which is a block element. That was in the days of XHTML and strict.

In HTML5, many old restrictions have been eliminated. But this IMG in P thing continues to exist. A paragraph tag is for text. Semantically, the IMG can should have been placed in a DIV tag, which is the more appropriate HTML option.

Using the CSS, inline elements can be converted to block elements. Hence, there is no need to place them in P tags.

img.align_right { float: right; margin: 0 0 1em 1em; }
img.align_left { float: left: margin: 0 1em 1em 0; }
img.align_center { display: block; margin: 1em auto; }

I write my books in Markdown. Unlike the Web, paragraphs in a physical book do not have spacing between them. Instead, the first line is indented. If I specify first-line indenting for paragraphs using CSS, then paragraphs containing images also get indented. It can be fixed with more CSS and appears fine in desktop browsers. However, when the CSS is processed by ebook creators (EPUB, MOBI) or Amazon KDP, formatting goes for a toss.

CommonMark should provide some way to write IMG tag directly to HTML without the P envelope.

[Crissov]

Arguably, images that are the only content of a paragraph, i.e. have empty lines before and after, should be made a figure instead, if the output format supports this – HTML does only after version 4.01 with the introduction of <figure>.

Image tag should expand to figure when used with title

With the syntax for images supporting titles in http://jgm.github.io/stmd/spec.html#images it would be great if the image tag would expand to a figure with caption like:  <figure> <img src="/url" alt="alt text"> <figcaption>My caption</figcaption> </figure> This is a departure from what is currently out there but an often requested feature that should find its way into the spec somehow (even with an alternative syntax).

Creating figures with a caption depending on context (no markup natural convention)

Hello everyone. I’m a new user, although not a new reader of this forum. I would like to propose a new extension addressing figure-like constructs in markdown. First my stance on markdown: what is neat in markdown is the fact that it reuses well ingrained written conventions in order to provide semantics and do a good job interpreting as HTML. In several discussions talking about figurification (sorry I made up a word) and adding captions I was struck by the unnatural constructs proposed to do …

[SubhashBrowser]

Right. Figure is the tag that CommonMark should use for images. It will save a lot of problems for ebook writers.

[chrisalley]

Because CommonMark aims to be “highly compatible” with existing implementations, I don’t think the core spec should be fundamentally changed to include figures.

However, there have been a number of discussions about different ways to implement the figure tag via extensions. My personal preference is for the community to unite around the iA Writer Content Block syntax for images in figures (and other embedded content), for which there is already a basic spec. Example:

Transclusion or including sub-documents for reuse

The generated HTML from /images/Structure.jpg (Data Flow) is: <figure> <img src="images/Structure.jpg" alt="Data Flow" /> <figcaption>Data Flow</figcaption> </figure> So, the figure caption doubles as the image’s alternative text, making it easier (and less repetitive) to add captioned images to a document quickly. There was also some discussion earlier about making alt text optional in some scenarios (e.g. quickly adding a set of images to a forum post), so this might be a nicer solution for…

[SubhashBrowser]

The default output can be highly compatible but cmark can have an optional command-line parameter to generate HTML5 content and replace old-style anachronisms such as p+img with figure. There is no reason for compatibility of the output if the user does not want it. I think, in HTML4, unknown tags are treated like DIVs. So, even if figure is generated, it will be more welcome than P. Unknown tags can also be styled in HTML4 using CSS.

[Brian_Lalonde]

How are we defining “highly compatible”? Is this by viewer market share? What systems aren’t aware or capable of figures in 2020?

[chrisalley]

Highly compatible with existing Markdown implementations. So, if you have some markup, a CommonMark parser should render the same output (or very close to the same) as markup rendered by a non-CommonMark Markdown parser such as Kramdown or Markdown.pl.

Because <figure> is a completely different HTML tag with a different meaning to <img>, I think figures are beyond the scope of the core spec are should be specified in an extension/add-on spec.

[jgm]

Pandoc has long had an implicit_figures extension that converts a
paragraph containing only an image (with non-null description) into
a proper figure with the description as the caption.

That is nearly almost better than a p containing an img. And it
can be implemented on top of existing cmark (or commonmark.js),
because it just requires manipulating the AST; no changes in the
parser itself are needed.

However, it doesn’t really provide the flexibility needed for
proper figures. There’s no way to have block-level content in
the caption. There’s no way to specify a short caption. There’s
no way to have alt text distinct from the caption. There’s no
way to have a figure with multiple images. This has led me to
think that a dedicated syntax for figures may be needed.

For relevant discussion see

Explicit Figure element in Block

[chrisalley]

What do you think of the content block spec @jgm? No doubt some advanced cases aren’t covered by it, but next to most other proposals, for individual figures, the syntax is relatively clean. Perhaps this could be combined with a block syntax for advanced cases?

For example, we have this figure example which @mb21 posted in the GitHub thread:

Using the content block syntax within the block syntax, something like this might be workable:

:::
/gull.jpg "a) A gull"
/tiger.jpg "b) A tiger"
/mouse.jpg "c) A mouse"

Figure 1: Picture of animals
:::

The nice thing about the content block syntax is that it keeps adding embedded content concise in simple cases, which will be the only cases for many writers.

[Alisher]

FOR EVERYBODY WHO SEEKS RIGHT ANSWER:

Do not do such mistake! Do not place img in figure just because there is nothing else. Place it in

, that will be semantically correct. If you care about SEO, you should use such tags for specific reasons listed down bellow:

- is a grouping tag, that contain objects related to sectioning content around this tag. Use img+p tags when you need to tell search engine, that this image must be there and nowhere else on this page. Examples for

: Let’s take youtube. There is a list of videos on the main page. All the videos contain heading, thumbnail, channel name, date, count of views. In this scenario you should tag: Heading - h tag Thumbnail - p tag with img inside Channel name, date, count of views - as p inside of footer or header depending on your message to search engine. (If you ask me, I would make them wrapped in footer tag, because most of the time this data is mandatory, but user do not make decisions on watching or not on this matter) - is a sectioning root, that's a specific category of semantic tags, that tells search engine that this content could be cut from this article/page without harm to main content and it still will have meaning itself. BTW this tag can be used not only for image, but for anything. Use tag figure when you need to tell search engine, that content inside can be placed anywhere on this page and it will not break the meaning of this page.

[rokejulianlockhart]

@Alisher

Do not do such mistake! Do not place img in figure just because there is nothing else. Place it in

, that will be semantically correct. If you care about SEO, you should use such tags for specific reasons listed down bellow:

- is a grouping tag, that contain objects related to sectioning content around this tag. Use img+p tags when you need to tell search engine, that this image must be there and nowhere else on this page. Examples for

@Alisher, you’ve not actually used any tags in your comment. Did you forget to escape them (so that they render as <tag>)?

`<tag>`