Html: figure/figcaption sparse flow content not valid

[felixsanz]

The spec says this about figure:

Content model:
Either: One figcaption element followed by flow content.
Or: Flow content followed by one figcaption element.
Or: Flow content.

The problem is, you can't do this:

<figure>
  <img>
  <figcaption>...</figcaption>
  <div></div>
</figure>

Because thats flow content followed by one figcaption followed by flow content, which apparently is not valid and maybe there are good use cases that should allow this structure since there shouldn't be technical impediments behind it.

The HTML validator fails (gives an error) when using this structure. Maybe it shouldn't.

I had an example use case but after discussing it in IRC, i don't think it's strong enough to provide a point.

Anyway i'm going to leave it here:

<figure>
  <img src="duck.jpg">
  <figcaption>The yellow duck splashes in the water</figcaption>
  <div>Picture taken: <time>2011-11-18</time></div>
</figure>

The figcaption element represents a caption or legend for the rest of the contents of the figcaption element's parent figure element, if any.

So, in this case, the date doesn't represent the content of the picture, it's just "metadata". The time element doesn't say anything about what's inside the picture, this is why i think it's bad idea to put it inside the figcaption element. And someone would say... "put it outside of figure"... Yeah... But the time relates to the picture!

The argument against is that figcaption is not representing the div element, which is true. But maybe the spec should allow it and the validator shouldn't give an error.

By the way, this is valid according to the spec:

<figure>
  <figcaption>The yellow duck splashes in the water</figcaption>
  <img src="duck.jpg">
  <div>Picture taken: <time>2011-11-18</time></div>
</figure>

Thats why maybe an error is not ideal here. Just for consistency reasons (order shouldn't matter).

[annevk]

It seems somewhat reasonable to be a bit more lax about this. The source of the standard also has a note about a potential <credit> element. While it's unlikely we'd introduce a new element at this point, it does seem reasonable for folks to have a way to include such functionality without creating invalid content.

So maybe we should just require the figure to be either before or after the figcaption and allow additional elements on the other side that also provide information about the figure. That wouldn't really allow for automatic extraction, but that's somewhat contrived anyway I think.

[zcorpan]

I think the date is reasonably part of the caption, similarly for credit. In particular the date is not in itself the figure -- the image is. It seems a bit confusing to reason about what was intended if flow content is allowed both before and after figcaption.

<figure>
  <img src="duck.jpg">
  <figcaption>
    <div>The yellow duck splashes in the water</div>
    <div>Picture taken: <time>2011-11-18</time></div>
  </figcaption>
</figure>

Order often does matter in HTML (e.g. table, fieldset...).

[felixsanz]

@annevk You gave me an idea with that tag. Also <small> tags are good use case here. For example to include clarifications about the picture, or copyright/licensing notices:

<figure>
  <img src="duck.jpg">
  <figcaption>The yellow duck splashes in the water</figcaption>
  <small>This picture is courtesy of XXXX</small>
</figure>

[patrickdark]

@felixsanz You could also use footer, which is almost the same thing as figcaption and doesn't have the needless content order restriction.

[domenic]

I agree with @zcorpan that the credit (e.g. <small>) should be inside the <figcaption>.

[felixsanz]

@domenic But the figcaption is a label/caption that describes what is the image about, right? Do you think a copyright notice describes what the picture is?

In my opinion, here's a comparative example:

The legend (caption) is what describes the content of the image, while the data source text is outside of it because it's not part of the label.

This could be translated into:

<figure>
  <img src="indiana_map.jpg">
  <figcaption>U.S. Indiana population map</figcaption>
  <small>Source: U.S. Census Bureau 2010</small>
</figure>

Sure, you can do <figcaption>U.S. Indiana population map gathered in 2010 by the U.S. Census Bureau</figcaption>, but i don't think my example should be considered semantically incorrect.

¯\_(ツ)_/¯

I'm OK whether this changes or not, i'm not really arguing.

[domenic]

Figcaption captions the figure. The caption can describe the actual pixels; it can describe its copyright provenance; it can describe its authorship; it can describe any aspect of the figure. The only thing in the spec is that it represents a caption or legend for the rest of the contents of the element.

[felixsanz]

Right, all clear then. Thanks

I don't know if i should close the issue or people still want to comment. Please close it if you consider so.

[annevk]

I'd like it to remain open until we've added some examples around credit and time and removed the mention of <credit> in the source. I'm fine with using figcaption for all of these though.

[patrickdark]

@felixsanz Seems like nested figures with a table would make sense for that image.

<figure>
    <img/>
    <figcaption>
        <figure>
            <figcaption/>
            <table/>
        </figure>
        <small/>
    </figcaption>
</figure>

[felixsanz]

Anyway, we shouldn't omit the fact that this is valid:

<figure>
  <figcaption>U.S. Indiana population map</figcaption>
  <img src="indiana_map.jpg">
  <small>Source: U.S. Census Bureau 2010</small>
</figure>

So, if you guys are saying that the <small> tag should be inside <figcaption>, in this example it should be too, don't you think?

But this is valid, while having <figcaption> in the middle is not. I think consistency should be improved in either way. Relax or enforce?

[patrickdark]

@felixsanz The structure is valid, but based on the spec, your caption applies to the small element as well, which would seem to be clearly incorrect.

[zcorpan]

@felixsanz an automated conformance checker can't find any error with that, because it cannot infer intent. There are various conformance requirements in the standard like this, e.g. table must be used for tabular data.

[annevk]

I created #3358 to address this as I suggested in https://github.com/whatwg/html/issues/2450#issuecomment-287990732.