This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7056 - <caption> and <figure><legend> elements should allow flow content children
Summary: <caption> and <figure><legend> elements should allow flow content children
Status: VERIFIED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf, a11y_table_summary
Depends on:
Blocks:
 
Reported: 2009-06-25 09:41 UTC by James Graham
Modified: 2010-10-04 14:49 UTC (History)
9 users (show)

See Also:


Attachments

Description James Graham 2009-06-25 09:41:46 UTC
It seems reasonable to allow tables and figures to have multiple paragraphs or lists in their captions. Therefore we should not be over restrictive and should allow flow content in table and figure captioning elements.
Comment 1 Olivier Gendrin 2009-06-25 13:48:38 UTC
But not allow an other <figure><legend> or <caption> to be nested.
Comment 2 Maciej Stachowiak 2010-03-14 14:48:19 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, 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

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
Comment 3 Leif Halvard Silli 2010-03-14 15:13:13 UTC
This bug is directly related to how Issue 32, table summaries, is solved.

Here is a list of all the proposed solutions to Issue 32:

http://www.w3.org/html/wg/wiki/ChangeProposals/comparsionSummarySolutions

My own change proposal (which you find a link to on the above page) says that block elements are disallowed inside <caption>, unless they are placed inside a <tableinfo> element. 

The purpose of the <tableinfo> element is so that it it shall be possible to separate the table caption from other info. The <tableinfo> element is avaiable to all media groups.

If you consider HTML4, and the interpretations of HTML4 (such as the the one found in the WCAG2 techniques  H39 and H73, then it is clear that one important reason for the @summary attribute is to not mix such information with the caption. (That is: The point is not necessarily to avoid that sighted users read "unecessary info", but to ensure that the caption is a caption and not a shortstory.)

I do not support that <caption> shall be permitted to have table information other than the caption, unless we have a programmatically determined way to separate the table caption from the table info.

I have voiced this kind of critisism against Ian's solution to allow paragraphs etc inside <caption> since day one.

I am not certain that <tableinfo> can solve the issue of separating the table caption from the table information in a satisfying way. But if it can't, then certainly dropping block elements directly inside can't solve it either. In which case we should simply go back to the HTML4 rule, which forbids block elements inside <caption>.

Please also note that <figure> provides all the necessary means to associate table information with the table. Something like this should be enough:

<figure>
<p>Table info</p>
<table><caption>caption</caption>
...
</table>
</figure>

PS: It is possible that some of the things I said above represents separate bugs that I should have opened ... Please feel free to suggest any ... 
Comment 4 Leif Halvard Silli 2010-03-14 15:14:59 UTC
This bug relates to table summaries. Issue 32.
Comment 5 Maciej Stachowiak 2010-03-14 15:31:55 UTC
I don't understand why this was reopened. The <caption> element was in fact changed to allow any flow content. Are you saying that it shouldn't allow flow content? Or do you think the change was wrong in some way?
Comment 6 Leif Halvard Silli 2010-03-14 15:44:46 UTC
(In reply to comment #5)
> I don't understand why this was reopened. The <caption> element was in fact
> changed to allow any flow content. Are you saying that it shouldn't allow flow
> content? Or do you think the change was wrong in some way?

If we allow <caption> to contain non-caption content, then it isn't a caption anymore. I have protested against Ian's permision to have non-caption content inside the <caption> since day one. The purpose of the caption is to idenify the table. Ian's caption example in the draft shows that the only way to discern between what is the identifying part of the <caption> from the "table information part" of the <caption>, is to perform a heuristic analysis.

Ian's solution to allow block elements inside <caption> came about as a reaction to the summary discussion.  I challenged him to say that if he remove @summary, then he must provide something else. And he provided this. So there is a very direct link between @sumamry and <caption>.

I don't understand the difference between your last two questions. But yes, I say that <caption> should not allow flow content. A <tableinfo> element would be a little bit like the <object> element: It would be a inline element which allows block elements inside.

(I say 'block' instead of 'flow', because I have a very blurred picture of what 'flow' means, in HTML5 sense.)
Comment 7 James Graham 2010-03-15 10:53:45 UTC
As the original reporter, I don't think this issue is substantially related to the @summary issue. In particular I feel that authors should have the freedom to have multiple paragraphs, lists, etc in captions for whatever purpose they like. I am quite happy to close this issue. I have no idea what problems would be solved by introducting a <tableinfo> element but I do know that it would be substantial additional complexity and that authors would typically get it wrong.
Comment 8 Leif Halvard Silli 2010-03-15 11:39:51 UTC
You may be the original openering of this bug. But Ian already in February 2009 responded to me:

>> As long as <caption> is strictly intended as a <table> title, there is 
>> need for another place to place other metadata that is directly linked 
>> to the table. Well, one method is perhaps to place <table>s in <figure>.
>
>I've clarified that the <caption> is not limited to the title, and 
>included an example of this.

See http://lists.w3.org/Archives/Public/public-html/2009Feb/0601

So Ian at least understand how these things are related. :-)
Comment 9 Laura Carlson 2010-03-15 11:42:54 UTC
Janina is proposing separate accessibility task force teleconference(s) to resolve possible misunderstandings regarding table summary. 
http://www.w3.org/2010/03/11-html-wg-minutes.html#item10

Perhaps this bug could be part of that effort.
Comment 10 Laura Carlson 2010-03-15 11:44:19 UTC
Janina is proposing separate accessibility task force teleconference(s) to resolve possible misunderstandings regarding table summary. 
http://www.w3.org/2010/03/11-html-wg-minutes.html#item10

Perhaps this bug could be part of that effort.
Comment 11 Leif Halvard Silli 2010-03-15 11:54:10 UTC
Discussed in February 2009: The need to separate table title from table info data. Here is Ian's reply:

http://lists.w3.org/Archives/Public/public-html/2009Feb/0690

On Tue, 24 Feb 2009, Leif Halvard Silli wrote:
>> 
>> Explanation: One only needs to read the table instruction as long as one 
>> is unfamilar with the table. Once one is familar with the table (because 
>> one has gone through it in all directions oneself) one will not be so 
>> interested the overview anymore.
>> 
>> So, it is not that the caption becomes more important, perhaps, but the 
>> summary that becomes less important. (It could als also be the opposite 
>> though: As you becomes familiar with the table, you understand the 
>> overview better.)
>> 
>> This is also one reason that one needs to distinguish captioning content 
>> from summarising content. One must be able to know what one refers to.
>
>Why?
>
>Consider the example in the spec, with the table for dice. Why wouldn't a 
>user just learn to ignore the caption once they knew what it said, 
>skipping past it to the table content? How would the UI be any different 
>if the user agent knew that the table's name ended at one point and the 
>usage help started after that point? Surely the user would still just have 
>to hit the "advance to next block" key either
Comment 12 Maciej Stachowiak 2010-03-15 12:03:14 UTC
(In reply to comment #11)
> Discussed in February 2009: The need to separate table title from table info
> data. Here is Ian's reply:
> 
> http://lists.w3.org/Archives/Public/public-html/2009Feb/0690
> 
> On Tue, 24 Feb 2009, Leif Halvard Silli wrote:
> >> 
> >> Explanation: One only needs to read the table instruction as long as one 
> >> is unfamilar with the table. Once one is familar with the table (because 
> >> one has gone through it in all directions oneself) one will not be so 
> >> interested the overview anymore.
> >> 
> >> So, it is not that the caption becomes more important, perhaps, but the 
> >> summary that becomes less important. (It could als also be the opposite 
> >> though: As you becomes familiar with the table, you understand the 
> >> overview better.)
> >> 
> >> This is also one reason that one needs to distinguish captioning content 
> >> from summarising content. One must be able to know what one refers to.
> >
> >Why?
> >
> >Consider the example in the spec, with the table for dice. Why wouldn't a 
> >user just learn to ignore the caption once they knew what it said, 
> >skipping past it to the table content? How would the UI be any different 
> >if the user agent knew that the table's name ended at one point and the 
> >usage help started after that point? Surely the user would still just have 
> >to hit the "advance to next block" key either
> 

It seems to me that the request for a special element to set apart some or all of the caption is a wholly separate request from this bug.

The request in this bug was to allow <caption> to contain flow content instead of just phrasing content. The upshot of that is that <caption> is now allowed to contain block-level elements. It seems to me that we would not want to remove that capability even if we had a mechanism to structure the caption's contents.
 
Comment 13 James Graham 2010-03-15 12:07:35 UTC
Leif: I can't see anything in your pointers to suggest that Ian believes that whether or not captions should allow flow content is at all affected by the @summary discussion. In any case I am not Ian and I do not believe there is any substantial relationship there. 

In any case if you would like to revert this change to the spec for some reason, I would prefer that you open a new bug setting out the rationale for restricting the content in <caption> and CC me. I don't know what the official protocol is here however.
Comment 14 Leif Halvard Silli 2010-03-15 12:19:22 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > Discussed in February 2009: The need to separate table title from table info

> 
> It seems to me that the request for a special element to set apart some or all
> of the caption is a wholly separate request from this bug.
> 
> The request in this bug was to allow <caption> to contain flow content instead
> of just phrasing content. The upshot of that is that <caption> is now allowed
> to contain block-level elements. It seems to me that we would not want to
> remove that capability even if we had a mechanism to structure the caption's
> contents.

Firstly: Ian has never commented this bug. Have you thought abvout why? I think it is because he had already allowed what James asked for when James filed this bug. (Compare the dates.). From that point of view, James's bug report may have been invalid. I don't know why James filed it - perhaps because Ian's change wasn't reflected in Validator.nu? I don't know. But since he has filed a bug suggesting that <caption> should allow flow-content, it should not be necessary to file a separate bug saying that it should not.

The points I want to make are: 

a) the content model of <caption> is not solved until @summary is solved. This has been clear from the very start, when Ian started to allow any kind of table info inside <caption>. (I say "any kind" in the sense "not only summaries for non-visual media") 

b) <caption> has a role of its own. It is for table identification. At least so it is in HTML4. We should be absolutely certain about the accessibility story before watering out its role. We would not allow flow content inside <h1>. So why inside <caption>?

c) <tableinfo> is just *one* possible solution to the problem - it is as solution *if* flow content should go into <caption> - if there are enough benefits for something like that.

Finally, may I ask: What is the justification for allowing flow content inside <caption>?  James did not provide any. What is your justification, for example? 
Comment 15 Leif Halvard Silli 2010-03-15 12:24:49 UTC
(In reply to comment #12)

I will also note that in HTML4, the following is - literally - already allowed:

<caption>Table 1. <object><ol><li>item 1<li>item 2</ol></object></caption>

So, we already more ore less have a table info element. And we already (in HTML4)  *can* separate the table caption from other info, by using <object>.  (HTML5 introduces som restrictions on <object> ... requirement to use type="" or data="", which HTML4 did not have - well that is another issue.)
Comment 16 Leif Halvard Silli 2010-03-15 12:27:41 UTC
(In reply to comment #13)
> Leif: I can't see anything in your pointers to suggest that Ian believes that
> whether or not captions should allow flow content is at all affected by the
> @summary discussion.

No, I probaly didn't understand what he said, right? You can just go back and read the exhanges between me and Ian - you will find a lot of reference to the role of <caption> in most all of them.

> In any case I am not Ian and I do not believe there is any
> substantial relationship there. 
> 
> In any case if you would like to revert this change to the spec for some
> reason, I would prefer that you open a new bug setting out the rationale for
> restricting the content in <caption> and CC me. I don't know what the official
> protocol is here however.

Well, you have file a bug saying that flow content should be allowed. Shouldn't you then give a rationale for that?

Comment 17 James Graham 2010-03-15 12:39:20 UTC
The rationale was basically that only allowing phrasing content in captions is an arbitrary restriction that has no obvious benefits. There are also use cases for allowing flow content children; for example scientific papers often have tables with rather long captions that provide detail about the interpretation of data in the table. Such captions benefit from additional structure enabled by allowing flow content in captions.
Comment 18 Ian 'Hixie' Hickson 2010-04-01 02:41:01 UTC
Reresolving as FIXED since that was the resolution of this bug. Do not reopen this bug for tangential issues, please file new separate bugs for each issue.
Comment 19 Michael Cooper 2010-09-02 13:43:40 UTC
Bug triage sub-team has verified this is fixed.