- From: <bugzilla@jessica.w3.org>
- Date: Fri, 10 Sep 2010 00:32:40 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10483 --- 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 element. 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. EXAMPLES OF THE CURRENT CONFUSION: (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> parent. (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 on the CC list for the bug.
Received on Friday, 10 September 2010 00:32:41 UTC