Any case where you want to wrap a <figcaption> in <div>s, you can instead wrap the *contents* of the <figcaption> in <div>s.

That is, instead of:
<figure>
  <img ...>
  <div><div><figcaption></figcaption></div></div>
</figure>

Just do this:
<figure>
  <img ...>
  <figcaption><div><div></div></div></figcaption>
</figure>

(In reply to comment #1)
Completely wrong. Things that are not legend at all should not be inserted into legend element. It would be semantically nonsensical and harmful.

Typo: "legend" should be read as "figcaption" in my comment #2.

Same response as your <legend> bug.  If you're just inserting <div>s for styling, they don't carry any semantics whatsoever.  It doesn't matter whether they're inside or outside the <figcaption>.

(In reply to comment #4)
> If you're just inserting <div>s for
> styling, they don't carry any semantics whatsoever.  It doesn't matter whether
> they're inside or outside the <figcaption>.

The bug is not about just wrapping FIGCAPTION in DIVs (it would be pointless). It's not about styling legend at all.

The bug is about _ordering_ elements: it should be possible to place sibling elements before and after FIGCAPTION to make possible implementing arbitrary designs. Such sibling elements may contain text or functional elements (not just some empty divs). To make this possible, LEGEND should be allowed to be wrapped in DIVs. Such DIVs would contain FIGCAPTION _and_ sibling elements that, according to site design, should be in place that is not allowed by current HTML5 spec.

Currently, FIGCAPTION element is similar to attribute and therefore mostly useless. It does exist, but can't be styled and placed where it needs to be according to arbitrary visual design.

If semantic element (FIGCAPTION) does NOT allow to implement specific site design while other elements (e.g., headers, divs) DO, the element will be just ignored in practice in favor to less semantic alternatives that allow to perform a real task.

Does semantic elements exist to be ignored in practice due to purely theoretical, nonsensical and wrong spec limitation? Unlikely.

HTML5 spec should be free from such artificial and pointless limitations.

Same applies to LEGEND element (bug 12834).

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: HTML is not a layout language. If CSS doesn't let you style your pages in the way you want without non-semantic elements, that's something we should fix in CSS, not HTML.

> Status: Rejected
> Change Description: no spec change
> Rationale: HTML is not a layout language. If CSS doesn't let you style your
> pages in the way you want without non-semantic elements, that's something we
> should fix in CSS, not HTML.

If something may be fixed in CSS, then, in practice, it means this will not be fixed never.

Anyway, CSS and HTML are separate things. Probable CSS possibilities cannot be a reason for HTML spec to contain unneeded and harmful restrictions that are purely theoretical and just corrupt page validation process while not making any useful things.

Theory should not exist for theory itself. Theory and practice should peacefully coexist, theory should not make practice harder that it should be.

The bug is an isolated situation. Please see more common bug report (bug 13062) that I have created.

Thanks.

mass-moved component to LC1

It's fairly common to have a gallery of images where each picture and that picture's caption links to a larger version of that image (and only those elements -- clicking on the empty space surrounding an image shouldn't follow the link).  Take this sample mockup of a figure/figcaption in a gallery:

"<figure>
<a href="bubbles-work-large.png">
   <img src="bubbles-work.jpeg"
      alt="Bubbles, sitting in his office chair, works on his
           latest project intently.">
   <figcaption>Bubbles at work</figcaption>
</a>
</figure>"

The best choice for the intended results would be a link tag ("a") that wraps the image tags and the figcaption tags, so that a mouseclick on either the image or the caption will bring up the larger version of the image.

As it now stands, the spec requires that two separate link tags be used to wrap the image and then to wrap the content inside the image.  If the image source changes, then that source must be updated in two different places for the same figure which violates best practices.

Wrapping the entire figure in a link tag produces undesired results -- a click on the empty space anywhere around the image will follow the link.  The desired result is that only a click on the image or caption should follow the link.

In my last comment, replace:
As it now stands, the spec requires that two separate link tags be used to wrap the image and then to wrap the content inside the image.  If the image source changes, then that source must be updated in two different places for the same figure which violates best practices.

with

As it now stands, the spec requires that two separate link tags be used, one to wrap the image and then another to wrap the caption inside the figcaption.  If the image source changes, then that source must be updated in two different places for the same figure which violates best practices.

Anyway, point is that ficaption shouldn't have to be first/last child of figure, you should be able to wrap image & figcaption in something.  Otherwise, you have to wrap the image in something and then wrap the caption (inside the figcaption) in the same thing.  If you try to wrap the whole figure, then you also end up wrapping all the blank space to the sides of the image.

If you wrapped the <figcaption> in something, it would no longer be a child of the <figure> element.

(In reply to Ian 'Hixie' Hickson from comment #11)
> If you wrapped the <figcaption> in something, it would no longer be a child
> of the <figure> element.

Yes, that's correct.  The current HTML5 spec says figcaption must be first/last child of figure and that's a bug.  You should be able to wrap figcaption in something without violating the HTML5 specification.  Here's why:

When linking an image and a caption (to a larger image, to another page, to anything), there are three possibilities.

1. Wrap everything in a link:
<a href=something-big.png>
<figure>
<img src=something-small.png>
<figcaption>something big, click for larger version</figcaption>
</figure>
</a>
Result:  Undesired - especially if you make the figure large enough that a descriptive caption has enough room to really display, you end up with lots of blank space on either side of the image in the figure box.

2. Wrap the image in a link, then wrap the caption text in a link inside the figcaption:
<figure>
<a href=something-big.png>
<img src=something-small.png>
</a>
<figcaption><a href=something-big.png>something big, click for larger version</a></figcaption>
</figure>
Result: Undesired - if the image source is updated and a new image is generated with a new name to get around far-caching LocalStorage caching, two sources must now be updated for the same image.

3. Wrap the image and figcaption in a link:
<figure>
<a href=something-big.png>
<img src=something-small.png>
<figcaption>something big, click for larger version</figcaption>
</a>
</figure>
Result: Desired outcome - one link, one thing to update and keep current, only desired elements are turned into links. However, this is not currently allowed by the HTML5 spec.

Figcaption should be able to be wrapped in something else between it and figure.

Why don't you just wrap the whole <figure> in the <a>?

The problem with allowing the <figcaption> to be wrapped is that it makes it dramatically harder for UAs to find the caption — instead of just checking the child list, they now have to check the entire subtree.

You said, "it makes it dramatically harder for UAs to find the caption".  It wouldn't be any harder than it currently is for the browser to find the image, which is kind of the most important part of a figure.

Regarding wrapping the whole figure in a link, I've said multiple times that this then also makes all the blank space on either side of an image also be a link.  You might ask, "What's wrong with that?"  Because swathes of blank apparently background space aren't usually supposed to be links.

Besides, figure and figcaption are basically just block-level div tags with a semantic meaning -- who cares whether the browser "knows" that figcaption is a child of figure?  Let figcaption float around the same as any other child div and it'll be in the right place by default.  The only thing that would be impacted would be spiders crawling webpages trying to make semantic maps of the internet and I honestly don't care how much more work a spider has to do since it doesn't impact users.

The browser never has to find the image, it just walks the tree and renders it wherever it is. The caption, though, might be something you need to find for semantic reasons (e.g. an AT could read it out when requested).

Making the blank space not clickable seems like a styling issue.


> Besides, figure and figcaption are basically just block-level div tags with
> a semantic meaning -- who cares whether the browser "knows" that figcaption
> is a child of figure?

That's what it means for it to have "semantic meaning".

Filed on the github tracker: https://github.com/w3c/html/issues/177

(In reply to comment #16)
It's unclear whether HTML bug tracking is going to be moved to GitHub entirely, or there are reasons to move just this specific bug.

We're working on moving from bugzilla to tacking on github.