(In reply to comment #0)
>
> In addition, the use of HTML tables in figure elements is being discussed in
> another bug. It is against established practice and procedure to use data
> tables in figures. And since the only type of table supported in HTML5 is a
> data table, it's erroneous to use the table in a figure element.

It seems like the evidence of that bug was that it's quite common to have tables in something label as a Figure. It also seemed to be quite common to give a table figure-like presentation (matching the semantics of the HTML <figure> element, but separately numbed as Tables instead of Figures. And finally, other markup languages such as DocBook specifically seem to allow tables in their figure element. Your counterpoint that tables in figures should first be converted into an image seems poorly founded, and as far as I can tell, no one else agrees that it is ever good practice to convert a table to an image in HTML.

It seems misleading to reference the original premise of the bug as if it's established fact, without citing any of that follow-up discussion.

(In reply to comment #1)
> (In reply to comment #0)
> >
> > In addition, the use of HTML tables in figure elements is being discussed in
> > another bug. It is against established practice and procedure to use data
> > tables in figures. And since the only type of table supported in HTML5 is a
> > data table, it's erroneous to use the table in a figure element.
> 
> It seems like the evidence of that bug was that it's quite common to have
> tables in something label as a Figure. It also seemed to be quite common to
> give a table figure-like presentation (matching the semantics of the HTML
> <figure> element, but separately numbed as Tables instead of Figures. And
> finally, other markup languages such as DocBook specifically seem to allow
> tables in their figure element. Your counterpoint that tables in figures should
> first be converted into an image seems poorly founded, and as far as I can
> tell, no one else agrees that it is ever good practice to convert a table to an
> image in HTML.
> 
> It seems misleading to reference the original premise of the bug as if it's
> established fact, without citing any of that follow-up discussion.
> 

No, it's not common. And is typically against typographical style guides in print publications. Regardless, this section is Primer material, not specification material.

Link to previous discussions on HTML tables in figure elements:

Bug; http://www.w3.org/Bugs/Public/show_bug.cgi?id=8404

(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > >
> > > In addition, the use of HTML tables in figure elements is being discussed in
> > > another bug. It is against established practice and procedure to use data
> > > tables in figures. And since the only type of table supported in HTML5 is a
> > > data table, it's erroneous to use the table in a figure element.
> > 
> > It seems like the evidence of that bug was that it's quite common to have
> > tables in something label as a Figure. It also seemed to be quite common to
> > give a table figure-like presentation (matching the semantics of the HTML
> > <figure> element, but separately numbed as Tables instead of Figures. And
> > finally, other markup languages such as DocBook specifically seem to allow
> > tables in their figure element. Your counterpoint that tables in figures should
> > first be converted into an image seems poorly founded, and as far as I can
> > tell, no one else agrees that it is ever good practice to convert a table to an
> > image in HTML.
> > 
> > It seems misleading to reference the original premise of the bug as if it's
> > established fact, without citing any of that follow-up discussion.
> > 
> 
> No, it's not common. 

It seems like many examples were cited of tabels labeled as Figures, both online and in real-world books and papers. Including books written by you. I will grant it is a small fraction of figures, but it seems wrong to me to declare it categorically incorrect. Furthermore, the case has been made that a floating numbered table has the semantics of a <figure> in general, even though often (but not always) they are labeled distinctively and numbered separately from Figures proper.

I realize that you may ultimately disagree with these arguments, and where the preponderence of the evidence lies. It just seemed misleading to me to ignore the counter-arguments entirely and state your opinion as if it were undisputed fact.


> And is typically against typographical style guides in
> print publications. Regardless, this section is Primer material, not
> specification material.

I think it's totally appropriate for the HTML specification to include usage examples and advice, especially in cases where correct usage is tricky or where a particular use case is not directly served by a single specific markup feature.

I agree with you that a non-normative authoring guide of some sort is a good place for advice, but I disagree that it's categorically wrong to have it in the main spec as well.

By the way, earlier, you also said:

> This bug does not impact on the current discussions about the table summary
> attribute, within the HTML Accessibility task force.

But it seems this bug does impact that discussion, because the Change Proposal for the table-summary issue adds to and edits the section in question. Most of that Change Proposal would be invalidated if the section in question were to be removed.

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > (In reply to comment #0)
> > > >
> > > > In addition, the use of HTML tables in figure elements is being discussed in
> > > > another bug. It is against established practice and procedure to use data
> > > > tables in figures. And since the only type of table supported in HTML5 is a
> > > > data table, it's erroneous to use the table in a figure element.
> > > 
> > > It seems like the evidence of that bug was that it's quite common to have
> > > tables in something label as a Figure. It also seemed to be quite common to
> > > give a table figure-like presentation (matching the semantics of the HTML
> > > <figure> element, but separately numbed as Tables instead of Figures. And
> > > finally, other markup languages such as DocBook specifically seem to allow
> > > tables in their figure element. Your counterpoint that tables in figures should
> > > first be converted into an image seems poorly founded, and as far as I can
> > > tell, no one else agrees that it is ever good practice to convert a table to an
> > > image in HTML.
> > > 
> > > It seems misleading to reference the original premise of the bug as if it's
> > > established fact, without citing any of that follow-up discussion.
> > > 
> > 
> > No, it's not common. 
> 
> It seems like many examples were cited of tabels labeled as Figures, both
> online and in real-world books and papers. Including books written by you. I
> will grant it is a small fraction of figures, but it seems wrong to me to
> declare it categorically incorrect. Furthermore, the case has been made that a
> floating numbered table has the semantics of a <figure> in general, even though
> often (but not always) they are labeled distinctively and numbered separately
> from Figures proper.
> 

This is incidental to this bug, and I did add a link to the other discussion to this list, if someone wanted to pursue it separately. 

> I realize that you may ultimately disagree with these arguments, and where the
> preponderence of the evidence lies. It just seemed misleading to me to ignore
> the counter-arguments entirely and state your opinion as if it were undisputed
> fact.
> 
> 
> > And is typically against typographical style guides in
> > print publications. Regardless, this section is Primer material, not
> > specification material.
> 
> I think it's totally appropriate for the HTML specification to include usage
> examples and advice, especially in cases where correct usage is tricky or where
> a particular use case is not directly served by a single specific markup
> feature.
> 
> I agree with you that a non-normative authoring guide of some sort is a good
> place for advice, but I disagree that it's categorically wrong to have it in
> the main spec as well.
> 
> By the way, earlier, you also said:
> 
> > This bug does not impact on the current discussions about the table summary
> > attribute, within the HTML Accessibility task force.
> 
> But it seems this bug does impact that discussion, because the Change Proposal
> for the table-summary issue adds to and edits the section in question. Most of
> that Change Proposal would be invalidated if the section in question were to be
> removed.
> 

Actually, no there is very little impact on the summary change.

The summary change removed summary from being obsolete but conforming, added a new attribute, a new explanation for what summary is, and only incidentally suggested a modification to the long example given.

The only impact would be if the section describing how to describe table structure is moved to a primer, the option for using summary would also be moved to a Primer. But the meat of the change, the status of summary, the addition or orientation, the API, the descriptive text, and conformance guidelines for user agents all belong in the spec.

It's only item 1.3 on the change proposal, "minor edits in the descriptions of the alternative mechanisms to summary" that would be impacted, and only that the edits would occur in material in a Primer, rather than in the spec.

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: Given how bad the current situation is regarding authors providing explanatory text for tables, I think we should given them as much information as possible, in as many places as possible. We do AT users a disservice if we pretend that their needs aren't important enough to include advice on how to best serve them in the spec.

(In reply to comment #5)
> 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: Given how bad the current situation is regarding authors providing
> explanatory text for tables, I think we should given them as much information
> as possible, in as many places as possible. We do AT users a disservice if we
> pretend that their needs aren't important enough to include advice on how to
> best serve them in the spec.
> 

More text will not make tables any clearer, or ensure people use the element in the proper way. What's needed is a good, clean, succinct example, with a clear explanation of each element of the table, including the summary attribute. 

A good explanation of how to use summary properly would do wonders for the table's accessibility. A meandering description of how people can use anything _but_ summary, is only going to cause conflict with previous versions of the markup, with existing screenreader implementations, and runs counter to the expressed interest and wishes of every accessibility person on the HTML WG team -- and beyond.

The section needs re-written, but such is best left for a change proposal.

I want this one escalated to an issue. Use the original title and comment as the body of the issue. Thanks.

This has been escalated to a tracker issue:

http://www.w3.org/html/wg/tracker/issues/92

Per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html, the HTML A11Y TF does not plan to formally work on this issue at this time. This does not mean the TF has no interest in it, but does not have immediate plans to work on it. The TF may review the issue in the future.

Working Group Decision: http://lists.w3.org/Archives/Public/public-html/2011Mar/0244.html

I presume the change requested in comment 9 is:

---------------------
Move the text, starting with "There are a variety of ways..." and
ending just before "The summary attribute on table elements...", from
its current location to a new subsection placed after the current
"4.9.13 Examples" section.

In its place, at the end of the previous paragraph, place a sentence
explaining that guidance for this case can be found in the new
section, with a link to that section.
---------------------

Checked in as WHATWG revision r5978.
Check-in comment: apply wg decision
http://html5.org/tools/web-apps-tracker?from=5977&to=5978