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

[Hugh Guiney]

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
author.

Ex:

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

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.