Summmary
Summary: Remove the figure element.
Rationale
The following is the text for the initial bug[1] associated with this Issue:
Currently the HTML5 specification has an overly broad definition about what can be allowed in a figure element:
“The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.”
This is counter to understandings about figure in other businesses and environments, where figures are illustrative graphics of some form. In addition, this provides a confusing parallel in functionality between figure and aside, enough so that people are going to have a difficult time knowing which is which, and when to use one over the other. In fact, with this parallelism, we don’t need both.
All assumptions I have read on figure is people assume the element will contain a reference to an image of some form and a caption. Yet caption is optional, and it sounds like anything can be included in figure. The specification examples show a poem and a code block, in addition to an image.
The figure element either should be pulled completely, in favor of the aside element, or it needs to have a tighter focus in its definition. It should consist of a graphic element, which could be an svg element, a mathml element, an img, an object, or, possibly, a video. It should then have one other element, which will be the caption. Since this element won’t be a svg, mathml, img, object, or video element, it could be anything, including just a regular paragraph. In fact, a regular element styled using CSS would be the best option.
This change would remove any confusion about this element, and there will be confusion. It would also eliminate the problem with having to create a special caption element, just for figure, as discussed in Issue 83.
In a second comment to the bug, I also added the canvas element to the list of allowable elements. The Editor’s rationale for marking the original bug WONTFIX
Rationale: I actually agree with Shelley on this, and that’s what HTML5 used to say. However, it is one of the very few topics which got a _huge_ outcry from Web authors around the Web, demanding that <figure> be allowed to contain basically any flow content (including sections, headings, paragraphs, lists, etc). That’s why the spec says what it does now.
Originally, my interest was only in cleaning up the figure element; to make it more consistent with standard practice in the print world. The more closely I examined the element and the discussions about it, though, the more I felt that we would be better off eliminating the figure element altogether.
The reason for specialized figure handling in the print world is because of typographic convention. This doesn’t really apply in the web world, because we have elements that can group, CSS that can style, WAI-ARIA for accessibility and semantics, as well as other semantic options. If we want to move the figure away from the text, but still have the two associated, we can just by linking the two. In fact, we would have to anyway, because there is no way to associate a figure element with its text if the two are in separate contexts, unless they are linked in some way.
There’s a good reason for specialized figure handling in the print world, but not for web pages. Because we don’t have a good understanding of why we have figure, we can’t determine what it should contain. We only have to look at the discussions about what should be allowed within the figure element to discover that no one really has a clear idea of what this element is for, or how it will be used. Well, other than something with an optional caption, that is tangentially related to the content of the page (as if “tangentially” has a great deal of meaning in a web context, considering that anything can be tangentially related to anything else with the simple addition of a link).
The figure element, as defined in the HTML5 spec, is also a far different construct than what was originally intended. The figure element originated from discussions related to finding a way to attach a caption to an img element[2], somewhat like the caption we attach to tables, but allowing markup rather than just text like the table’s caption attribute. I’m not sure at which step in the evolutionary path it went from a caption to an img, to this all encompassing something with an optional caption we have today.
I did find emails from Michael Fortin[3][4] and Simon Peters[5][6], providing use cases for the figure element. Several of the use cases that Michael pointed out were to Apple online manual web pages. He classifies the code samples that Apple labels as listings, as figures. However, the Apple company itself, restricted the use of figure for illustrative images, only. For tables it used the moniker Table, for listings, Listing. As such, Apple’s own terminology undermines the credibility of these pages as use cases for allowing actual code samples as figures. More specific to the point of this change proposal, if we add a new element for figure, why not for listings, too? That’s also a separate typographical entity in the print world.
Other use cases provided ran the gamut from the pre element for ASCII art, to actual tables, though we already have a table construct in HTML. And when we try to limit what’s allowed, someone somewhere will dig up some actual use case online, somewhere, defending the particular use.
As can be seen, either we allow everything in the figure element in order to meet all possible sets of existing use cases online, in which case figure is really nothing more than a variation on the div element; or we restrict the element to a small subset of allowable elements, and continually fight the battle of, “Well, what about this? What about that?” All for an element that, in actuality, doesn’t provide much in the way of semantics or usefulness.
The figure element is really is nothing more than a grouping mechanism, as was noted back in the beginning of the discussion about the element[7]. So why don’t we use what exists now, rather than create something new?
I was reminded recently that the WAI-ARIA states and roles are useful beyond their primary task, which is provide information for screen readers such as JAWS and NVDA. Other “screen readers”, such as search web bots, like Google’s, can also make use of the semantic information they provide. Among the semantics we can define with ARIA is being able to assign an image role to a div element, and link the image’s caption to another HTML element.
As an example, in the WAI-ARIA 1.0 specification, there is an image listing that I modified, below:
<div role="img" aria-labelledby="caption">
<img src="example.png" alt="Some descriptive text">
<p id="caption">A visible text caption labeling the image.</p>
</div>
Compare with the figure element:
<figure>
<img src="example.png" alt="Some descriptive text">
<figcaption>A visible text caption labeling the image.</p>
</figure>
There is little different between the two, and the ARIA example has the added benefit in that it is implemented in many screen readers today. Best of all, there’s nothing about this example that disallows its use by search bots or other tools and applications, who can then attach the right caption for the element rather than have to scan the surrounding text to derive a caption, or using the alt text.
If the figure is located apart from the text that references it, giving the outer div element an id attribute allows us to link the figure in the text. If we don’t need a physical link, we can use terminology, such as Figure 1, Figure 2, and relate the text and the illustration using this approach. There is nothing about the figure element that changes how the text/illustration are connected—you still need to link the two, or use the caption, itself, to connect the two.
You don’t have to use an img element within the div element. You don’t have to use a div, either. For the pre/ASCII art use case, attach the role and aria-labelledby attributes to the pre element:
<pre role="img" aria-labelledby="caption">
...
</pre>
It’s also a simple matter to style whatever we use, too. For instance, a CSS setting for the img example could be the following:
[role="img"]
{
margin: 10px;
border: 1px solid #ccc;
}
[role="img"] p
{
margin-left: 20px;
font-style: italic;
font-size: .8em;
line-height: 1em;
}
We could also further annotate the element using one of the three available semantic annotation technologies available to us: RDFa, Microdata, and Microformats. In fact, we’re overrun with an abundance of semantic annotation capability—too much so to worry about creating single purposed elements supposedly for semantic reasons.
Details
Based on the March 4th HTML5 specification, remove Section 4.5.12, on the figure element. Also remove any additional references to the figure element. In addition, remove Section 4.5.13, on the figcaption element, and any reference to it, too.
Impact
Positive
This alternative to figure I’ve provided in this change proposal is a frugal one that serves the same purpose for multiple user agents, multiple audiences, and uses available technology and specifications. It allows people to create any form of illustration, and ensures they’re accessible.
Removing the figure element and associated figcaption element, helps trim down the overlarge number of elements that have been added with HTML5. Each new element we add to the specification has a related cost when it comes to implementation—not only across browsers, but also other tools, such as HTML editors, and HTML generation tools.
In addition, encouraging the use of existing HTML, CSS, and ARIA properties and attributes also encourages reuse over creating new, which should be a fundamental goal of this group. If there is a strong rationale for creating something new, and there really isn’t a good alternative, then we can feel justified in creating new elements. However, in the case of figure, as both Michael and Simon have pointed out, we’ve made do with what we have today. We can improve what we have with the addition of the ARIA states and roles, and ensure both a semantic and an accessible solution.
Negative
Change will require HTML5 editor time. As far as I know, there is no implementation of figure in browsers or other tools, and there is no dependence on it that I can see in web pages. There might have been some modification to validation tools to support the figure element.
References
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8404
[2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-November/007859…
[3] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-June/006828.html
[4] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-July/012194.html
[5] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-December/008301…
[6] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-December/008302…
[7] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-June/006822.html