Allow <figure> where <img> is allowed, in <p> in particular

Written by Henri Sivonen with contributions from Leif Halvard Silli (add your name here if you edit the wiki page).

Summary

The proposed change is making it possible (and conforming) for authors to use <figure> where <img> can be used. In particular, with this change, it becomes possible to use <figure> as the first child of <p>, which is useful for floating figures.

Rationale

Currently, HTML5 makes it impossible to for HTML authors to use <figure> as a child of <p>, because <figure> automatically closes <p> in the tree builder.

This is bad for authors on the conceptual level, because <figure> is primarily supposed to be a way to express images that have a caption, so being unable to use <figure> in places where <img> can be used is conceptually confusing.

This is bad for authors on the pragmatic level, because given the CSS features available to authors currently and in the foreseeable future, the easiest way to make the top edge of a float align with the top edge of the text in a block regardless of margin/padding/border on the block box is to place the float as the first child of the block. That is, one would want to place <figure> as the first child of <p> when making a floating figure associated with a paragraph. Floating figures are the typical expected use for <figure>.

For <figure> to be useful to authors, it is essential to make it easy to use <figure> where <img> can be used and, in particular, to make it easy to use floating figures within the practical constraints arising from the CSS formatting model as it is available to authors today.

The above is the rationale for making it conforming to use <figure> where <img> is conforming and the rationale for making <figure> not automatically close <p>.

However, making only those changes would make things confusing, because non-image figures, such as blocks of preformatted code marked up using the <pre> element, would automatically close <p>, and some kinds of figures couldn't be used inside <p> elements. This would be inconsistent and confusing. The problem is fixed by making <figure> prevent <p> autoclosing across it like <button>.

When <figure> prevents <p> autoclosing across it like <button>, it becomes unnecessary to propose that <figcaption> be made not close <p>. Hence, this proposal leaves <figcaption> as an element that autocloses <p>. (If <figure> become like <button>, it would be necessary to propose that <figcaption> not close <p>, either.)

Please note that this Change Proposal explicitly doesn't attempt to enforce any particular authoring practice. Instead, for pragmatic reasons, considering the Priority of Constituencies, this Change Proposal puts Authors ahead of Theoretical Purity by giving authors more options even if the options given could be viewed as possibilities for Authors to opt to violate Separation of Concerns.

Details

1. In the section The figure element, change "Flow content" under "Categories" to "Embedded content", change "flow content" under "Contexts in which this element can be used" to "embedded content" and in the text "The figure element represents some flow content" change "flow content" to "embedded content".
2. In the definition of have an element in button scope, add an item "figure in the HTML namespace" to the list.
3. In the Parsing HTML Documents section, replace all occurrences of "in button scope" with "in button or figure scope".
4. In the "in body" insertion mode, remove "figure" from the start tag token entry that now lists it. (To make <figure> behave like any other start tag. The end tag entry is left as is intentionally.)

Impact

Positive Effects

Legacy compatibility

Same way parsing → <p><figure><img><figcaption>Lorem ipsum</figcaption></figure>Dolor sit amet</p> would parse the same way in legacy browsers and HTML5-compliant browsers.

Authoring

Simple and logical floats → using the figure element as a child of the p element and float the figure box so that its top edge aligns with the top edge of the first line box in the p box regardless of the margin/padding/border on the p element. This is not only a practical thing – it might be entirely logical to place the image inside the p.

Simple logics = simple image captioning → to allow the figure element with img and figcaption as its children wherever the img element can be used is intuitive considering that figure is primarily a mechanism for attaching a caption to an img. It is difficult to answer the question why an image may have caption when it is placed outside a p, but not when it is placed inside a p.

Images and other figures are aligned → Once authors no longer care about browsers that don't implement this Change Proposal, authors will be able to use the figure element wherever an img element could be used regardless of the children of figure, which is intuitive. The figure element itself tells us that anything can be a figure, even ASCII art - it is not limited to embedded exterenal resources. This makes it difficult to explain, for example why one is permitted to place a “real”, embedded image inside a p, but not permitted to place an ASCII image inside a p.

Float anything, caption anything & anywhere → Once authors no longer care about browsers that don't implement this Change Proposal, the change proposed here would repair some of the damage caused by Acid2 and make it possible to put a floating table inside a p by placing the table as a child of figure and floating the figure.

Accessibility

Permission to use block elements inside object → HTML5 (unlike HTML4) currently considers the following as illegal nesting of p inside p: <p>Lorem <object data=foo ><p>Currently illegal nesting</p></object> Dolor.<p> This change proposal would offer an alternative way, which explicitly would separate the p's from one anothyer, namely the option to wrap the object inside a figure element:
<p>Lorem <figure><object data=foo ><p>Would become legal</p></object></figure> Dolor.</p>. (Note: This positive effect would a side effect of adopting this change proposal, but it would be possible to achieve the effect simply by modifying the conformance definition for the children of object independently of figure.)

Captions → The ability of an image to have a caption regardless of whether the image appeaers inside or outside a p element, is a positive thing for accessibility.

Negative Effects

• <p><figure><pre>Code example</pre><figcaption>Lorem ipsum</figcaption></figure>Dolor sit amet</p> (where pre is an example of any element that autocloses p) will parse sensibly in HTML5-compliant browsers but will fail to Degrade Gracefully in legacy browsers. Thus, the change being proposed would reach its full utility only once legacy browsers have faded away. (Authors could hack around this by writing <p><figure><object><pre>Code example</pre></object><figcaption>Lorem ipsum</figcaption></figure>Dolor sit amet</p>.)

Conformance Classes Changes

User agents (that support the text/html syntax) and HTML conformance checkers would have to change. Authoring tools that wish to support the full range of conforming documents would have to change, but authoring tools that don't wish to support the authoring of all possible conforming document wouldn't need to change.

Risks

The listed negative effect may cause author confusion as long as HTML5-incompliant user agents have a noticeable installed base. However, the negative effect would be no more confusing than <p>foo<section><p>bar</p></section><p>baz</p>.

A notable user agent (Chrome 7?) might ship without an implementation of this Change Proposal, which would cause confusion.

References

• ISSUE-128
• Bug 10589