This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
<figcaption> is an odd element name. At the same time, <summary> doesn't seem especially good as the name of the caption of the <details>. I do not see that "summary" better sums up the purpose of the caption of <details> than it would sum up the purpose of the caption of <figure>. But, by "joning forces", then <summary> could become a good name both for the caption of <figure> as well as the caption of <details>. In other words: change the name of <figcaption> to <summary>. HTML5 anyway designates a wider role for captions than HTML4 does. (Consider the content model of <caption> in HTML4 vs the content model in HTML5.) Thus, 'summary' seems like a good name for the caption of <figure> - a caption can be a summary of the figure. Changing the name to <summary> would also cut down on the amount of new elements. A shared caption element would also make authors see that <details> and <figure> share the same structure. Which in turn may help authors to consider both elements and thus better make the right choice. Also, in case a script were to turn a <details> into <figure> or vice-versa, then this would be simpler if the have a shared caption element. Documentation of how similar HTML5 define <summary> and <figcaption>: <summary>'s definition: ]] The summary element represents a summary, caption, or legend for the rest of the contents of the summary element's parent details element, if any. [[ <figcaption>'s definition: ]] The figcaption element represents a caption or legend for the rest of the contents of the figcaption element's parent figure element, if any. [[ <summary> in <details>'s definition: ]] The first summary element child of the element, if any, represents the summary or legend of the details. If there is no child summary element, the user agent should provide its own legend (e.g. "Details"). [[ <figcaption> in <figure>'s definition: ]] The first figcaption element child of the element, if any, represents the caption of the figure element's contents. If there is no child figcaption element, then there is no caption. [[
The current definition of figure is far too easily confused with aside. Talking about "the side of the page" in the figure element definition confuses it with the aside element. Why does placement need to be mentioned at all? I suggest deleting: "that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix." The current definitions of the aside and figure sound almost identical, except that figure has a caption. They are not only uncomfortably generic but also dangerously close in meaning, which adds complexity and ambiguity. Bad complexity leads to frustration, wasted time and wasted money. Developers will tend to confuse the two elements and use them incorrectly. It will present a challenge for educators to teach the difference. Bruce has mentioned that his view is figure is: > 1) illustrative and 2) "typically referred to in the main article/ section". > Aside is tangential, > figure is integral. http://lists.w3.org/Archives/Public/public-html/2010Jun/0171.html If that is true, it would be a way of differentiating the two. Some developers may want more choices and complex levels of control. But they don't want the complexity that entails elements that are ambiguous, error prone, or difficult to learn.
I want to have this issue resolved quickly. Maciej recently published the chairs decision on <details>, in which he started to point to books on HTML5. If books on HTML5 - before HTMl5 is ready - can be used to justify HTML5 features, then clearly, we should seek to decide quickly whether to change the captoin element for <figure> from <figcaption> to <summary>. Hence I added the TrackerRequest keyword to this bug.
(In reply to comment #2) > I want to have this issue resolved quickly. Maciej recently published the > chairs decision on <details>, in which he started to point to books on HTML5. > > If books on HTML5 - before HTMl5 is ready - can be used to justify HTML5 > features, then clearly, we should seek to decide quickly whether to change the > captoin element for <figure> from <figcaption> to <summary>. I think you are misstating what the decision said. Books on HTML5 were not cited as as a positive argument for <details>. Rather they were mentioned in opposition to the argument that documenting it was an undue burden. You don't have to worry about early books on HTML5 preventing us from changing the spec. > Hence I added the TrackerRequest keyword to this bug. I think that's premature, since the bug is not resolved yet. So I am removing the keyword for now. However, one thing to consider. ISSUE-83 already covered the naming of the elements used to caption/label the <figure> and <details> elements, and has been resolved: http://www.w3.org/html/wg/tracker/issues/83 Is there any new information in this bug?
Reply to comment #3. Is there anyway to get the bug to be resolved faster? Currently we see that the editor prefers to work on "HTML6" (e.g. in the form of WebSRT) rather than resolving HTML5 bugs - at least, that is the impression I get. It also seems important that HTML5 book authors, and other "implementors" are aware that the <figcaption> name is contested. So could we mark it as a contested issue in the spec? Regarding Issue-83, then that was an issue that Shelley raised because she disagreed with the solution to reuse <dt> as caption element inside <details>&<figure>. (The issue was also about _not_ using <dd> as container element in <details>&<figure>) The issue was solved via an amicable solution (which I disagreed with - I expressed the view that both elements should have the same name in my comment - I am sorry to not have repeated it when you called for objections. Here is on of my comments: http://www.w3.org/mid/20100126015859583799.762f5ee2@xn--mlform-iua.no ]] I only see that <details> needs a caption. And if <summary> is marketed as a neutral caption element (that is: if it is used both in <figure> and <details>) _then_ I think it /could/ work, also for <details>. Because then its use in <figure> might spill over positively to <detail> and vice-versa. [[ So, from my perspective, the amicable solution did solve the specific issue that Shelley raised. The solution did, however, create a new issue: two different caption names. I have not observed that the question of using <summary> as the caption element of both <details>&<figure> have been given any consideration. No one has chosen to argue whether for or against my proposal to use <summary> for both elements, as far as I can see. Specifically, no one has justified that <summary> has any special link to <details> in contrast to <figure>. In fact, I find it better fit to <figure>. But, in my view, the element would understood the best if it is used as caption element for both <figure>&<details>. Right now we are solving another issue, ISSUE-30, where bad design, including bad choice of name for the attribute (see Tantec's response in the poll) is cited as one of hte problems with @longdesc. So clearly, the name is important and part of the design.
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: The names were decided by WG decision, if I'm not mistaken.