Change Proposal: <fcaption> and <dlabel>

Summary

The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details. The content portions of these elements (as opposed to the caption or label) would not have any special markup, they would be nested directly inside the figure or details element.

Note: Besides "fcaption", I think an arguably equally good suggested name is "figcaption". For "dlabel", I think either "dsummary" or "summary" could be a good alternative. I'm willing to update this Change Proposal to go with those or other reasonably similar alternatives based on whatever is most popular, or just leave it to editor's discretion to choose among plausibly similar names.

Rationale

Problems with Using dt/dd for figure and details Elements

These considerations are also relevant for many other proposals for resolving this issue.

Backwards Compatibility

Due to IE's legacy parsing issues, the dt and dd elements create problems for authors attempting to use and style these elements. The simplest workaround (wrapping both figure and details in an extra div) that authors would need to apply to avoid these issues is not intuitive, as clearly demonstrated by the wide range of alternative solutions that were attempted prior to its discovery.

Legacy Cruft

The use of extra div elements may lead to a lot of confusion among authors, at least initially, and ultimately end up becoming extraneous markup that authors just include without really understanding why, even after the current generation of browsers are long since dead.

We've seen this kind of problem before with authors, for example, frequently wrapping scripts with pseudo-HTML-comments initially intended to hide the script from what are now very ancient browsers, none of which have been in use for over a decade.

Styling Clashes

In addition to the aforementioned styling bug in IE, many existing stylesheets already include styles for the dt and dd elements, used in description lists (dl elements). Authors attempting to incorporate figure or details into their existing pages would have to take care to avoid unintended styling clashes caused by selectors that aren't specific enough. i.e. It's common for authors to simply use the selector as "dt" or "dd", rather than "dl>dt" and "dl>dd", as that is currently unnecessary. Authors will then have to adjust their styles, which could potentially cause unintended side affects to to the change in specificity of the selectors.

Default Styles

The default styles for dt and dd elements is not ideal for figures. As the dd element is usually indented with margin and/or padding, authors will usually be required to remove this with their own stylesheets, rather than being able to rely on more sensible defaults. It is true that eventually UA stylesheets may have special rules for "figure > dt" and the like, but during the transition period it will be extra work to remove inappropriate default styles.

Structural Differences

Since authors are already familiar with the meanings and structure of dt and dd when used within dl, their very distinct meanings and structure when used within the figure and details may be confusing to authors.

The dl element may contain multiple groups of dt and dd elements, wheres within figure and details, each element may only be used once.

Within dl, a group must have one or more dt elements followed by one or more dd elements, whereas within figure, the elements may appear in any order.

Semantic Differences

For the figure element, it's not very intuitive to determine which of either dt or dd represents the caption and which represents the content such as an image. Some authors may interpret dd as being the description, which is what it means within dl, and thus assume that dd is meant for the caption, and the dt meant for the image or other content. However, the spec defines these with the opposite meanings, with the understanding the dt, or title, is a synonym for caption. Both alternatives points of view make some sense, but neither stands out as being obviously correct. This will likely lead to a lot of authors using these elements in reverse.

Unnecessary Elements

The dd element is completely unnecessary to distinguish it from the caption, which has its own element. This combined with the extraneous div required for IE compatibility adds two extra elements that are not logically needed. A previous iteration of the spec used the legend element for the caption, without any special wrapper just for the content. This model seems much more intuitive and required less markup to use, and thus easier to get right. Authors who do wish to have an extra wrapper around the content may use div if they choose, but should not be required to use it.

When there is no caption, using figure then requires authors to use 3 extra elements, where they should only need one:

<div> <!-- IE legacy workaround -->
  <figure>
    <dd><img src="image" alt="..."></dd>
  </figure>
</div>

This will be unappealing to authors who may, as a result of the complexity, opt not to use the figure element.

Aesthetics

Aesthetics is not necessarily the sole or most important concern. However, many authors seem to find the novel use of dt and dd unpleasant to read. dt and dd are relatively obscure elements, they are very short abbreviations, and their meaning in context is unclear, especially in figure. In particular, the following markup seems mysterious and strikes many as ugly and unintuitive:

 <figure>
   <dd><img src="image" alt="..."></dd>
   <dt>A Pair of Cats</dd>
 </figure>

This seems to trigger a "yuck factor", and it would be wise to avoid that. Aesthetics may seem like a relatively unimportant factor; however, the desire to avoid introducing new elements that led to dt/dd being used is itself largely an aesthetic concern.

Why This Proposal is the Best Solution

In addition to the rationale relative to the status quo in the spec, this proposal is better than some of the proposed alternatives.

Follows HTML Precedent for Structured Elements

Some HTML elements have relatively free content models, while others are "structured" - there are some or all child elements that have special meaning. Structured elements typically have helper elements that are specific to one element, or to a small family of related elements, to express their internal structure. Examples, from past versions of HTML, new in HTML5, and proposed for future versions of HTML:

• table has thead, tfoot, tbody, td, th, tr, caption, col and colgroup.
• ul, ol and menu have li.
• fieldset has legend.
• applet and object have param.
• video and audio have source.
• dl has dt and dd.
• select and datalist have option and optgroup.
• ruby has rp and rt.
• datagrid was proposed to have a number of specialized child elements.

In some cases (such as table or the list elements), the structured element can only have its specialized children. In other cases (fieldset, applet/object, or audio/video), the structured element can have relatively free content in addition to its specialized children.

Thus, when introducing new structured elements such as figure and details, the normal design pattern for HTML is to introduce new specialized child elements to represent their structure. It is not the norm to reuse a very common element such as "h1" to represent specialized structure in a certain context. It is not the norm to reuse specialized child elements in a way that differs from their established content and meaning, as with dt/dd or legend. And it is unprecedented to use an attribute that can occur on any element to represent specialized structure, as with the proposed caption attribute. Furthermore, details and figure are not particularly closely related in purpose. One is a UI control, the other is a representation of the structure of prose documents. So it does not make sense for them to share a specialized child element.

Applying a different design pattern for internal element structure to figure and details is likely to be confusing. The confusion of deviating from the usual HTML design pattern for this is likely to be greater than the cognitive cost of introducing no or fewer new elements.

Avoids Clunky or Inappropriate Names

The new element fltcap, suggested by another Change Proposal, appears confusing and mysterious. No one seems to get what it means on first reading. The expansion as "floating caption" seems confusing and semantically wrong. First, "floating caption" is not a very common term of art in publishing, but whenever it is used, it seems to refer to captions overlayed on top of the image, not figure captions in general. Furthermore, a details control does not in general have a "caption", floating or otherwise, rather it is a UI control and therefore is normally considered to have a "label". Alternately you could say "summary" based on the spec term for the short text of a details element.

The new element c is an extremely short and mysterious name. There is a limit to how many one-letter identifiers one can have in a language without rendering it unreadable or confusing, and they should be reserved for extremely common elements. Captions do not make the cut.

Reusing legend does not seem like a good semantic fit for either figure or details. While a figure's caption is sometimes called a legend, the term "legend" in this context more often refers to the key next to a map or chart explaining how to read various visual elements. A details element is a UI element and those aren't ordinarily referred to as having a legend.

h1 connotes "header", which is not quite right for either figure or details.

The caption attribute is good for figure, but not details. However, that proposal retains the dt/dd names for details. And those names remain clunky and non-obvious in the context of details (hard to remember which is which) and retain all of the general problems of using dt/dd for both elements.

"caption" and "label" (or "summary"), or variations thereof, are the most semantically appropriate names for the caption and label respectively on figure and details.

Does Not Introduce Compatibility Problems

Reuse of almost any existing element in an unrelated context introduces compatibility problems, whether "hard" problems with parsing or behavior, or "soft" problems with pre-existing author styles. This Change Proposal uses brand new elements and thus avoids all these problems, unlike the use of dt/dd, legend, label, caption, or h1. All of those are known to have some lesser or greater technical issues.

Does Not Introduce Redundant Elements for the Content

Semantically, and for purposes of UA behavior, we only really need to distinguish the caption part of the element. There is no need to wrap the remaining body part with a special element. True, they can be handy as a styling hook, but authors who need that styling hook can always use