[whatwg] <figure><img><* caption>

Hugh Guiney hugh.guiney at gmail.com
Wed Dec 2 00:58:50 PST 2009

On Tue, Dec 1, 2009 at 7:08 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> The @caption proposal isn't for an attribute on <p> only, but rather
> for an attribute on any element that is a child of a <figure>.  (It's
> just that most of the time using a <p> is most appropriate.)

Ah, OK. Well, given the circumstances, this does seem like the best
approach, though I feel conditionally allowing certain attributes
depending on an element's context is a step in the wrong direction.
It's confusing given the way HTML will have worked up until that
point; as a document author, although I expect elements themselves
only to be allowed in certain contexts, I also expect them to carry
all of their attributes with them when they are; i.e., attributes are
perceived as belonging to the element within which they are set, not
the parent of that element.

Most of us agree that a more semantic element would be ideal here, yet
we can't use one [yet] because of current technical limitations. That
sounds like the very situation microformats was created to address.
What if we used @itemprop as a placeholder for a future figure-caption
element? To make things less verbose, <figure> could have an implied
@itemscope and @itemtype unless specifically overwritten by the


<img src="figure.gif" alt="graph">
<p itemprop="caption">The findings</p>

On Tue, Dec 1, 2009 at 9:58 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> It's not just rendering issues - all current browsers produce a broken DOM
> when you include <legend> outside of <fieldset>, ranging from dropping the
> <legend> element entirely to creating a fieldset to doing the IE thing of
> adding void elements named "legend" and "/legend" (but without the usual
> script workaround.

Is this issue being addressed by the latest DOM specification? It
seems there should really be a standard behavior for browsers when
encountering unknown or unexpected elements that ensures that the next
version of HTML is not similarly encumbered by this.

More information about the whatwg mailing list