figcaption w/h tags?

figcaption with h tags

[EastTexas]

figcaption w/h tags?

W3C - Validation Output: 1 Warning

Below is a list of the warning message(s) produced when checking your document.

Line 79, Column 4: "Empty heading".


Example:

<figure>

<figcaption>

<h5>Can I use h4-h6 tags here?</h5>

<p>some more txt here</p>

</figcaption>

<img src="image.png" alt="some img">

</figure>

[lucy24]

Q: Why do you want to? The named element <figcaption> has a particular meaning, which may be mutually exclusive with the meaning of an <hx> element.

Conceptually I see what you're aiming for: it's the header of the caption. But that's not what hx elements are for; they apply to the whole document.

The figure element represents some flow content, optionally with a caption, that is self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document.

And that's for the whole figure, of which the caption is a child. There doesn't seem to be any equivalent to <th> for figures, worse luck.

You could look up the horse's mouth [w3.org] but I warn you, it will probably give you a headache unless you stop short at the picture (the only part that's halfway intelligible).

Are you prepared to dump MSIE <= 8? That seems to be the cutoff for most html 5 features.

[EastTexas]

I've been testing figcaption as a cleaner alternative to a div for product description.

I have given ie8 users the heave-ho w/ a warning & moved to jQuery 2.x. 8)

[mattur]

You could look up the horse's mouth [w3.org...]
Note this is a link to the outdated W3C "HTML5" snapshot, which has now been superceded and is no longer maintained. W3C snapshots are for patent-lawyers, not developers. The most up to date copy of the HTML spec at the W3C is the "HTML5.1" editors draft:

[w3.org...]

Alternatively refer to the upstream WHATWG living standard which the W3C versions are (mainly) copied from, and which is always up to date:

[whatwg.org...]

If you find yourself using headings in a figcaption, it may be better to instead use <article> rather than <figure>, See:

[whatwg.org...]

[EastTexas]

Thanks for the info 8)

[SelenIT]

W3C's HTML5.0 spec is not outdated. It was intended to be a restricted subset of HTML5 spec that contains only stable features, in order to give it W3C Recommendation status within 2014. Less stable features are postponed to a second stage of the spec, which is supposed to reach Recommendation status in the late 2016 or something. So it's HTML5.0 that browsers will have to follow in the nearest future, while HTML5.1 will be still a draft with only experimental implementations. See [dev.w3.org...]

The subject problem occurs only in W3C html validator, but not in html5.validator.nu, the engine of which it is based on. According to the both W3C and WHATWG specs, placing a heading into a figcaption, although doesn't make much sense, is still not formally prohibited, and html5.validator.nu validates it with no warning. I suppose that this warning is just a bug of W3C validator.

[mattur]

W3C's HTML5.0 spec is not outdated. It was intended to be a restricted subset of HTML5 spec that contains only stable features, in order to give it W3C Recommendation status within 2014. Less stable features are postponed to a second stage of the spec, which is supposed to reach Recommendation status in the late 2016 or something.

Incorrect. The W3C's snapshot system is for patent lawyers, not implementers or developers. Implementers follow the latest, most up to date version of the spec i.e. the spec with the fewest bugs. Implementers generally use the WHATWG version for this reason, and developers should do the same.

The W3C's HTML5.0 has already been superseded by HTML5.1. The HTML5.0 snapshot's purpose is to invoke the W3C's patent policy, which requires 2 interoperable implementations - "stability" has nothing to do with it.

In turn, HTML5.1 will be pruned down to only features which have 2 interoperable implementations, and put through the W3C's publication process as a frozen, out of date snapshot to invoke the W3C's patent policy while the ongoing maintenance and development of the HTML language moves to HTML5.2.

So it's HTML5.0 that browsers will have to follow in the nearest future, while HTML5.1 will be still a draft with only experimental implementations

If implementers followed the HTML5.0 spec, there would never be 2 interoperable implementations of new features, so there would never be new stuff added to HTML through the W3C's patent process.

(I'm a member of the W3C HTMLWG, for what it's worth).

[SelenIT]

Thanks for your clarification! Some parts were really surprising for me, so could you please clarify them a bit more?

If implementers followed the HTML5.0 spec, there would never be 2 interoperable implementations of new features, so there would never be new stuff added to HTML

I didn't mean that implementers shouldn't follow the newer spec, My point was impementations of the draft spec can be not interoperable and usually are not production-ready. Many of such implementations are available only with vendor prefix and/or experimental flag. I always thought that if a browser doesnt support a feature from CR/PR/Rec spec, it's a browser bug that should be fixed, but if it doesn't support a feature from some early WD, it's just missing (experimental) feature. If it is wrong, how do developers distinguish these cases?

Implementers generally use the WHATWG version for this reason, and developers should do the same.

Surprised to hear this from the member of the W3C HTMLWG:) As far as I know, WHATWG (and personally Hixie) has slightly different view of the HTML5 future, so the divergence between WHATWG and W3C versions will only increase (e.g. WHATWG won't drop <hgroup>, they unlikely accept <footer> inside <blockquote> for attribution, etc.). And if W3C makes changes in the spec that contradict the preferred spec for implementers and developers... so what is the purpose of the W3C spec itself?

[mattur]

If it is wrong, how do developers distinguish these cases?

It's best to use a resource like [caniuse.com...] to tell what features are widely supported, not specs. The W3C process (theoretically) requires 2 interoperable implementations, but is routinely gerrymandered by the W3C anyway just so they can publish something.

For example, the test suite coverage of the HTML5.0 spec is not wide enough to determine whether there really are actually two fully interoperable implementations of the functionality contained in the HTML5.0 spec. But W3C is currently in the process of doing whatever it takes to get a HTML spec with the W3C logo on it out of the door this year for political and marketing reasons.

And if W3C makes changes in the spec that contradict the preferred spec for implementers and developers... so what is the purpose of the W3C spec itself?

I really wouldn't worry too much about the differences between the W3C spec and the WHATWG spec. Implementers generally use the WHATWG spec. The W3C spec is just a copy-and-paste of the WHATWG spec with a few bike-sheddy differences. For example the W3C spec made hgroup non-conformant for political reasons, but browsers are still required to support it, so it's not going anywhere.

The main, some would say only, purpose of the W3C copy of the spec is to invoke the W3C Patent Process

(I should note I'm more of a WHATWG Sideline Cheerleader and Hixie Fanboy, but also a member of HTMLWG. We all hoped the work could be successfully transferred to the HTMLWG, and WHATWG could wither away, but the HTMLWG has been a complete and utter disaster since the beginning and is now just a slow motion car-crash - most participants already gave up on it years ago. It's quite sad really)