[Bug 10483] <figcaption> should be considered the caption of <figure> _itself_


--- Comment #3 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2010-09-10 00:32:39 ---
(In reply to comment #2)
> Rationale: I have no idea what you're requesting here or what problem it would  solve.

THE REQUEST:  That <figcaption> is defined as having the same kind of
crelationship to its parent element, as <caption> already has to *its* parent

THE PROBLEM: the caption model of <figure> differs from the caption model of
<table>. To say that <figcaption> represents the _content_ of <figure>, is a
synonymous with saying that it is the caption of _child(ren)_ of the element.
So while <caption> explicitly captions its parent element, <figcaption> is
currently explicitly defined to caption " represents the caption of the figure
element's contents". This content does not even need to be an element, it could
simply be a text node. What if <figure> has no content, apart from
<figcaption>? Does <figcaption> then caption nothingness? 

SOLUTION: instead of "represents the caption of the figure element's contents",
the draft should say "represents the caption of the figure element" (or simply
copy the wording used about <caption>: "represents the title of the _figure_
that is its parent" ). This would clarify that <figcaption>; just like
<caption>, captions its parent element.


(A) HTML speaks loudly about <caption>'s relationship to its parent element,
and it is reasonable to believe that authors will be affected by the definition
of <caption> when they interpret <figcaption>:

  (1) [HTML5#the-caption-element defines] <caption> as the title of its <table>
  (2) by default, user agents display the caption element outside border of the
<table> element, despite that it is a child element of <table>.

(B) <Figure> is defined by HTML5 as "self-contained". To say that <figcaption>
captions the content  of <figure>, instead of <figure> itself, contradicts with
the "self-contained" definition: it makes it seem as if <figure> is just
wrapper for the <figcaption> plus the content, and that the important thing is
- to quote a much cited use case - the relationsship between e.g. the <img>
child  and <figcaption>.

(C) The name of the element isn't <contentcaption>, it is <figcaption>! A
<figcaption> logically is the figure's caption. 

(D) Possible <img> caption confusion: HTML5 permits @alt to be dropped whenever
<img> is the sole content of a <figure> with a <figcaption>. However, if the
author interprets this as a relationship between <img> and <figcaption>, then
he/she might not realize that a paragraph element around the <img> makes the
<figcaption> the caption of the <p> and not of the <img>. Or, if one simply
adds some text around the <img>, then some authors would believe that the
<figcaption> still captions the <img>, despite that the figure now consists of
an <img> plus some text. By emphasizing that the <figcaption> captions
<figure>, then authors will get this point better. (This point would have been
even easier to get, if there also existed a <figbody> element.)

(E) The section about #the-table-element describes how one can place a <table>
inside a <figure>, and thus drop the <caption>, using the <figcaption> instead.
The section about #the-caption-element even *recommends* doing so, whenever
<table> is the sole content of <figure>.  Here we can see the confusion very
directly: <caption> is the <table> element's caption. However, since HTML5 says
that <figcaption> is the caption of the content of <figure>, then <caption> and
<figcaption> would in fact caption the same thing: both of them would caption
the <table> element ... 

(F) In Bug 9817 Rich Schwerdtfeger explains a practical consequence of not
defining properly whether the caption (in that case <summary>) "belongs" to its
parent element or to the content of the parent element. (He  recommends that
only <details> receive focus and that the <summary> be a label for it.) Making
sure that implementations links <figcaption> to <figure>, will create a
consistent and stable interaction pattern.

So, while the issue from one point is a little bit theoretical, it *is*
important to get this right: let us build on the clear perception of
<caption>'s relationsship to its parent, and underline the same understanding
for <figcaption>. Then both authors and implementors has better chanse of
getting the <figure> element right.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 10 September 2010 00:32:41 UTC