The Figure Element

Robert Crowther Jan 2022

Last Modified: Feb 2023

The figure element was introduced recently, in HTML 5, which started to be used around 2017,

<figure></figure>

It introduces some semantic capability to HTML, but also challenges to typographic understanding.

Recommendations

Content to be wrapped in figure tags is a (usually small) section that transforms content in text
Intuitively, that means figure tags will be round most non‐text content intended for block‐level display i.e. that you feel would sit in a paragraph
However, there are deviations from the intuitive. Some paragraph level items are part of text flow, so should not be wrapped in figure. Some items are not in text flow, so should be an aside e.g. advertisements, pull quotes, navigation menus
If software is not sophisticated, err on the side of wrapping all block/paragraph type content in a figure element. This includes objects, images, tables, and quotes. The exception is blockquote, do not wrap a blockquote in a figure.

Note that elements contained in figures may have use elsewhere, not in figures. For example, if used as above, an image will be a figure, but images can also be used as text decoration e.g. decorative headlines.

As always, remember I’m no expert. The full story…

In practice

If you read a few articles on the web, you will get practicality—“the figure [element] lets you add a caption”. So,

<figure>
  <img src="factory.png"/>
</figure>

can be decorated with the also new figcaption element,

<figure>
  <img src="factory.png"/>
  <figcaption>
    Factory, Pensylvania
  </figcaption>
</figure>

We shouldn’t ignore this. People will be marking up all over the web in the way they are saying. And perhaps firms will be working with this, and assume semantic meaning.

What the spec says

Figure is classed as ‘flow content’, which glossed means anything that is content, not metadata or meta‐structure. And it contains flow content. It is a sectioning device, which is an important duty—it means the figure element interacts with article and section elements, and the implicit sections generated by headings, as part of document structure.

the spec is keen to point out that figures are related to text flow. If they are not related, they are an ‘aside’. On the other hand, they are not text flow. This is a quote from the spec on an example they supply,

The first image [of a blockquote] is literally part of the example’s second sentence, so it’s not a self‐contained unit, and thus figure would be inappropriate.

The spec talks about ‘self‐contained’ data several times, saying that a figure should be self‐contained. While that may be true, I think an easier rule of thumb may be, ‘is this a media transformation of text content’? For example, I write,

Whitworth screw threads are an old thread standard that can still be found in machinery today.

But as a media transformation of that, I provide a table, an old advertisement, or a video link. This new content may re‐enforce the point in the text, or be for further pursuit by the interested. That is a figure.

What typography says

I can’t afford the books, but from what I can source, typography says that a figure is something like a ‘non‐text block of content’. Non‐text excludes quoting. Block here means specifically, non‐inline, not part of text flow, not positioned relative to text flow (like a float) but a break in text flow. However, typography seems to retain the word ‘figure’ for images, graphs etc. (go figure).

In typography, but I’ve never seen in HTML, figures are given a separate table of contents. Also tables, used in much the same way as figures, usually get their own table of contents.

Typography also has something to say about other text decorations. It has long been a feature of some forms of writing to lead chapters and/or books with an interesting quotation. These are called epigraphs. Similarly, a book may include occasional illustrations, or a frontpiece.

Typography does not have the idea of blockquotes, it uses the word ‘verbatim’, and may include ideas like ‘boxed/ruled text’. For our use, it would seem these are much the same as the HTML blockquote element, which may offer a more decisive abstraction.

Typography, as far as I know, has much the same distinctions as HTML about pictures (images), figures, and labels (captions).

Use of figure in HTML

Putting this together, the two theoretical bases seem to be in agreement over the use of images, and whether they are a figure or not. Lists, incidentally, are almost always not a figure unless (exceptionally) the list is quoted from elsewhere and in illustration e.g. ‘Doctor Brogenbroom’s seven points for a successful life’.

However, we do have this case now that there are two kinds of content that is large enough to need a visual block. There is content that is standalone/transformative so is a figure, and content that is necessary to text flow. More talk about this further down.

Meanwhile, lets look at how the figure element can/should be used with other common HTML elements.

Tables

HTML spec says a table is ‘flow content’. Tables may have a caption element. For our purposes, we don’t need to know about construction.

This is not helpful, as all visual elements in HTML are ‘flow content’. Is a table section content? The spec makes no mention, so I assume not. Fortunately, in a description of how to place captions, the spec includes examples of tables wrapped in figure tags. So, with no explanation, which I admit is not convincing, it seems the figure element can wrap tables.

To establish the typography concept of tables, the document needs to maintain two lists, one of figures, one of tables. These will render in much the same way, perhaps with common visual tropes, then lead to similar but separate tables‐of‐content. In HTML, the examples suggest these are mashed into one concept, the figure.

In the course of an example with descriptive title (‘the blue line means..’) the HTML spec seems dismissive of table captioning/titling,

The best option, of course, rather than writing a description explaining the way the table is laid out, is to adjust the table such that no explanation is needed.

Perhaps this is for descriptive legends, but doesn’t convince about the thinking here. That said, the committees involved are wrestling with the old specs, people’s requirements and usage, and their own conceptualisations,

Anyway, the upshot is reasonably clear. Unless HTML markup tools are sophisticated, and there is a need to create tables as visual asides, or a need to make tables which flow with text that can not be read otherwise, HTML tables should be wrapped in figure tags.

<figure>
  <table>
    content...
  </table>
</figure>

BlockQuotes

First, I push the ‘quote’ element aside. It is for sure phrasal, or to most people ‘inline’, content.

The element that involves us is ‘blockquote’. This element has been around for years. It seems to suggest that the early web had an instinctive need for a figure for quotes, so specified the blockquote. Though the element predates concepts of figure and caption, that’s how it would be conceptualized now.

First, as discussed above, text that is quoted in a block may or may not be a ‘figure’. Like images, there may be quotes that are asides, and that are critical to textflow. They should be marked up differently.

What does the spec say? It says a blockquote element is a ‘sectioning root’. This is important. It means a blockquote is AsFarAsIKnow currently regarded as a quote wrapped in a figure. And I suppose that, because it is implicitly a figure/‘sectioned content’, the blockquote should not be wrapped in another figure.

This gives us a headache. People may ask, “How do I then caption a blockquote?” The answer to that is awkward, though not impossible. In typography, blockquotes are rarely titled. They are usually cited and yes, the HTML spec encourages cite elements in blockquote elements. But the initial query is valid enough. As would be, “How do I markup an essential but substantial piece of quoted textflow?”

I don’t know the answer, and am not in a position to ask the questions. But I would suggest that one way out is to regard the blockquote element as I have described, an instinctive impulse from the past that has not necessarily lived beyond it’s time, but sits as a shortcut in modern HTML spec concepts. Blockquote is a shortcut for,

<figure>
  <quote>
    content...
  </quote>
</figure>

The blockquote element is no more or less clumsy than the above. Though the above will let you add a figcaption element, which is semantically impossible with a blockquote.

One thing that HTML will allow you to do, thank goodness, is add a cite element wherever you like.

Code and figures

Finally, we have a slight issue with code elements. Fortunately, if you have read the above, we do not. Code blocks come in two forms— those essential to text flow, or transformative stand‐alone. And it is clear that code examples represent a text transformation. This would be a transformative stand‐alone code‐block,

<figure>
<pre><code>
   ...
</code></pre>
</figure>

How to markup ‘essential to text’ blocks?

So far we have said that there are two kinds of block‐rendered text content. And mentioned that if in doubt, content large enough to go in a block should probably be wrapped in figure tags. And that there may be software problems rendering as anything else—it is unlikely any convenience markup can express the difference.

But what if the HTML‐generation software or process can express the difference? How would ‘essential to text’ blocks be marked up? The point is, it must be marked up somehow, otherwise, it has no semantic meaning and, practically, there is no way to apply CSS. Is this to be rendered inline or as a block?

<quote>Not fade away</quote>

Definition of an ‘essential to text’ mark

The purpose is to create a generic mark that indicates a division of content. The content is either not text, or is transformed/specialised text, such as a quote or code. However, unlike the contents of a ‘figure’ element, the content is essential to text reading. Also unlike the figure element, the mark has no structural effect. However, the mark will indicate that the content is large enough to need a block for visual presentation. It will not fit into visual, and perhaps aural, text flow.

You may feel the mention of visual presentation means this is a style concern, but it is not. The element will mark transformed content, and will do so generically. In much the same way the ‘empth’ element indicates a change of tone in text.

As far as I can tell, such a mark does not exist. ‘object’ is intended for active objects in a page.

What is the name of this ‘essential to text’ mark?

This is the kind of decision I feel a committee makes better. Yes I do. But I’ll discuss. Also, I’m going to give examples as element tags. Discussion under next heading.

It may be tempting to follow the name ‘blockquote’, for consistency. But we need something generic, to wrap round any content. How about,

<block>
...
</block>

But this seems too generic. Is a ‘block’ a structural item? We could mention ‘text’, as it represents a ‘block’ in text. But ‘textblock’ or ‘blocktext’ will not work, as they suggest a type of content.

So maybe,

<blockcontent>
...
</blockcontent>

Has some appeal, if a little long.

There is the possibility of mentioning the action, so ‘flowblock’. Against is the fact no other HTML uses action words, and the word is uncomfortably close to current CSS usage.

Another thought I had was to abandon ‘block’ and use the generic nature of ‘div’. ‘textdiv’ has the same problem as ‘textblock’, it suggests content. For a while I used,

<divblock>
...
</divblock>

Which I like as a word. However, these are not divisions at all, the point is they are essential to phrasing content. So I’m now using an embattled word,

<spanblock>
...
</spanblock>

And you may find some on this site. Anyway, there is no standard, so it’s your decision.

Mark as tag or attribute?

The way most people would instinctively solve this would be to add a class. You may feel, and I do a little, that there is no argument for a new element for an item that seems largely to be visual. Another consideration is that a class is easier to change, both in development and existing code.

Yet you can’t escape that there is no representation for this case that the HTML spec outlines. And if you think of it that way, this mark is semantic. And that an element definition will sit well next to text elements like ‘emph’.

As a class definition, the three types of content referred above look like this,

<table class="spanblock">
  content...
</table>

<quote class="spanblock">
  content...
</quote>

<pre><code class="spanblock">
  content...
</code></pre>

The element solution looks like this,

<spanblock>
  <table>
    content...
  </table>
</spanblock>

<spanblock>
  <quote>
    content...
  </quote>
</spanblock>

<spanblock>
<pre><code>
   ...
</code></pre>
</spanblock>

…and now I veer towards preferring a new element, as it is a complement to the ‘figure’ element and makes CSS clear. But it is your call.

Last note

Figure is a new piece of HTML, and from what I have seen is not used, or arbitrarily thrown round markup. I think it’s an element that allows me to be clearer in semantic meaning, and make cleaner CSS. I hope it will not blink.

And aside, the page you are reading may not follow the arguments or recommendations above. We all have software battles to fight.

References

The HTML Standard, figures section,: https://html.spec.whatwg.org/multipage/grouping-content.html#the-figure-element
Wikibooks writeup on Latex, figures section. Not theoretical, but description of a system based in typographical theory,: https://en.wikibooks.org/wiki/LaTeX/Floats,_Figures_and_Captions